From owner-freebsd-arm@freebsd.org Sun Sep 27 22:16:10 2020 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 0EBDD373B94 for ; Sun, 27 Sep 2020 22:16:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C00NS5c80z4TZs for ; Sun, 27 Sep 2020 22:16:08 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1601244960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KvfFyVb9ktwtE1Kpx85lX7WL+Ne4+1soFMjg1sM8hTs=; b=eQkayvf64LoqKfpkx8IJVe+dKeRcPW4Kk3YTFWE1+Ijhh4+xRac/uN8gi1rvoov6s3KIf4 psOyFY4oQQOHiWw3vQWQjkIMC2tVTscGBE3WXr6w4CZqePEM/ZPx8j7VFxQNIFcmI3F+Iq YPiHMLri57Q2CxxvofD36M/d8Q6/Mgk= Received: from amy.home (lfbn-idf2-1-288-247.w82-123.abo.wanadoo.fr [82.123.126.247]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 150ab2c2 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 27 Sep 2020 22:16:00 +0000 (UTC) Date: Mon, 28 Sep 2020 00:16:00 +0200 From: Emmanuel Vadot To: John-Mark Gurney Cc: Oskar Holmlund , Oskar Holmlund via freebsd-arm Subject: Re: clock problems with BeagleBone Black on 12.2BETA2 Message-Id: <20200928001600.a66e86d36b5c94294a98358a@bidouilliste.com> In-Reply-To: <20200927220826.GH4213@funkthat.com> References: <202009222004.08MK4xFj037249@mail.karels.net> <8217af510a451f10ea173bf1e26d04dcd50e8ca6.camel@freebsd.org> <1072725987.651720.1600964732891@mail.yahoo.com> <1441631630.802580.1600987963534@mail.yahoo.com> <20200925092059.5b9cb22fa87a478e1254b0f4@bidouilliste.com> <20200927220826.GH4213@funkthat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4C00NS5c80z4TZs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=eQkayvf6; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.01)[0.015]; NEURAL_HAM_LONG(-1.01)[-1.014]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; FREEMAIL_CC(0.00)[yahoo.com,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 22:16:10 -0000 On Sun, 27 Sep 2020 15:08:27 -0700 John-Mark Gurney wrote: > Emmanuel Vadot wrote this message on Fri, Sep 25, 2020 at 09:20 +0200: > > On Thu, 24 Sep 2020 22:52:43 +0000 (UTC) > > Oskar Holmlund via freebsd-arm wrote: > >=20 > > > > Den torsdag 24 september 2020 21:36:38 CEST, Ed Maste skrev:=20 > > > > > > > > On Thu, 24 Sep 2020 at 12:31, Ian Lepore wrote: > > > > > > > > > > It was mentioned on irc a few days ago when someone noticed the B= BB in > > > > > the CI setup was failing... > > > > > > > > > > hrm, looks like BBB has been broken since end of July > > > > > panic: Duplicated clock registration: clk@4_0 > > > > > ah, mmel r363700 > > > > > emaste: im sorry, but this is (unfortunately) expected > > > > > collateral damage. im aware of this problem but right solution is= not > > > > > trivial and it needs more time. > > > > > > > > > > (strejda =3D=3D mmel@) > > > > > > > > > > Then it was mentioned a while later that that BBB is using a very= old > > > > > u-boot, so maybe that has something to do with it. > > > >=20 > > > > I've updated uboot on eMMC on the the CI system's BBB to: > > > > U-Boot SPL 2020.07 (Sep 24 2020 - 04:58:48 +0000)^M > > > >=20 > > > > however it's still failing the same way: > > > >=20 > > > > clk_fixed7: on ofw_clkbus0^M > > > > clk_fixed7: Cannot FDT parameters.^M > > > > device_attach: clk_fixed7 attach returned 6^M > > > > clk_fixed7: on ofw_clkbus0^M > > > > clk_fixed7: Cannot FDT parameters.^M > > > > device_attach: clk_fixed7 attach returned 6^M > > > > ti_clkctrl0: mem 0x14-0x14f on ti_omap4_cm0^M > > > > ti_clkctrl1: mem 0x4-0xd7 on ti_omap4_cm1^M > > > > ti_clkctrl2: mem 0x4-0x7 on ti_omap4_cm2^M > > > > > > > > panic: Duplicated clock registration: clk@4_0 > > > > ^M > > > > ^M > > > > cpuid =3D 0^M > > > > time =3D 1^M > > > > > > > > phk@ reported success booting 13-CURRENT snapshots though, so I'm n= ot > > > > really sure what's going on. > > >=20 > > > Well this is u-boot playing a trick on us. > > >=20 > > > To have a common ground lets assume we use the snapshot from > > > https://download.freebsd.org/ftp/snapshots/arm/armv7/ISO-IMAGES/13.0/ > > > FreeBSD-13.0-CURRENT-arm-armv7-BEAGLEBONE-20200924-3c514403bef.img.xz > > >=20 > > > DD to sd-card and press the "sysboot alter"-button it will boot to lo= gin prompt. > > >=20 > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > Booting [/boot/kernel/kernel]...=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 =A0 > > > Using DTB provided by EFI at 0x87ee7000. > > > Kernel entry at 0x97000200... > > > Kernel args: (null) > > > ---<>--- > > > < remove some 30 lines of output > > > > ofwbus0: > > > simplebus0: on ofwbus0 > > > simplebus1: mem 0x44c00000-0x44c00= 7ff,0x44c00800-0x44c00fff,0x44c01000-0x44c013ff,0x44c01400-0x44c017ff on0 > > > simplebus2: on simplebus1 > > > simplebus3: on simplebus1 > > > simplebus4: on simplebus1 > > > ti_sysc0: mem 0-0x3 on simplebus4 > > > ti_prcm0: mem 0-0x1fff on ti_sysc0 > > > ofw_clkbus0: on ti_prcm0 > > >=20 > > > Login as root and run: > > > root@generic:~ # rm -rf /boot/msdos/dtb/ > > > root@generic:~ # reboot > > >=20 > > >=20 > > > Now at boot we got the same problem as Ed Maste described. > > > At this boot simplebus1 has lost its ranges and ti_prcm0 are also a l= ittle bit different. > > > ... > > > ofwbus0: > > > simplebus0: on ofwbus0 > > > simplebus1: on simplebus0 > > > ti_prcm0: mem 0x200000-0x203fff on si= mplebus1 > > > ofw_clkbus0: on ti_prcm0 > > > clk_fixed0: on ofw_clkbus0 > > > clk_fixed1: on ofw_clkbus0 > > > clk_fixed2: on ofw_clkbus0 > > > clk_fixed3: on ofw_clkbus0 > > > clk_fixed4: on ofw_clkbus0 > > > clk_fixed5: on ofw_clkbus0 > > > .... > > > device_attach: clk_fixed7 attach returned 6 > > > clk_fixed7: on ofw_clkbus0 > > > clk_fixed7: Cannot FDT parameters. > > > device_attach: clk_fixed7 attach returned 6 > > > ti_clkctrl0: mem 0x14-0x14f on ti_omap4_cm0 > > > ti_clkctrl1: mem 0x4-0xd7 on ti_omap4_cm1 > > > ti_clkctrl2: mem 0x4-0x7 on ti_omap4_cm2 > > > panic: Duplicated clock registration: clk@4_0 > > >=20 > > > cpuid =3D 0 > > > time =3D 1 > > > KDB: stack backtrace: > > > db_trace_self() at db_trace_self > > > =A0=A0=A0=A0=A0=A0=A0=A0 pc =3D 0xc04e25f8=A0 lr =3D 0xc00704ac (db_t= race_self_wrapper+0x30) > > > =A0=A0=A0=A0=A0=A0=A0=A0 sp =3D 0xc0d14810=A0 fp =3D 0xc0d14928 > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > > >=20 > > > U-Boot have its own version of devicetree used in the SPL. Later in t= he boot process if "the real" u-boot cant find any devicetree files in its = partition it uses its default. The default are from Linux 4.20: > > > https://github.com/u-boot/u-boot/blob/v2020.07/arch/arm/dts/am33xx.dt= si > > >=20 > > > The devicetree expected by the clock implementation are Linux 5.7 and= later. > > >=20 > > > To fix the problem in CI build - just copy devicetrees from base into= the FAT partition for uboot to find. > > >=20 > > > //Oskar > >=20 > > Thanks for testing on your side Oskar, > >=20 > > As a reminder, using u-boot embedded dtb will almost always result in > > problems. > > At best the dtb embedded is the same one from Linux (and so the same > > one from our tree) but stripped down, nodes are missing etc ... > > At worse it's either from an old version of Linux or a completly > > different one specialy made for u-boot. >=20 > Can we add a FreeBSD specific node, and if it's not present print a > warning? >=20 > I mean, it's less than ideal, but provides some idea. We could even > possibly add a FreeBSD kernel version to the node to do a compare > against... >=20 > I understand the idea of unversioned dtb, but the way that Linux > changes things enough, it seems like it's not really a valid option > in the long run... Yes we can, see https://github.com/evadot/freebsd/commits/dts-freebsd-branded It's not tested yet. > > There is no real way for us to warn the user as dts aren't versionned > > so all we can do is blindly accept the dtb passed to loader(8) via efi > > (or LINUX_BOOT_ABI in case of bootm/booti). > >=20 > > Note that we need u-boot to preload the dtb for us for a few reasons : > > - In a EFI based env we cannot query u-boot for the board name, we > > only have the full DTB. > > - On some boards, like BBB, the same u-boot is used for multiple > > boards (BBB, PocketBeagle etc ...) so booting in a generic way is only > > possible if u-boot load the dtb for us. > > - On some boards u-boot modify the dtb based on the version of the > > boards or something and will enable/disable some nodes or add some new > > ones. >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." --=20 Emmanuel Vadot