some targets can process requests fast enough without dedicated
batch api implementation.
provide generic implementationn for such targets.
Change-Id: I152681441e70e0e98396274d9305d371d2bbfbe3
Remove now-unused stuff related to the PNX0101 processor,
which was missed during the removal of the IFP-7xx port.
Change-Id: I5ff248b3e83cb67a357743130c3e51ed84a720e5
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
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
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
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
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
ie by only using HAVE_BOOTLOADER_USB_MODE, instead of blanket-enabling
USB_ENABLE_STORAGE for numerous SoC families
Change-Id: Ief433a1d693876072779e714883438c0012ba2e0
Define HAVE_LC_OPEN_FROM_MEM if the target implements
lc_open_from_mem(). Make HAVE_CODEC_BUFFERING depend
on this feature.
Change-Id: If5f70db58963dcdc33848b860c028841ac380ab2
Move HAVE_CODEC_BUFFERING to config.h, and disable all
related code on targets that don't support the feature,
ie. hosted targets that can't implement lc_open_from_mem().
Change-Id: I0d2a43900cd05b1a80c3cee519f8ad7b26e39fe7
Add CONFIG_BINFMT to select the binary format used for
plugins/codecs and define two options for the existing
implementations (native ".rock" format or dlopen-based).
Split the load_code.h header into two separate headers
to make it look less messy.
Change-Id: Ibd66773160df35a8c6f29a617d12c961bdabf317
sdmmc_host is a portable driver for targets with SD/MMC
storage. It handles all the logic needed to initialize
and access SD/MMC devices which is common to all targets.
Targets only need to implement functions to issue SD/MMC
commands, manage clocks & power, and managing the insert
state of the card (if it is hotswappable). This vastly
reduces the work needed to get a new SD/MMC based target
up & running.
At present it's only written for and tested with SD cards,
as I don't have access to an MMC-based target to test on.
Change-Id: I6a0d7747113c11a3697ae20cbb551bef8bfd1292
The ZEN V target is the only one which has volume buttons,
but lacks the menu and shortcut buttons.
IMO an independant keymap will make maintenance easier.
Change-Id: Ide79fab629b13eae94946561d99052e570c0e4f2
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
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
Original commit credit to Amaury Pouly, Moshe Piekarski
Pushed across the finish line by Dana Conrad
To enable, see setting under General Settings --> System --> USB-DAC.
On devices with few endpoints, this may not work while HID and/or
mass storage is enabled.
Adds new dedicated mixer channel.
setting usb-dac can have values:
- never (0)
- always (1)
- while_charge_only (2)
- while_mass_storage (3)
Relevant devices are DWC2 and ARC usb controller devices. That being:
x1000 Native targets (m3k, erosqnative, q1, others...?),
sansac200, creativezenxfi2, vibe500, ipodmini2g,
ipod4g, creativezenxfi, creativezenxfi3, sansaview, ipodcolor,
creativezenxfistyle, samsungypz5, sansafuzeplus, iriverh10_5gb,
tatungtpj1022, gigabeats, faketarget, samsungyh820, gogearhdd1630, samsungyh925, ipodmini1g, ipodvideo, creativezenmozaic, sonynwze370, creativezen, gogearsa9200, gogearhdd6330, sonynwze360, sansae200, mrobe100, iriverh10, creativezenv, ipodnano1g, samsungyh920
USB Driver-wise, it should be noted that this patch requires some
slight changes:
- proper blocking on control OUT transfers, to make sure the data is
received *before* using it, the usb_core should probably use that too
- drivers can now support interface alternate settings
- drivers can be notified of completion by a new fast handler, which
is called directly from the driver; this is is necessary for
isochronous transfers because going through the usb queue is way too
slow
Designware changes:
- enable for USBOTG_DESIGNWARE
- set maxpacketsize to 1023 for ISO endpoints
Change-Id: I570871884a4e4820b4312b203b07701f06ecacc6
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
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
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
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
* on-screen keyboard
* font manipulation, caching, rendering, and generation
* VFAT code parses and generates utf16 dirents
* WIN32 simulator reads and writes utf16 filenames
Note that this patch doesn't _enable_ >16bit unicode support; a followup
patch will turn that on for appropriate targets.
Known bugs:
* Native players in 32-bit unicode mode generate mangled filename
entries if they include UTF16 surrogate codepoints. Root cause
is unclear, and may reside in core dircache code.
Needs testing on:
* windows simulator (16bit+32bit)
Change-Id: I193a00fe2a11a4181ddc82df2d71be52bf00b6e6
A bit of context, this device is a clone of the FunKey-S with a different form factor, hardware is mostly identical, the relevant difference is it has audio out (via usb-c, adapter to 3.5mm is included), this is the reason why the FunKey-SDK is needed for bulding.
This port is based on the old SDL 1.2 code because the device doesn't have SDL2 support. Alongside what was supported in the SDL 1.2 builds this port supports battery level, charging status and backlight control.
Change-Id: I7fcb85be62748644b667c0efebabf59d6e9c5ade
* Only bootloader builds
* Plugins disabled
* No keymaps to anything else
* No simulator
* Touchscreen not wired up yet
* Audio still untested
Bugs:
* rotary encoder does nothing in bootloader
(might be bootloader bug, might be something else)
Other stuff pulled in:
* Unify all of the (identical!) hibyos makefiles
* Rename the "bootloader" to more generic name
Change-Id: I6d8a3b58de726db8e89cf193c90960a070a575c2
The Echo R1 is a new open-hardware music player design, based
on the STM32H743 microcontroller. Schematics and hardware
documentation for it can be found here:
- https://github.com/amachronic/echoplayer
This is an incomplete port. The bootloader can be loaded using
OpenOCD and it can draw to the LCD using SPI. SDRAM is working
but hasn't been extensively tested.
Change-Id: Ifd2bee15c49868fbc989683d3ca14dce48bf3e18
-Wunterminates-string-initialization will complain if we try to shove
a "string" into a fixed array that is too small. Sometimes this is
intentional; when you are merely using "string" as a standin for
"non-terminated sequence of bytes". In these cases we need to mark
the "string" as "not actually a string" with an attribute. Applies to
GCC >=8, but this warning isn't pulled in by -Wextra until GCC >= 15.
Change-Id: Ib94410a22f4587940b16cf03d539fbadc3373686
Cortex-M7 support was added in GCC 5, while GCC 4.9 only
supports the M4. The instruction set is almost identical
between both processors; the only difference is that the
M7 supports double-precision floating point and the M4
doesn't.
Since Rockbox currently doesn't use the FPU, building M7
targets as M4 works fine.
Change-Id: I5880d6e81a85fa9b3e16e08d57e7955b4493df0b
Even though ARMv7-M has a hardware divider, 64-bit division is
handled in software and needs a div0 handler. The libgcc routines
call __aeabi_{i,l}div0 so we alias those to __div0.
Change-Id: I5152c43d39e25e03f31404753f13978a614aca06
Currently, only the development bootloader can be built successfully.
This is a part of the large iPod Nano 3G and iPod Nano 4G support patch.
Credit: Cástor Muñoz <cmvidal@gmail.com>
Change-Id: I74ea0da999ddb1d8ce5d0f5434141b3f0b5f7448
Currently, only a bootloader can be built successfully. The development bootloader is functional, it enables further progress on the port.
This is a part of the large iPod Nano 3G and iPod Nano 4G support patch.
Credit: Cástor Muñoz <cmvidal@gmail.com>
Change-Id: Idf85e42334b0e0ae36f9ed273e2940d5d7736e34
ARMv7-M has hardware division, so it doesn't require __div0
or any support functions for 32-bit division.
Change-Id: I840683a1a77d737f378899ca4bcf858216b81014
Add some logic to detect classic and M-profile cores, and make
this info available to the build system. All existing targets
are classic profile.
Change-Id: I07bfcd418bcaa6297b9bbf889fc189f167147428
Use AXP2101's egauge battery percent level if available (hw4 units).
If not available (_battery_level() will return -1 on hw1-hw3 units),
fall back to voltage battery level.
Also fix logic in axp2101_battery_status()
Change-Id: Ic300418532dae6f7772fff8bf5e2b32516f3b973
Currently only S5L8701 (Nano 2G) and S5L8702 (Classic/6G, Nano 3G) are defined. This change adds the remaining to CONFIG_CPU, as a preparation for porting to these platforms. It also defines the RTC types for Nano 3G and Nano 4G.
New CONFIG_CPU options:
S5L8720 - iPod Nano 4G
S5L8730 - iPod Nano 5G
S5L8723 - iPod Nano 6G
S5L8760 - iPod Nano 7G
Change-Id: I4e9e00163c0d0d5a5303f9eee428f9be47a48359
This is a preparation to introduce support for the following SoC models: S5L8720 (iPod Nano 4G, iPod Touch 2G), S5L8730 (iPod Nano 5G), S5L8723 (iPod Nano 6G) and S5L8740 (iPod Nano 7G)
The whole family consists of SoCs which are similar, running ARMv6 and Thumb2 instructions, but some peripherals are located at a different address.
No functional change is to be expected so far.
Change-Id: If1f7669c49cf110ccc52c5234cc42ffd6f2b4e80
When enabled this allows 512n and 4Kn drives to be used with a single build.
(So far all ATA SSDs use 512 byte logical sectors)
Change-Id: I902d2318ca8abb581699c0bca68d6e3ec227d064
