It seems connecting an iPod Video to a Mac triggers the null
request check, resulting in a panic. Ignoring the error with
a bare return "fixes" it and allows the iPod to connect. This
isn't ideal though, because it could silently introduce bugs
on other targets.
The likely cause of this is the host sending control requests
too fast, or a driver problem (the Video uses the ARC driver,
which is still on the legacy interface), with multiple requests
getting queued at once. Since the USB core expects to deal with
only one request at a time, the second response trips the check.
Try to handle this situation a bit more gracefully by detecting
overlapped requests and returning a STALL to the host when it
occurs. At this point the USB stack is able to safely handle a
new request.
Link: https://forums.rockbox.org/index.php/topic,54414.0.html
Change-Id: I9a2b7e35620ff540ebdb39f81671377062a4917d
These are more efficient than separate pin/unpin calls because
pin count increment and decrement can be done cheaply when the
data pointer is known.
Secondly, pinned access can be made safe against preemption by
hardware interrupts or other CPU cores; buflib_get_data() can't.
This makes it more useful under different threading models and
for SMP targets; both of which are not particularly relevant to
Rockbox now, but might be in the future.
Change-Id: I09284251b83bbbc59ef88a494c8fda26a7f7ef26
This is intended for improving the effectiveness of tools like
ASAN when debugging memory errors in the sim. It's not meant to
be a serious allocator for hosted targets.
Enable it by changing the buflib backend in config.h.
Change-Id: I0cf23cefa47ee35dede7b49e0e5b72dac60e8d3e
To minimize code duplication between buflib backends move the
public part of the API to buflib.h. Also rewrote documentation
for the whole API.
Change-Id: I4d7ed6d02084d7130cb41511e63c25ec45b51703
Gate buflib_get_data() checking, debug printing, and buflib
integrity checks behind individual defines in buflib.h, and
turn them all off by default. If needed, they can be turned
on manually when compiling.
The buflib debug menu is only available if debug printing is
enabled, so after this commit it will no longer be included
in normal builds -- it isn't very useful to end users.
Change-Id: Iab25b7852bc7c5592ce04c9c45762046a87d5bc3
Removing the variable-length name in the middle of buflib metadata
makes it a lot easier to deal with.
Change-Id: I6eaf236c2285cae40fb6ff0fa5acf827972cdd8b
The CRC is a fairly useless safety check because we already
have specific checks to validate the metadata, and CRCs are
only verified before calling the move callback. Removing the
check should not significantly reduce buflib's robustness.
Change-Id: Ica99bd92fc514819b4fd9f359b4272e581020f75
Remove the name handling code, but leave the allocation structure
otherwise untouched; it's as if all callers provided a NULL name.
The public API still accepts names but names are no longer stored
or returned.
Change-Id: I6c4defcdfd255774f02030949a0fd731477e6a54
Naming your allocations is more of a debugging feature; it's a
bad idea to abuse this feature for storing some random string.
The font code does exactly that to remember the path used to
load a font, and it's the only code that uses buflib names in
this way.
Store the path inside the font allocation instead as a regular
char array. For simplicity it's MAX_PATH sized, so this'll use
a bit more memory than the buflib name method, maybe 1-2 KiB if
a few fonts are loaded.
Change-Id: Ie286a1a273d6477af9e5d3f76e0534b62f72e8f7
It's usually only called from init() in main.c, so this is safe.
There is one more call in system-dm320.c from system_init(), but
that's also "safe". I don't know if it's okay to call i2c_init()
twice, but presumably it works...
Change-Id: I9c1cd918d162d9955f7cf03209e836cbd5e30c57
On single-core targets, system_init() is only called from init()
in main.c, which is also INIT_ATTR, so this is safe.
Multi-core targets additionally call system_init() from cop_main(),
which isn't marked INIT_ATTR. I'm fairly certain that it would be
safe to add INIT_ATTR to cop_main() with a bit of refactoring, but
I don't have a way of testing it. So for now, leave INIT_ATTR off
for multi-core targets.
Change-Id: I8fe4358f975880ca317d46bda01d7d9db529d3e3
chunk_alloc allows arrays (or any data) to be allocated in smaller chunks
you have to save the indices..
variable data will have variable indices you need to
store these as [chunk_alloc] doesn't keep track
if you have a fixed size for each
alloc you can do indice / sizeof(data)
or index * sizeof(data) to convert
Lots of debug stuff still in and it needs optimization
User provides chunk_size and max_chunks
max_chunks * struct chunk will be allocated at start
with (1) chunk_size allocation initially
alloc_chunk() with size = 0 shrinks the last allocation to the size of the data used
add OOM checks on buflib_alloc -- oops
move bytes available to the header -- less memory per chunk & better alignment
keep track of the current in use chunk index -- should speed things up a bit
Now allows:
realloc chunk header
larger allocations than chunk size
reallocs smaller than existing will shrink the current array
rather than alloc a new and copy data
Comments welcome :)
Change-Id: I8ed170eef73da95da19430a80b32e5debf0c8276
Fixes a bug introduced by commit 5d0c382a59 that caused graphical
corruption on anti-aliased fonts.
Change-Id: I6052ca758382bd9a1154d2e2208dee633dd17715
Avoids a harmless out of bounds reads in ASAN that occurs with
malloc buflib. Code size and performance is similar.
Change-Id: I1c674d046b069e64ad8cb6941356f7c568a81e88
fiio m3k native is currently the only player with
defined buttons different from the standard
mapping.
This allows the user to use the keyremap plugin
to specify differing keymaps for their device in the locked state
Change-Id: Ie0b447bba0d5978e8d23fed423df30c794afc6f9
Add context flags to keyremap
CONTEXT_LOCKED
CONTEXT_REMOTE
CONTEXT_REMOTE_LOCKED
--CONTEXT_PLUGIN-- Removed -- Plugins need a custom action list
supplied and a method of supplying them
Change-Id: I5201d275ad0ab6130c2d05d5afb0c450f5c1746c
Add INIT_ATTR to some low-hanging fruit in the X1000 code:
GPIO init, GPIO initial state tables, clock init, and DMA init.
Change-Id: Ia02b20945da1bbed103e2e01eaf60553eb5f72d4
Enable INIT_ATTR support in config.h. Load init code to the
codec buffer, following the convention used by other targets
that support INIT_ATTR.
Change-Id: I8935fbaa100f0013bb328d71c4a49ec2ffafd003
check for invalid userdata by assigning the address of 'invalid_userdata'
this cleans up the functions a bit and removes some extra conditionals
Change-Id: Ic5e13147796e629010a1436eb60042f6550a959c
The font code expects the full path to be stored in the
buflib alloc so this breaks eg. saving the glyph cache.
This reverts commit 2b4a4070c9.
Change-Id: I53844c39b34b14f7c8e5999825c1d012fa3f74dc
As those form factors are typically not runtime removable and as such
expect to always being powered up.
This is an experimental change, and we might revert it if it doens't help
Change-Id: I61187f297866f64589a546352828a0ff8169fa30
HAVE_MULTIVOLUME is a subset of HAVE_MULTIDRIVE
in normal circumstances they are interchangable
but when the internal drive is not found the assumption falls apart
at the moment most of the bootloader are less selective about what drives/volumes
they will mount therefore the volume might not match between what the bootloader
returns for multiboot and what the firmware sees
updating bootloaders will fix this but it should probably be made more robust
at the same time
Change-Id: I93acd4a539894f093211b74b030df3b2c6a0aa11
This is a small wrapper function which calls other init code
and is only called from init code; mark it INIT_ATTR to fix
the unsafe reference.
Change-Id: I5525461e9fd63955c6396d3151d209c457b3d798
Avoid startup code clashing with the .init section, which is
by convention used for INIT_ATTR code that can be discarded
after app initialization.
Change-Id: Id59b7618ef41e65c33fc0f133644e07555a913eb
Get the linker to automatically assign load addresses for
the .iram and .tcsm sections. Taken from the i.MX31 linker
script.
Change-Id: Ic03d577d8690c777726daf373a3289316639bfb9
This flash chip is found on some Surfans F20 units. For our purposes
it's the same as the GD5F1GA4xExx so just #define an alias instead of
adding a whole new chip struct.
Change-Id: I2f4c4fbf1faf3a0c7a1503534430afacbddc426e
