Tons of GPT errors on boot when USB drive is connected

[dnwhoop02]

Odroid N2+ booting from eMMC with a 4TB USB drive.  With the USB drive disconnected, the system boots fine and very quickly.  With the USB drive connected, it throws hundreds of errors for about 30 seconds before finally moving on and booting from the eMMC.  I have no desire to ever boot from SD or USB, so I would like to just disable those options.  I found this topic https://forum.armbian.com/topic/10349-disable-u-boot-usb-support/ but I can't really follow what they're talking about and I have no idea how to patch U-boot or build a new boot image.  Is there an easier way to do this?

 

Here's what the errors look like:

 

Hit any key to stop autoboot:  2  1  0 
starting USB...
Bus usb@ff500000: Register 3000140 NbrPorts 3
Starting the controller
USB XHCI 1.10
scanning bus usb@ff500000 for devices... GPT: first_usable_lba incorrect: 800 > 0
find_valid_gpt: *** ERROR: Invalid GPT ***
GUID Partition Table Header signature is wrong: 0xF0F7C330 != 0x5452415020494645
find_valid_gpt: *** ERROR: Invalid Backup GPT ***
GPT: first_usable_lba incorrect: 800 > 0
find_valid_gpt: *** ERROR: Invalid GPT ***
GUID Partition Table Header signature is wrong: 0xF0F7C330 != 0x5452415020494645
find_valid_gpt: *** ERROR: Invalid Backup GPT ***
GPT: first_usable_lba incorrect: 800 > 0
>>>>> ( Repeated a few hundred times ) <<<<
find_valid_gpt: *** ERROR: Invalid GPT ***
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
find_valid_gpt: *** ERROR: Invalid Backup GPT ***
** Invalid partition 1 **
Couldn't find partition usb 0:1
Card did not respond to voltage select! : -110
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
>>>>>>>( Then it boots normally )<<<<<<<<<<

 

[c0rnelius]

Find the /dev/node `lsblk`

 

Flashing options:

eMMC:
sudo dd if=u-boot.bin of=/dev/mmcblkX bs=512 seek=1

SDCARD:
sudo dd if=u-boot.bin.sd.bin of=/dev/mmcblkX conv=fsync bs=1 count=442
sudo dd if=u-boot.bin.sd.bin of=/dev/mmcblkX conv=fsync bs=512 skip=1 seek=1

 

 

u-boot.bin u-boot.bin.sd.bin

[dnwhoop02]

Just to confirm, in this case would I use /dev/mmcblk1boot0 ?

Where did you get those .bin files (or did you just build them)?  I did a lot of searching on this but couldn't find anything (granted it's probably b/c I didn't know exactly what I was looking for).

 

Thank you!

 

# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda            8:0    0  3.6T  0 disk
└─sda1         8:1    0  3.6T  0 part /mnt/usbdrive
mmcblk1      179:0    0 29.1G  0 disk
└─mmcblk1p1  179:1    0 28.8G  0 part /var/log.hdd
                                      /
mmcblk1boot0 179:32   0    4M  1 disk
mmcblk1boot1 179:64   0    4M  1 disk
zram0        251:0    0  1.8G  0 disk [SWAP]
zram1        251:1    0   50M  0 disk /var/log
zram2        251:2    0    0B  0 disk

 

[c0rnelius]

@dnwhoop02

 

sudo dd if=u-boot.bin of=/dev/mmcblk1 bs=512 seek=1

 

[c0rnelius]

6 hours ago, dnwhoop02 said:

Where did you get those .bin files (or did you just build them)?  I did a lot of searching on this but couldn't find anything (granted it's probably b/c I didn't know exactly what I was looking for).

 

They were custom built.

 

I suspect the issue is: https://github.com/armbian/build/blob/main/patch/u-boot/v2022.10/meson64-boot-usb-nvme-scsi-first.patch

 

[Z11ntal33r]

I just want to say, c0rnelius, you are a lifesaver! I’ve spent several hours trying to figure out this issue, and it’s reassuring to see I’m not the only one dealing with it. This problem must be more common than it seems. I initially thought it was related to power management, as the external drives might be drawing too much power.

 

In my case, I tried countless methods to disable USB power management and other tweaks, but it turns out the simple custom boot file was the ultimate solution!
 

For reference, I’m running v24.11.1 on an Odroid N2 with Armbian Linux 6.6.63-current-meson64

 

Update

This is a more widely issue it seems given there are other releated threads

 

Edited January 28 by Z11ntal33r

[hvedemelsbof]

@c0rneliues very nice, i had a boot loop when usb hdd was connected, that was solved by your build.

The related bananapim5 has a "patch of the patch":

https://github.com/armbian/build/blob/main/patch/u-boot/v2022.10/board_bananapim5/meson64-boot-nvme-scsi-first.patch

shouldn't the base patch just be changed to not prioritize USB? Am i not right, that at least for the N2+, usb boot can be achieved via SPI?

 

Being completely new to u-boot, i also don't understand the difference between the boot.scr environment called 

boot_targets

( https://docs.u-boot.org/en/latest/develop/bootstd/overview.html#boot-targets )

and how that relates to what's being patched directly into the u-boot build shipped with armbian.

I tried to override the boot targets to not include usb by setting the u-boot environment (in boot.cmd and then remaking the .scr file), but that had no effect.

 

It seems like something should be fixed in the armbian release, but i'm not really sure what - would down-prioritizing usb in the armbian patch break usb booting for some?

[c0rnelius]

@hvedemelsbof

 

What the patch is doing is changing the boot targets. Normally SD/MMC would take priority and USB, NVMe and SCSI would be the fall back. With SPI onboard, you could still achieve USB boot by enabling PREBOOT in the u-boot defconfig, along with `usb start`. So in that case the patch wouldn't be required. Same goes for NVMe and SATA boot.

 

In my testing, this also works if you treat the SD or MMC as just a boot mech. Flashing u-boot to it and installing the OS directly to the USB, NVMe or SATA drive.

 

In my opinion those patches should no longer be used, as cleaner methods are available. But that's not my call.

 

Quote

https://docs.u-boot.org/en/latest/develop/bootstd/overview.html#boot-targets

I've never messed with this boot_target variable. Looks to me, if you set that var in the boot.cmd/scr, you can change the hard coded targets. Whether or not it will work on AML units, I have no clue.