Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it
Date: Sun, 09 Oct 2022 06:05:56 UTC
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