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

bob prohaska <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On Sun, Oct 02, 2022 at 07:30:57PM -0700, Mark Millard wrote:
> On 2022-Oct-2, at 17:46, bob prohaska <[email protected]> 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.

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.  

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


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

Thank you for all you help, I'm sorry it's turning
into such a snipe hunt.

bob prohaska
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.