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

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?

> work without
> trouble on Pi4 under both FreeBSD-current and RasPiOS. No
> microSD, they just boot.

That is with HPS's patch for FreeBSD's main, if I read this
correctly. 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.

So is the 0x152d:0x1561 well behaved on a RPi3B (U-Boot or
EDK2 or both)? Does that get you to each RPi3B having a
good context if you use a 0x152d:0x0577 on a RPi4B?

> The two Pi3's in hand seem to behave very differently using
> u-boot vs EDK2. The Pi3 running 13-stable worked better with
> EDK2, the machine just updated to capture HPS's patch

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

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

The EDK2 stage? The FreeBSD loader stage? Log file(s)?

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

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.

> Likely my fault, but haven't found it yet.
> 
> It does appear that the two Pi3's are somewhat different. They were
> bought some time apart, but these are the two which shared a MAC 
> address. Perhaps there are other anomalies. This is in addition
> to the variety of usb-serial bridge used, JMS 561, 576 (583) or
> 578. 

I assume "usb-serial bridge" means USB-SATA-bridge.

I'm back to not being able to track logs vs. labeling. Is
the following right?

JMS561: 0x152d:0x1561     (how many of these?)
JMS576: 0x152d:0x0583     (how many of these?)
JMS578: 0x152d:0x0577 (?) (how many of these?)

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.

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.

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.

===
Mark Millard
marklmi at yahoo.com