Thanks to Crozone because the new ipodloader v2.9.0d works with my iPod 3rd modded 128gb sd card !!!
I have an other problem : i can launch others programs igpSP, etc .. i see it launch at 78 Mhz but iBoy launch at 75 Mhz and don't work. It loop to Zeroslackr launch ?

Thanks a lot 👍

If possible, I would like to talk about this project. I have a lot of questions. Can you give me a contact method?

Some CF cards and CF to SD card adapters appear to be causing an "Invalid MBR" error. The MBR appears to be incorrect.

So far these all appear to be for LBA28 (<128GB) cards, so it is worth investigating if there's something wrong with the LBA28 codepath side the LBA48 patch.

We need to be able to build ipodloader2 on a modern cross compiler arm toolchain.
The current build system consists of old toolchain binaries on a 32-bit debian VM, which is highly impractical.

gcc-arm-none-eabi is available in the debian package repository and will be the target.

The goal is to have the project build without any errors or warnings.

Work is ongoing in the https://github.com/crozone/ipodloader2/tree/arm-none-eabi branch.

• Install toolchain on a modern 64 bit Linux (Debian 10 running under WSL)
• Build and link the project without errors
• Build and link the project without warnings
• Get bootloader working on real hardware

Issue

The iPod 5.5G may fail to find valid partitions.

Description

When plugged in via USB, the iPod 5.5G presents the drive to the host as having 2048 byte logical sectors, when in reality the drive has 512 byte logical sectors.

When the iPod is formatted, the host will (usually?) create a partition table in the iPod MBR with sector offsets that assume 2048 byte sector sizes.

Then, when the bootloader is loaded by iPodLoader2 on the iPod itself, the partition table offsets will actually be 1/4 the value that they're supposed to be given 512 byte logical sectors. This invalidates the partition table, since none of the partitions will be where the MBR says they are.

This issue isn't unique to the iPod, it's is a well known "gotcha" issue with many USB->IDE/SATA drive enclosures that will often present 2K or 4K logical sectors for drives that actually use 512 logical sectors. However, the iPod 5.5G appears to be the only iPod that presents a sector size that is not 512 bytes when plugged in via USB, so it's the only model of iPod where this issue occurs.

Currently there's an undocumented hack that attempts to detect the sector size used for the MBR partition offsets:

But this doesn't appear to work consistently and I cannot find any documentation as to why or how this should work. iTunes maybe creates a custom MBR and places this value here indicating the logical sector size used, but this is an unknown, and I'm not sure how the original authors derived this technique.

Potential fixes I'm brainstorming:

• Always try 1x and then 4x the partition offset, with partition peeking to verify
• Detect when we're on an iPod 5G and then try 4x and then 1x the offset, with partition peeking to verify
• Do some reverse engineering of the Apple FW to see how it handles this (because it must handle it somehow), and then do whatever it does.

iPodLoader 2 is doing a 32 bit write to GPIO Port A, which Clicky specifies as an 8 bit GPIO port. This crashes the emulator with an illegal read:

ERROR clicky_desktop                           > Fatal Error! Caused by: FatalMemException {
    context: MemExceptionCtx {
        pc: 0x40008018,
        access: MemAccess {
            kind: Write,
            offset: 0x6000d060,
            val: U32(
                0xffffffdf,
            ),
        },
        in_device: "4xGPIO Port Block > GPIO Port:A > IntLevel",
    },
    reason: ContractViolation {
        msg: ">8-bit access to a 8-bit interface",
        severity: Error,
        stub_val: None,
    },
}

Real hardware is seemingly unaffected.

The offending code is here, the inl and outl, which should be changed to inb and outb:

According to the iPod Linux docs, the port is really 8 bits, so it looks like an open and shut mistake in iPodLoader2.

For reference, here is how Rockbox reads the port:

https://github.com/daniel5151/clicky/blob/e199dcfe70510c7ff16ee9e55add5b3095e36c5c/resources/documentation/Rockbox/pp5020.h#L338-L345

Hello ! it's me again. I don't understand why i can't modif the ipodloader menu (photo) despite the fact that I modified the loader.cfg file correctly placed in the root of the iPod?
Thanks

The bootloader currently exhibits an issue where files located at very high FAT32 cluster addresses will be read as corrupt files. This issue is not easily spotted because it only manifests itself when files important to the bootloader (ipodloader.conf and kernels) are moved to a very high cluster index. Fresh drives without any music or other data on them will not exhibit these issues.

A very notable and frustrating failure case is the boot menu becoming corrupt. This is caused when ipodloader.conf is modified when the drive has many GB of data already on it. If the file is increased in size enough to cause a relocation, it may be relocated to the end of the drive. It will be read as corrupt data by the bootloader.

Previously it was suspected that the iPod hardware was itself corrupting the filesystem on these large drives, but examining the FAT32 filesystem structure with disk utilities and verifying the structure manually with hex tools shows that the filesystem itself is actually intact. Furthermore the Apple OS and Linux FAT32 drivers appear to be able to read all files on the drives just fine, as can a host Windows machine when the iPod is mounted.

It is therefore highly likely that fat32.c is the culprit, especially given it already has other known issues.