From owner-freebsd-arm@freebsd.org Fri Sep 25 07:21:08 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 D18A03ED1F4 for ; Fri, 25 Sep 2020 07:21:08 +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 4ByNcg43pMz4l2X; Fri, 25 Sep 2020 07:21:07 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1601018460; 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=lLeCQcU7e4kPy63+n+RJdssUZtWQbvgoD2ep4k5KKFQ=; b=nB9jhPiB6gCMb8AIYMjC4X/gy+/2Uay0oWPhPR4R7l2H2oB+Yc92g21yzXebZZ0MMLod7T P6FxIDBuBwpzuKhLM4AwZsJOJBYfFsXXt27/6olntuReYg0P2Y59AVkUThA/oLWgj62fK6 gnJm+1BxZeQl520pcIYWweBYBXkLL+Q= 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 160961c5 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 25 Sep 2020 07:21:00 +0000 (UTC) Date: Fri, 25 Sep 2020 09:20:59 +0200 From: Emmanuel Vadot To: Oskar Holmlund Cc: Oskar Holmlund via freebsd-arm , Ian Lepore , Ed Maste Subject: Re: clock problems with BeagleBone Black on 12.2BETA2 Message-Id: <20200925092059.5b9cb22fa87a478e1254b0f4@bidouilliste.com> In-Reply-To: <1441631630.802580.1600987963534@mail.yahoo.com> References: <202009222004.08MK4xFj037249@mail.karels.net> <8217af510a451f10ea173bf1e26d04dcd50e8ca6.camel@freebsd.org> <1072725987.651720.1600964732891@mail.yahoo.com> <1441631630.802580.1600987963534@mail.yahoo.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: 4ByNcg43pMz4l2X X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=nB9jhPiB; 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.77 / 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)[4]; 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_HAM_LONG(-1.01)[-1.012]; 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_SHORT(-0.23)[-0.230]; NEURAL_HAM_MEDIUM(-1.03)[-1.028]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] 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: Fri, 25 Sep 2020 07:21:08 -0000 On Thu, 24 Sep 2020 22:52:43 +0000 (UTC) Oskar Holmlund via freebsd-arm wrote: > > 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 BBB 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 not > > 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 login = 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-0x44c007ff,= 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 littl= e bit different. > ... > ofwbus0: > simplebus0: on ofwbus0 > simplebus1: on simplebus0 > ti_prcm0: mem 0x200000-0x203fff on simple= bus1 > 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_trace= _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 the b= oot process if "the real" u-boot cant find any devicetree files in its part= ition 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.dtsi >=20 > The devicetree expected by the clock implementation are Linux 5.7 and lat= er. >=20 > To fix the problem in CI build - just copy devicetrees from base into the= FAT partition for uboot to find. >=20 > //Oskar Thanks for testing on your side Oskar, 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. 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). 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 Emmanuel Vadot