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

From: Warner Losh <imp_at_bsdimp.com>
Date: Mon, 03 Oct 2022 03:40:34 UTC
On Sun, Oct 2, 2022 at 9:26 PM Klaus Küchemann <maciphone2@googlemail.com>
wrote:

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

The situation with rpi is more complex than the other arm64 boards that are
supported given the disparity in the availability
and timeliness of documentation for its parts and the difficulty, at least
in the past, to get proper support for people that tried
to make things better. It isn't helped by the hoops that u-boot has to jump
through to boot on this platform to be sure,
which is what you are running into here.

Warner