This is a tool written in C which does basically the same job
as regtools' headergen_v2, but using a new input format which
is less verbose than XML. In the interests of simplicity it
omits some features that regtools does support, like variant
registers or the SoC selector stuff so it cannot completely
replace regtools on the i.MX platforms that use these features.
RegGen doesn't generate API macros like regtools does; instead
these are expected to be maintained by hand, since it's arguably
easier to do that way.
Since RegGen has no dependencies beyond a C compiler it can
be integrated with the build system without adding any new
build time dependencies. This will allow generating headers
automatically, which is a substantial improvement over running
headergen_v2 by hand and committing the generated output.
The RegGen tool itself is licensed as GPLv3+, but generated
headers can be licensed as the user chooses.
Change-Id: If18f9577f8f4df6e2c97c1665b725773dd5466f0
Original author Melissa Autumn (https://codeberg.org/oopsallnaps/rockbox-hibyos) with contributions from Marc Aarts.
Adaptation to Rockbox standards by Marc Aarts
Change-Id: I09e5af7ba0a75c648e4b9fd424badc2d3665c943
Make the final .echo binary an ELF file. Most STM32s have
their SRAM divided in multiple non-contiguous regions and
putting an ELF loader in the bootloader is basically the
only reasonable way to load Rockbox on such a system.
Change-Id: I818ef9fefe0d53b44cf64402ee1794ad261343eb
Otherwise, toggling USE_ELF in the target's configure section
and running 'make reconf' has no effect, because the previous
value of USE_ELF is inherited from the makefile.
Change-Id: I72d605ef6987fc590871566d73b24acf37e8fbe6
This adds debug symbols to rockbox.elf & bootloader.elf to
make debugging with GDB easier. This won't affect code that
runs on the target because debug symbols are stripped from
the final binary.
Change-Id: I9efe207c63e8bd96404213aad96405be27030ae9
Before:
Scanning files (may take some time)...Read metadata for /Music/foo/bar/baz.ogg
After:
Scanning files (may take some time)...
Read metadata for /Music/foo/bar/baz.ogg
Change-Id: Id3816104779fd80930cd213bab29765bdd3db451
Turns out I compile-tested stale trees instead of the broken change
Net result is just the simpler MIPS revision (32/64/"classic") lookup rather than
the sub-revision (eg mips32r2 etc).
Change-Id: Ideebe522d29132f00f3769222f3846000b3a89fd
This allows us to easily distinguish between mips32 and mips32r2
(Works at least as far back as gcc 4.9)
Change-Id: I2bcba194fd9cbeedf76cea739252271908bf73d0
* Detection of 64-bit Arm v8-a
* Proper detection of integer division support
* always on v7-m, v8-a, v9-a, v8-m.main
* sometimes on v7-a, v7-r, v8-r
* never on v8-m.base v6-m, v6 and older "classic"
* tl;dr: Rely on toolchain preprocessor definition
For the most part these additional variations won't acutally work
for native target builds, but sane -A detection is needed for
"local" builds now. -R detection is left out as it's not likely
to matter.
Change-Id: I8f6a52edc4d14490fc00e2f487406eca701eef02
The only v7-a targets we have are built using the androidndk (with gcc
4.9) but it is possible to perform "self-hosted" builds for eg the
simulator or the sdlapp.
Where this gets messy is the considerable amount of inline arm
asm we have.
Native builds will need considerably more work to support
v7-a processors, but we have to start somewhere.
(Note that this contains parts of commit 508bfabe8, which had to
be reverted due to breakage)
Change-Id: Ia1c8e10d21a976c68fdaae58e4d776854b63186c
They haven't seen any work since 2013, and likely hasn't compiled in at
least a couple of releases -- not that we ever "released" anything for
these targets.
Futhermore, upstream for both has been effectively dead for about as
long, and there's been no user reports of these being used since 2017
(and even then only in passing).
It isn't worth the effort to triage their current state, much less
uplift into something supportable, while the maintenance burden of
keeping these things in-tree can be demonstrated by the diffstat.
Change-Id: Id93bd450679d1b75e2c74295b3ae1548cd241b24
This reverts commit 508bfabe83.
Reason for revert: Completely breaks builds made using Android toolchains. A different approach is necessary.
Change-Id: Ie8767f1f304c1313e8a539179bc33d1cc7032a3c
It seems that there are a couple of codecs that use assembly optimizations. Some of their instruction sequences are not valid Thumb code. To be able to compile them successfully on TI OMAP4430, ARM mode is forced on the codecs.
Change-Id: I932186177b540985e37cb3a5333943572da1c60a
I didn't change the number of anything that would be consider "popular"
but the longnames are all unchanged so it's only muscle memory that will
be affected.
Change-Id: Ic34a2e01801b14e81d4f7c84633bf10fdcbc43c9
Makes sure any fonts specified are either:
* Present in the theme itself
* One of the fonts in the Rockbox bundle
Change-Id: I215132835e2ae7faa06662637bc867df9c5dba92
This commit adds changes to the original rockbox sources.
Note: the port files, functions, folders, etc., will be referred
to as 'ctru' to avoid using the Nintendo name elsewhere.
Change-Id: I0e2d3d4d2a75bd45ea67dc3452eb8d5487cf1f5a
This reverts commit 4bc336b8be.
Reason for revert: Font coverage for decomposed diacritics is actually *worse* than using fully composed characters.
Change-Id: Ide37dadd5e9883c1c764ffa35f7e64a7ba91d705
We already have pretty solid support for glyph combining, so this will
allow us to utilize that to fill in gaps of our font coverage. This is
most notable for Vietnamese, Turkish, and numerous other latin-based
writing systems that have unique glyphs that are essentially just a
"standard" ascii letter plus a diacritic mark.
This leaves *voice* strings fully composed/normalized.
It also has no effect on user-supplied strings (eg filenames or file
metadata)
When we eventually utf8proc merged, this can be removed in favor
of always doing the [de]composition in-system. We will also need
to revisit our diacritic tables to ensure there's nothing missing.
Change-Id: I7012d27010bb33fb0b565ac7dfd57a16bdcad34f
Simulators (and some hosted targets) no longer get a free pass!
This commit includes general fixes for simulator builds, but it
will undoubtedly result in many more warnings that need to be properly
fixed.
Change-Id: I6bb9d3fc4a29ccfe40366c438e058b5dfff0ddc3
'arm946cc' was only used by the never-finished 'tcc77x' targets that
were removed from the tree in 3ba2f6e5c7 (April 2021)
Change-Id: I935847ec9d339b8e90c6d2362113c2ff94b8b20f
When matching the target id in a phrase, if there is more than one match
we always use the final one. This allows us to easily specify a
default/wildcard entry that gets overridden by a target-specific one.
The list of targets was sorted alphabetically to ensure consistent ordering
from one run of the tooling to the next.
However, if a phrase contained both device-specific phrases as well as a
generic "feature" fallback, alphabetical sorting may screw things up, as
the "feature default" was no longer at the top of the list. This is
known to be an issue for LANG_TIME_SET_BUTTON and LANG_TIME_REVERT, but
may affect other phrases as well.
(To be blunt, we shouldn't be mixing feature and device-specific targets
in this context. The "feature default" should be removed in favor of
target-specific entries, but in this specific case it looks to be a
real PITA due to incomplete keymaps)
Consequently, work around this by sorting the target list within each phrase
based on the ordering in the master (ie English) language file.
Change-Id: Id32439c179a98663f414530fb36012f9b217c1b6
This reverts commit 5323c49fe6.
This caused build failures on two of the three affected targets. The intent
of the delted code was to force thumb on unless it had been explicitly
disabled. Due to extreme space constraints those targets _need_ to
be built in thumb mode.
Shrink audio buffer from ~256MB to ~192MB. Increase plugin buffer size
to 2MB, not that it should matter given how much extra RAM this platform has.
This leaves plenty of room for the base OS to do what it needs to do.
Change-Id: I59ca235b9cf80cf86d406e4a144fee7d7784ed5d
This represents a 256K increase from the former (MEMORYSIZE-0.75), and
is necessary due to the growth in our binary sizes over the past decade
or so.
It is debatable if this is enough given that our actual memory
usage is approximately (MEMORYSIZE+3) megabytes (plus runtime OS
overhead) for the typical hosted build, but giving the host OS a bit
more breathing room is warranted.
Change-Id: I53e044585a32efd50a85e68d64fd21921eda01a3
We used 16-bit variables to store the 'character code' everywhere but
this won't let us represent anything beyond U+FFFF.
This patch changes those variables to a custom type that can be 32 or 16
bits depending on the build, and adjusts numerous internal APIs and
datastructures to match. This includes:
* utf8decode() and friends
* font manipulation, caching, rendering, and generation
* on-screen keyboard
* FAT filesystem (parsing and generating utf16 LFNs)
* WIN32 simulator platform code
Note that this patch doesn't _enable_ >16bit unicode support; a followup
patch will turn that on for appropriate targets.
Appears to work on:
* hosted linux, native, linux simulator in both 16/32-bit modes.
Needs testing on:
* windows and macos simulator (16bit+32bit)
Change-Id: Iba111b27d2433019b6bff937cf1ebd2c4353a0e8
All toolchain dependencies are circa the GCC 10.5.0 release:
GCC 10.5.0, binutils 2.40, gmp 6.2.1, mpfr 4.1.1, mpc 1.3.1, isl 0.24
Native:
* arm - mini2g, nano2g works
- ipod6g hangs at logo display
* mips - xduoox3 works
* m68k - binaries untested
Hosted:
* arm - samsungypr0 works
* mips - xduoox3ii works
* Android NDK - unchanged at GCC 4.9.4
Change-Id: Ic157255d76030e66325719e64331f553cb7c4363
