The semaphore was released after all bytes were read/written
without waiting for the EOT event, which is why the delay at
the end of the transfer needed to be longer than expected.
Change-Id: I6b48fc01cda69564c0ec8f843afd1b0c3a9c5a3c
I have a 1TB SD card that gets filesystem corruption when writing large
amounts of data when using Rockbox in USB storage mode. The card doesn't show
this behaviour when using the original firmware or when using an external SD
card writer.
This is on an Aigo Eros Q device. Same brand 512GB card does not exhibit this
behaviour.
Whether this specific SD card explicitly requires CMD23 or if there's a
problem with the controller's timing of auto-CMD12 in combination with this
card is currently unknown, but implementing it does solve the problem.
This change request implements CMD23 by first probing if SBC is supported by
the SD card and then using it instead of AUTO_CMD12.
Change-Id: Ib2dc8e179b0fab98ca59c348061cb7d5850884dd
The driver didn't handle the busy signal at the end of
some command responses (R1b response type), notably the
CMD12 (STOP_TRANSMISSION) sent after a multiblock write
would time out because DTIMER==0 and leave the DPSM in
an incorrect state for the next command, causing a hang.
Change-Id: I406337a7612f759418a4872979aa2de5aa2244c7
When doing I/O, the interrupt can rarely fire with no
active command and no status bits set. This is probably
because the interrupt is set pending by the NVIC while
the handler is already running, so should be harmless.
Change-Id: I0c2570abe6e3c85ddbfa2ebe0afcf8677b77408f
I'm leaving it enabled because that's clearly the intent
of the bootloader, but at least there's now an easy path to disabling it
if so desired.
Change-Id: I4f4ecc9a453d376f92e411e0544b587fe4b4c864
This way we don't need to stub out a bunch of functionality when we
don't have any actual USB class drivers enabled.
Change-Id: Ia0ecf5be4bb41bebfcd347090959f3204a2aba59
They haven't seen development activity for the better part
of two decades and apparently were never able to even boot
to Rockbox, although the Rockbox bootloader could load the
original firmware.
Change-Id: I5cfa5909c21feaf2825aa685a05e78044b893a13
Allow toggling the system debug state from the debug menu
in Rockbox, or by holding a button combo at boot, so that
an SWD/JTAG debugger can be attached to normal non-debug
builds without too much hassle.
Change-Id: Iee47ef916ade2e5ec1094a63c68e48f1b27b0bbb
While 50 MHz works for low activity and small amounts of
data, there are frequent CRC errors when handling larger
transfers. Increasing drive strength only makes it worse.
Everything seems stable at 25 MHz though.
Change-Id: I3471c490ab63b2302b21ee2fe601519ee5a40ce5
The handful of uses are only doing zero initialization
so don't need to go in the data section, they can go in
bss instead.
Change-Id: I7108ac60867aa20b4429ac0747d00109563bb3bf
Both targets were part of the (presumably dead) Lyre project
and no longer build. The Mini2440 was much more complete than
the Lyre and doesn't seem terribly difficult to fix up to the
point where it at least builds, if someone still cares -- but
given it is a dev board in a box, it's unlikely it ever saw
much use.
Change-Id: I09745379d28db69ea9aaf77f0a62b049884260e1
Some purely mechanical fixes to get the normal build
working. Besides missing symbols all the plugins and
codecs build just fine.
Change-Id: I946ba39096a46be8308450bafd51a0995db8e323
It doesn't seem to have been functional ever and currently
doesn't build; eg. the last commit to the LCD driver added
a syntax error, and there's some duplicate functions between
mmu-armv6.S and system-pp502x.c. Doesn't seem worth the
effort to fix.
Change-Id: I82b5bec3ed9686f28aedbe283818af792b96daf4
These targets haven't seen any changes since 2008-09
have bitrotted to the point they don't compile anymore.
With only internal NAND flash for storage which doesn't
seem to have ever been accessible from Rockbox, they've
never been usable and there's probably not much point
keeping them around any more.
Change-Id: I2fc63da20682b439126672065ae013044cb2d1c4
It looks like the GDB stub only ever worked for the Archos
Recorder and iRiver IFP-7xx, neither of which are in-tree
any more.
Change-Id: If1910675b88b4707d26df9bc095818902af2d25b
PLUGIN_USE_IRAM is almost equivalent to USE_IRAM except
that USE_IRAM might be defined in core, but not plugins.
All remaining uses of PLUGIN_USE_IRAM are inside plugins,
however, so there is no point keeping both defines around.
Change-Id: I6902c85651f3d82b7d19ea32eaa60fc5c19eded7
The section copy loops in crt0.S rely on sections starting
and ending on 4-byte aligned addresses. If the last variable
alloacted in the BSS section isn't a multiple of 4 bytes,
then _bssend can get misaligned and break the copy loop.
This problem was masked by -fcommon since COMMON variables
go at the end of the BSS section, and they were for the most
part a multiple of 4 bytes. The switch to -fno-common broke
the bootloader because with COMMON gone, the last thing in
BSS was a 1-byte variable in led.o. The main binary appears
to have had the correct alignments by sheer luck.
Change-Id: I21ee3653d89d1607a2f458c457f1a51e33c22f05
We were using a definition of 0b100 for "Quad Input / Quad Output" mode
which is marked as "reserved" in the X1000 TRM. The correct value is
0b101.
Somehow this "worked" for some devices but failed for others?
Credit for this discovery+fix goes to forum user ZappBranigan2972
Change-Id: Iedbd2d1b6da55113e266ad8aa51fc9c3130bf2b8
Using a simple memcpy to a separate framebuffer prevents
objectionable levels of flickering caused by scanning out
the main framebuffer while it's modified between updates.
With optimized memcpy, copying the whole framebuffer takes
about 260us at maximum CPU+bus frequency. Using DMA would
likely be a bit faster and more power-efficient, but that
can be left as a future optimization.
Change-Id: Ia6dc36d797cdb7a5f6663078c0ecce661267bedf
This assembly implementation is marginally faster than
the non-size-optimized C version for large copies, but
is around half the code size.
Unaligned loads/stores will be used on platforms that
support it: though slower than aligned accesses, this
is still faster than copying byte-by-byte and has the
advantage of simplicity and small code size.
Change-Id: Ieee73d7557318d510601583f190ef3aa018c9121
Either QSPI is not wired up, or there is some other issue preventing
them from working correctly.
If this doesn't show any more issues then we should be able to produce a
new set of bootloader builds enabling support for the HifiWalker H2 v2.3
variant. We will eventually find out if other OEMs have chosen dfferent
flash parts for their specific ErosQ/K variations.
(Credit for these experiments goes to the forum users
ZappBranigan2972 and gonzyfrigus)
Change-Id: I349f4bbac509010753ac2ad24ad42a234cccdea5
Split up the single massive '#if' condition into several
smaller blocks to make it easier to understand what is
happening. Compiled binaries should remain unchanged.
Change-Id: I65359cb55c60d71d5a424cafda83c83bddb20974
Bootloaders with HAVE_USBSTACK but without HAVE_BOOTLOADER_USB_MODE end
up with USB_NUM_DRIVERS of 0 which leads to a warning due to a signed
number being checked to see if it's >= 0.
Work around this temporarily; the proper fix is to not build usb_core
and its class drivers when BOOTLOADER & !HAVE_BOOTLOADER_USB_MODE
Change-Id: I1b41140d31ba9df6b4c760478c4265d4e5584963
this invokes specified class driver's notify_event method.
initial purpose is to trigger a callback from isr, like a timer event.
Change-Id: Id600e9f0d8840a12da779d5a15783edf14bd76b5
First, leave USB_FULL_INIT on for all non-bootloader builds; this is
needed for devices that don't have a USBSTACK (such as most hosted
targets and ones that provide USB<>ATA in hardware)
Then unwind another hack that is no longer needed now that USB_FULL_INIT
is not set in most bootloaders.
Change-Id: I00881ac76b2469e5cd7700bad2203c58ef1e09e7
The intent here is that when HAVE_USBSTACK is not defined, or we are
in a bootloader wthout HAVE_BOOTLOADER_USB_MODE, a device may still
some of USB subsystem initialized. For example, this may be needed
to enable USB-based charging functionality.
So, get rid of the blanket enables of USB_FULL_INIT based on target SoC,
enabling HAVE_BOOTLOADER_USB_MODE on targets that need it, and clean up
the initial mess. Most of this mess is because usb_core.c has no sense
of USB_FULL_INIT or not, and is always included when HAVE_USBSTACK is
set (even in bootloaders without BOOTLOADER_USB_MODE), but dealing with
that latter case will come later.
Change-Id: I7f805b89dded39aeea2db9038209780069e3b600
Framebuffer access consumes a lot of SDRAM bandwidth.
Moving it to AXI SRAM should be a big improvement as
it's around 8x faster (2x clock speed, 4x bus width).
Also take advantage of explicitly assigning sections
to the special :NONE segment, which means they will
not appear in any ELF program header and thus aren't
visible to the bootloader. They can then overlap
areas used by the bootloader -- by the time they're
written, the bootloader will be long gone -- making
it easier to make efficient use of SRAM.
Change-Id: I2392fd23b17472cc08dc5fe4556f6def3cc186ed
Explicitly set 8-byte alignment as per the AAPCS, which
says the stack should be 8-byte aligned at a public ABI
boundary.
Change-Id: Ie60b664718119ea576e7c6b5efaac011eb907531
ie by only using HAVE_BOOTLOADER_USB_MODE, instead of blanket-enabling
USB_ENABLE_STORAGE for numerous SoC families
Change-Id: Ief433a1d693876072779e714883438c0012ba2e0
Many bootloaders broke because they have only partial USB
implementations -- HAVE_USBSTACK but without HAVE_BOOTLOADER_USB_MODE...
and a pile of exceptions.
Those exceptions need to be cleaned up properly, but for now, get the
build going again by wrapping the new ack-tracking bits with the
USB_FULL_INIT define created by the above conditions.
Change-Id: I936d4989b8c8195ee30d53808f61104a4986942a
currently, exclusive disk mode was enabled at the same time as the
usb insertion. when multiple usb configurations exist, this is not
appropriate.
manage it in the core and enable it only when necessary.
Change-Id: Iadbec05fad1d1319471233227ae0e72c12079295
add second argument to usb_acknowledge.
it can be used for more appropriate connection tracking that does not
rely on timeout in the future.
Change-Id: I8a44366b7c7a1f944524c4ba8ecd6d9673746a65
To avoid problems with SDMMC DMA not being able to
access all SRAMs equally, the ELF binary is loaded
at the top of SDRAM and then copied into place.
Change-Id: Icf16d02bc15605539cbe781dd27709225abca8f9
This is a small & simple ELF loader which just copies
program segments from disk to memory. It only supports
static binaries right now.
Change-Id: I8944feb5b9dafcc5c56e12383aed25e2718ad7ea
Most of system_init() should only be performed once after
reset, and is not safe to re-run when the bootloader jumps
to the application.
Change-Id: I4d2e804ce4884da13b9167ddcda860ef3b5ba7d0
Use flash & AXI SRAM for the bootloader, ITCM/DTCM and
SDRAM for Rockbox. Hardly the most optimal use of SRAMs
but it's good enough to get started.
Fixes the Echo R1 app build, which wasn't fitting in
AXI SRAM.
Change-Id: I4f7e5f618d27b553e5ff8dec1d5c4c61ac9d8eb0
