From nobody Mon Oct 03 03:40:34 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mgmnq6fbGz4fK4d for ; Mon, 3 Oct 2022 03:40:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mgmnq0CPKz3Hrd for ; Mon, 3 Oct 2022 03:40:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x62e.google.com with SMTP id kg6so4185196ejc.9 for ; Sun, 02 Oct 2022 20:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=QwZbQE4fiW9z0ms/yi3lWKV93iwh7NDGEEW/JKSPn4w=; b=rbxS4m/GxqvGYFCHYS+uqixmF+1Nda4M0/Qz89YhBMoHOF4xB/rnhjHI+HyVHtGjJK +3g9RNvxtnt5jSvZZcmwyi0MQJYAA557lesqRhI/0MuFgWC/YBfNrA3GOVUAx2zbmwlZ TYOpyRtbp/yE56H+Q9KmVVVi88nTeQcvgWIzCjZIli9je4Sp7IxLAWvkmpZvz7d5tu1v v+7n1wrc5KGStzqamb9fh9ZXa6e87PDXTQHrZGGVXQxS0Sqegg4Aq0Blx3/D1zDI/6+A z1GBSUie/yQxmB4q5QDTEvGw08F17VpbXNb83tGekBGIeBgtHkJvOC6w1bxh50I3aa1g h14w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=QwZbQE4fiW9z0ms/yi3lWKV93iwh7NDGEEW/JKSPn4w=; b=ONQLWA+ajKS7QsyFqLyTHBpGed9uKuwWuDI1lQSaaigMLL5CUUZzvkhX9CsutYKQOh asHxw7W1UinHS/vCWwn+25OsZzJ08iYuR/eXVfjOv4p5SX87sN3cCE8g1FmsFcya0lnA 8h9LG2/+EBQHL/NmoKqORyEc39YS1oXH3qze0nXavwR1FPlLJRfPVi7fvtS7Rmv2ICcc rC48NqHhwa0dV1HOYO1GXzFVnsRlvCwRKs60KDXU6AKwbkjjUuoMVMtyb5zE2A4zZvN4 2svT87/0OUQdwBthcSEvlTgTOtVL0oHqhSdeVSS7rTyJXNcGA8j4d2olfKUF6VcJ0AmG xtEg== X-Gm-Message-State: ACrzQf3XWkduW5ivI1qtbi4elagMsx+nUgg5kj1itqRJ+UqomyEgbFZx e3SYP471IEXZJ32Bq8lkIpesgAP7oax1Q0n9wuGViQ== X-Google-Smtp-Source: AMsMyM4N2Myp++AyAQjYQEC5tl2jT0KV1EosN0AsZO0scXxqchvo2C7T0zRFWELmbUeqb80fst/31gW7WO7JVPusKv8= X-Received: by 2002:a17:907:e91:b0:782:607a:8dc9 with SMTP id ho17-20020a1709070e9100b00782607a8dc9mr14147025ejc.729.1664768445182; Sun, 02 Oct 2022 20:40:45 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <20221001174724.GA98055@www.zefox.net> <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> <20221003004624.GA3381@www.zefox.net> <385E11EB-A2AB-4218-AA6C-91752B0899A7@googlemail.com> In-Reply-To: <385E11EB-A2AB-4218-AA6C-91752B0899A7@googlemail.com> From: Warner Losh Date: Sun, 2 Oct 2022 21:40:34 -0600 Message-ID: Subject: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it To: =?UTF-8?Q?Klaus_K=C3=BCchemann?= Cc: Mark Millard , bob prohaska , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000cf0c2705ea191b18" X-Rspamd-Queue-Id: 4Mgmnq0CPKz3Hrd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="rbxS4m/G"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[googlemail.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEMAIL_CC(0.00)[yahoo.com,www.zefox.net,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N --000000000000cf0c2705ea191b18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 2, 2022 at 9:26 PM Klaus K=C3=BCchemann wrote: > > > > Am 03.10.2022 um 04:30 schrieb Mark Millard : > > > > On 2022-Oct-2, at 17:46, bob prohaska 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.h= tml > >> 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. > > > > > > =3D=3D=3D > > Mark Millard > > marklmi at yahoo.com > > you can probably fix issue B)(MultiUserGarbage) by changing the baudrate > on the fly=E2=80=A6 > IIRC e.g. with picocom it was by pressing ctrl-k or so =E2=80=A6 > But from past experience I also think that EDK2 is not the solution=E2=80= =A6 > > > > Am 03.10.2022 um 04:10 schrieb bob prohaska : > > > 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 ar= e > 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 --000000000000cf0c2705ea191b18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 2, 2022 at 9:26 PM Klaus = K=C3=BCchemann <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:<= br> >>>
>>> hard to read and remember every log but I thought Bob wrote ab= out aprox. 30 successful reboots after the mdelay patch,
>>
>> That is correct. Shortly afterward I tried a second usb-sata enclo= sure.
>>
>> I didn't immediately notice a difference and though it didn= 9;t matter.
>> You comments served to make me think again.
>>
>>> while of course that could be coincidence, who really knows wh= at 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 troub= lesome JMS576.
>
> I'm confused. The logs I have show 0x0583 (earlier) and 0x577 (lat= er).
> 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<= br> > the ??? part.)
>
>> https://pdf1.al= ldatasheet.com/datasheet-pdf/view/1136441/JMICRON/JMS576.html
>> Contains a brief description, but I didn't see much quantitati= ve 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
>=C2=A0 =C2=A0end up messed up.
>
> B) Serial console: once multi-user (or so) starts it is
>=C2=A0 =C2=A0garbage
>
> (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

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


> 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 e= lse. 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 l= ike 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 some= times frustrating lacking features such as appropriate
Bluetooth audio or so).

The situation w= ith rpi is more complex than the other arm64 boards that are supported give= n the disparity in the availability
and timeliness of documentati= on for its parts and the difficulty,=C2=A0at least in the past, to get prop= er support for people that=C2=A0tried
to make=C2=A0things better.= It isn't helped by the hoops that u-boot has to jump through to boot o= n this platform to be sure,
which is what you are running into he= re.

Warner

--000000000000cf0c2705ea191b18--