Date: Sun, 2 Oct 2022 19:30:57 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Klaus K??chemann <maciphone2@googlemail.com>, freebsd-arm@freebsd.org Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <B32F06DD-DFAF-4CB7-A973-7C07846F6E8E@yahoo.com> In-Reply-To: <20221003004624.GA3381@www.zefox.net> References: <E3A1C678-8C47-4283-9F9F-4C9011DB8A2B@yahoo.com> <20221001174724.GA98055@www.zefox.net> <ABFDD634-5CB6-4DAE-B4DE-629CE7E4FE06@yahoo.com> <20221001193033.GA98348@www.zefox.net> <46226720-D867-4AD3-9559-A4365FAC28C4@yahoo.com> <6DB88FC9-629C-43E6-9673-32640FC547F7@yahoo.com> <20221002182049.GA2255@www.zefox.net> <5FFDAA6A-AD8C-4E40-A2EB-4082E5086679@googlemail.com> <38DFEB91-AC60-4FD1-8088-95B0A06C5E5D@yahoo.com> <EEC43DA1-6B68-4FDD-A68A-A3055E86E407@googlemail.com> <20221003004624.GA3381@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >> hard to read and remember every log but I thought Bob wrote about = aprox. 30 successful reboots after the mdelay patch, >=20 > That is correct. Shortly afterward I tried a second usb-sata = enclosure. >=20 > I didn't immediately notice a difference and though it didn't matter. > You comments served to make me think again. >=20 >> while of course that could be coincidence, who really knows what = happens in this untrackable inconsistent behavior of the usb-boot?! >=20 > Unfortunately in this case, human inconsistency (my own, alas) was = compounding at least > part of the trouble.=20 >=20 > 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.ht= ml > Contains a brief description, but I didn't see much quantitative = information. >=20 > I've reverted the host to the less troublesome JMS576 and will try to=20= > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B32F06DD-DFAF-4CB7-A973-7C07846F6E8E>