Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No FAT signature 55-AA in boot sector #5

Open
hathach opened this issue Feb 26, 2021 · 10 comments
Open

No FAT signature 55-AA in boot sector #5

hathach opened this issue Feb 26, 2021 · 10 comments

Comments

@hathach
Copy link

hathach commented Feb 26, 2021

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
Copy link

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
Copy link
Author

hathach commented Mar 30, 2021

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
Copy link
Contributor

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
Copy link

emaste commented Apr 24, 2022

We recently made a change in FreeBSD to accommodate this (after a user discovered we did not automount a pico): freebsd/freebsd-src@e06ce93

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
Copy link

popy2k14 commented Dec 1, 2022

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
Copy link

Zitt commented Jan 16, 2023

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
Copy link

lurch commented Jan 16, 2023

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
Copy link

matsobdev commented Jul 1, 2024

@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
Copy link

Zitt commented Oct 18, 2024

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

@kilograham
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants