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
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
Removes dependency on distuitls (ModuleNotFoundError: No module named 'distutils');
gtk-doc-tools still required;
Change-Id: I50f69411d146b5b9b9c496b3507bcef5bb1638bc
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
