The bootloader starts the OF when the player is woken by plugging in
USB, because the OF was the only firmware that could give the host
write access to the internal flash. A build with FTL_ALLOW_WRITE
can do that itself, so boot Rockbox there and leave the OF to a held
key. Builds without it keep the old behaviour.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I74af2f8c56436a3f7c9ad97d1b1638469807f0dc
Before the original firmware resets itself, e.g. at the end of a
firmware update, it stores a boot mode in an undocumented GPIO1
register that keeps its value over the reset. The NAND bootloader
reads it to decide whether to boot at all, then starts our
bootloader, which chose Rockbox or the OF from the buttons alone, so
an OF that restarted itself came back up as Rockbox.
Rockbox never writes the register and it reads 0 after power-on, so
boot the OF whenever it is set.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I22a98cafad48f66302a8401c9df847a073675a58
Currently if you want to compile a bootloader like so:
$ ../tools/configure --rbdir=/.rockbox.aigoerosq --target=aigoerosq --type=b
This won't work because the bootloader is hard coded to look for the rockbox Linux binary in /.rockbox/rockbox.erosq regardless of what is specified by '--rbdir'.
This commit adds support for ROCKBOX_DIR in the hosted HibyOS bootloaders.
After compiling, they can be installed with adb via (for example):
adb push build/bootloader.erosq /usr/bin/bootloader.erosq
Change-Id: Ic4ceb75107f608beacfd497998a11a5874e87ac1
Scaffolding for a port, starting from the rk27xx generic target: configure
entry 146 (target id 117, model number 132), config/samsungypcp3.h, and
firmware/target/arm/rk27xx/ypcp3/.
- LCD: the rk27xx LCD interface (lcdif-rk27xx.c) with this panel's init
sequence, from RE. See g#1050. Looks like SPFD5420A 18-bit bus,
400x240 landscape. It differs from the generic panel's sequence in the
gamma curve and in not writing VCOM_HV1.
- Backlight: PD4 / PWM0 with the generic board's timing, which the hwstub
work found to be the same.
- Storage: the microSD slot. Card detect is PC7, active low,
as on the generic board.
- Keys: the YP-R0's key set - five-way yog, Back, Menu, Rec/User, Power -
so the target uses SAMSUNG_YPR0_PAD and its keymaps. Eight keys sit on
two resistor ladders on the LSADC, found in the original firmware and
measured on a unit:
channel 1 up 158, down 295, select 435, left 561, right 687
channel 2 menu 155, back 292, user 431
each key owning half a step either side of its reading;
power is GPIO C1, active high.
Builds as firmware and as bootloader. Status 3 (unusable) in builds.pm.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: Iff4984023415f341ca7507af6b5b2b551201e953
run_file() joins /mnt/sd_0 and the filename without a /, so /bin/sh cannot open any script and always returns 2.
The path bug has been fixed and the buffer size adjusted and freed after execution.
GPT 6 Sol did the work. I'm just the meat proxy.
Change-Id: I644a773b2bd707e0ee2d8c70c91b7a6075cf2622
Currently, the link points to the unofficial bootloader builds and installation instructions by freemyipod.org, but it can be changed at any time by the rockbox.org website maintainer.
Co-authored-by: ChatGPT-5.6 Luna
Change-Id: I05a78a6540ebcc0e03a1f12f5d765e69e68af00c
Move the iriver-specific functions for detecting flashed
Rockbox/OF images into system-iriver.c and remove the
HAVE_FLASHED_ROCKBOX define which is now redundant (all
targets using system-iriver.c enable it).
Copyright attribution on the new system-iriver.h header
is a best guess from Git history.
Change-Id: If1933f881a63fd517162ab9ca8f4a3007b997739
Rockbox only drives NAND parts proven on hardware, and this tree has one
model to prove them on. This is the image that lets an owner of another
Nano 3G supply what validating theirs takes: a bootloader built with
-DNAND_CHECK and run from DFU, which never touches the NOR flash or
writes to the NAND.
Testing evidence: firmware/target/arm/s5l8702/ipodnano3g/TESTING.md.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: I46328b69f8011337790f35a195de97b5bcf347a5
The Nano 3G keeps everything behind the S5L8702 flash controller and
Apple's FTL ("Whimory"), and nand-nano3g.c was a stub, so the port had
no storage at all. This is the flash driver, the FTL and the wiring that
makes the NAND Rockbox's disk. The three are one change because neither
half is usable without the other: the driver alone cannot see a
filesystem, and the FTL alone has nothing to drive.
Testing evidence: firmware/target/arm/s5l8702/ipodnano3g/TESTING.md.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Change-Id: Ib04a991489ff3a1a63cd55552e4a8d7ec7a5fc8c
Most of the churn here occurs because 'filesize' is one of
the redefined filesystem functions, but some of the structs
used by the native FS code also include a 'filesize' member
variable which gets renamed by the macro in some but not all
source files.
It's easier to rename 'filesize()' to 'ffilesize()' rather
than try to clean up the macro mess or renaming the struct
members.
There is weirdness with root_realpath() which now breaks on
native builds because it was assumed to be unprefixed there.
dir_get_info() was unprefixed everywhere but this just seems
inconsistent; make it follow the FS_PREFIX() convention too.
Change-Id: Ic3700c6234ea45f32679c1a8429d70fdb8f4088a
Pure file move, in preparation for a second Ingenic SoC.
dma, gpio, i2c, installer, kernel, nand and the SPL NAND backend
move from target/mips/ingenic_x1000/ to target/mips/ingenic/
Drivers that cannot move as whole files, because part of each is
genuinely X1000-specific, are left alone for now: msc, uart, sfc, the
debug menu and the OST helpers in system-x1000.c.
Verified as a no-op: built at target 246 --type=b before and after from
the same source path, bootloader.bin is byte-identical, and every moved
file's object has the same instruction stream under its new name.
Builds clean with no warnings for targets 246, 260 and 247, both
--type=n and --type=b.
Change-Id: I9f67c23384df49b8c4554d695b772bcd54a4e32f
Co-Authored-By: Claude Opus 5
HibyOS-based target: keymaps, LED, powermgmt, bootloader and sim support,
plus cabbiev2 for the new 360x640x16 screen. Opus 5 helped w/ debugging
and the initial scaffolding.
Updated name to FB_STRIDE_MISMATCH, added simulator bmp and specs.
Change-Id: If797ac6581cf75d9d1fcf36e615ee03cf6f905d6
Holding HOLD on the remote while powering on was incorrectly
detected as a bootloader mode entry request because remote_type()
was not yet initialized. Add sleep(HZ/8) after lcd_remote_init()
and re-check remote_button_hold() only if a remote is detected.
Fixes erratic bootloader entry on remote-connected H300.
Change-Id: Ic042cf5ff40713e93b2096d4ee48d7e1001ce4a5
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
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
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
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
"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
ie by only using HAVE_BOOTLOADER_USB_MODE, instead of blanket-enabling
USB_ENABLE_STORAGE for numerous SoC families
Change-Id: Ief433a1d693876072779e714883438c0012ba2e0
add second argument to usb_acknowledge.
it can be used for more appropriate connection tracking that does not
rely on timeout in the future.
Change-Id: I8a44366b7c7a1f944524c4ba8ecd6d9673746a65
Add a 'make start' target which starts Rockbox using a
debugger. This only works to load the main binary, but
makes it much faster to test changes that don't affect
plugins/codecs.
Because SDRAM isn't accessible at reset and the main
binary is usually too big to fit in SRAM, the bootloader
must be flashed first before Rockbox can be loaded in
this way.
The boot protocol involves GDB writing a check pattern
to SRAM while the CPU is held in reset. The bootloader
detects the pattern and takes a breakpoint, by which
time SDRAM is accessible; GDB can then upload a binary
ELF image (copied as a raw file, since the ELF will be
loaded using RB's ELF loader) and leave the breakpoint
to continue booting.
From there the bootloader can load the ELF binary from
memory, exactly like a normal SD card boot.
Change-Id: I4eb971b4162ea422e38660455cfa0958cefaa18d
To avoid problems with SDMMC DMA not being able to
access all SRAMs equally, the ELF binary is loaded
at the top of SDRAM and then copied into place.
Change-Id: Icf16d02bc15605539cbe781dd27709225abca8f9
On the Echo R1, the main regulator is enabled primarily by
the power button and USB input, and secondarily by the CPU's
own output pins (cpu_power_on signal or RTC alarm output).
From a user perspective, the player should appear to power
up and down only if the power button is long pressed, which
must be implemented in software. These logical power states
are called "active" and "inactive" in the bootloader.
Going from inactive to active will attempt to boot Rockbox
unless a button (d-pad down) is held to enter bootloader
USB mode instead. Going from active to inactive will shut
down the player. The bootloader will also automatically
shut down after a short timeout, if USB is not plugged in.
In the inactive state, the player is supposed to enumerate
over USB so it can negotiate a charging current, but should
otherwise appear "off". In particular it shouldn't expose
mass storage or even power up the SD card, nor power up the
LCD/backight. This isn't implemented yet, because there's
no way to dynamically change USB configurations (eg. going
from active to inactive should trigger re-enumeration to
switch to charge only mode). To avoid surprising behavior,
the bootloader will just boot Rockbox immediately if USB is
plugged in at boot.
Change-Id: Icd1d48ef49a31eb32b54d440e9211aaf40c6b974
* When SHOW_LOGO is not defined, print the version at the
same time as the logo would have been displayed
* Don't re-init the display after every message in USB mode
Change-Id: Ida0f5643b1d57004877ec5c42fc14028f53b1c89
For some reason it was locally defined everywhere. Move a single
definition into common.h instead.
Change-Id: Ie2fad74acccd89e40fcbb0f47258d2e14e0f8285
Enable high speed USB for the Echo R1. Includes reasonably
complete support for full speed USB on the STM32H743 since
that was necessary to debug why it wasn't working at first
(which turned out to be a bug in memcpy, not a hardware or
driver issue).
Change-Id: Ie713195b22ba88c79b9b0d6eb289cb9ccd2763c2
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
Early 6th gen ipods (80GB and 160GB "fat") are limited to LBA28
which results in a hard upper limit of 128GiB on the storage size.
The later 120GB model also shares this limitation. These are identified
by HwVr of 0x00130000 and 0x00130100, respectively.
The final revision of the iPod Classic series (160GB "thin") does not
have this limitation, and can be identified by a HwVr of 0x00130200 or
0x00130300.
This is strictly an issue with Apple's stock firmware, and not the
hardware, and Rockbox will happily utilize the full capabiltiies of any
installed storage device. Unfortunately, if you boot into the stock
Apple firmware, said firmware will destructively trash the partition
table and filesystem.
Consequently, the Rockbox bootloader will now check if the installed
drive requires LBA48, making sure the flashed firmware also supports
LBA48. If not, we will disallow booting into the OF (including disk mode)
altogether. This check can be overridden by holding down LEFT, at which
point you get to keep all the pieces.
Note: While Apple never released firmware without these limitaitons on
the older models, there is a way to update to update these to the newer
firmware. This requires altering the stored HwVr, so it is safe to use
the HwVr as a proxy for the installe firmware capabilities.
Change-Id: Icdd5754f2a3d38c6de67fc7565fabc7aa20f19b3
Show this in in the info dump when we can't find a filesystem to mount
in main() plus in the ipod bootloaders
Change-Id: I3b437ae0032b17f29c0dd94043743f14d2b2f3ad
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
