clock problems with BeagleBone Black on 12.2BETA2

[Emmanuel Vadot]

On Thu, 24 Sep 2020 22:52:43 +0000 (UTC)
Oskar Holmlund via freebsd-arm <freebsd-arm at freebsd.org> wrote:

> > Den torsdag 24 september 2020 21:36:38 CEST, Ed Maste <emaste at freebsd.org> skrev: 
> >
> > On Thu, 24 Sep 2020 at 12:31, Ian Lepore <ian at freebsd.org> wrote:
> > >
> > > It was mentioned on irc a few days ago when someone noticed the BBB in
> > > the CI setup was failing...
> > >
> > > <emaste> hrm, looks like BBB has been broken since end of July
> > > <emaste> panic: Duplicated clock registration: clk at 4_0
> > > <emaste> ah, mmel r363700
> > > <strejda> 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 == 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.
> > 
> > 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
> > 
> > however it's still failing the same way:
> > 
> > clk_fixed7: <Fixed factor clock> on ofw_clkbus0^M
> > clk_fixed7: Cannot FDT parameters.^M
> > device_attach: clk_fixed7 attach returned 6^M
> > clk_fixed7: <Fixed factor clock> on ofw_clkbus0^M
> > clk_fixed7: Cannot FDT parameters.^M
> > device_attach: clk_fixed7 attach returned 6^M
> > ti_clkctrl0: <TI clkctrl> mem 0x14-0x14f on ti_omap4_cm0^M
> > ti_clkctrl1: <TI clkctrl> mem 0x4-0xd7 on ti_omap4_cm1^M
> > ti_clkctrl2: <TI clkctrl> mem 0x4-0x7 on ti_omap4_cm2^M
> >
> > panic: Duplicated clock registration: clk at 4_0
> > ^M
> > ^M
> > cpuid = 0^M
> > time = 1^M
> >
> > phk@ reported success booting 13-CURRENT snapshots though, so I'm not
> > really sure what's going on.
> 
> Well this is u-boot playing a trick on us.
> 
> 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
> 
> DD to sd-card and press the "sysboot alter"-button it will boot to login prompt.
> 
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...               
> Using DTB provided by EFI at 0x87ee7000.
> Kernel entry at 0x97000200...
> Kernel args: (null)
> ---<<BOOT>>---
> < remove some 30 lines of output >
> ofwbus0: <Open Firmware Device Tree>
> simplebus0: <Flattened device tree simple bus> on ofwbus0
> simplebus1: <Flattened device tree simple bus> mem 0x44c00000-0x44c007ff,0x44c00800-0x44c00fff,0x44c01000-0x44c013ff,0x44c01400-0x44c017ff on0
> simplebus2: <Flattened device tree simple bus> on simplebus1
> simplebus3: <Flattened device tree simple bus> on simplebus1
> simplebus4: <Flattened device tree simple bus> on simplebus1
> ti_sysc0: <TI SYSC Interconnect> mem 0-0x3 on simplebus4
> ti_prcm0: <TI Power and Clock Management> mem 0-0x1fff on ti_sysc0
> ofw_clkbus0: <OFW clocks bus> on ti_prcm0
> 
> Login as root and run:
> root at generic:~ # rm -rf /boot/msdos/dtb/
> root at generic:~ # reboot
> 
> 
> 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 little bit different.
> ...
> ofwbus0: <Open Firmware Device Tree>
> simplebus0: <Flattened device tree simple bus> on ofwbus0
> simplebus1: <Flattened device tree simple bus> on simplebus0
> ti_prcm0: <TI Power and Clock Management> mem 0x200000-0x203fff on simplebus1
> ofw_clkbus0: <OFW clocks bus> on ti_prcm0
> clk_fixed0: <Fixed clock> on ofw_clkbus0
> clk_fixed1: <Fixed clock> on ofw_clkbus0
> clk_fixed2: <Fixed clock> on ofw_clkbus0
> clk_fixed3: <Fixed clock> on ofw_clkbus0
> clk_fixed4: <Fixed clock> on ofw_clkbus0
> clk_fixed5: <Fixed clock> on ofw_clkbus0
> ....
> device_attach: clk_fixed7 attach returned 6
> clk_fixed7: <Fixed factor clock> on ofw_clkbus0
> clk_fixed7: Cannot FDT parameters.
> device_attach: clk_fixed7 attach returned 6
> ti_clkctrl0: <TI clkctrl> mem 0x14-0x14f on ti_omap4_cm0
> ti_clkctrl1: <TI clkctrl> mem 0x4-0xd7 on ti_omap4_cm1
> ti_clkctrl2: <TI clkctrl> mem 0x4-0x7 on ti_omap4_cm2
> panic: Duplicated clock registration: clk at 4_0
> 
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
>          pc = 0xc04e25f8  lr = 0xc00704ac (db_trace_self_wrapper+0x30)
>          sp = 0xc0d14810  fp = 0xc0d14928
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> 
> U-Boot have its own version of devicetree used in the SPL. Later in the 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.dtsi
> 
> The devicetree expected by the clock implementation are Linux 5.7 and later.
> 
> To fix the problem in CI build - just copy devicetrees from base into the FAT partition for uboot to find.
> 
> //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.

-- 
Emmanuel Vadot <manu at bidouilliste.com>