iPodLoader2 fixes

[crozone]

Just a heads up, I have an updated version of iPodLoader 2 here:

https://github.com/crozone/ipodloader2/releases

which fixes some longstanding PATA and FAT32 issues in the bootloader, in case you run into them.

P.S. I noticed you use -Og to reduce the size of the iPL binary to avoid it overwriting irq_desc. Is this an issue on real hardware and do you think I should be compiling iPodLoader 2 releases with the same option?

P.P.S I have a feeling this emulator will prove to be extremely valuable for resurrecting the iPod Homebrew and iPod Linux communities, so I just want to add a huge thanks here 😄

[daniel5151]

Wow, I'm surprised I didn't stumble across ProjectZeroSlackr earlier!
I assumed most iPod development ended ~2007, but hey, I guess not 😅

Next time I get the chance, I'll be sure to build and test your updated version of ipodloader2 in clicky. Maybe I'll even remove my own fork of ipodloader2 from the source tree...

---

Believe it or not, but I've actually managed to get this far in the project without even owning an original iPod! The bulk of clicky's implementation was pretty straightforward "read the code, and implement the corresponding hardware" sort of development, and didn't require testing anything on physical hardware. That said, as the project has dragged on, it's become more and more obvious that I should probably pick up a used iPod to do some physical testing with...

I noticed you use -Og to reduce the size of the iPL binary to avoid it overwriting irq_desc...

I'm using -Og to make debugging easier.
I originally compiled with -O0, but the code ended up being just small enough to fit into RAM, but big enough that the stack would smash into the static data at times! Boy, that was a nasty bug to track down...

If you're releasing binaries for end-user use, -Os should be just fine!

---

Thanks for the encouragement!
I'm glad to see that there are still people out there hacking away at these iconic 'lil devices 😄

While it sucks that COVID ended up cancelling all of my post-graduation travel, it did give me a long, uninterrupted stretch of time to work on various side projects, including this one! Working on clicky was a great way to keep busy in the many months between graduating from uni and starting full-time work, and I'm pretty happy with how much progress I've made in that time.
Unfortunately, my "vacation" is ending in a couple weeks, and once full-time work starts, I'm not sure how much time I'll be able to put into clicky...

The plan right now is to give the repo one last cleanup, add/fix any relevant documentation, and list some of the next steps I would take (if I had more time). After that, I'll probably shill share clicky publicly on Reddit / Hackernews, and see if there's anyone that would be interested in contributing to the project. Hopefully someone will come out of the woodwork and keep development going!

[crozone]

Wow, I'm surprised I didn't stumble across ProjectZeroSlackr earlier!
I assumed most iPod development ended ~2007, but hey, I guess not 😅

ZeroSlackr was a late discovery of mine also. The single best thing about it is that it mounts the root fs via a loopmount to an ext2 image file on the FAT32 partition, instead of requiring an actual ext2/3 partition on the drive. This should definitely be the way all iPod Linux works in the future, because it's so much safer and easier than re-partitioning an iPod.

I don't know if it has really been touched in the last ~10 years though...

---

Believe it or not, but I've actually managed to get this far in the project without even owning an original iPod! The bulk of clicky's implementation was pretty straightforward "read the code, and implement the corresponding hardware" sort of development, and didn't require testing anything on physical hardware.

That's actually amazing. If you do need a test pod, the iPod 4G is great since they are quite cheap on eBay (~$50 USD) and have a lovely big monochrome display.
You might want to mod it with the iFlash adapter and a big SD card to actually make it a usable music player. The four iPods that support LBA48 (>128GB drives) are the iPod 4G (monochrome or color), the 2nd gen mini, the iPod 5/5.5g Video, and the 160GB "7th gen" classic. The rest of the iPods are LBA28 and max out at 128GB hard drives, although I'm pretty sure this is a software/firmware limitation (from the ATA driver) and nothing to do with the actual hardware. iPod Loader, Rockbox, and iPod Linux can probably read big drives no matter what, but I haven't verified it.

If you need to verify any model specific behaviour, I have almost every generation of the PortalPlayer iPods handy.

If you're releasing binaries for end-user use, -Os should be just fine!

Phew 😅

Also I'm currently trying to get iPodLoader2 building with arm-none-eabi (having issues with linking 'abort' because libunwind stuff), but until then I'd suggest keeping iPodLoader2 in your repo as well since you may be the only person alive to who can currently build it with a modern toolchain (I'm currently building with GCC 3.4.3 in a 32 bit debian VM).

---

After that, I'll probably shill share clicky publicly on Reddit / Hackernews, and see if there's anyone that would be interested in contributing to the project. Hopefully someone will come out of the woodwork and keep development going!

The great thing about the iPod community is that there are still plenty of diehards, hopefully some of them know how to code 😄. I'm going to dive through the code in more detail and see if there's anything I can contribute. Being able to emulate and observe the original iPod OS in an emulator is basically the dream for accurately reverse engineering it.

[daniel5151]

Also I'm currently trying to get iPodLoader2 building with arm-none-eabi

Unfortunately, I only moved my modified ipodloader2 code in-tree after making the changes that got it building on arm-none-eabi (oops). It was a while ago, but IIRC, it didn't require too much work to get working with a modern toolchain? If you diff my copy of ipodloader2 with the one at https://github.com/iPodLinux/ipodloader2, all the misc changes I made should reveal themselves. For reference, I've been compiling with arm-none-eabi-gcc 9.2.1

That said, I've never actually hardware validated my custom builds of ipodloader2, so there's a small chance that there could be some subtle miscompilation on the newer tool-chain. That said, I've stepped-through almost every line in the ipodloader2 codebase, and the assembly all looks reasonable, so it's probably fine ¯\_(ツ)_/¯

---

I'm going to dive through the code in more detail and see if there's anything I can contribute

Awesome man, any and all contributions are more than welcome!

I've tried to keep the codebase as clean and documented as possible, so hopefully it won't be too difficult to get a feel for how things work. As part of my upcoming documentation pass, I'll also be drafting up a brief architectural overview of the emulator, which should make it easier to see the "bigger picture" of how the various modules work together.

If you need to verify any model specific behaviour, I have almost every generation of the PortalPlayer iPods handy.

Running git grep -C1 -EI "TODO\??|FIXME\??|HACK\??|XXX\??|unimplemented|todo" should list a bunch of places where clicky could be improved. In particular, there are quite a few comments which document various "guesses" I've made about the PortalPlayer SoC, which I haven't been able to hardware validate. A good place to start might be to validate some of these assumptions, as emulating a device incorrectly is usually worse than not emulating it at all!

[crozone]

Hi @daniel5151, me again. I've finally come back around to this project and managed to get my build of iPodLoader2 working with arm-none-eabi.

The trick is that only -Og and -O1 optimisation levels work. -O0 fails probably because it's too big (aforementioned stack smash issue). -Os, -O2, -O3 all fail for unknown reasons, probably because of an optimisation that's enabled in -O2.

• -O0 - 87kb, Hangs indefinitely
• -Og - 58kb, Boots fine
• -O1 - 56kb, Boots fine
• -Os - 50kb, Hangs indefinitely
• -O2 - 56kb, Rapidly crashes and bootloops
• -O3 - 79kb, Hangs indefinitely

Not sure if any of this is that useful but hopefully it helps if you run into any issues like this with different optimisation levels. I'm going to try to track down the exact offending optimisations and see if I can modify the code to get it booting with them.

P.S. Do you still need an iPod 4G boot ROM?

[daniel5151]

Hey again!

As you might be able to tell by the steep drop-off in commits, this project is now firmly on the backburner for me. It was a great time-sink during shelter-at-home quarantine, but now that I've started a new job, moved to a new city, etc... I haven't had much time to work on clicky again.

While I'm more than happy to answer any questions you might have (to the best of my ability) and collaborate on stuff, it has been a while since I've looked at all this, so my memory might be a bit fuzzy...

Some general tips on when optimizations break code:

• check for any uses of inline asm. older compilers were far more lenient with specifying in/out params, clobbers, etc... and you'll often get pretty egregious miscompiles on newer compilers
• scrutinize any hardware memory accesses that don't use volatile that might have gotten optimized away
• it could be useful to compile with the code with optimization and debugging symbols, and then try to step through the code in clicky to see if you can get an idea of where things go off the rails

And I've got my own iPod 4G boot ROM :)

Best of luck!