IPL binary processing

[9ary]

Currently the PicoBoot build process involves running a PicoBoot-specific script on the DOL to be included in firmware. While it's not a bad idea to keep this separate from the upstream iplboot build script, I think the process should at least be automated.

Additionally, I believe we've discussed using a very small stub as the IPL binary in order to load an unencrypted DOL from PicoBoot flash. This would do two things:

• Lift the restrictions on load address, entry point and size since PicoBoot does not control BS1.
• Allow users to load their own DOL via USB (and possibly via the Swiss file manager), so that PicoBoot does not have to ship with and keep up to date a third party IPL implementation.
  • It would still be perfectly okay to include a default implementation for convenience. I'd suggest sticking with iplboot because Swiss is a fast-moving target and keeping up with it will get old fast. This was the driving force behind iplboot in the first place.

Of course all of this is predicated on overhauling the current codebase to remove the need to duplicate bits in the payload, and enabling PicoBoot to process commands from the GC.

[toru173]

Why do we duplicate bits? I assumed it was either:

A) To get the same bit on 4 pins simultaneously, to allow for higher drive current B) To accomodate for some voodoo required in the Pico’s PIO.

[Extrems]

The answer is A). Although only 2 pins are actually used, webhdx found it only worked with 3-4 pins.

[criptych]

The answer is A). Although only 2 pins are actually used, webhdx found it only worked with 3-4 pins.

If that's the case, why set the drive current to 4ma and duplicate pins instead of using one pin set to 8ma? Honestly curious, I figure there's an aspect I'm missing since it's specifically set to 4ma (although that's apparently the default as well).