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

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. 

> 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.

> 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,
the other is using an ASMT adapter with bootcode.bin and timeout.

> 
> So this RPi3B is main [so: 14] now?

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

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. 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.

> 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...

> 
> 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
> JMS576: 0x152d:0x0583     (how many of these?)
Only one
> JMS578: 
One
> 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. It's perhaps significant that both Pi3's were
early models that still required setting the OTP bit. Maybe the USB
firmware contains bugs. Once FreeBSD takes over, they don't bite.  

> 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. Once
booted either one works perfectly.  


> 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? 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. 

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. 

Thanks for reading, and all your counsel!

bob prohaska