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

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

> On Sun, Oct 02, 2022 at 07:30:57PM -0700, Mark Millard wrote:
>> On 2022-Oct-2, at 17:46, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>>> 
>>> The more troublesome bridge contains a JMS577 chip, the less troublesome JMS576.
>> 
>> I'm confused. The logs I have show 0x0583 (earlier) and 0x577 (later).
>> I'm not aware of a 0x0576 example in the set at all.
>> 
>> (The JMS??? naming and the 0x0??? product ID's normally match for
>> the ??? part.)
>> 
> On close inspection the enclosure recognized as  0x152d:0x583 
> contains the JMS576 chip. That's the better-behaved one.

Is the JMS576 labeling actually on the chip? (Can you even
see the labeling on the chip?) Or is the JMS576 labeling
more like overall product marketing labeling?

0x0583 vs. 0x0576 leaves open the possibility of a bad
firmware revision in the part?

> The enclosure recognized as 0x152d:0x0577 contains a JMS577 chip,
> that's the worse-behaved unit. 
> 
> It looks like the first two EC-UASP enclosures purchased (which both 
> work fine on RPi4's) report 152d:1561. They are clearly different, 
> with crystal cans on the circuit boards.  

So there are 4 EC-UASP enclosures overall? Could you be so lucky
as to have (oldest EC-UASP's used on oldest RPi* family):

Both 0x152d:0x1561 work with the RPi3B's
and:
0x152d:0x0583 and 0x152d:0x0577 work with the RPi4B's?

(I'm not sure what all combinations have been tried.)

> The two units we're fiddling with presently came much later, under 
> the same product description.  

Ahh.

>> I'll note that I've reverted my active environment back to
>> its normal content. I've not figured out a way to get
>> reasonable evidence, given the combinations we have observed.
> 
> Understood. 
> 
>> I'll note that RPi3 EDK2 UEFI is not an option as far as I
>> know. I've never had it work for two things that I checked
>> up front:
>> 
> 
> I take it that EDK2 is a tool for _writing_ bootloaders,
> not a bootloader itself; is that correct? 

The team(s) that make EDK2 support the RPi3*'s and
RPi4*'s publish releases when they update EDK2. I
actively use a RPi4* EDK2 (UEFI/ACPI) on some 
FreeBSD RPi4B's. (Other RPi4B's have the FreeBSD
U-Boot context instead.) But my usage context is
limited so what is supported via ACPI vs. not is
not significant for me. I also have patches involved
for this usage.

There is the FreeBSD port sysutils/edk2 with FLAVOR's
for rpi3 and rpi4 (and more). These do not track the
specific commits that those teams published based on,
using more recent materials generally.

Currently, building sysutils/edk2 is broken. My
submittal to make it build again has not been applied:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266404

I've no clue if the RPi3* EDK2 UEFI/DeviceTree problems
are just in FreeBSD or not. The EDK2 build supposedly
works with various Linux's when DeviceTree is selected
instead of ACPI. (The RPi3* UEFI/ACPI is Microsoft
specific, not standard --so not appropriate for *BSD or
Linux variants. Device Tree needs to be used.)

===
Mark Millard
marklmi at yahoo.com