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
The previous commit just switched the voice used for the nightlies; this
changes the default used when using the cmdline voice.pl tool without
the user overriding it with something else.
Change-Id: I5144fe66e355f3c41677ca37226a743667d291bf
Does better for short phrases/words than 'semaine'. "No/Yes" and
numbers in were pretty bad in particular.
Change-Id: I795ad57b7ca8c5b8a3fe0c2b721ef167d0dd9f6d
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
In a non-default Git worktree, the .git directory is replaced
by a file containing the path to the real .git directory. This
breaks the version detection logic because it expects .git to
be a directory.
Passing the root of the source tree via "git -C", letting Git
figure out if we're in a repo or not, solves this problem.
Change-Id: I595f1a694258cad490b1a4964f8ae9d51ae76de1
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
gui_usb_screen_run() is a do{} while(0) macro, resulting in an unused
variable warning in the "caller"
Change-Id: I4b4b00ef38decfb5cc9db0da3d81ad0c9a4207d1
