Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it

On 2022-Oct-9, at 17:28, bob prohaska <fbsd@www.zefox.net> wrote:

> On Sat, Oct 08, 2022 at 11:05:56PM -0700, Mark Millard wrote:
>> On 2022-Oct-8, at 21:09, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>>> On Thu, Oct 06, 2022 at 07:21:21PM -0700, bob prohaska wrote:
>>>> 
>>>> Next experiments will be to try a 0x0577 enclosure with 
>>>> Pi3 and Pi4 running -current with HPS's patch. Probably
>>>> tomorrow. 
>>>> 
>>> 
>>> So far it appears that the 0x0577 enclosures
>> 
>> So more than one of these 0x152d:0x0577 ? Do they all behave
>> similarly for the booting issues?
> 
> To the extent that the 0x0577 enclosures boot Pi4's under both
> FreeBSD and RasPiOS, yes.  
> 
>> 
>> That is with HPS's patch for FreeBSD's main, if I read this
>> correctly. 
> 
> Yes, it is with HPS's patch, but since FreeBSD never had trouble
> booting from USB at any point, it seems a side issue. 

You provided pelorus_console.txt8_no_debug.txt where FreeBSD had
problems, reporting a mountroot failure. The start of that, with
some context, was:

Root mount waiting for: usbus1
usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device JMicron USB Mass Storage (0x152d:0x0577)
Root mount waiting for: usbus1
usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored)

and progressed to:

Mounting from ufs:/dev/da0s2a failed with error 19.

pelorus_console.txt4_mountroot_failure.txt has 3 examples of such
mountroot failures from 3 separate boot attempts, also when
0x152d:0x0577 was in use.

So: Definitely not a side issue for FreeBSD for the
RPi3B/bridge/software involved in those 2 log files.

>> In some respects some of the below is presuming
>> the context of the MFC to 13.1-STABLE and that the patch
>> would continue to work the same in that context.
>> 
> 
>> As I remember you indicated that the 0x152d:0x0583 was being
>> well behaved with RPi3 EDK2, covering one RPi3B.
>> 
> 
> Yes. 
> 
>> So is the 0x152d:0x1561 well behaved on a RPi3B (U-Boot or
>> EDK2 or both)? 
> 
> Works most of the time, but still requires manual intervention.

U-Boot? EDK2? Both? (Possibly answered by-example below.)
What stage(s)?  (Not answered below.)

>> Does that get you to each RPi3B having a
>> good context if you use a 0x152d:0x0577 on a RPi4B?
>> 
> Sort of; The "good" Pi3 is using a 0X1561 enclosure with EDK2,

So this one still has the manual intervention required
sometimes? What stage(s)?

> the other is using an ASMT adapter with bootcode.bin and timeout.

U-Boot? EDK2? Is the combination reliable?

Note: The standard EDK2 related content includes a bootcode.bin in
with the other RPi* firmware --and so bootcode.bin is involved in
any normal EDK2 boot usage. (Adding timeout should not hurt and
might help for some boot media.)

>> So this RPi3B is main [so: 14] now?
> 
> Yes, the "bad" Pi3.

Have any combinations involving this RPi3B worked overall?
Have all the combinations involving this RPi3B been tried?
If yes, which worked the best?

>>> fails
>>> detection with EDK2, silently stopping after the ESC/boot/setup
>>> option expires.
>> 
> 
> Yes.  

The closest text above the "yes" is your text, not mine.
I'm unsure how to interpret this "yes".

>> The EDK2 stage? The FreeBSD loader stage? Log file(s)?
>> 
> I'm still not confident that the second EDK2 boot microSD
> was set up correctly.

Any reason that it is not just an exact/complete copy of
the content of the original (working) EDK2 media, at least
for this stage of testing activity?

> I found an error in config.txt, fixed it
> and that didn't help. Could be more than one error, however. 
> Basically it does not report "no disk" and delivers a blank
> screen.

The above might be worth a serial console log of the sequence.

>> At the EDK2 stage, the FreeBSD kernel is not involved.
>> (The HPS patch is a kernel patch, if I understand right,
>> not a loader patch. So: the kernel not involved in this
>> failure if I read things right.)
>> 
> Understood.
> 
>> At the EDK2 stage, finding, loading, and starting the
>> FreeBSD loader (on the same media that the FreeBSD kernel
>> is to be from, but in the msdosfs) is eventually involved.
>> No extra copies of the FreeBSD loader in any other msdosfs
>> should be present. I can not tell form the wording if the
>> FreeBSD loader was found, loaded, or started vs. if things
>> hung up before the FreeBSD loader was found.
> 
> There were no extaneous files on the microSD card, but there 
> was a full suite of MSDOS files on the USB disk. That didn't
> cause problems on the first Pi3. On the second? Maybe...

Extra files on the USB media should not hurt anything so
one as there is only one msdosfs with the FreeBSD boot
loader in its required path.

>> I assume "usb-serial bridge" means USB-SATA-bridge.
>> 
> Yes, sorry. Not a typo, but a "braino"....
> 
>> I'm back to not being able to track logs vs. labeling. Is
>> the following right?
>> 
>> JMS561: 0x152d:0x1561     (how many of these?)
> Only one, used on a Pi4. No problems, so not reported

You now indicate manual intervention for a RPi3B (earlier
above).

>> JMS576: 0x152d:0x0583     (how many of these?)
> Only one
>> JMS578: 
> One

So is the JMS578 a 0x152d:0x0578 ?

It seems to be another one for which I've not seen any logs.

>> 0x152d:0x0577 (?) (how many of these?)
> Two. 
> 
>> 
>> I do not remember any log files with/for the 0x152d:0x1561 .
>> Nor do I remember any notes about if the 0x152d:0x1561 is
>> well behaved with any RPi3B.
> 
> It's decently behaved with the "good" Pi3, but fails disk discovery
> maybe half the time.

U-Boot? EDK2? Both? What stage(s)?

(Disk discovery happens multiple times overall, including
it happening in FreeBSD.)

> It's perhaps significant that both Pi3's were
> early models that still required setting the OTP bit.

The one I have access to is that old.

(An editing error in recent years means the warranty bit is
set to indicates unsupported overclocking of the RPi3B.
But that happened long after any warranty applied.)

> Maybe the USB
> firmware contains bugs.

Pre-RPi4's, bootcode.bin on the microsd card's msdsofs (if present)
replaces the internal firmware for such.

> Once FreeBSD takes over, they don't bite.  

Again, you have supplied logs showing FreeBSD mountroot errors.
FreeBSD is having troubles with disk discovery, at least when
0x152d:0x0577 is involved with one of the RPi3B.

>> I do not remember your reporting observing any boot-behavior
>> differences between your RPi3B, given the same U-Boot/EDK2,
>> FreeBSD loader, and FreeBSD kernel used on both. If there are
>> such, indicating which RPi3B for each test would be important.
>> 
> The first Pi3, once booted with a JMS bridge, has worked perfectly
> The second Pi3 has so far booted only with the ASMT bridge.

U-Boot? EDK2? both?

I take it you use the term "booted" to mean that there were no
FreeBSD mountroot errors, despite mout root being a FreeBSD
activity with the kernel already running.

> Once
> booted either one works perfectly.  

The kind of activity after mount root finishes does not do
a bunch of the types of activity done by mount root and
before.

>> Having differing U-Boot/EDK2's, FreeBSD loader's, or FreeBSD
>> kernel's that were involved in differing behavior is more likely
>> to follow the firmware/software combination, and not the RPi3B
>> when such are swapped. I do not know if you have done such
>> testing.
> 
> Is it possible to boot ARMv7 on a Pi3 or Pi4?

There is no ARMv7 EDK2 so far as I know. So the ARMv7 U-Boot would
need to be in use U-Boot and the ARMv7 RPi* firmware files would
need to be present.

https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/ (the end of
the BETA) is from this year. Prior to that the official support was
all ARMv7 or ARMv6 based.

> That would let me
> set up a single SATA drive that could be tested on any host in
> my collection with any candidate USB-SATA bridge. 

As I understand, such could work. But I've not tested such
combinations. I doubt that those FreeBSD folks that developed
the RPi4B support did much testing of armv7 use then or since.

I'm not sure how much RAM would be put to use on a RPi4B with
more than 2 GiBytes of RAM.

> To some extent, ARMv7 was the original target system. I rather
> got sidetracked by arm64. It isn't needed for present purposes, 
> the memory demands of 64 bit are a real headache on 1GB hosts.
> I was drawn to it by an expectation that FreeBSD support for 32
> bit systems would atrophy. It hasn't, yet. 

It will be interesting to see how long FreeBSD keeps ARMv7 and
ARMv6 going. Fedora 37 (in BETA) dropped ARMv7, not having ARMv6
to drop as I understand. Fedora 37 is also the first Fedora to
officially support the RPi4B (and variants).


===
Mark Millard
marklmi at yahoo.com