Re: Boot from USB on RPi4 8GB? [SOLVED]

On 2021-Jun-12, at 18:18, William Carson <freebsd at dsllsn.net> wrote:

> . . .
>> 
>>> Sadly, it also would not boot from either of my NVMe-USB adapters.
>> 
>> Is the failing behavior identical to before? If not, what
>> evidence is it now producing when trying to boot? ("would
>> not boot" leaves open all possible ways of failing.)
>> 
>> You previously reported getting:
>> 
>> QUOTE
>> scanning bus xhci_pci for devices... Device NOT ready
>>  Request Sense returned 02 04 01
>> END QUOTE
>> 
>> Someone else recently was getting that and got around
>> the problem while trying 3 U-Boot extra steps. They
>> are listed below and I leave in the indication of which
>> happened to work in that context. The point is to
>> establish a configuration setting before U-Boot tries to
>> scan the USB buses looking for the storage media.
>> Otherwise a "usb reset" would need to happen after
>> making the configuration change.
>> 
>> QUOTE
>>> Looking around on the web I see reports of the:
>>> 
>>> Request Sense returned 02 04 01
>>> 
>>> (and the matching Device NOT ready) mean that the
>>> problem will occur and that repeating usb start
>>> or usb reset again until it does not report that
>>> leads to things working.
>>> 
>>> But I've also seen other, more complete information
>>> indicating that there is a environment setting
>>> (showing an example value):
>>> 
>>> usb_ready_retry=5
>>> 
>>> to set up before the usb restart (or usb start)
>>> command. It deals with the issue more explicitly
>>> for slow devices.
>>> 
>>> Another one is (units: msec):
>>> 
>>> usb_pgood_delay=10000
>>> 
>> Presto! using editenv usb_pgood_delay prompted for input, typing 10000
>> and hitting return set the value and the disk was found.
>> 
>> It looks like the setting can only be saved to microSD. With
>> no card saveenv reports
>> Saving Environment to FAT... Card did not respond to voltage select!
>> Failed (1)
>> 
>>> There are also device that have problems with
>>> large transfers and require extra protocol to
>>> deal with transfer problems before they will
>>> work again, U-Boot not doing that.
>>> 
>>> usb_max_blk=20
>>> 
>>> sets a old historical value that generally
>>> just works for such devices form what I read.
>>> 
>>> I see no indication that other usb commands are
>>> worthwhile until one has avoided that "Request
>>> Sense returned 02 04 01" message for usb reset
>>> (a.k.a. usb start).
>>> 
>>> The reports of this sort of thing are not limited
>>> to RPi's and go back to at least 2014.
>>> 
>>> If I understand correctly, usb_ready_retry and
>>> usb_pgood_delay and usb_max_blk are part of
>>> normal U-Boot builds these days. But I'm not
>>> certain of that.
>> 
>> END QUOTE
> 
> Ok, so in the scenario of SN550 + GeekWorm + USB3, when I'm at the U-Boot> prompt, I did the following:
> 
>    editenv usb_pgood_delay
>    edit: 10000
>    editenv usb_ready_retry
>    edit: 5
>    editenv usb_max_blk
>    edit: 20
>    usb reset ; run usb_boot
> 
> And we have a successful USB3 boot all the way to the login prompt! Unfortunately as indicated, I could not saveenv. I'm not going to bother any more with the Samsung NVMes due to the power issue and not having any way to provide external, dedicated power to them.
> 
> With this success, I figured I'd try adding these env values to my u-boot build and go back to using my crochet image. I added this patch to sysutils/u-boot-rpi4:
> 
> # cat files/patch-include_configs_rpi.h
> --- include/configs/rpi.h.orig  2021-06-12 23:20:03.061510000 -0000
> +++ include/configs/rpi.h       2021-06-12 23:20:14.131306000 -0000
> @@ -209,6 +209,9 @@
>        ENV_DEVICE_SETTINGS \
>        ENV_DFU_SETTINGS \
>        ENV_MEM_LAYOUT_SETTINGS \
> +       "usb_pgood_delay=10000\0" \
> +       "usb_ready_retry=5\0" \
> +       "usb_max_blk=20\0" \
>        BOOTENV

I'd be surprised if all 3 assignments were required for your
specific context: likely more than what is necessary for that
context.

But it might not be worth bothering to explore for a more
minimal combination/singleton.

> I built my new image, dd'ed it to the SN550, and booted with the GeekWorm + USB3. I aborted the autoboot and did a printenv to confirm the environment variables were set. They were. I pulled the power and did a fresh boot, and we booted successfully all the way to the FreeBSD login prompt! Problem solved indeed.

Cool.

> Thank you so much for all of your help and patience, Mark. I wonder if maybe those defaults should be added to the u-boot-rpi4 or u-boot-rpi-arm64 ports? (I won't pretend to know how this might impact other users.)
> 
> Oh, also, I dropped usb_pgood_delay down to 2000, which seemed common for other boards and worked just fine:

Again: Cool.

> -boot-2021.04/configs/teres_i_defconfig:CONFIG_PREBOOT="setenv usb_pgood_delay 2000; usb start"
> u-boot-2021.04/include/configs/alt.h:   "usb_pgood_delay=2000\0"
> u-boot-2021.04/include/configs/aristainetos2.h: "usb_pgood_delay=2000\0" \
> u-boot-2021.04/include/configs/beacon-rzg2m.h:  "usb_pgood_delay=2000\0"        \
> u-boot-2021.04/include/configs/gw_ventana.h:    "usb_pgood_delay=2000\0" \
> u-boot-2021.04/include/configs/minnowmax.h:                                     "usb_pgood_delay=40\0"
> u-boot-2021.04/include/configs/nitrogen6x.h:    "usb_pgood_delay=2000\0" \
> . . .


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)