Re: clock problems with BeagleBone Black on 12.2BETA2

> Den torsdag 24 september 2020 21:36:38 CEST, Ed Maste <[email protected]> skrev: 
>
> On Thu, 24 Sep 2020 at 12:31, Ian Lepore <[email protected]> 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@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@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@generic:~ # rm -rf /boot/msdos/dtb/
root@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@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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"