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

> Am 03.10.2022 um 04:30 schrieb Mark Millard <marklmi@yahoo.com>:
> 
> On 2022-Oct-2, at 17:46, bob prohaska <fbsd@www.zefox.net> wrote:
> 
>> On Sun, Oct 02, 2022 at 10:18:28PM +0200, Klaus K??chemann wrote:
>>> 
>>> hard to read and remember every log but I thought Bob wrote about aprox. 30 successful reboots after the mdelay patch,
>> 
>> That is correct. Shortly afterward I tried a second usb-sata enclosure.
>> 
>> I didn't immediately notice a difference and though it didn't matter.
>> You comments served to make me think again.
>> 
>>> while of course that could be coincidence, who really knows what happens in this untrackable inconsistent behavior of the usb-boot?!
>> 
>> Unfortunately in this case, human inconsistency (my own, alas) was compounding at least
>> part of the trouble. 
>> 
>> 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.)
> 
>> https://pdf1.alldatasheet.com/datasheet-pdf/view/1136441/JMICRON/JMS576.html
>> Contains a brief description, but I didn't see much quantitative information.
>> 
>> I've reverted the host to the less troublesome JMS576 and will try to 
>> reproduce some of the earlier results as a sanity check.
> 
> 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.
> 
> 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:
> 
> A) microsd cards: Even pre-existing file names for msdosfs
>   end up messed up.
> 
> B) Serial console: once multi-user (or so) starts it is
>   garbage
> 
> (I can ssh into the boot but I've not done much that way,
> given the problems reported above.)
> 
> Another issue is that Device Tree is needed instead of
> ACPI because the ACPI is non-standard [matching Microsoft].
> (For RPi4B EDK2 I use UEFI/ACPI, it being based on the
> standard. Some of the RPi4B's normally run under the
> UEFI/ACPI environment.)
> 
> I retried RPi3B EDK2 today and the above is still the
> status for it.
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com

you can probably fix issue B)(MultiUserGarbage) by changing the baudrate on the fly…
IIRC e.g. with picocom it was by pressing ctrl-k or so …
But from past experience I also think that EDK2 is not the solution…


> Am 03.10.2022 um 04:10 schrieb bob prohaska <fbsd@www.zefox.net>:

> I'd like to see FreeBSD run well on readily available, inexpensive hardware. That. used to be an i386 PC clone. Soon it'll be something else. I hope some flavor of Pi. ..
> .. I'm just a squeaky wheel.

We squeaky wheels tend to use squeaky Operating Systems on squeaky hardware :-) Ha Ha..
For the Pi platform we would have to immediately begin developing drivers like Wifi, audio, perhaps graphics 
to be an appropriate fbsd-client-setup.
Understanding bootloaders like here is a good starting point but if we are not willing to start the driver thing on our own,
Without the help of any fbsd-developer,
that will be the end of aarch64 cheap hardware for FreeBSD.
Instead a cheaper amd64 will do it(makes good progress but even amd is sometimes frustrating lacking features such as appropriate 
Bluetooth audio or so).

Regards

Klaus