Confirmed on iFlash-modded ipodvideo, USB mass storage connections
frequently fail with bus resets during mount on macOS, and trigger
"reset high-speed USB device" errors on Linux during sequential
reads.
The root cause is: storage_read_sectors() calls yield() via
ata_wait_intrq(), which switches to the main thread running
handle_usb_events() loop. This calls send_event(GUI_EVENT_ACTIONUPDATE),
triggering LCD redraw that takes approximately 110ms. This stalls the
ATA DMA completion, causing the USB bulk transfer to time out from the
host's perspective.
This commit removes the yield to prevent the reading thread from being
preempted by the lengthy LCD redraw during DMA completion.
This also improves sequential read throughput from ~13MB/s to ~18MB/s.
Change-Id: Ia552f97aa0169c93c4f21e250d13dc3a626661d4
* Terminating record of the max unicode codepoint (0x10ffff)
* Add in Arabic diacritic marks in the 0x10efa..10efff range
This is currently disasbled due to it effectively doubling the
size of our diacritic table. The diacritics added are unlikely
to be seen in practice as they are used only in some formal
Quaranic contexts. If we identify other diacritic marks above
0xffff, then we can turn this code on.
Change-Id: I50c2eace18c70be6fe7199fccab190e7da401089
* When the codepoint > 0xffff, don't overflow past the end
of our diacritic table (Fixed by William Wilgus)
* Truncation of the 'info' field causes the RTL flag to be dropped
(RTL flag is b15 but we truncate it into an 8-bit variable)
Both bugs introduced in a2c10f6189 (September 2025)
Change-Id: Id5425606f2cf91d3b3a81f4b67a97d546de81e41
These files have been missing copyright headers since
they were added in comit d0b72e2590 ("GSoC/Buflib:
Add buflib memory alocator to the core.").
Thomas Martitz seems to be the original author, which
is documented in the commit metadata and backed up by
emails from the rockbox-dev archive, for example [1].
[1]: https://www.rockbox.org/mail/archive/rockbox-dev-archive-2011-08/0000.shtml
Change-Id: Id1a3abd4975674ffbc6f7e9123ee57d49bcaa38e
Move the rather large block of code that's been copied
in three separate linker scripts into the CPU header.
Change-Id: I9f38e4901fa4ff699f00d97064a9cdaf7cfd6aab
Move the definition of NOCACHE_BASE to the CPU headers
instead of having them copy-and-pasted in a few places.
Change-Id: Ibbab27a5a07906d46dbd4dd9065f2238bc885d6b
Mostly motivated by PP needing CACHEALIGN_SIZE in linker
scripts, which can't include system.h, so move these to
cpu.h instead. Also gets rid of the default 32 byte line
size that was used if the target didn't define alignment
itself. RK24xx, DM320, and JZ4740 were missing this but
have been confirmed (from datasheets) to use 32-byte cache
lines.
Add checks to make sure the macros are appropriately
(un)defined based on the HAVE_CPU_CACHE_ALIGN define,
and make sure their values are consistent when they
are defined.
Disable HAVE_CPU_CACHE_ALIGN for hosted targets since it
arguably doesn't matter if there's a cache, if we aren't
responsible for cache maintenance.
A few files in rbcodec use CACHEALIGN_SIZE, but these
can be converted to MEM_ALIGN_SIZE, which is identical
to CACHEALIGN_SIZE if the latter is defined. On other
targets, it aligns to at least sizeof(intptr_t).
Change-Id: If8cf8f6ec327dc3732f4cd5022a858546b9e63d6
The JZ47xx and S5L87xx processor families used their own
special defines (__ASSEMBLY__ and ASM respectively) in
their CPU headers to check if they were included from an
assembly source file.
For GCC the standard seems to be __ASSEMBLER__, so check
for that instead and remove the non-standard symbols.
Being more consistent across platforms makes it easier to
include cpu.h from cross-platform files (eg. plugin.lds).
Change-Id: I282930cad34e1a2ff18166f3b4338548b34f4a49
Remove now-unused stuff related to the PNX0101 processor,
which was missed during the removal of the IFP-7xx port.
Change-Id: I5ff248b3e83cb67a357743130c3e51ed84a720e5
These fields are defined by FAT32 itself, and are specified as 32-bit
values. So switch them from sector_t to simple uint32_t.
Change-Id: I98afecfbe1f8a1b83fbdd4ec3fea016b8e0b985d
According to the datasheet, the PLL fractional mode is
apparently not supported in the medium VCO range.
The LCD isn't picky about front/back porch settings so
modify these to get a dot clock close to 6 MHz (within
~0.1% error).
Change-Id: I51647534db8c2b261391864db9262a0b04548e6d
* pcm_play_data
* pcm_play_stop
* pcm_play_stop_int
* pcm_is_playing
* pcm_set_frequency
* pcm_get_frequency
* pcm_apply_settings
Now, the only user of these functions are the mixer and recording layers
that provide a higher-level API to plugins and the main [playback]
application.
Outside of the PCM core, pcm_apply_settings() was only used immediately
following a call to mixer_set_frequency(), so the latter function
now always calls the former.
Change-Id: I61c3144dc156b9de9b7963160b525c6d10c6ad4b
Playback is implemented using a target-specific PCM layer,
using the STM32H7 SAI & DMA registers directly. There are
a number of pop/click issues:
1. Slight click when powering up the amplifiers
2. Click when starting and stopping playback
3. Popping when changing playback frequency
4. Popping when shutting down
It should be possible to eliminate or at least mitigate
(2) to (4) in software, but (1) happens as a result of
powering on the amplifiers while everything is muted so
might be unavoidable.
Change-Id: I398b66596176fb2341beb7deba7bf6f4f3fb82b3
move target-specific pcm operations into builtin_pcm_sink.
in subsequent commits, another pcm_sink is added, and it becomes
possible to switch between them.
Change-Id: I8f8b9661e01d6e6472f34224ddc3760856778457
Though the rev1 hardware is capable of recording from a
headset mic, this feature seems likely to be dropped on
future hardware revisions, and I don't see much point to
implementing it now.
Change-Id: I77e403bdd1ca53f9018835d3c3042dc86ee0f8f3
Remove the generic TLV320AIC3104 codec header. The codec
is sufficiently complex that a one-size-fits-all driver
isn't really feasible, eg. due to different clocking and
output configurations.
It's easier for targets to have their own audio headers
tailored to their use case than a generic header with
lots of ifdefs.
Change-Id: I63d92d57c28ddd7da7aa3174bd583d8afb1aa56d
Firmware didn't start sleep countdown if
1. Display was already dimmed
2. Fade out timer was set
You can reproduce this by:
1. Set fade out timer. For example, 500ms
2. Wait till display will be dimmed and go to sleep
3. Switch hold ON or plug headphones
Change-Id: I27ca857aa8db4551bd9caad4815cd73a64bf6185
According to RM0433 the DCTRL register needs to be written
after DLENR and DTIMER. This is respected for data transfer
commands but not for non-data commands. Nothing bad seems
to be happening because of this, but it seems wise to rectify
the issue.
Change-Id: I55d8f2c1994bff747e5978847fda57445f001b02
According to RM0433 consecutive writes to the CLKCR and CMDR
registers must be separated by at least 7 AHB clock cycles.
The initialization code didn't respect this and it seemed to
be causing a nasty bug, where the SDMMC bus clock got stuck
at 400 KHz in hardware. Despite the CLKCR register reading
back the correct value, it could not be written with a new
value even in the debugger; resetting the peripheral was the
only way out of this state.
Adding some dummy register reads after any access to CLKCR
should insert the necessary number of wait states. Without
the fix, the SDMMC clock gets stuck about 12% of the time.
With this fix, the clock always initializes correctly.
Change-Id: Iba85b8e1e3c60992ddc42fb4c1e66c37941ed617
If not, these devices will charge very slowly (0.07A) when plugged into a wall plug, and will all discharge slowly when docked & playing music.
Enabling this option (that is already enabled by default on some other devices like erosq and fiio m3k) make them pull between 0.20 and 0.30. They charge faster, just as fast as on Stock OS, and won't discharge when playing music while docked.
Change-Id: I90a59caaca463354772b1869f7333d8efce4f117
Replace the factor calculation from pcm-alsa.c, which
is based on signal *power* ratios, with the fp_factor()
calculation that is based on amplitude ratios. Because
power changes with the square of amplitude, this means
1 dB of power equals 2 dB of amplitude.
Rockbox's volume controls are amplitude-based, so the
smallest step size for pcm-alsa was effectively 2 dB.
The fp_factor() method supports 0.1 dB steps and is a
bit more accurate besides, so it's simply superior in
all respects (aside from taking a few more CPU cycles
to calculate the factor).
Change-Id: I34d143c225d8b5e085cde299fc405f83c13314bf
Disabling an IRQ in the NVIC may not take effect right away;
if the IRQ is being disabled to implement a critical section
it's necessary to follow up with dsb + isb to serialize the
NVIC update. Add a helper function for doing this.
Change-Id: Iaaa238ad39997cc3c6d62867d265cf9e9e0e5c4b
pcm_play_data -> mixer_channel_play_data
pcm_set_frequeny -> mixer_set_frequency
pcm_play_stop -> audio_stop at startup / mixer_channel_stop at shutdown
pcm_is_playing -> mixer_channel_status
All of these have been removed from the plugin API. Updated API docs to
clarify role of audio_stop() vs mixer_channel_stop()
Todo: get rid of pcm_play_[un]lock().
Change-Id: I8800c131b51f064ee923a4c6e42aa405d33851fc
At low speed there's some occasional corrupted pixels,
most visible on album art and such; this goes away at
medium speed.
Change-Id: Ice4eaec4284023d2d3f5c571b242cb27ebc26da9
The problem with drive strength and things not working reliably
at 50 MHz turned out to be entirely caused by the ESD diodes on
the data/command/clock lines, which have a whopping 200-300 pF
junction capacitance -- 6-10x higher than the 30 pF limit given
by the MMC spec.
After desoldering the diodes the bus seems stable at 50 MHz and
with any drive strength (note MEDIUM is still fast enough even
for 50 MHz, so the drive strength is unchanged).
Change-Id: If9847ee4145f5ed2f7e172cfa89acad0737a897f
* Get rid of the SD_CIM_RESET meta-command and put all
reset/init logic into one place
* Don't double-issue the SD_GO_IDLE_STATE command
* Explicitly set lowest speed upon reset
Change-Id: I5abfe9f64997e39087b8a77d525f90c77733a1a8
It was limited to 48KHz due to insufficient IRAM but at some point in
the last five years or so that must have changed.
Change-Id: Ia893ed5e1f3026158daad77991c3d9cca2fed97c
* Rework logf/DEBUG distinction
* Don't try to init a card that isn't detected
* Inform card that host supports SDUC
* Implement CMD22 (SET_UPPER_ADDR)
* Implement CMD23 (SET_BLOCK_COUNT)
* Disable DMA for transfers under 512 bytes
* Created ACMD+data xfer command path
* Incorrect handling of RESPONSE_R7
* Clean up 4bit stuff, only turn it on after we enable it in the card.
* Clear END_CMD_RES bit _after_ we check the status
* Probe SCR <-- NOT YET WORKING, DISABLED
jz4740 had these additional improvements:
* Restructuring to bring it closer to 4760 driver
* Unified read/write setup code
* IRQ handling and polling improvements
Change-Id: I47379f097af4bf50177499b3d80a6c9c42d48057
