Several places in the codebase implemented an ad-hoc form of pinning;
they can be converted to use buflib pinning instead.
Change-Id: I4450be007e80f6c9cc9f56c2929fa4b9b85ebff3
When I converted all the clipping checks in 4b8fe8acd1 I messed
up the hline and vline checks. This produced some weird panics on
the Shanling Q1, probably memory corruption -- but somehow it got
past AddressSanitizer. Go figure.
Change-Id: I84820c23a491d422218c72d2d5e199e2fc7def0f
allow buflib_free to check for invalid or already freed handles
within the function -- remove all the invalid handle guards thru core_free
Change-Id: Ibdcbc82760fc93b674c42283fca420d94907df8e
Simplify update_viewport() by calling update_viewport_rect().
The resulting LCD driver calls are the same either way and
for some reason, update_viewport() didn't handle non-default
stride viewports correctly.
Change-Id: Ic34d3d40e4f758db897cb3944d9d7475bbdb4d2c
clear_display() on grayscale LCDs sets the number of scrolling
lines to 0 but that's wrong, the scollers need to be shut down
first. Call scroll_stop() for that, as is done on color LCDs.
Change-Id: I75fb6839ed04f6fe1eb8e2855c8db820fcedddb8
There's no need to generate separate copies of these functions
for main and remote LCDs; we can just pass the viewport directly.
Change-Id: I20aa04a58d327b479a942708e161068bd6a3357b
Only the scroll engine calls this, but it's easily replaced
by the return value of set_viewport_ex().
Change-Id: I2e2c8234f969bc07c9ff7d864e58551115175e26
All three functions are nearly identical regardless of the
LCD pixel format. Consolidate them into a generic version in
lcd-bitmap-common.c.
Change-Id: Iab13429ea27ea2b0150b9004535bd27d4a4121a0
In-viewport clipping code is duplicated across 8 files, making
it a chore to change anything related to clipping; refactor the
clipping logic into dedicated functions.
Change-Id: I4ab20bb3c59b0406098d0c7d23833025f17a320a
The get_address_fn implementations for some remote LCDs were
checking LCD_STRIDEFORMAT unconditionally, but that macro is
only valid for the main LCD. The remote LCD code only supports
horizontal strides, so when compiling for a remote LCD, force
the use of horizontal stride addressing.
This fixes a buffer overflow and out of bounds write that occurs
with the M:Robe 500 remote LCD. (Tested with sim + ASan only.)
Change-Id: I99c6aa11d38f5105b096fc448948b9ec1b27dfe6
Instead of putting "#ifdef LCD_STRIDEFORMAT" at every usage of the
macro it's simpler to have config.h define LCD_STRIDEFORMAT to the
default of horizontal stride when the target leaves it unspecified.
Change-Id: Ib187012aad65ac678dbd837b1464a83bad722411
This was only enabled for the mrobe500 and sansaconnect targets.
Most targets are therefore running without this "safety" measure,
and presumably we'd have noticed long ago if there was a problem.
So in all likelihood this is just a bunch of dead code that we
don't need to carry around.
Change-Id: I7d27701a38b1c2a985ee73fa6f277ad215d8d385
This makes status by event debounce status changes over
a 200ms period, which is what polling was already using.
This is helpful on targets where events are excessively
noisy and generate a lot of transitions during insertion
and extraction.
Change-Id: I0eae2cca93aaa865e33c94a1318c27e91c7f7c4b
An allocation is pinned by calling buflib_pin() to up its pin count.
The pin count is like a reference count: when above 0, buflib won't
move the allocation and won't call its move callbacks. This makes it
safe to hold the pointer returned by buflib_get_data() across yields
or allocations.
Note that pinned allocations can still shrink because there are some
use cases where this would be valid, if buffer users coordinate with
the shrink callback.
Change-Id: I0d0c2a8ac7d891d3ad6b3d0eb80c5b5a1b4b9a9d
Since allocation is infrequent in Rockbox enabling the extra
checks to catch memory corruption is probably worth the time
and code size cost.
Change-Id: If0d701421054328c57b69e4d0af30759d799d158
Using a length 1 char array to point to the name buffer triggers
a -Warray-bounds warning from GCC when fortified strcpy is used.
This type of construct isn't safe in general -- if the compiler
makes assumptions based on the array bound it can create subtle
bugs when accessing the array out of bounds.
Instead, add a function get_block_name() which returns a pointer
to the name field by casting. This suppresses the warning and it
should be a bit more portable.
Change-Id: I25d4f46f799022ad0ec23bef0218f7595cc741ea
These don't have any users and there is already another way to
print blocks (which is actually used by the debug menu).
Change-Id: Ic6a4f874c6499c42bc046e8af3e4aaddc9e68276
If we don't check or generate CRCs then the CRC field can be left
out of the header, which reduces buflib overhead slightly.
Change-Id: I08b4cf77a701d8f6da453e019a0373d858a79ae4
Move CRC checking and updating behind a paranoia bit, like the
other checks, so it can be enabled and disabled.
Change-Id: Icff66c842cbd5af2d99aa91e6c40447a64e6d4b2
Handle checks ensure that the data in the handle table points
within buflib memory and checks handle entry pointers in block
headers before dereferencing them.
Change-Id: Ic16f1b81c1a0ea63c0e7f48d87938293b75c2419
Tighten up checking by adding length checks to loops which
ensure the iteration stays within bounds. Check is disabled
by default and can be enabled using a BUFLIB_PARANOIA bit.
Change-Id: I35e911e0878797d5ebf732be548ca659f6910fe0
Buflib is written with a lot of hardcoded offsets to header fields,
arbitrary pointer arithmetic, and similar but not quite duplicated
code, making maintenance a nightmare.
Most of the pointer arithmetic involving header fields is replaced
by indexing from two well-defined pointers, the block start and end
pointers. The start pointer points to the first header field, and
he end pointer is one past the end of the header.
Hardcoded field indices are replaced by two enums. Forward indices
(fidx_XXX) are used to access fields from a block start pointer and
negated backward indices (-bidx_XXX) are used to index from a block
end pointer. There is no overlap between the indices because of the
variable length name field in the middle of the header. The length
of the fixed fields in the block header is now a #define'd constant
rather than being open coded.
There is now a function to acquire the block end pointer from the
user data pointer (ie. the pointer stored in the handle table). The
old code was not consistent in this; some functions would handle a
non-aligned user pointer, which may occur as a result of shrinking,
while other uses just assumed the user pointer was aligned.
Block CRC calculations have also been factored out to a function
that accepts block start and end pointers.
Change-Id: I6a7e8a8c58aec6c6eaf0e5021400032d8e5f841e
The block header has a variable length due to the embedded name.
The name length is stored at the back of the header after the
name, in order to allow finding the start of the header if only
the user data pointer is known (eg. from the handle table).
The name length is actually not interesting in itself; storing
the total length of the block header instead is marginally more
efficient, saving one addition in handle_to_block().
Instead the extra arithmetic must be done by buflib_get_name(),
which is a much less common operation than handle_to_block().
Change-Id: Ia339a1d2f556a11a49deae0871203e70548bd234
The way it iterated over the handle table is unsafe if *every*
handle is free, leading to an out of bounds access.
This is a contrived example, but the bug can be triggered by
making several allocations, freeing them out of order so that
the handle table remains uncompacted, and then triggering a
compaction using buflib_alloc_maximum().
Change-Id: I879e2f0b223e6ca596769610ac46f4edf1107f5c
It isn't obvious why the "handle->val = -1" at the end of handle_alloc
is needed so add an explanatory comment. But "handle->val = 1" prior to
calling handle_free is simply a dead store.
Change-Id: I9ab4e96e87e940cfd1a2ed56f089287821669c73
Since we're scanning the handle table for the first free slot,
we know none of the scanned slots are free. Use that knowledge
to update first_free_handle and avoid rescanning filled slots
again when the next handle is allocated.
Change-Id: I457372f66c231168cfffa7e905d1e9fb80002f5f
Use the standard IS_ALIGNED macro and check alignment against
sizeof(buflib_data), as it can be greater than 4 bytes if we're
on a 64-bit platform (eg. simulator).
Change-Id: I15110937d1f2978e733d169050de9531fe218214
Exiting the loop implies next_block == block, so remove that check.
The check ret < block is false only if block is the first block, which
can be checked before the loop, saving a few cycles in that case.
Change-Id: Id493b5259a23a35a70b09dfe4bc4eacaf420760c
This is another chip used in newer Surfans F20 units. Like the
Winbond chip, it's a 1-gigabit chip with on-die ECC. Notably it
has an expanded 128-byte OOB area that is only accessible when
on-die ECC is disabled.
Change-Id: I2203918a15c914097f5a6bbe4afa2d3a60dc67f7
This chip is apparently used in some Surfans F20 units, and has
the same geometry as the ATO25D1GA. It has an on-die ECC engine.
Change-Id: I4d37a2455620ce43cec0a9bcbb32c776d1a8eba1
Decouple chip IDs from chips, and allow the chip ID table to list
which read ID method should be used. Use a safe controller setup
during identification instead of using the first chip's parameters.
Change-Id: Ia725959c31b2838f4a3a30e5bb7fa6652ef377ed
There is actually no need to parameterize most commands with row
or column cycles, usually the opcode and row/column address width
are linked. When this is not the case we can use raw SFC commands
or define new macros.
Change-Id: I22459d732dc01012e6a8ae026c4fb85495d372b4
Using predefined commands is too inflexible so allow the chip data
to specify I/O commands directly.
Change-Id: Ie8f943914da4b8299678a59b1063c4c6d226e83e
The iPod classic/6G comes with 64MB of RAM. This
brings it in line with the plugin buffer size of some
other targets that have the same amount of RAM,
such as the Fiio M3K, and enables the use of
PictureFlow for users with very large databases.
Change-Id: I1ccae1cacda7a243139f4887f54bd35cc8e501cf
Use per-function sections to avoid linking in x1000_boot_linux()
on normal builds, which prevents link errors due to referencing
a non-existent usb_close().
Change-Id: Ied7b233603c49fc856db8445e368675b181e2f1f
Many SPI NAND flash chips have on-die ECC engines that report
ECC status via the status feature register. This code handles
the common case where ECC status is reported with 2 bits: one
bit to indicate if flips were detected & corrected, and another
bit to indicate an uncorrectable error.
Change-Id: I5d587cd960ca9d090d2629e890724a6bc411e70c
