No FAT signature 55-AA in boot sector

[hathach]

I have issues using Elm Cham's fatfs to mount pico's uf2 disk and figure out that Boot sector doesn't include FAT signature 55-AA at offset 510. Current implementation has FAT signature at MBR which is not correct/enough https://github.com/raspberrypi/pico-bootrom/blob/master/bootrom/virtual_disk.c#L295

ideally would be defined here https://github.com/raspberrypi/pico-bootrom/blob/master/bootrom/virtual_disk.c#L63

static const uint8_t boot_sector[] = {
  // existing code
  [510] = 0x55,
  [511] = 0xAA
}

If you think the change make sense I could make an PR for it.

[ghollingworth]

This isn't going to be fixed in any short period of time since it requires a metal mod to the chip. So for the moment, it's probably best to 'not check' for it in the software.

[hathach]

thanks for the reply, I am well aware this is burn into rom and a fix will need a re-fab or some sort. I have already implement and walkaround for this. Basically just insert the magic into 510 offset when reading lba=1 (skip the check will need to modify the fatfs library). Hope this will help others, feel free to close it at anytime.

    // sector 0 is MBR
    // sector 1 is boot sector, but it doesn't have FAT signature
    if (sector == 1)
    {
      buff[510] = 0x55;
      buff[511] = 0xAA;
    }

[kilograham]

Its a bit of a weird one to be checking actually, since Windows itself will happily mount such a volume, and those fields are supposed to indicate a bootable volume (which this isn't). Windows FYI is happy without these two bytes, but still seems to require valid boot code in the first 3 bytes) go figure.

[emaste]

We recently made a change in FreeBSD to accommodate this (after a user discovered we did not automount a pico): https://github.com/freebsd/freebsd-src/commit/e06ce938ddc0222c6ed10a70108f71685923bd45

There's some commentary in a FreeBSD bug report at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262964 - FreeBSD shouldn't be checking for 55 AA at all, instead doing more thorough validation of the BPB.

/*
 * XXX the signature 0x55 0xAA as the last two bytes of 512 is not required
 * by specifications, but was historically required by fstyp.  This check
 * should be removed, with a more comprehensive BPB validation instead.
 */

[popy2k14]

I am working on using the pico as device connected to android tablets. Tested on two android devices (One with android 10 & one with android 11) and both come up with "Format of the device is needed" popup.

So i think also android has such an detection issue!

The really bad thing about is, with issue in the rom itself, i can not auto update the RPI from the android hosts.

[Zitt]

Is it possible for someone to fork this repo with the required fixes and with clear instructions to compile as a Second Stage bootloader? IE to test functionality on existing silicon?

[lurch]

I've not tried it myself, but I spotted this project a while ago and thought it looked interesting: https://github.com/brendena/pico_drag_n_drop_programmer Perhaps it can be adapted to do what you're asking for?

[matsobdev]

@popy2k14 Yes, it would be nice to have opportunity to just flash UF2 from Android, but some. Android 8.0.0 on Galaxy S7, not working, but eg. Kaon kstb6077 STB (8.0.0) - no problem. Maybe clue might be a fact, that it is host only USB.

[Zitt]

So; did "we" miss this fix for a " a metal mod to the chip" for the Pico 2? If so a real disappointment.

[kilograham]

nope, it is fixed in RP2350; this is the repo for the RP2040 bootrom