From owner-freebsd-arm@freebsd.org Tue Mar 16 17:17:03 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 10CB65B60A1 for ; Tue, 16 Mar 2021 17:17:03 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F0Kht3TFCz4qxg for ; Tue, 16 Mar 2021 17:17:01 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x432.google.com with SMTP id o14so7077743wrm.11 for ; Tue, 16 Mar 2021 10:17:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=XUrC4hG8g0c8BLKRmVMk/rCqPKqEy5jONP8Ekj8ALq8=; b=GGXHgTdeZTxNYdHM3eWBSYb7C1c7Nbr81kx1A4rvikRTgdZQdBNulbgx1w37wq8d1M YIqDf2Ce9mEnCkOddP03DudiKKVTeDaXEB3SbOjJhkmVI57p7wCN6L/58AmIb69k9CTr +9poAqArjpLScTyfNT+DsC0jfvCLk7/NOiXfdGGlq+34OmXh8D4Jm/JFoqnX48OsGoev zr2ueCVHc/16HEkO8+XgblrQWY3rOTjQ2hAqUH4D2+/dc6iJeaf5NvIwoXGZ8gAPjifH w/TuKiTPXnjtoQ4YInF5SZ68JCTMNzqcizImCZkBRFWxNwLqO2KqUqYmID+rEB2yhVhZ q5yA== X-Gm-Message-State: AOAM533pbvd8tY7eywgvERu3vvJ0E5hdAFvosnXxtdYlcXPESVPZwDAd INY+UhdUVhTdFcZzPBF8e60= X-Google-Smtp-Source: ABdhPJy/9iL6+GfJpbyN15ZngatKAPGbHIV/p0joU+s8psBHpWzDz8isHJfxoiJ+trF2hI4SL0bMuQ== X-Received: by 2002:a5d:5043:: with SMTP id h3mr92918wrt.120.1615915020750; Tue, 16 Mar 2021 10:17:00 -0700 (PDT) Received: from [192.168.1.167] (dynamic-046-114-153-138.46.114.pool.telefonica.de. [46.114.153.138]) by smtp.googlemail.com with ESMTPSA id 91sm23922380wrl.20.2021.03.16.10.16.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Mar 2021 10:17:00 -0700 (PDT) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: rpi4b main-n245392-8423f5d4c12 won't boot due to microsd timeout [FIXED] Date: Tue, 16 Mar 2021 18:16:58 +0100 References: <79EB88DA-0144-4A12-B716-3CF5011F16C4@yahoo.com> <0281510F-3FDF-4500-AD98-D20A2150BD91@googlemail.com> To: Mark Millard , freebsd-arm@freebsd.org, tech-lists In-Reply-To: Message-Id: <4DF0F59D-20A8-4E80-8AA6-76A85C8BDC38@googlemail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4F0Kht3TFCz4qxg X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org,zyxst.net]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::432:from]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[46.114.153.138:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::432:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::432:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 17:17:03 -0000 > Am 16.03.2021 um 11:23 schrieb Mark Millard : >=20 > On 2021-Mar-15, at 23:26, Klaus K=C3=BCchemann wrote: >=20 >> Am 16.03.2021 um 02:50 schrieb Mark Millard via freebsd-arm = : >>>=20 >>> So there would seem to be no urgent aspect of >>> existing RPi[34] u-boot ports vs. Klaus K.'s >>> build(s) to lead Klaus to put up reviews on >>> Phabricator for updates to: >>>=20 >>> sysutils/u-boot-rpi-arm64 >>> sysutils/u-boot-rpi3 >>> sysutils/u-boot-rpi4 >>=20 >> Well, while it would be possible to suggest (pre-)-patches e.g. in = sysutils/u-boot-rpi4 for review, if necessary ... >> it=E2=80=99s not possible to upgrade u-boot-release-versions only for = the RPI in its single-ports, >> because there is a single =E2=80=9AMasterdir`- u-boot which will = upgrade all u-boot-single-ports in the ports-tree. >=20 > As I understand some of the sysutils/u-boot-master/Makefile > notation, there is a hook for slave ports to specify a > UBOOT_VERSION different from 2020.10 without changing > other u-boot ports: >=20 > # grep UBOOT_VERSION /usr/ports/sysutils/u-boot*/Makefile > /usr/ports/sysutils/u-boot-master/Makefile:PORTVERSION=3D = ${UBOOT_VERSION} > /usr/ports/sysutils/u-boot-master/Makefile:.if !defined(UBOOT_VERSION) = && defined(UBOOT_VERSION_${FAMILY:tu}) > = /usr/ports/sysutils/u-boot-master/Makefile:UBOOT_VERSION=3D${UBOOT_VERSION= _${FAMILY:tu}} > /usr/ports/sysutils/u-boot-master/Makefile:UBOOT_VERSION?=3D 2020.10 > /usr/ports/sysutils/u-boot-master/Makefile:.if = defined(U_BOOT_SLAVE_PORTREVISION_${UBOOT_VERSION}) > /usr/ports/sysutils/u-boot-master/Makefile:PORTREVISION=3D = ${U_BOOT_SLAVE_PORTREVISION_${UBOOT_VERSION}} >=20 > Note the: >=20 > UBOOT_VERSION?=3D 2020.10 >=20 > which makes 2020.10 just a default that a slave > ports can override. well, of course we can override whatever we want when doing for = ourselves. But in this case it wouldn=E2=80=99t even make sense only for myself as = 1 person, because I have 4 or 5 totally different compile -targets. Of course, this only applies in principle, because exceptions confirm = the rule. 1 popular exception was the =E2=80=9Eboot-from-SSD-killer-feature=E2=80=9C= where I uploaded a=20 U-boot-rc somewhere together with a dts-patch before that patches made = it upstream somewhere. So FreeBSD was able to boot off xhci even before some tux-distros . >=20 >> masterdir-upgrades usually come relatively slow in FreeBSD, sometimes = weeks after the upstream. >=20 > Possibly because folks have not been putting > up reviews to get a committer to apply an > update that they have tested first. Well, when understanding u-boot- releases(not rc) as an needed = upstream-source , I don`t think that there would be any technical objection doing = u-boot-upgrades nearly "the same day" as the upstream does.=20 Well, I remember that putting up reviews in this context can lead to = something like complication ,I=E2=80=99m sure you also remember :-) Ha = Ha=20 >=20 >> So if we want u-boot release-candidates (-rc) , faster ports-upgrades = or add own features, upstream-patches: we have to compile them = ourselves.=20 >=20 > It is true that someone likely has to build > and test before committal by a committer > (and you have in the example at hand). >=20 >> That=E2=80=99s why I upload them sometimes to somewhere for some = reason(testing, patches, whatever). >=20 > So there has been more than personal testing > by you. Well, for u-boot it=E2=80=99s always good to have the latest( in = contrast to the firmware). >=20 >> Fortunately u-boot is not as much error-prone as the firmware so = uploads of u-boot - rc can be more seen as feature. >>=20 >> As an example it would be possible to apply patches to : >>> sysutils/u-boot-rpi-arm64 >>> sysutils/u-boot-rpi3 >>> sysutils/u-boot-rpi4 >> But the maintainers then always have look if patches made it = upstream and then remove/change=20 >> them again for every single port with the next release=E2=80=A6 = understandable why they would not like that :-) >=20 > Not true for those 3 ports, at least as worded: those 3 > ports have no maintainer now. (A committer might impose > requirements to be willing to commit but their judgments > might not exactly match what they would make as a > maintainer.) >=20 > And, again, there seem to be hooks in the infrastructure > to support having something other than 2020.10 for some > u-boot ports but not others. This suggests that using > newer is not, of itself, out of bounds. >=20 IIRC it=E2=80=99s the firmware-port which is out of maintenance, not = u-boot ?? But seeing Mike`s name mentioned in the sysutils/u-boot-rpi-arm64 - port=20= seems to clearly mean that there=E2=80=99s 'official' interest to get = things under control ;-) >> =E2=80=A6.while on the other hand it=E2=80=99s not so uncommon to = apply patches before they make it upstream in u-boot. >> So self-compiling makes life a bit easier. >=20 > Note that I've no clue if you had to do patching > of something that could possibly go upstream or > not. The above could apply either way. I did nothing special with u-boot2021-04-rc3 (except unimportant = 'ums'-feature), In this case I was more interested in having the latest = upstream-patches(not only for the rpi). > Am 16.03.2021 um 17:44 schrieb tech-lists : >=20 > If my usb3 disk is plugged in after it boots, the pi will panic. If I = reboot replacing just the u-boot with Klaus's u-boot, I get the same = result.=20 > If I replace all 3 files with the latest versions as described in the > URLs, (again generic kernel so with debug on main/14), it will still = panic when usb is plugged in.=20 of course that panic really should never happen. Having a =E2=80=9Epoisoned=E2=80=9C mix of firmware-files can lead to = that. USB needs a clean combination of at least fixup4x.dat, start4.elf & = bcm2711-rpi-4-b.dtb. So you could use the git-tagged one mentioned by Mark or the complete=20 Msdos-partition(only for 4b) I had uploaded. If your machine still panics (even after a msdos-partition - cleanup) : please report wit dmesg(if possible), Thank you ! =E2=80=A6.P.S: overwriting u-boot is much less risk than overwriting = firmware-files !) K.=