Use ":" as the separator. Useful for plugin development and debugging.
Example:
../tools/configure --target=hibyr1 --type=ADS --plugins="properties.c:imageviewer"
This creates a debug simulator build for Hiby R1 with the properties.c file and the imageviewer directory plugins enabled.
Change-Id: If974cfb0c54bd2c1a53ae11cc3f942c698ef2fe4
Low speed works for 50pF loads up to 12 MHz. LCD signals
fall well within those limits so there's no reason to use
any higher speed.
Change-Id: I6dab899fac316bb02572174ef13a98cccbf4ae66
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
SDL needs to do lcd_update from the main thread
stars.lua uses an event that runs in a timer thread
so in the sim the screen never updates
Change-Id: I6002525363010c3133ebbfb490763f747c5d773a
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
Someone opened a bug, its not a bug but it is annoying
these are the smallest screens so the 18 character width ends up
wasting lines that could be displaying characters
this layout repeats some but should be more ergonomic
Change-Id: I2ed4c0887477aac49821c4edb6f3bf174e38d36e
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
you should be able to have multiple parameters to a single plugin
you can do this from outsid the plugin, but not from within the plugin
this makes it possible to have several entries with the same
plugin and a different parameter for each entry
it now also updates the name of the entry to the name of the parameter
instead of the name of the plugin (unless user edited it)
Change-Id: Ifb52b21e3b8ed3257364635b5d92e7c21a35a199
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
Removing STUBOFFSET in commit 78542df466 caused DRAMSIZE
to be computed incorrectly, not taking into account the
16k offset used for 'IRAM'. As a result plugins & codecs
got shifted 16k upwards from their intended load address,
making them unable to load.
Change-Id: I6c338e04506e12fa2b8a69286a1ed785a2f8042d
The mess here can be reduced by paying careful attention to
how the linker allocates LMAs/VMAs within MEMORY regions.
Changing the way .ncdata and .ncbss are defined so that they
reserve the LMA/VMA ranges they use in PLUGIN_RAM removes the
need to explicitly set the VMAs of other sections, cutting
down on the number of ifdefs needed and making the script a
bit simpler.
Change-Id: I316fc6e8dedd621537261d52c1ec7c20ec09438a
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
Looks like I forgot to test the hosted builds and for some
reason thought that make would expand objcopy recursively...
Change-Id: I61264eadcb1235660566f6a9f19f8718ebe14583
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
This reverts commit 91ec6f1e1e.
Reason for revert: Massive sea of red, looks like hosted + sim builds.
Change-Id: I98a3954d68ad2cc521e13c3683bf4a6f45f88b36
Some purely mechanical fixes to get the normal build
working. Besides missing symbols all the plugins and
codecs build just fine.
Change-Id: I946ba39096a46be8308450bafd51a0995db8e323
From what I can see the Creative Zen Vision ports, which
were the only ones to set USE_ELF prior to the Echo R1 port,
do not work except for a bootloader and never even got to
the point of booting Rockbox. This explains why they build
codecs and plugins as ELF binaries, yet there is no code to
load ELF format codecs or plugins.
Anyhow, add a new setting, PLUGIN_USE_ELF, which controls
whether plugins & codecs are left as ELF or converted to
flat binaries. This makes it possible for the Echo R1 to
use the flat binary .rock format, and makes it possible to
have ELF plugins/codecs on targets with non-ELF main binaries.
Seeing as nothing needs ELF plugins/codecs right now, the
new default is to generate them as flat binaries unless
the target requests otherwise.
Change-Id: I9ffae669978de5cc7ad214cd50d97ad6e8938394
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
The location (and number of pages) is apparently manufacturer-dependent.
here are some known so far:
Winbond: page 1
gigadevice: page 4
This info is only queried/dumped when explicitly requested for debug
purposes.
Change-Id: Icc4f9c0d4f2cc9097b2295c8f42a22aab392d0d5
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
"Aigo Player" => "Hiby Player"
"Aigo Recovery" => "HibyOS Recovery"
All four (so far) brandings of the "erosq/k" family utilize the same
HibyOS+HibyPlayer platform. This platform is additionally shared by
nearly all X1000-based devices.
...So let's call it what it is.
Change-Id: I986ed202ad0ca13b0650be87cf5b612c9648e571
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
The constant NVOL_FACTOR used in the calculations needs
to be scaled if the target doesn't represent volumes in
1/10th dB units (ie. most targets). Using a wrong factor
caused the results to be slightly "off", with wide steps
between points on the upper end of the volume curve.
Drop use_linear_dB_scale() because the magic constant
involved has a similar problem (and we don't use this
function anyway).
Also, make sure to account for the guaranteed min/max
points when generating the normalized volume table to
avoid sometimes generating one or two extra volume steps
very close to the min/max volumes.
Change-Id: I5c15809a7306f14bb1befe6d29a5e2b5b0974eaa
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
On targets where plugins can use IRAM, mpegplayer copies
its own IRAM region to main memory before enabling voiced
menus and then copies it back when exiting the menu.
I'm reasonably certain this is unnecessary because the
core IRAM area is completely separate from plugin IRAM
(which is the same memory as codec IRAM). If they _did_
conflict, then we'd expect to see massive problems with
voiced menus during normal playback since most codecs
make fairly heavy use of IRAM.
There are two other reasons to get rid of this hack:
(1) it's ugly, and (2) it will not work on targets with
"split" IRAM like on the STM32H743 where the fastest
code/data memories are separate.
Change-Id: Id8656539c7cafb724691494c54a07448fbcf8129
