* beaglebone black boot failure Linux v5.15.rc1
@ 2021-09-16 9:15 Vaittinen, Matti
2021-09-17 6:14 ` Tony Lindgren
0 siblings, 1 reply; 24+ messages in thread
From: Vaittinen, Matti @ 2021-09-16 9:15 UTC (permalink / raw)
Cc: Tony Lindgren, linux-omap, Grygorii Strashko, Suman Anna,
Andrew F. Davis, Paul Barker, Peter Ujfalusi,
Benoît Cousson, linux-kernel
Hi dee Ho peeps,
Yesterday I asked about this at #armlinux so if someone saw my message
there - this is the same topic.
My beaglebone black (rev c) based test environment fails to boot with
v5.15-rc1. Boot succeeds with the v5.14.
I use pretty old uBoot, TFTP to load kernel and device-tree, and have
hosted the rootfs on NFS server.
The v5.15-rc1 fails to boot with no prints from kernel visible in serial
console. Please see the serial log at the end of this message.
Bisecting the Linus' tree pointed out the commit:
[1c7ba565e70365763ea780666a3eee679344b962] ARM: dts: am335x-baltos:
switch to new cpsw switch drv
I don't see this exact commit touching the BBB device-tree. In Linus'
tree it is a part of a merge commit. Reverting the whole merge on top of
the v5.15-rc1
This reverts commit 81b6a285737700c2e04ef0893617b80481b6b4b7, reversing
changes made to f73979109bc11a0ed26b6deeb403fb5d05676ffc.
makes my beaglebone black to boot again.
Yesterday I tried adding this patch:
https://lore.kernel.org/linux-omap/20210915065032.45013-1-tony@atomide.com/T/#u
pointed by Tom on top of the v5.15-rc1 - no avail. I also did #define
DEBUG at ti-sys.c as was suggested by Tom - but I don't see any more output.
Any suggestions what to check next?
Best Regards
Matti Vaittinen
Serial log below:
Reset Source: Global external warm reset has occurred.
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
reading uEnv.txt
561 bytes read in 4 ms (136.7 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from uEnv.txt
Importing environment from mmc ...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.255.126; our IP address is 192.168.255.1
Filename 'zImage'.
Load address: 0x81000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#######################
4.5 MiB/s
done
Bytes transferred = 9875968 (96b200 hex)
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.255.126; our IP address is 192.168.255.1
Filename 'am335x-boneblack.dtb'.
Load address: 0x82000000
Loading: #####
3.2 MiB/s
done
Bytes transferred = 67151 (1064f hex)
Kernel image @ 0x81000000 [ 0x000000 - 0x96b200 ]
## Flattened Device Tree blob at 82000000
Booting using the fdt blob at 0x82000000
Loading Device Tree to 8ffec000, end 8ffff64e ... OK
Starting kernel ...
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-16 9:15 beaglebone black boot failure Linux v5.15.rc1 Vaittinen, Matti @ 2021-09-17 6:14 ` Tony Lindgren 2021-09-17 10:28 ` Vaittinen, Matti 0 siblings, 1 reply; 24+ messages in thread From: Tony Lindgren @ 2021-09-17 6:14 UTC (permalink / raw) To: Vaittinen, Matti Cc: linux-omap, Grygorii Strashko, Suman Anna, Andrew F. Davis, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2149 bytes --] Hi, * Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> [210916 09:15]: > Yesterday I asked about this at #armlinux so if someone saw my message > there - this is the same topic. > > My beaglebone black (rev c) based test environment fails to boot with > v5.15-rc1. Boot succeeds with the v5.14. > > I use pretty old uBoot, TFTP to load kernel and device-tree, and have > hosted the rootfs on NFS server. Using older u-boot versions should be just fine. Using bootz with zImage instead of uimage is a good reason to update for folks using a really old u-boot though. > The v5.15-rc1 fails to boot with no prints from kernel visible in serial > console. Please see the serial log at the end of this message. > > Bisecting the Linus' tree pointed out the commit: > [1c7ba565e70365763ea780666a3eee679344b962] ARM: dts: am335x-baltos: > switch to new cpsw switch drv > > I don't see this exact commit touching the BBB device-tree. In Linus' > tree it is a part of a merge commit. Reverting the whole merge on top of > the v5.15-rc1 > > This reverts commit 81b6a285737700c2e04ef0893617b80481b6b4b7, reversing > changes made to f73979109bc11a0ed26b6deeb403fb5d05676ffc. > > makes my beaglebone black to boot again. > > Yesterday I tried adding this patch: > https://lore.kernel.org/linux-omap/20210915065032.45013-1-tony@atomide.com/T/#u > pointed by Tom on top of the v5.15-rc1 - no avail. I also did #define > DEBUG at ti-sys.c as was suggested by Tom - but I don't see any more output. Correction, that was me, not Tom :) For me, adding any kind of delay fixed the issue. Also adding some printk statements fixed it for me. > Any suggestions what to check next? Maybe try the attached patch? If it helps, just try with the with the ti,sysc-delay-us = <2> added as few modules need that after enable. It's also possible there is an issue with some other device that is now getting enabled other than pruss. The last XXX printk output should show the last device being probed. Looks like you need to also enable CONFIG_SERIAL_EARLYCON=y, and pass console=ttyS0,115200 debug earlycon in the kernel command line. Regards, Tony [-- Attachment #2: debug.patch --] [-- Type: text/plain, Size: 1056 bytes --] diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi --- a/arch/arm/boot/dts/am33xx-l4.dtsi +++ b/arch/arm/boot/dts/am33xx-l4.dtsi @@ -845,6 +845,7 @@ pruss_tm: target-module@300000 { /* 0x4a300000, ap 9 04.0 */ ti,sysc-sidle = <SYSC_IDLE_FORCE>, <SYSC_IDLE_NO>, <SYSC_IDLE_SMART>; + ti,sysc-delay-us = <2>; clocks = <&pruss_ocp_clkctrl AM3_PRUSS_OCP_PRUSS_CLKCTRL 0>; clock-names = "fck"; resets = <&prm_per 1>; diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -2,7 +2,7 @@ /* * ti-sysc.c - Texas Instruments sysc interconnect target driver */ - +#define DEBUG #include <linux/io.h> #include <linux/clk.h> #include <linux/clkdev.h> @@ -3051,6 +3051,8 @@ static int sysc_probe(struct platform_device *pdev) if (!ddata) return -ENOMEM; + dev_info(&pdev->dev, "XXX %s\n", __func__); + ddata->offsets[SYSC_REVISION] = -ENODEV; ddata->offsets[SYSC_SYSCONFIG] = -ENODEV; ddata->offsets[SYSC_SYSSTATUS] = -ENODEV; ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-17 6:14 ` Tony Lindgren @ 2021-09-17 10:28 ` Vaittinen, Matti 2021-09-17 10:47 ` Tony Lindgren 2021-09-17 10:57 ` Grygorii Strashko 0 siblings, 2 replies; 24+ messages in thread From: Vaittinen, Matti @ 2021-09-17 10:28 UTC (permalink / raw) To: Tony Lindgren Cc: linux-omap, Grygorii Strashko, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel Hi deeee Ho Tony & All, On 9/17/21 09:14, Tony Lindgren wrote: > Hi, > > * Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> [210916 09:15]: >> My beaglebone black (rev c) based test environment fails to boot with >> v5.15-rc1. Boot succeeds with the v5.14. >> >> Bisecting the Linus' tree pointed out the commit: >> [1c7ba565e70365763ea780666a3eee679344b962] ARM: dts: am335x-baltos: >> switch to new cpsw switch drv >> >> I don't see this exact commit touching the BBB device-tree. In Linus' >> tree it is a part of a merge commit. Reverting the whole merge on top of >> the v5.15-rc1 >> >> This reverts commit 81b6a285737700c2e04ef0893617b80481b6b4b7, reversing >> changes made to f73979109bc11a0ed26b6deeb403fb5d05676ffc. >> >> makes my beaglebone black to boot again. >> >> Yesterday I tried adding this patch: >> https://lore.kernel.org/linux-omap/20210915065032.45013-1-tony@atomide.com/T/#u >> pointed by Tom on top of the v5.15-rc1 - no avail. I also did #define >> DEBUG at ti-sys.c as was suggested by Tom - but I don't see any more output. > > Correction, that was me, not Tom :) Oh.. Sorry! I don't know where I picked Tom from... My bad! > For me, adding any kind of delay fixed the issue. Also adding some printk > statements fixed it for me. > >> Any suggestions what to check next? > > Maybe try the attached patch? If it helps, just try with the with the > ti,sysc-delay-us = <2> added as few modules need that after enable. > > It's also possible there is an issue with some other device that is now > getting enabled other than pruss. The last XXX printk output should show > the last device being probed. > > Looks like you need to also enable CONFIG_SERIAL_EARLYCON=y, and pass > console=ttyS0,115200 debug earlycon in the kernel command line. Ah. Thanks again. I indeed lacked the "debug earlycon" parameters. Now we're more likely to see what went wrong :) I pasted the serial log form failing boot with v5.15-rc1 which has both the patch you linked me above and the patch you suggested me to test in previous email. Best Regards Matti [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.15.0-rc1-00002-g5285574596c0 (mvaittin@fedora) (arm-linux-gnueabihf-gcc (Linaro GCC 6.4-2017.11) 6.4.1 20171012, GNU ld (Linaro_Binutils-2017.11) 2.27.0.20161229) #552 Fri Sep 17 15:12:34 EEST 2021 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black [ 0.000000] earlycon: omap8250 at MMIO 0x44e09000 (options '') [ 0.000000] printk: bootconsole [omap8250] enabled [ 0.000000] Memory policy: Data cache writeback [ 0.000000] efi: UEFI not found. [ 0.000000] cma: Reserved 48 MiB at 0x9c800000 [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000080000000-0x000000009fefffff] [ 0.000000] HighMem empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000080000000-0x000000009fefffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000009fefffff] [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] AM335X ES2.1 (sgx neon) [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 129666 [ 0.000000] Kernel command line: console=ttyS0,115200n8 debug earlycon root=/dev/nfs rw nfsroot=192.168.255.126:/home/mvaittin/nfs ip=192.168.255.1:192.168.255.126::255.255.255.0:bbb1:eth0 nfsrootdebug [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Memory: 450224K/523264K available (9216K kernel code, 1684K rwdata, 4988K rodata, 1024K init, 350K bss, 23888K reserved, 49152K cma-reserved, 0K highmem) [ 0.000000] random: get_random_u32 called from cache_alloc_refill+0x301/0x670 with crng_init=0 [ 0.000000] ftrace: allocating 45825 entries in 135 pages [ 0.000000] ftrace: allocated 135 pages with 4 groups [ 0.000000] trace event string verifier disabled [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] IRQ: Found an INTC at 0x(ptrval) (revision 5.0) with 128 interrupts [ 0.000000] TI gptimer clocksource: always-on /ocp/interconnect@44c00000/segment@200000/target-module@31000 [ 0.000001] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns [ 0.008062] clocksource: dmtimer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns [ 0.017961] TI gptimer clockevent: 24000000 Hz at /ocp/interconnect@48000000/segment@0/target-module@40000 [ 0.029510] Console: colour dummy device 80x30 [ 0.034199] Calibrating delay loop... 995.32 BogoMIPS (lpj=1990656) [ 0.062394] pid_max: default: 32768 minimum: 301 [ 0.067399] LSM: Security Framework initializing [ 0.072239] Yama: becoming mindful. [ 0.075866] SELinux: Initializing. [ 0.079586] TOMOYO Linux initialized [ 0.083392] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.090929] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.100024] CPU: Testing write buffer coherency: ok [ 0.105111] CPU0: Spectre v2: using BPIALL workaround [ 0.111068] Setting up static identity map for 0x80100000 - 0x80100054 [ 0.118820] EFI services will not be available. [ 0.124132] devtmpfs: initialized [ 0.143080] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 [ 0.151366] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.161419] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [ 0.173171] pinctrl core: initialized pinctrl subsystem [ 0.179555] DMI not present or invalid. [ 0.184021] NET: Registered PF_NETLINK/PF_ROUTE protocol family [ 0.192575] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.200114] audit: initializing netlink subsys (disabled) [ 0.206594] thermal_sys: Registered thermal governor 'fair_share' [ 0.206609] thermal_sys: Registered thermal governor 'bang_bang' [ 0.212920] audit: type=2000 audit(0.144:1): state=initialized audit_enabled=0 res=1 [ 0.227080] thermal_sys: Registered thermal governor 'step_wise' [ 0.227450] cpuidle: using governor menu [ 0.252742] No ATAGs? [ 0.255098] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.276698] iommu: Default domain type: Translated [ 0.281759] iommu: DMA domain TLB invalidation policy: strict mode [ 0.289435] vgaarb: loaded [ 0.292741] SCSI subsystem initialized [ 0.296853] libata version 3.00 loaded. [ 0.301078] usbcore: registered new interface driver usbfs [ 0.306782] usbcore: registered new interface driver hub [ 0.312290] usbcore: registered new device driver usb [ 0.317793] mc: Linux media interface: v0.10 [ 0.322230] videodev: Linux video capture interface: v2.00 [ 0.327985] pps_core: LinuxPPS API ver. 1 registered [ 0.333096] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 0.342511] PTP clock support registered [ 0.347879] NetLabel: Initializing [ 0.351420] NetLabel: domain hash size = 128 [ 0.355903] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO [ 0.361822] NetLabel: unlabeled traffic allowed by default [ 0.368330] clocksource: Switched to clocksource dmtimer [ 0.470970] VFS: Disk quotas dquot_6.6.0 [ 1.116330] random: fast init done [ 1.439253] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.455668] NET: Registered PF_INET protocol family [ 1.460941] IP idents hash table entries: 8192 (order: 4, 65536 bytes, linear) [ 1.469100] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear) [ 1.477779] TCP established hash table entries: 4096 (order: 2, 16384 bytes, linear) [ 1.485792] TCP bind hash table entries: 4096 (order: 2, 16384 bytes, linear) [ 1.493170] TCP: Hash tables configured (established 4096 bind 4096) [ 1.499824] UDP hash table entries: 256 (order: 0, 4096 bytes, linear) [ 1.506575] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear) [ 1.513951] NET: Registered PF_UNIX/PF_LOCAL protocol family [ 1.520473] RPC: Registered named UNIX socket transport module. [ 1.526589] RPC: Registered udp transport module. [ 1.531433] RPC: Registered tcp transport module. [ 1.536274] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 1.542911] PCI: CLS 0 bytes, default 64 [ 1.549012] Initialise system trusted keyrings [ 1.554162] workingset: timestamp_bits=14 max_order=17 bucket_order=3 [ 1.560945] zbud: loaded [ 1.564591] NFS: Registering the id_resolver key type [ 1.569909] Key type id_resolver registered [ 1.574229] Key type id_legacy registered [ 1.578394] nfs4filelayout_init: NFSv4 File Layout Driver Registering... [ 1.585301] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering... [ 1.593170] fuse: init (API version 7.34) [ 1.597646] orangefs_debugfs_init: called with debug mask: :none: :0: [ 1.604488] orangefs_init: module version upstream loaded [ 1.610057] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled [ 1.707849] Key type asymmetric registered [ 1.712211] Asymmetric key parser 'x509' registered [ 1.717380] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 244) [ 1.725139] io scheduler mq-deadline registered [ 1.729818] io scheduler kyber registered [ 1.734615] ti-sysc target-module@4b000000: XXX sysc_probe [ 1.742605] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled [ 1.753477] libphy: Fixed MDIO Bus: probed [ 1.758477] CAN device driver interface [ 1.762960] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.769732] ehci-pci: EHCI PCI platform driver [ 1.774387] ehci-platform: EHCI generic platform driver [ 1.779857] ehci-omap: OMAP-EHCI Host Controller driver [ 1.785360] usbcore: registered new interface driver usb-storage [ 1.793033] i2c_dev: i2c /dev entries driver [ 1.798277] softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=1) [ 1.806989] softdog: soft_reboot_cmd=<not set> soft_active_on_boot=0 [ 1.814789] cpuidle: enable-method property 'ti,am3352' found operations [ 1.822160] ledtrig-cpu: registered to indicate activity on CPUs [ 1.828718] hid: raw HID events driver (C) Jiri Kosina [ 1.834493] usbcore: registered new interface driver usbhid [ 1.840257] usbhid: USB HID core driver [ 1.844610] drop_monitor: Initializing network drop monitor service [ 1.851533] NET: Registered PF_INET6 protocol family [ 1.857872] Segment Routing with IPv6 [ 1.861728] In-situ OAM (IOAM) with IPv6 [ 1.865858] mip6: Mobile IPv6 [ 1.868926] NET: Registered PF_PACKET protocol family [ 1.874139] can: controller area network core [ 1.878687] NET: Registered PF_CAN protocol family [ 1.883710] Key type dns_resolver registered [ 1.888114] mpls_gso: MPLS GSO support [ 1.892201] ThumbEE CPU extension supported. [ 1.896615] Registering SWP/SWPB emulation handler [ 1.901550] omap_voltage_late_init: Voltage driver support not added [ 1.908824] registered taskstats version 1 [ 1.913108] Loading compiled-in X.509 certificates [ 1.918224] zswap: loaded using pool lzo/zbud [ 1.923115] Key type ._fscrypt registered [ 1.927294] Key type .fscrypt registered [ 1.931339] Key type fscrypt-provisioning registered [ 1.939318] Key type encrypted registered [ 1.943634] ima: No TPM chip found, activating TPM-bypass! [ 1.949397] ima: Allocated hash algorithm: sha256 [ 1.954333] ima: No architecture policies found [ 1.974048] ti-sysc 44d00000.target-module: XXX sysc_probe [ 1.979958] ti-sysc 44d00000.target-module: 44d00000:4000:0:NA:NA:12152dd2 [ 1.988004] remoteproc remoteproc0: wkup_m3 is available [ 1.995587] ti-sysc 44e00000.target-module: XXX sysc_probe [ 2.001499] ti-sysc 44e00000.target-module: 44e00000:2000:0:NA:NA:03004502 [ 2.009249] ti-sysc 44e07000.target-module: XXX sysc_probe [ 2.015294] ti-sysc 44e07000.target-module: 44e07000:1000:0:10:114:50600801:gpio [ 2.024517] ti-sysc 44e09050.target-module: XXX sysc_probe [ 2.030321] ti-sysc 44e09050.target-module: 44e09000:1000:50:54:58:50412603:uart [ 2.039014] ti-sysc 44e0b000.target-module: XXX sysc_probe [ 2.044819] ti-sysc 44e0b000.target-module: 44e0b000:1000:0:10:90:5040000b:i2c [ 2.053206] ti-sysc 44e0d000.target-module: XXX sysc_probe [ 2.058993] ti-sysc 44e0d000.target-module: 44e0d000:1000:0:10:NA:47300001:adc [ 2.066973] ti-sysc 44e10000.target-module: XXX sysc_probe [ 2.072739] ti-sysc 44e10000.target-module: 44e10000:10000:0:NA:NA:4e8b0100:scm [ 2.081798] pinctrl-single 44e10800.pinmux: 142 pins, size 568 [ 2.091090] ti-sysc 44e31000.target-module: XXX sysc_probe [ 2.096953] ti-sysc 44e31000.target-module: 44e31000:1000:0:10:14:00000015:timer [ 2.105039] ti-sysc 44e35000.target-module: XXX sysc_probe [ 2.111512] ti-sysc 44e35000.target-module: 44e35000:1000:0:10:14:502a0501:wdt [ 2.120298] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec [ 2.128247] ti-sysc 44e3e074.target-module: XXX sysc_probe [ 2.134064] ti-sysc 44e3e074.target-module: 44e3e000:1000:74:78:NA:4eb01106:rtc [ 2.143269] omap_rtc 44e3e000.rtc: registered as rtc0 [ 2.148541] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01T00:00:00 UTC (946684800) [ 2.160185] ti-sysc 48022050.target-module: XXX sysc_probe [ 2.166060] ti-sysc 48022050.target-module: 48022000:1000:50:54:58:50412603:uart [ 2.174292] ti-sysc 48024050.target-module: XXX sysc_probe [ 2.180086] ti-sysc 48024050.target-module: 48024000:1000:50:54:58:50412603:uart [ 2.188200] ti-sysc 4802a000.target-module: XXX sysc_probe [ 2.193978] ti-sysc 4802a000.target-module: 4802a000:1000:0:10:90:5040000b:i2c [ 2.201916] ti-sysc 48030000.target-module: XXX sysc_probe [ 2.207687] ti-sysc 48030000.target-module: 48030000:1000:0:110:114:40300a0b:mcspi [ 2.215991] ti-sysc 48038000.target-module: XXX sysc_probe [ 2.221760] ti-sysc 48038000.target-module: 48038000:2000:0:4:NA:44307b02:mcasp [ 2.230891] ti-sysc 4803c000.target-module: XXX sysc_probe [ 2.236725] ti-sysc 4803c000.target-module: 4803c000:2000:0:4:NA:44307b02:mcasp [ 2.244804] ti-sysc 48040000.target-module: XXX sysc_probe [ 2.250598] ti-sysc 48040000.target-module: 48040000:1000:0:10:14:4fff1301 [ 2.258119] ti-sysc 48042000.target-module: XXX sysc_probe [ 2.263886] ti-sysc 48042000.target-module: 48042000:1000:0:10:14:4fff1301 [ 2.272307] ti-sysc 48044000.target-module: XXX sysc_probe [ 2.278131] ti-sysc 48044000.target-module: 48044000:1000:0:10:14:4fff1301 [ 2.286463] ti-sysc 48046000.target-module: XXX sysc_probe [ 2.292283] ti-sysc 48046000.target-module: 48046000:1000:0:10:14:4fff1301 [ 2.300625] ti-sysc 48048000.target-module: XXX sysc_probe [ 2.306433] ti-sysc 48048000.target-module: 48048000:1000:0:10:14:4fff1301 [ 2.314772] ti-sysc 4804a000.target-module: XXX sysc_probe [ 2.320598] ti-sysc 4804a000.target-module: 4804a000:1000:0:10:14:4fff1301 [ 2.328954] ti-sysc 4804c000.target-module: XXX sysc_probe [ 2.335079] ti-sysc 4804c000.target-module: 4804c000:1000:0:10:114:50600801:gpio [ 2.343953] OMAP GPIO hardware version 0.1 [ 2.349058] ti-sysc 480602fc.target-module: XXX sysc_probe [ 2.354899] ti-sysc 480602fc.target-module: 48060000:1000:2fc:110:114:31010000:sdio [ 2.364542] ti-sysc 48080000.target-module: XXX sysc_probe [ 2.370389] ti-sysc 48080000.target-module: 48080000:10000:0:10:14:00000020:elm [ 2.378413] ti-sysc 480c8000.target-module: XXX sysc_probe [ 2.384187] ti-sysc 480c8000.target-module: 480c8000:1000:0:10:NA:00000400:mailbox [ 2.392727] omap-mailbox 480c8000.mailbox: omap mailbox rev 0x400 [ 2.399576] ti-sysc 480ca000.target-module: XXX sysc_probe [ 2.405387] ti-sysc 480ca000.target-module: 480ca000:1000:0:10:14:50020000 [ 2.414265] ti-sysc 4819c000.target-module: XXX sysc_probe [ 2.420106] ti-sysc 4819c000.target-module: 4819c000:1000:0:10:90:5040000b:i2c [ 2.429434] at24 2-0054: supply vcc not found, using dummy regulator [ 2.467691] at24 2-0055: supply vcc not found, using dummy regulator [ 2.502628] at24 2-0056: supply vcc not found, using dummy regulator [ 2.538589] at24 2-0057: supply vcc not found, using dummy regulator [ 2.574332] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz [ 2.580807] ti-sysc 481a0000.target-module: XXX sysc_probe [ 2.586667] ti-sysc 481a0000.target-module: 481a0000:1000:0:110:114:40300a0b:mcspi [ 2.594987] ti-sysc 481a6050.target-module: XXX sysc_probe [ 2.600790] ti-sysc 481a6050.target-module: 481a6000:1000:50:54:58:50412603:uart [ 2.608871] ti-sysc 481a8050.target-module: XXX sysc_probe [ 2.614638] ti-sysc 481a8050.target-module: 481a8000:1000:50:54:58:50412603:uart [ 2.622726] ti-sysc 481aa050.target-module: XXX sysc_probe [ 2.628493] ti-sysc 481aa050.target-module: 481aa000:1000:50:54:58:50412603:uart [ 2.636567] ti-sysc 481ac000.target-module: XXX sysc_probe [ 2.642641] ti-sysc 481ac000.target-module: 481ac000:1000:0:10:114:50600801:gpio [ 2.651921] ti-sysc 481ae000.target-module: XXX sysc_probe [ 2.658078] ti-sysc 481ae000.target-module: 481ae000:1000:0:10:114:50600801:gpio [ 2.667193] ti-sysc 481cc020.target-module: XXX sysc_probe [ 2.673023] ti-sysc 481cc020.target-module: 481cc000:2000:20:NA:NA:a3170504:dcan [ 2.681071] ti-sysc 481d0020.target-module: XXX sysc_probe [ 2.686855] ti-sysc 481d0020.target-module: 481d0000:2000:20:NA:NA:a3170504:dcan [ 2.695078] ti-sysc 481d82fc.target-module: XXX sysc_probe [ 2.700860] ti-sysc 481d82fc.target-module: 481d8000:1000:2fc:110:114:31010000:sdio [ 2.710849] ti-sysc 48000000.interconnect:segment@200000:target-module@0: XXX sysc_probe [ 2.719360] ti-sysc 48000000.interconnect:segment@200000:target-module@0: 48200000:10000:NA:NA:NA:NA [ 2.730103] ti-sysc 48300000.target-module: XXX sysc_probe [ 2.735935] ti-sysc 48300000.target-module: 48300000:1000:0:4:NA:47400001:epwmss [ 2.744045] ti-sysc 48302000.target-module: XXX sysc_probe [ 2.749823] ti-sysc 48302000.target-module: 48302000:1000:0:4:NA:47400001:epwmss [ 2.757881] ti-sysc 48304000.target-module: XXX sysc_probe [ 2.763651] ti-sysc 48304000.target-module: 48304000:1000:0:4:NA:47400001:epwmss [ 2.771715] ti-sysc 4830e000.target-module: XXX sysc_probe [ 2.777477] ti-sysc 4830e000.target-module: 4830e000:1000:0:54:NA:4f201000:lcdc [ 2.786181] ti-sysc 48311fe0.target-module: XXX sysc_probe [ 2.791994] ti-sysc 48311fe0.target-module: 48310000:2000:1fe0:1fe4:NA:00000020:rng [ 2.800820] omap_rng 48310000.rng: Random Number Generator ver. 20 [ 2.807315] random: crng init done [ 2.814207] ti-sysc 4a101200.target-module: XXX sysc_probe [ 2.820080] ti-sysc 4a101200.target-module: 4a100000:8000:1200:1208:1204:4edb0100:cpgmac [ 2.830347] ti-sysc 4a326000.target-module: XXX sysc_probe [ 2.836198] 8<--- cut here --- [ 2.839339] Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0266000 [ 2.847215] pgd = 342d2420 [ 2.850000] [e0266000] *pgd=81ec1811, *pte=4a326653, *ppte=4a326453 [ 2.856467] Internal error: : 1008 [#1] THUMB2 [ 2.861036] Modules linked in: [ 2.864176] CPU: 0 PID: 65 Comm: kworker/u2:2 Not tainted 5.15.0-rc1-00002-g5285574596c0 #552 [ 2.872946] Hardware name: Generic AM33XX (Flattened Device Tree) [ 2.879212] Workqueue: events_unbound deferred_probe_work_func [ 2.885231] PC is at sysc_probe+0xb30/0xf6c [ 2.889545] LR is at omap_reset_deassert+0x8d/0x164 [ 2.894569] pc : [<c05afb40>] lr : [<c0605e2d>] psr: 40000033 [ 2.901009] sp : c1bcb798 ip : 05355555 fp : c0a56460 [ 2.906379] r10: 00000000 r9 : 00000001 r8 : 00000000 [ 2.911746] r7 : c110be4c r6 : c1f5ae10 r5 : c1f52240 r4 : c1105288 [ 2.918457] r3 : e0266000 r2 : 00000001 r1 : 00026000 r0 : 00000000 [ 2.925171] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none [ 2.932687] Control: 50c5387d Table: 80004019 DAC: 00000051 [ 2.938590] Register r0 information: NULL pointer [ 2.943430] Register r1 information: non-paged memory [ 2.948622] Register r2 information: non-paged memory [ 2.953813] Register r3 information: 0-page vmalloc region starting at 0xe0240000 allocated at __devm_ioremap+0x6f/0x78 [ 2.964915] Register r4 information: non-slab/vmalloc memory [ 2.970734] Register r5 information: slab kmalloc-256 start c1f52200 pointer offset 64 size 256 [ 2.979701] Register r6 information: slab kmalloc-512 start c1f5ae00 pointer offset 16 size 512 [ 2.988661] Register r7 information: non-slab/vmalloc memory [ 2.994481] Register r8 information: NULL pointer [ 2.999316] Register r9 information: non-paged memory [ 3.004508] Register r10 information: NULL pointer [ 3.009433] Register r11 information: non-slab/vmalloc memory [ 3.015343] Register r12 information: non-paged memory [ 3.020625] Process kworker/u2:2 (pid: 65, stack limit = 0xa1c5a543) [ 3.027159] Stack: (0xc1bcb798 to 0xc1bcc000) [ 3.031637] b780: ???????? ???????? [ 3.040045] b7a0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.048451] b7c0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.056860] b7e0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.065267] b800: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.073674] b820: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.082082] b840: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.090489] b860: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.098898] b880: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.107303] b8a0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.115711] b8c0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.124119] b8e0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.132527] b900: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.140935] b920: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.149342] b940: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.157749] b960: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.166156] b980: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.174566] b9a0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.182974] b9c0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.191383] b9e0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.199790] ba00: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.208195] ba20: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.216605] ba40: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.225011] ba60: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.233417] ba80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.241827] baa0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.250233] bac0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.258644] bae0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.267051] bb00: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.275459] bb20: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.283866] bb40: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.292275] bb60: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.300680] bb80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.309089] bba0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.317498] bbc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.325908] bbe0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.334319] bc00: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.342728] bc20: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.351135] bc40: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.359542] bc60: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.367951] bc80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.376358] bca0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.384764] bcc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.393173] bce0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.401581] bd00: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.409987] bd20: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.418395] bd40: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.426804] bd60: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.435213] bd80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.443620] bda0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.452029] bdc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.460437] bde0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.468844] be00: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.477251] be20: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.485659] be40: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.494066] be60: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.502477] be80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.510884] bea0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.519291] bec0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.527698] bee0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.536107] bf00: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.544514] bf20: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.552923] bf40: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.561331] bf60: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.569739] bf80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.578146] bfa0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.586553] bfc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.594958] bfe0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 3.603378] [<c05afb40>] (sysc_probe) from [<c0695135>] (platform_probe+0x5d/0x88) [ 3.611178] [<c0695135>] (platform_probe) from [<c069334b>] (really_probe+0x12b/0x2c8) [ 3.619334] [<c069334b>] (really_probe) from [<c069356f>] (__driver_probe_device+0x87/0x17c) [ 3.628019] [<c069356f>] (__driver_probe_device) from [<c0693699>] (driver_probe_device+0x35/0xa4) [ 3.637244] [<c0693699>] (driver_probe_device) from [<c0693951>] (__device_attach_driver+0x61/0xa8) [ 3.646560] [<c0693951>] (__device_attach_driver) from [<c0691c7b>] (bus_for_each_drv+0x47/0x70) [ 3.655604] [<c0691c7b>] (bus_for_each_drv) from [<c06931b3>] (__device_attach+0x8f/0xf0) [ 3.664023] [<c06931b3>] (__device_attach) from [<c06926f3>] (bus_probe_device+0x5b/0x60) [ 3.672443] [<c06926f3>] (bus_probe_device) from [<c0690e19>] (device_add+0x389/0x640) [ 3.680597] [<c0690e19>] (device_add) from [<c08064b5>] (of_platform_device_create_pdata+0x71/0xa0) [ 3.689919] [<c08064b5>] (of_platform_device_create_pdata) from [<c08065fd>] (of_platform_bus_create+0x10d/0x244) [ 3.700484] [<c08065fd>] (of_platform_bus_create) from [<c0806879>] (of_platform_populate+0x5d/0xd8) [ 3.709886] [<c0806879>] (of_platform_populate) from [<c05add17>] (simple_pm_bus_probe+0x2b/0x50) [ 3.719020] [<c05add17>] (simple_pm_bus_probe) from [<c0695135>] (platform_probe+0x5d/0x88) [ 3.727617] [<c0695135>] (platform_probe) from [<c069334b>] (really_probe+0x12b/0x2c8) [ 3.735766] [<c069334b>] (really_probe) from [<c069356f>] (__driver_probe_device+0x87/0x17c) [ 3.744452] [<c069356f>] (__driver_probe_device) from [<c0693699>] (driver_probe_device+0x35/0xa4) [ 3.753677] [<c0693699>] (driver_probe_device) from [<c0693951>] (__device_attach_driver+0x61/0xa8) [ 3.762991] [<c0693951>] (__device_attach_driver) from [<c0691c7b>] (bus_for_each_drv+0x47/0x70) [ 3.772037] [<c0691c7b>] (bus_for_each_drv) from [<c06931b3>] (__device_attach+0x8f/0xf0) [ 3.780454] [<c06931b3>] (__device_attach) from [<c06926f3>] (bus_probe_device+0x5b/0x60) [ 3.788873] [<c06926f3>] (bus_probe_device) from [<c0690e19>] (device_add+0x389/0x640) [ 3.797023] [<c0690e19>] (device_add) from [<c08064b5>] (of_platform_device_create_pdata+0x71/0xa0) [ 3.806336] [<c08064b5>] (of_platform_device_create_pdata) from [<c08065fd>] (of_platform_bus_create+0x10d/0x244) [ 3.816899] [<c08065fd>] (of_platform_bus_create) from [<c0806879>] (of_platform_populate+0x5d/0xd8) [ 3.826302] [<c0806879>] (of_platform_populate) from [<c05add17>] (simple_pm_bus_probe+0x2b/0x50) [ 3.835434] [<c05add17>] (simple_pm_bus_probe) from [<c0695135>] (platform_probe+0x5d/0x88) [ 3.844030] [<c0695135>] (platform_probe) from [<c069334b>] (really_probe+0x12b/0x2c8) [ 3.852182] [<c069334b>] (really_probe) from [<c069356f>] (__driver_probe_device+0x87/0x17c) [ 3.860871] [<c069356f>] (__driver_probe_device) from [<c0693699>] (driver_probe_device+0x35/0xa4) [ 3.870095] [<c0693699>] (driver_probe_device) from [<c0693951>] (__device_attach_driver+0x61/0xa8) [ 3.879409] [<c0693951>] (__device_attach_driver) from [<c0691c7b>] (bus_for_each_drv+0x47/0x70) [ 3.888455] [<c0691c7b>] (bus_for_each_drv) from [<c06931b3>] (__device_attach+0x8f/0xf0) [ 3.896874] [<c06931b3>] (__device_attach) from [<c06926f3>] (bus_probe_device+0x5b/0x60) [ 3.905295] [<c06926f3>] (bus_probe_device) from [<c0690e19>] (device_add+0x389/0x640) [ 3.913443] [<c0690e19>] (device_add) from [<c08064b5>] (of_platform_device_create_pdata+0x71/0xa0) [ 3.922756] [<c08064b5>] (of_platform_device_create_pdata) from [<c08065fd>] (of_platform_bus_create+0x10d/0x244) [ 3.933320] [<c08065fd>] (of_platform_bus_create) from [<c0806879>] (of_platform_populate+0x5d/0xd8) [ 3.942722] [<c0806879>] (of_platform_populate) from [<c05add17>] (simple_pm_bus_probe+0x2b/0x50) [ 3.951857] [<c05add17>] (simple_pm_bus_probe) from [<c0695135>] (platform_probe+0x5d/0x88) [ 3.960452] [<c0695135>] (platform_probe) from [<c069334b>] (really_probe+0x12b/0x2c8) [ 3.968600] [<c069334b>] (really_probe) from [<c069356f>] (__driver_probe_device+0x87/0x17c) [ 3.977286] [<c069356f>] (__driver_probe_device) from [<c0693699>] (driver_probe_device+0x35/0xa4) [ 3.986512] [<c0693699>] (driver_probe_device) from [<c0693951>] (__device_attach_driver+0x61/0xa8) [ 3.995827] [<c0693951>] (__device_attach_driver) from [<c0691c7b>] (bus_for_each_drv+0x47/0x70) [ 4.004871] [<c0691c7b>] (bus_for_each_drv) from [<c06931b3>] (__device_attach+0x8f/0xf0) [ 4.013290] [<c06931b3>] (__device_attach) from [<c06926f3>] (bus_probe_device+0x5b/0x60) [ 4.021710] [<c06926f3>] (bus_probe_device) from [<c0692a9b>] (deferred_probe_work_func+0x77/0xa4) [ 4.030931] [<c0692a9b>] (deferred_probe_work_func) from [<c01343d5>] (process_one_work+0x109/0x310) [ 4.040336] [<c01343d5>] (process_one_work) from [<c0134921>] (worker_thread+0xe5/0x3a8) [ 4.048663] [<c0134921>] (worker_thread) from [<c01397a7>] (kthread+0xe3/0x11c) [ 4.056194] [<c01397a7>] (kthread) from [<c0100139>] (ret_from_fork+0x11/0x38) [ 4.063632] Exception stack(0xc1bcbfb0 to 0xc1bcbff8) [ 4.068824] bfa0: ???????? ???????? ???????? ???????? [ 4.077233] bfc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 4.085640] bfe0: ???????? ???????? ???????? ???????? ???????? ???????? [ 4.092446] Code: f100 81cc 696b 440b (6818) 46cc [ 4.097375] ---[ end trace eba2b1d5f478df09 ]--- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-17 10:28 ` Vaittinen, Matti @ 2021-09-17 10:47 ` Tony Lindgren 2021-09-17 10:57 ` Grygorii Strashko 1 sibling, 0 replies; 24+ messages in thread From: Tony Lindgren @ 2021-09-17 10:47 UTC (permalink / raw) To: Vaittinen, Matti Cc: linux-omap, Grygorii Strashko, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel Hi, * Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> [210917 10:29]: > Oh.. Sorry! I don't know where I picked Tom from... My bad! No worries :) > > For me, adding any kind of delay fixed the issue. Also adding some printk > > statements fixed it for me. > > > >> Any suggestions what to check next? > > > > Maybe try the attached patch? If it helps, just try with the with the > > ti,sysc-delay-us = <2> added as few modules need that after enable. > > > > It's also possible there is an issue with some other device that is now > > getting enabled other than pruss. The last XXX printk output should show > > the last device being probed. > > > > Looks like you need to also enable CONFIG_SERIAL_EARLYCON=y, and pass > > console=ttyS0,115200 debug earlycon in the kernel command line. > > Ah. Thanks again. I indeed lacked the "debug earlycon" parameters. Now > we're more likely to see what went wrong :) I pasted the serial log form > failing boot with v5.15-rc1 which has both the patch you linked me above > and the patch you suggested me to test in previous email. OK thanks. > [ 2.830347] ti-sysc 4a326000.target-module: XXX sysc_probe > [ 2.836198] 8<--- cut here --- > [ 2.839339] Unhandled fault: external abort on non-linefetch (0x1008) > at 0xe0266000 Yup, this is the pruss target-module@300000 that has the first reg at 4a326000. The oops look very similar to what I was seeing with my bbb. The external abort means the pruss module is not properly enabled when accessing the registers. Not sure what might be different here, presumably all am335x hardware has the pruss. Maybe try with a larger ti,sysc-delay-us value? I doubt that helps though as 2 is the most we've seen so far for the delay needed.. Maybe the issue is in omap_reset_deassert(). You could try adding some printk to omap_reset_deassert() and see if the issue happens right away or after deasserting the reset. If it's after deasserting the reset, you could adding delay to the end of omap_reset_deassert() and see if that helps. Regards, Tony ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-17 10:28 ` Vaittinen, Matti 2021-09-17 10:47 ` Tony Lindgren @ 2021-09-17 10:57 ` Grygorii Strashko 2021-09-17 11:01 ` Grygorii Strashko 1 sibling, 1 reply; 24+ messages in thread From: Grygorii Strashko @ 2021-09-17 10:57 UTC (permalink / raw) To: Vaittinen, Matti, Tony Lindgren Cc: linux-omap, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel On 17/09/2021 13:28, Vaittinen, Matti wrote: > Hi deeee Ho Tony & All, > > On 9/17/21 09:14, Tony Lindgren wrote: >> Hi, >> >> * Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> [210916 09:15]: > >>> My beaglebone black (rev c) based test environment fails to boot with >>> v5.15-rc1. Boot succeeds with the v5.14. >>> >>> Bisecting the Linus' tree pointed out the commit: >>> [1c7ba565e70365763ea780666a3eee679344b962] ARM: dts: am335x-baltos: >>> switch to new cpsw switch drv >>> >>> I don't see this exact commit touching the BBB device-tree. In Linus' >>> tree it is a part of a merge commit. Reverting the whole merge on top of >>> the v5.15-rc1 >>> >>> This reverts commit 81b6a285737700c2e04ef0893617b80481b6b4b7, reversing >>> changes made to f73979109bc11a0ed26b6deeb403fb5d05676ffc. >>> >>> makes my beaglebone black to boot again. >>> >>> Yesterday I tried adding this patch: >>> https://lore.kernel.org/linux-omap/20210915065032.45013-1-tony@atomide.com/T/#u >>> pointed by Tom on top of the v5.15-rc1 - no avail. I also did #define >>> DEBUG at ti-sys.c as was suggested by Tom - but I don't see any more output. >> >> Correction, that was me, not Tom :) > > Oh.. Sorry! I don't know where I picked Tom from... My bad! > >> For me, adding any kind of delay fixed the issue. Also adding some printk >> statements fixed it for me. >> >>> Any suggestions what to check next? >> >> Maybe try the attached patch? If it helps, just try with the with the >> ti,sysc-delay-us = <2> added as few modules need that after enable. >> >> It's also possible there is an issue with some other device that is now >> getting enabled other than pruss. The last XXX printk output should show >> the last device being probed. >> >> Looks like you need to also enable CONFIG_SERIAL_EARLYCON=y, and pass >> console=ttyS0,115200 debug earlycon in the kernel command line. > > Ah. Thanks again. I indeed lacked the "debug earlycon" parameters. Now > we're more likely to see what went wrong :) I pasted the serial log form > failing boot with v5.15-rc1 which has both the patch you linked me above > and the patch you suggested me to test in previous email. > [...] > [ 2.786181] ti-sysc 48311fe0.target-module: XXX sysc_probe > [ 2.791994] ti-sysc 48311fe0.target-module: > 48310000:2000:1fe0:1fe4:NA:00000020:rng > [ 2.800820] omap_rng 48310000.rng: Random Number Generator ver. 20 > [ 2.807315] random: crng init done > [ 2.814207] ti-sysc 4a101200.target-module: XXX sysc_probe > [ 2.820080] ti-sysc 4a101200.target-module: > 4a100000:8000:1200:1208:1204:4edb0100:cpgmac This one cpsw > [ 2.830347] ti-sysc 4a326000.target-module: XXX sysc_probe This one pruss and it still shows sysc_probe Not sure what are the dependency here :( if any. Additional option to try - cmdline param "initcall_debug" and maybe increase print level in really_probe_debug() I see one possible diff if you could try: diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi index c9629cb5ccd1..d62943ba3506 100644 --- a/arch/arm/boot/dts/am33xx-l4.dtsi +++ b/arch/arm/boot/dts/am33xx-l4.dtsi @@ -801,7 +801,7 @@ davinci_mdio_sw: mdio@1000 { compatible = "ti,cpsw-mdio","ti,davinci_mdio"; - clocks = <&cpsw_125mhz_gclk>; + clocks = <&cpsw_125mhz_clkctrl AM3_CPSW_125MHZ_CPGMAC0_CLKCTRL 0>; clock-names = "fck"; #address-cells = <1>; #size-cells = <0>; > [ 2.836198] 8<--- cut here --- > [ 2.839339] Unhandled fault: external abort on non-linefetch (0x1008) > at 0xe0266000 > [ 2.847215] pgd = 342d2420 > [ 2.850000] [e0266000] *pgd=81ec1811, *pte=4a326653, *ppte=4a326453 > [ 2.856467] Internal error: : 1008 [#1] THUMB2 > [ 2.861036] Modules linked in: > [ 2.864176] CPU: 0 PID: 65 Comm: kworker/u2:2 Not tainted > 5.15.0-rc1-00002-g5285574596c0 #552 > [ 2.872946] Hardware name: Generic AM33XX (Flattened Device Tree) > [ 2.879212] Workqueue: events_unbound deferred_probe_work_func > [ 2.885231] PC is at sysc_probe+0xb30/0xf6c > [ 2.889545] LR is at omap_reset_deassert+0x8d/0x164 > [ 2.894569] pc : [<c05afb40>] lr : [<c0605e2d>] psr: 40000033 > [ 2.901009] sp : c1bcb798 ip : 05355555 fp : c0a56460 > [ 2.906379] r10: 00000000 r9 : 00000001 r8 : 00000000 > [ 2.911746] r7 : c110be4c r6 : c1f5ae10 r5 : c1f52240 r4 : c1105288 > [ 2.918457] r3 : e0266000 r2 : 00000001 r1 : 00026000 r0 : 00000000 > [ 2.925171] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA Thumb > Segment none > [ 2.932687] Control: 50c5387d Table: 80004019 DAC: 00000051 > [ 2.938590] Register r0 information: NULL pointer > [ 2.943430] Register r1 information: non-paged memory > [ 2.948622] Register r2 information: non-paged memory > [ 2.953813] Register r3 information: 0-page vmalloc region starting > at 0xe0240000 allocated at __devm_ioremap+0x6f/0x78 > [ 2.964915] Register r4 information: non-slab/vmalloc memory > [ 2.970734] Register r5 information: slab kmalloc-256 start c1f52200 > pointer offset 64 size 256 > [ 2.979701] Register r6 information: slab kmalloc-512 start c1f5ae00 > pointer offset 16 size 512 > [ 2.988661] Register r7 information: non-slab/vmalloc memory > [ 2.994481] Register r8 information: NULL pointer > [ 2.999316] Register r9 information: non-paged memory > [ 3.004508] Register r10 information: NULL pointer > [ 3.009433] Register r11 information: non-slab/vmalloc memory > [ 3.015343] Register r12 information: non-paged memory > [ 3.020625] Process kworker/u2:2 (pid: 65, stack limit = 0xa1c5a543) > [ 3.027159] Stack: (0xc1bcb798 to 0xc1bcc000) > [ 3.031637] b780: > ???????? ???????? > [ 3.040045] b7a0: ???????? ???????? ???????? ???????? ???????? > ???????? ???????? ???????? what is these ?? :( > [ 3.603378] [<c05afb40>] (sysc_probe) from [<c0695135>] > (platform_probe+0x5d/0x88) > [ 3.611178] [<c0695135>] (platform_probe) from [<c069334b>] > (really_probe+0x12b/0x2c8) > [ 3.619334] [<c069334b>] (really_probe) from [<c069356f>] > (__driver_probe_device+0x87/0x17c) > [ 3.628019] [<c069356f>] (__driver_probe_device) from [<c0693699>] > (driver_probe_device+0x35/0xa4) > [ 3.637244] [<c0693699>] (driver_probe_device) from [<c0693951>] > (__device_attach_driver+0x61/0xa8) > [ 3.646560] [<c0693951>] (__device_attach_driver) from [<c0691c7b>] > (bus_for_each_drv+0x47/0x70) > [ 3.655604] [<c0691c7b>] (bus_for_each_drv) from [<c06931b3>] > (__device_attach+0x8f/0xf0) > [ 3.664023] [<c06931b3>] (__device_attach) from [<c06926f3>] > (bus_probe_device+0x5b/0x60) > [ 3.672443] [<c06926f3>] (bus_probe_device) from [<c0690e19>] > (device_add+0x389/0x640) > [ 3.680597] [<c0690e19>] (device_add) from [<c08064b5>] > (of_platform_device_create_pdata+0x71/0xa0) > [ 3.689919] [<c08064b5>] (of_platform_device_create_pdata) from > [<c08065fd>] (of_platform_bus_create+0x10d/0x244) > [ 3.700484] [<c08065fd>] (of_platform_bus_create) from [<c0806879>] > (of_platform_populate+0x5d/0xd8) > [ 3.709886] [<c0806879>] (of_platform_populate) from [<c05add17>] > (simple_pm_bus_probe+0x2b/0x50) > [ 3.719020] [<c05add17>] (simple_pm_bus_probe) from [<c0695135>] > (platform_probe+0x5d/0x88) > [ 3.727617] [<c0695135>] (platform_probe) from [<c069334b>] > (really_probe+0x12b/0x2c8) > [ 3.735766] [<c069334b>] (really_probe) from [<c069356f>] > (__driver_probe_device+0x87/0x17c) > [ 3.744452] [<c069356f>] (__driver_probe_device) from [<c0693699>] > (driver_probe_device+0x35/0xa4) > [ 3.753677] [<c0693699>] (driver_probe_device) from [<c0693951>] > (__device_attach_driver+0x61/0xa8) > [ 3.762991] [<c0693951>] (__device_attach_driver) from [<c0691c7b>] > (bus_for_each_drv+0x47/0x70) > [ 3.772037] [<c0691c7b>] (bus_for_each_drv) from [<c06931b3>] > (__device_attach+0x8f/0xf0) > [ 3.780454] [<c06931b3>] (__device_attach) from [<c06926f3>] > (bus_probe_device+0x5b/0x60) > [ 3.788873] [<c06926f3>] (bus_probe_device) from [<c0690e19>] > (device_add+0x389/0x640) > [ 3.797023] [<c0690e19>] (device_add) from [<c08064b5>] > (of_platform_device_create_pdata+0x71/0xa0) > [ 3.806336] [<c08064b5>] (of_platform_device_create_pdata) from > [<c08065fd>] (of_platform_bus_create+0x10d/0x244) > [ 3.816899] [<c08065fd>] (of_platform_bus_create) from [<c0806879>] > (of_platform_populate+0x5d/0xd8) > [ 3.826302] [<c0806879>] (of_platform_populate) from [<c05add17>] > (simple_pm_bus_probe+0x2b/0x50) > [ 3.835434] [<c05add17>] (simple_pm_bus_probe) from [<c0695135>] > (platform_probe+0x5d/0x88) > [ 3.844030] [<c0695135>] (platform_probe) from [<c069334b>] > (really_probe+0x12b/0x2c8) > [ 3.852182] [<c069334b>] (really_probe) from [<c069356f>] > (__driver_probe_device+0x87/0x17c) > [ 3.860871] [<c069356f>] (__driver_probe_device) from [<c0693699>] > (driver_probe_device+0x35/0xa4) > [ 3.870095] [<c0693699>] (driver_probe_device) from [<c0693951>] > (__device_attach_driver+0x61/0xa8) > [ 3.879409] [<c0693951>] (__device_attach_driver) from [<c0691c7b>] > (bus_for_each_drv+0x47/0x70) > [ 3.888455] [<c0691c7b>] (bus_for_each_drv) from [<c06931b3>] > (__device_attach+0x8f/0xf0) > [ 3.896874] [<c06931b3>] (__device_attach) from [<c06926f3>] > (bus_probe_device+0x5b/0x60) > [ 3.905295] [<c06926f3>] (bus_probe_device) from [<c0690e19>] > (device_add+0x389/0x640) > [ 3.913443] [<c0690e19>] (device_add) from [<c08064b5>] > (of_platform_device_create_pdata+0x71/0xa0) > [ 3.922756] [<c08064b5>] (of_platform_device_create_pdata) from > [<c08065fd>] (of_platform_bus_create+0x10d/0x244) > [ 3.933320] [<c08065fd>] (of_platform_bus_create) from [<c0806879>] > (of_platform_populate+0x5d/0xd8) > [ 3.942722] [<c0806879>] (of_platform_populate) from [<c05add17>] > (simple_pm_bus_probe+0x2b/0x50) > [ 3.951857] [<c05add17>] (simple_pm_bus_probe) from [<c0695135>] > (platform_probe+0x5d/0x88) > [ 3.960452] [<c0695135>] (platform_probe) from [<c069334b>] > (really_probe+0x12b/0x2c8) > [ 3.968600] [<c069334b>] (really_probe) from [<c069356f>] > (__driver_probe_device+0x87/0x17c) > [ 3.977286] [<c069356f>] (__driver_probe_device) from [<c0693699>] > (driver_probe_device+0x35/0xa4) > [ 3.986512] [<c0693699>] (driver_probe_device) from [<c0693951>] > (__device_attach_driver+0x61/0xa8) > [ 3.995827] [<c0693951>] (__device_attach_driver) from [<c0691c7b>] > (bus_for_each_drv+0x47/0x70) > [ 4.004871] [<c0691c7b>] (bus_for_each_drv) from [<c06931b3>] > (__device_attach+0x8f/0xf0) > [ 4.013290] [<c06931b3>] (__device_attach) from [<c06926f3>] > (bus_probe_device+0x5b/0x60) > [ 4.021710] [<c06926f3>] (bus_probe_device) from [<c0692a9b>] > (deferred_probe_work_func+0x77/0xa4) > [ 4.030931] [<c0692a9b>] (deferred_probe_work_func) from [<c01343d5>] > (process_one_work+0x109/0x310) > [ 4.040336] [<c01343d5>] (process_one_work) from [<c0134921>] > (worker_thread+0xe5/0x3a8) > [ 4.048663] [<c0134921>] (worker_thread) from [<c01397a7>] > (kthread+0xe3/0x11c) > [ 4.056194] [<c01397a7>] (kthread) from [<c0100139>] > (ret_from_fork+0x11/0x38) > [ 4.063632] Exception stack(0xc1bcbfb0 to 0xc1bcbff8) > [ 4.068824] bfa0: ???????? > ???????? ???????? ???????? > [ 4.077233] bfc0: ???????? ???????? ???????? ???????? ???????? > ???????? ???????? ???????? > [ 4.085640] bfe0: ???????? ???????? ???????? ???????? ???????? ???????? > [ 4.092446] Code: f100 81cc 696b 440b (6818) 46cc > [ 4.097375] ---[ end trace eba2b1d5f478df09 ]--- > > -- Best regards, grygorii ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-17 10:57 ` Grygorii Strashko @ 2021-09-17 11:01 ` Grygorii Strashko 2021-09-17 11:34 ` Vaittinen, Matti 0 siblings, 1 reply; 24+ messages in thread From: Grygorii Strashko @ 2021-09-17 11:01 UTC (permalink / raw) To: Vaittinen, Matti, Tony Lindgren Cc: linux-omap, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel On 17/09/2021 13:57, Grygorii Strashko wrote: > > > On 17/09/2021 13:28, Vaittinen, Matti wrote: >> Hi deeee Ho Tony & All, >> >> On 9/17/21 09:14, Tony Lindgren wrote: >>> Hi, >>> >>> * Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> [210916 09:15]: >> >>>> My beaglebone black (rev c) based test environment fails to boot with >>>> v5.15-rc1. Boot succeeds with the v5.14. >>>> >>>> Bisecting the Linus' tree pointed out the commit: >>>> [1c7ba565e70365763ea780666a3eee679344b962] ARM: dts: am335x-baltos: >>>> switch to new cpsw switch drv >>>> >>>> I don't see this exact commit touching the BBB device-tree. In Linus' >>>> tree it is a part of a merge commit. Reverting the whole merge on top of >>>> the v5.15-rc1 >>>> >>>> This reverts commit 81b6a285737700c2e04ef0893617b80481b6b4b7, reversing >>>> changes made to f73979109bc11a0ed26b6deeb403fb5d05676ffc. >>>> >>>> makes my beaglebone black to boot again. >>>> >>>> Yesterday I tried adding this patch: >>>> https://lore.kernel.org/linux-omap/20210915065032.45013-1-tony@atomide.com/T/#u >>>> pointed by Tom on top of the v5.15-rc1 - no avail. I also did #define >>>> DEBUG at ti-sys.c as was suggested by Tom - but I don't see any more output. >>> >>> Correction, that was me, not Tom :) >> >> Oh.. Sorry! I don't know where I picked Tom from... My bad! >> >>> For me, adding any kind of delay fixed the issue. Also adding some printk >>> statements fixed it for me. >>> >>>> Any suggestions what to check next? >>> >>> Maybe try the attached patch? If it helps, just try with the with the >>> ti,sysc-delay-us = <2> added as few modules need that after enable. >>> >>> It's also possible there is an issue with some other device that is now >>> getting enabled other than pruss. The last XXX printk output should show >>> the last device being probed. >>> >>> Looks like you need to also enable CONFIG_SERIAL_EARLYCON=y, and pass >>> console=ttyS0,115200 debug earlycon in the kernel command line. >> >> Ah. Thanks again. I indeed lacked the "debug earlycon" parameters. Now >> we're more likely to see what went wrong :) I pasted the serial log form >> failing boot with v5.15-rc1 which has both the patch you linked me above >> and the patch you suggested me to test in previous email. >> > > [...] > >> [ 2.786181] ti-sysc 48311fe0.target-module: XXX sysc_probe >> [ 2.791994] ti-sysc 48311fe0.target-module: >> 48310000:2000:1fe0:1fe4:NA:00000020:rng >> [ 2.800820] omap_rng 48310000.rng: Random Number Generator ver. 20 >> [ 2.807315] random: crng init done >> [ 2.814207] ti-sysc 4a101200.target-module: XXX sysc_probe >> [ 2.820080] ti-sysc 4a101200.target-module: >> 4a100000:8000:1200:1208:1204:4edb0100:cpgmac > > This one cpsw > >> [ 2.830347] ti-sysc 4a326000.target-module: XXX sysc_probe > > This one pruss and it still shows sysc_probe > > Not sure what are the dependency here :( if any. > > Additional option to try - cmdline param "initcall_debug" and maybe increase print level in really_probe_debug() > Just to be clear - idea is to see *all* probes - not only sysc. [...] -- Best regards, grygorii ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-17 11:01 ` Grygorii Strashko @ 2021-09-17 11:34 ` Vaittinen, Matti 2021-09-17 12:36 ` Grygorii Strashko 0 siblings, 1 reply; 24+ messages in thread From: Vaittinen, Matti @ 2021-09-17 11:34 UTC (permalink / raw) To: Grygorii Strashko, Tony Lindgren Cc: linux-omap, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel [-- Attachment #1: Type: text/plain, Size: 4064 bytes --] Thanks a lot guys! On 9/17/21 14:01, Grygorii Strashko wrote: > > > On 17/09/2021 13:57, Grygorii Strashko wrote: >> >> >> On 17/09/2021 13:28, Vaittinen, Matti wrote: >>> Hi deeee Ho Tony & All, >>> >>> On 9/17/21 09:14, Tony Lindgren wrote: >>>> Hi, >>>> >>>> * Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> [210916 09:15]: >>> >>>>> My beaglebone black (rev c) based test environment fails to boot with >>>>> v5.15-rc1. Boot succeeds with the v5.14. >>>>> >>>>> Bisecting the Linus' tree pointed out the commit: >>>>> [1c7ba565e70365763ea780666a3eee679344b962] ARM: dts: am335x-baltos: >>>>> switch to new cpsw switch drv >>>>> >>>>> I don't see this exact commit touching the BBB device-tree. In Linus' >>>>> tree it is a part of a merge commit. Reverting the whole merge on >>>>> top of >>>>> the v5.15-rc1 >>>>> >>>>> This reverts commit 81b6a285737700c2e04ef0893617b80481b6b4b7, >>>>> reversing >>>>> changes made to f73979109bc11a0ed26b6deeb403fb5d05676ffc. >>>>> >>>>> makes my beaglebone black to boot again. >>>>> >>>>> Yesterday I tried adding this patch: >>>>> https://lore.kernel.org/linux-omap/20210915065032.45013-1-tony@atomide.com/T/#u >>>>> >>>>> pointed by Tom on top of the v5.15-rc1 - no avail. I also did #define >>>>> DEBUG at ti-sys.c as was suggested by Tom - but I don't see any >>>>> more output. >>>> >>>> Correction, that was me, not Tom :) >>> >>> Oh.. Sorry! I don't know where I picked Tom from... My bad! >>> >>>> For me, adding any kind of delay fixed the issue. Also adding some >>>> printk >>>> statements fixed it for me. >>>> >>>>> Any suggestions what to check next? >>>> >>>> Maybe try the attached patch? If it helps, just try with the with the >>>> ti,sysc-delay-us = <2> added as few modules need that after enable. >>>> >>>> It's also possible there is an issue with some other device that is now >>>> getting enabled other than pruss. The last XXX printk output should >>>> show >>>> the last device being probed. >>>> >>>> Looks like you need to also enable CONFIG_SERIAL_EARLYCON=y, and pass >>>> console=ttyS0,115200 debug earlycon in the kernel command line. >>> >>> Ah. Thanks again. I indeed lacked the "debug earlycon" parameters. Now >>> we're more likely to see what went wrong :) I pasted the serial log form >>> failing boot with v5.15-rc1 which has both the patch you linked me above >>> and the patch you suggested me to test in previous email. >>> >> This really feels like an timing/synchronization issue. Adding various prints to I tried adding prints to omap_reset_deassert() made the Ooops to go away. I suspect the prints did change timing just the needed bit. Later the boot hanged to NFS mount failing though - but that may also be problem on the NFS server side. (I jave a new laptop and I am still trying to set-up my development environment there.) >> [...] >> >>> [ 2.786181] ti-sysc 48311fe0.target-module: XXX sysc_probe >>> [ 2.791994] ti-sysc 48311fe0.target-module: >>> 48310000:2000:1fe0:1fe4:NA:00000020:rng >>> [ 2.800820] omap_rng 48310000.rng: Random Number Generator ver. 20 >>> [ 2.807315] random: crng init done >>> [ 2.814207] ti-sysc 4a101200.target-module: XXX sysc_probe >>> [ 2.820080] ti-sysc 4a101200.target-module: >>> 4a100000:8000:1200:1208:1204:4edb0100:cpgmac >> >> This one cpsw >> >>> [ 2.830347] ti-sysc 4a326000.target-module: XXX sysc_probe >> >> This one pruss and it still shows sysc_probe >> >> Not sure what are the dependency here :( if any. >> >> Additional option to try - cmdline param "initcall_debug" and maybe >> increase print level in really_probe_debug() >> > > Just to be clear - idea is to see *all* probes - not only sysc. > > [...] > I added initcall_debug && changed the pr_debug() to pr_err() in really_probe_debug(). Log from that run is attached. The omap_reset_deassert() was not instrumented to print/delay for this run. Best Regards Matti Vaittinen [-- Attachment #2: bbb_boot_pruss_minicom_2.cap --] [-- Type: application/vnd.tcpdump.pcap, Size: 152009 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-17 11:34 ` Vaittinen, Matti @ 2021-09-17 12:36 ` Grygorii Strashko 2021-09-20 10:05 ` Matti Vaittinen 0 siblings, 1 reply; 24+ messages in thread From: Grygorii Strashko @ 2021-09-17 12:36 UTC (permalink / raw) To: Vaittinen, Matti, Tony Lindgren Cc: linux-omap, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel On 17/09/2021 14:34, Vaittinen, Matti wrote: > Thanks a lot guys! > > On 9/17/21 14:01, Grygorii Strashko wrote: >> >> >> On 17/09/2021 13:57, Grygorii Strashko wrote: >>> >>> >>> On 17/09/2021 13:28, Vaittinen, Matti wrote: >>>> Hi deeee Ho Tony & All, >>>> >>>> On 9/17/21 09:14, Tony Lindgren wrote: >>>>> Hi, >>>>> >>>>> * Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> [210916 09:15]: >>>> >>>>>> My beaglebone black (rev c) based test environment fails to boot with >>>>>> v5.15-rc1. Boot succeeds with the v5.14. >>>>>> >>>>>> Bisecting the Linus' tree pointed out the commit: >>>>>> [1c7ba565e70365763ea780666a3eee679344b962] ARM: dts: am335x-baltos: >>>>>> switch to new cpsw switch drv >>>>>> >>>>>> I don't see this exact commit touching the BBB device-tree. In Linus' >>>>>> tree it is a part of a merge commit. Reverting the whole merge on >>>>>> top of >>>>>> the v5.15-rc1 >>>>>> >>>>>> This reverts commit 81b6a285737700c2e04ef0893617b80481b6b4b7, >>>>>> reversing >>>>>> changes made to f73979109bc11a0ed26b6deeb403fb5d05676ffc. >>>>>> >>>>>> makes my beaglebone black to boot again. >>>>>> >>>>>> Yesterday I tried adding this patch: >>>>>> https://lore.kernel.org/linux-omap/20210915065032.45013-1-tony@atomide.com/T/#u >>>>>> >>>>>> pointed by Tom on top of the v5.15-rc1 - no avail. I also did #define >>>>>> DEBUG at ti-sys.c as was suggested by Tom - but I don't see any >>>>>> more output. >>>>> >>>>> Correction, that was me, not Tom :) >>>> >>>> Oh.. Sorry! I don't know where I picked Tom from... My bad! >>>> >>>>> For me, adding any kind of delay fixed the issue. Also adding some >>>>> printk >>>>> statements fixed it for me. >>>>> >>>>>> Any suggestions what to check next? >>>>> >>>>> Maybe try the attached patch? If it helps, just try with the with the >>>>> ti,sysc-delay-us = <2> added as few modules need that after enable. >>>>> >>>>> It's also possible there is an issue with some other device that is now >>>>> getting enabled other than pruss. The last XXX printk output should >>>>> show >>>>> the last device being probed. >>>>> >>>>> Looks like you need to also enable CONFIG_SERIAL_EARLYCON=y, and pass >>>>> console=ttyS0,115200 debug earlycon in the kernel command line. >>>> >>>> Ah. Thanks again. I indeed lacked the "debug earlycon" parameters. Now >>>> we're more likely to see what went wrong :) I pasted the serial log form >>>> failing boot with v5.15-rc1 which has both the patch you linked me above >>>> and the patch you suggested me to test in previous email. >>>> >>> > > This really feels like an timing/synchronization issue. Adding various > prints to > > I tried adding prints to omap_reset_deassert() made the Ooops to go > away. I suspect the prints did change timing just the needed bit. Later > the boot hanged to NFS mount failing though - but that may also be > problem on the NFS server side. (I jave a new laptop and I am still > trying to set-up my development environment there.) > > >>> [...] >>> >>>> [ 2.786181] ti-sysc 48311fe0.target-module: XXX sysc_probe >>>> [ 2.791994] ti-sysc 48311fe0.target-module: >>>> 48310000:2000:1fe0:1fe4:NA:00000020:rng >>>> [ 2.800820] omap_rng 48310000.rng: Random Number Generator ver. 20 >>>> [ 2.807315] random: crng init done >>>> [ 2.814207] ti-sysc 4a101200.target-module: XXX sysc_probe >>>> [ 2.820080] ti-sysc 4a101200.target-module: >>>> 4a100000:8000:1200:1208:1204:4edb0100:cpgmac >>> >>> This one cpsw >>> >>>> [ 2.830347] ti-sysc 4a326000.target-module: XXX sysc_probe >>> >>> This one pruss and it still shows sysc_probe >>> >>> Not sure what are the dependency here :( if any. >>> >>> Additional option to try - cmdline param "initcall_debug" and maybe >>> increase print level in really_probe_debug() >>> >> >> Just to be clear - idea is to see *all* probes - not only sysc. >> >> [...] >> > > I added initcall_debug && changed the pr_debug() to pr_err() in > really_probe_debug(). Log from that run is attached. The > omap_reset_deassert() was not instrumented to print/delay for this run. can you try just disable pruss_tm in am335x-bone-common.dtsi? -- Best regards, grygorii ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-17 12:36 ` Grygorii Strashko @ 2021-09-20 10:05 ` Matti Vaittinen 2021-09-21 7:47 ` Tony Lindgren 0 siblings, 1 reply; 24+ messages in thread From: Matti Vaittinen @ 2021-09-20 10:05 UTC (permalink / raw) To: Grygorii Strashko, Vaittinen, Matti, Tony Lindgren Cc: linux-omap, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel Hi dee Ho peeps & Thanks. On 9/17/21 15:36, Grygorii Strashko wrote: > > > On 17/09/2021 14:34, Vaittinen, Matti wrote: >> Thanks a lot guys! >> >> On 9/17/21 14:01, Grygorii Strashko wrote: >>> >>> >>> On 17/09/2021 13:57, Grygorii Strashko wrote: >>>> >>>> >>>> On 17/09/2021 13:28, Vaittinen, Matti wrote: >>>>> Hi deeee Ho Tony & All, >>>>> >>>>> On 9/17/21 09:14, Tony Lindgren wrote: >>>>>> Hi, >>>>>> >>>>>> * Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> [210916 >>>>>> 09:15]: >>>>> >>>>>>> My beaglebone black (rev c) based test environment fails to boot >>>>>>> with >>>>>>> v5.15-rc1. Boot succeeds with the v5.14. >>>>>>>>> I added initcall_debug && changed the pr_debug() to pr_err() in >> really_probe_debug(). Log from that run is attached. The >> omap_reset_deassert() was not instrumented to print/delay for this run. > > can you try just disable pruss_tm in am335x-bone-common.dtsi? > I did try: diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi index 0ccdc7cd463bc62812f0f2797adb0f7bff1bd1b1..538af3fa0e6361923b40598fd33637c868298a83 100644 --- a/arch/arm/boot/dts/am335x-bone-common.dtsi +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi @@ -402,5 +402,5 @@ &rtc { }; &pruss_tm { - status = "okay"; + status = "disabled"; }; and the boot did no longer produce an oops. NFS mount still hung. It took me a while to dig out that the cpsw_new.c was not compiled with my config. The TI_CPSW_SWITCHDEV was not set. I did set the TI_CPSW_SWITCHDEV=y after which the bbb booted-up. Enabling the pruss_tm still produces an oops. Finally, adding the udelay(100); (as Tony suggested) at the end of the omap_reset_deassert() did make the oops go away even when pruss_tm was enabled. I don't know what would be a proper fix though. Best Regards Matti Vaittinen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-20 10:05 ` Matti Vaittinen @ 2021-09-21 7:47 ` Tony Lindgren 2021-09-21 16:07 ` Suman Anna 2021-09-22 8:44 ` Vaittinen, Matti 0 siblings, 2 replies; 24+ messages in thread From: Tony Lindgren @ 2021-09-21 7:47 UTC (permalink / raw) To: Matti Vaittinen Cc: Grygorii Strashko, Vaittinen, Matti, linux-omap, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: > Finally, adding the udelay(100); (as Tony suggested) at the end of the > omap_reset_deassert() did make the oops go away even when pruss_tm was > enabled. I don't know what would be a proper fix though. The following patch works for me on bbb with the following test script: #!/bin/sh module="4a326000.target-module" driver="/sys/bus/platform/drivers/ti-sysc" while true; do echo ${module} > ${driver}/bind echo ${module} > ${driver}/unbind done It also allows leaving out the udelay for dra7 iva reset. Care to try this and see if it helps? Regards, Tony 8< ----------------- diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c --- a/drivers/soc/ti/omap_prm.c +++ b/drivers/soc/ti/omap_prm.c @@ -825,26 +825,29 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev, writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl); spin_unlock_irqrestore(&reset->lock, flags); - if (!has_rstst) - goto exit; - - /* wait for the status to be set */ - ret = readl_relaxed_poll_timeout_atomic(reset->prm->base + + if (has_rstst) { + /* wait for the status to be set */ + ret = readl_relaxed_poll_timeout_atomic(reset->prm->base + reset->prm->data->rstst, v, v & BIT(st_bit), 1, OMAP_RESET_MAX_WAIT); - if (ret) - pr_err("%s: timedout waiting for %s:%lu\n", __func__, - reset->prm->data->name, id); - -exit: - if (reset->clkdm) { - /* At least dra7 iva needs a delay before clkdm idle */ - if (has_rstst) - udelay(1); - pdata->clkdm_allow_idle(reset->clkdm); + if (ret) + pr_err("%s: timedout waiting for %s:%lu\n", __func__, + reset->prm->data->name, id); + } else { + /* wait for the reset bit to cleaar */ + ret = readl_relaxed_poll_timeout_atomic(reset->prm->base + + reset->prm->data->rstctrl, + v, !(v & BIT(id)), 1, + OMAP_RESET_MAX_WAIT); + if (ret) + pr_err("%s: timedout waiting for %s:%lu\n", __func__, + reset->prm->data->name, id); } + if (reset->clkdm) + pdata->clkdm_allow_idle(reset->clkdm); + return ret; } -- 2.33.0 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-21 7:47 ` Tony Lindgren @ 2021-09-21 16:07 ` Suman Anna 2021-09-21 16:40 ` H. Nikolaus Schaller 2021-09-21 20:29 ` Drew Fustini 2021-09-22 8:44 ` Vaittinen, Matti 1 sibling, 2 replies; 24+ messages in thread From: Suman Anna @ 2021-09-21 16:07 UTC (permalink / raw) To: Tony Lindgren, Matti Vaittinen Cc: Grygorii Strashko, Vaittinen, Matti, linux-omap, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel Hi Matti, Tony, On 9/21/21 2:47 AM, Tony Lindgren wrote: > * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: >> Finally, adding the udelay(100); (as Tony suggested) at the end of the >> omap_reset_deassert() did make the oops go away even when pruss_tm was >> enabled. I don't know what would be a proper fix though. I have been able to boot v5.15-rc1 just fine on my BBB without any additional changes [1]. May I ask what is your BBB board version? My board is rev.A5C. I vaguely remember from all those years ago when I first enabled PRUSS on AM335x that some earlier BBB versions had some issues around PRUSS. regards Suman [1] https://marc.info/?l=linux-omap&m=163223991005545&w=2 > > The following patch works for me on bbb with the following test script: > > #!/bin/sh > > module="4a326000.target-module" > driver="/sys/bus/platform/drivers/ti-sysc" > > while true; do > echo ${module} > ${driver}/bind > echo ${module} > ${driver}/unbind > done > > It also allows leaving out the udelay for dra7 iva reset. Care to try > this and see if it helps? > > Regards, > > Tony > > 8< ----------------- > diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c > --- a/drivers/soc/ti/omap_prm.c > +++ b/drivers/soc/ti/omap_prm.c > @@ -825,26 +825,29 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev, > writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl); > spin_unlock_irqrestore(&reset->lock, flags); > > - if (!has_rstst) > - goto exit; > - > - /* wait for the status to be set */ > - ret = readl_relaxed_poll_timeout_atomic(reset->prm->base + > + if (has_rstst) { > + /* wait for the status to be set */ > + ret = readl_relaxed_poll_timeout_atomic(reset->prm->base + > reset->prm->data->rstst, > v, v & BIT(st_bit), 1, > OMAP_RESET_MAX_WAIT); > - if (ret) > - pr_err("%s: timedout waiting for %s:%lu\n", __func__, > - reset->prm->data->name, id); > - > -exit: > - if (reset->clkdm) { > - /* At least dra7 iva needs a delay before clkdm idle */ > - if (has_rstst) > - udelay(1); > - pdata->clkdm_allow_idle(reset->clkdm); > + if (ret) > + pr_err("%s: timedout waiting for %s:%lu\n", __func__, > + reset->prm->data->name, id); > + } else { > + /* wait for the reset bit to cleaar */ > + ret = readl_relaxed_poll_timeout_atomic(reset->prm->base + > + reset->prm->data->rstctrl, > + v, !(v & BIT(id)), 1, > + OMAP_RESET_MAX_WAIT); > + if (ret) > + pr_err("%s: timedout waiting for %s:%lu\n", __func__, > + reset->prm->data->name, id); > } > > + if (reset->clkdm) > + pdata->clkdm_allow_idle(reset->clkdm); > + > return ret; > } > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-21 16:07 ` Suman Anna @ 2021-09-21 16:40 ` H. Nikolaus Schaller 2021-09-21 16:49 ` Suman Anna 2021-09-22 9:27 ` Vaittinen, Matti 2021-09-21 20:29 ` Drew Fustini 1 sibling, 2 replies; 24+ messages in thread From: H. Nikolaus Schaller @ 2021-09-21 16:40 UTC (permalink / raw) To: Matti Vaittinen, Tony Lindgren Cc: Grygorii Strashko, Vaittinen, Matti, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel, Suman Anna, linux-omap Hi Matti, Tony, > Am 21.09.2021 um 18:07 schrieb Suman Anna <s-anna@ti.com>: > > Hi Matti, Tony, > > On 9/21/21 2:47 AM, Tony Lindgren wrote: >> * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: >>> Finally, adding the udelay(100); (as Tony suggested) at the end of the >>> omap_reset_deassert() did make the oops go away even when pruss_tm was >>> enabled. I don't know what would be a proper fix though. > > I have been able to boot v5.15-rc1 just fine on my BBB without any additional > changes [1]. Same for me with a v5.15-rc1 based kernel. > May I ask what is your BBB board version? My board is rev.A5C. I have an Rev B6 with EXP41 display attached. I think Matti reported a Rev C board? > I vaguely remember from all those years ago when I first enabled PRUSS on AM335x > that some earlier BBB versions had some issues around PRUSS. What I am not using is PRUSS so it may (or may not) be disabled in CONFIG. BR, Nikolaus ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-21 16:40 ` H. Nikolaus Schaller @ 2021-09-21 16:49 ` Suman Anna 2021-09-22 9:27 ` Vaittinen, Matti 1 sibling, 0 replies; 24+ messages in thread From: Suman Anna @ 2021-09-21 16:49 UTC (permalink / raw) To: H. Nikolaus Schaller, Matti Vaittinen, Tony Lindgren Cc: Grygorii Strashko, Vaittinen, Matti, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel, linux-omap On 9/21/21 11:40 AM, H. Nikolaus Schaller wrote: > Hi Matti, Tony, > >> Am 21.09.2021 um 18:07 schrieb Suman Anna <s-anna@ti.com>: >> >> Hi Matti, Tony, >> >> On 9/21/21 2:47 AM, Tony Lindgren wrote: >>> * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: >>>> Finally, adding the udelay(100); (as Tony suggested) at the end of the >>>> omap_reset_deassert() did make the oops go away even when pruss_tm was >>>> enabled. I don't know what would be a proper fix though. >> >> I have been able to boot v5.15-rc1 just fine on my BBB without any additional >> changes [1]. > > Same for me with a v5.15-rc1 based kernel. > >> May I ask what is your BBB board version? My board is rev.A5C. > > I have an Rev B6 with EXP41 display attached. I think Matti reported a Rev C board? > >> I vaguely remember from all those years ago when I first enabled PRUSS on AM335x >> that some earlier BBB versions had some issues around PRUSS. > > What I am not using is PRUSS so it may (or may not) be disabled in CONFIG. Hi Nikolaus, Irrespective of whether you enable PRUSS configs or not (it's not enabled by default), the ti-sysc bus driver performs a enable and disable sequence during it's probe of the pruss_tm target-module. The module quirks are applied using the SYSC revision register value. The module will be disabled by the time you get to the console, and thereafter the enabling of PRUSS IP is done through pm_runtime API when the pruss module is probed. regards Suman ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-21 16:40 ` H. Nikolaus Schaller 2021-09-21 16:49 ` Suman Anna @ 2021-09-22 9:27 ` Vaittinen, Matti 2021-09-24 18:40 ` Robert Nelson 1 sibling, 1 reply; 24+ messages in thread From: Vaittinen, Matti @ 2021-09-22 9:27 UTC (permalink / raw) To: H. Nikolaus Schaller, Matti Vaittinen, Tony Lindgren Cc: Grygorii Strashko, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel, Suman Anna, linux-omap On 9/21/21 19:40, H. Nikolaus Schaller wrote: > Hi Matti, Tony, > >> Am 21.09.2021 um 18:07 schrieb Suman Anna <s-anna@ti.com>: >> >> Hi Matti, Tony, >> >> On 9/21/21 2:47 AM, Tony Lindgren wrote: >>> * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: >>>> Finally, adding the udelay(100); (as Tony suggested) at the end of the >>>> omap_reset_deassert() did make the oops go away even when pruss_tm was >>>> enabled. I don't know what would be a proper fix though. >> >> I have been able to boot v5.15-rc1 just fine on my BBB without any additional >> changes [1]. > > Same for me with a v5.15-rc1 based kernel. > >> May I ask what is your BBB board version? My board is rev.A5C. > > I have an Rev B6 with EXP41 display attached. I think Matti reported a Rev C board? Oops. Yes I did. I _thought_ I have Rev-C (3?) boards. Not exactly sure why I think so - perhaps that was what I ordered... And I really think the ones connected to automated test setup at the office are Rev-C. Now that I tried to verify this - The one which I used to reproduce this issue (and now verify the patch from Tony) at home, seems to have say "PCB Rev6B" on PCB. However the u-boot says: => printenv board_rev board_rev=00C0 => but I have no idea where the environment variable comes from... Maybe a stupid question - how to find out the exact revision? Best Regards Matti Vaittinen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-22 9:27 ` Vaittinen, Matti @ 2021-09-24 18:40 ` Robert Nelson 2021-09-30 8:10 ` Tony Lindgren 0 siblings, 1 reply; 24+ messages in thread From: Robert Nelson @ 2021-09-24 18:40 UTC (permalink / raw) To: Vaittinen, Matti Cc: H. Nikolaus Schaller, Matti Vaittinen, Tony Lindgren, Grygorii Strashko, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel, Suman Anna, linux-omap On Wed, Sep 22, 2021 at 4:28 AM Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> wrote: > > On 9/21/21 19:40, H. Nikolaus Schaller wrote: > > Hi Matti, Tony, > > > >> Am 21.09.2021 um 18:07 schrieb Suman Anna <s-anna@ti.com>: > >> > >> Hi Matti, Tony, > >> > >> On 9/21/21 2:47 AM, Tony Lindgren wrote: > >>> * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: > >>>> Finally, adding the udelay(100); (as Tony suggested) at the end of the > >>>> omap_reset_deassert() did make the oops go away even when pruss_tm was > >>>> enabled. I don't know what would be a proper fix though. > >> > >> I have been able to boot v5.15-rc1 just fine on my BBB without any additional > >> changes [1]. > > > > Same for me with a v5.15-rc1 based kernel. > > > >> May I ask what is your BBB board version? My board is rev.A5C. > > > > I have an Rev B6 with EXP41 display attached. I think Matti reported a Rev C board? > > Oops. Yes I did. I _thought_ I have Rev-C (3?) boards. Not exactly sure > why I think so - perhaps that was what I ordered... And I really think > the ones connected to automated test setup at the office are Rev-C. > > Now that I tried to verify this - The one which I used to reproduce this > issue (and now verify the patch from Tony) at home, seems to have say > "PCB Rev6B" on PCB. However the u-boot says: > > => printenv board_rev > board_rev=00C0 > => > > but I have no idea where the environment variable comes from... > > Maybe a stupid question - how to find out the exact revision? Run: hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -n 28 | cut -b 5-28 Then lookup: https://github.com/beagleboard/image-builder/blob/master/readme.md Regards, -- Robert Nelson https://rcn-ee.com/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-24 18:40 ` Robert Nelson @ 2021-09-30 8:10 ` Tony Lindgren 2021-09-30 9:41 ` Vaittinen, Matti 0 siblings, 1 reply; 24+ messages in thread From: Tony Lindgren @ 2021-09-30 8:10 UTC (permalink / raw) To: Robert Nelson Cc: Vaittinen, Matti, H. Nikolaus Schaller, Matti Vaittinen, Grygorii Strashko, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel, Suman Anna, linux-omap * Robert Nelson <robertcnelson@gmail.com> [210924 18:41]: > On Wed, Sep 22, 2021 at 4:28 AM Vaittinen, Matti > <Matti.Vaittinen@fi.rohmeurope.com> wrote: > > Maybe a stupid question - how to find out the exact revision? > > Run: > > hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -n 28 | cut -b 5-28 > > Then lookup: > > https://github.com/beagleboard/image-builder/blob/master/readme.md So do I need some kernel module for this with the mainline kernel loaded? I don't have eeprom listed under 0-0050. I also see eeprom only for am335x-pocketbeagle.dts and am57xx-beagle-x15-common.dtsi so maybe it should be justd added? I guess this could be checked with i2cget command too meanwhile. Regards, Tony ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-30 8:10 ` Tony Lindgren @ 2021-09-30 9:41 ` Vaittinen, Matti 0 siblings, 0 replies; 24+ messages in thread From: Vaittinen, Matti @ 2021-09-30 9:41 UTC (permalink / raw) To: Tony Lindgren, Robert Nelson Cc: H. Nikolaus Schaller, Matti Vaittinen, Grygorii Strashko, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel, Suman Anna, linux-omap Hi dee Ho peeps. On 9/30/21 11:10, Tony Lindgren wrote: > * Robert Nelson <robertcnelson@gmail.com> [210924 18:41]: >> On Wed, Sep 22, 2021 at 4:28 AM Vaittinen, Matti >> <Matti.Vaittinen@fi.rohmeurope.com> wrote: >>> Maybe a stupid question - how to find out the exact revision? >> >> Run: >> >> hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -n 28 | cut -b 5-28 >> >> Then lookup: >> >> https://github.com/beagleboard/image-builder/blob/master/readme.md Thanks! What I read out was: A335BNLT00C03614BBBK9018 which I assume means the Rev C. (Two of the boards have element 14 printed on PCB, one has beagleboard.) > > So do I need some kernel module for this with the mainline kernel > loaded? I don't have eeprom listed under 0-0050. > > I also see eeprom only for am335x-pocketbeagle.dts and > am57xx-beagle-x15-common.dtsi so maybe it should be justd added? I did have the eeprom driver load and eeprom accessible - and I don't think I have any DTS modifications. Perhaps you just don't have the correct eeprom driver enabled at config? Best Regards -- Matti ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-21 16:07 ` Suman Anna 2021-09-21 16:40 ` H. Nikolaus Schaller @ 2021-09-21 20:29 ` Drew Fustini 2021-09-21 21:49 ` Suman Anna 1 sibling, 1 reply; 24+ messages in thread From: Drew Fustini @ 2021-09-21 20:29 UTC (permalink / raw) To: Suman Anna Cc: Tony Lindgren, Matti Vaittinen, Grygorii Strashko, Vaittinen, Matti, linux-omap, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel On Tue, Sep 21, 2021 at 9:09 AM Suman Anna <s-anna@ti.com> wrote: > > Hi Matti, Tony, > > On 9/21/21 2:47 AM, Tony Lindgren wrote: > > * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: > >> Finally, adding the udelay(100); (as Tony suggested) at the end of the > >> omap_reset_deassert() did make the oops go away even when pruss_tm was > >> enabled. I don't know what would be a proper fix though. > > I have been able to boot v5.15-rc1 just fine on my BBB without any additional > changes [1]. > > May I ask what is your BBB board version? My board is rev.A5C. That rev is quite old [1]. Would you be able to try a Rev C? It has been in production since around 2014 with the move from 2GB to 4GB eMMC. Thanks, Drew [1] https://elinux.org/Beagleboard:BeagleBoneBlack#Revision_A5C ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-21 20:29 ` Drew Fustini @ 2021-09-21 21:49 ` Suman Anna 2021-09-21 22:00 ` Robert Nelson 0 siblings, 1 reply; 24+ messages in thread From: Suman Anna @ 2021-09-21 21:49 UTC (permalink / raw) To: Drew Fustini Cc: Tony Lindgren, Matti Vaittinen, Grygorii Strashko, Vaittinen, Matti, linux-omap, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel On 9/21/21 3:29 PM, Drew Fustini wrote: > On Tue, Sep 21, 2021 at 9:09 AM Suman Anna <s-anna@ti.com> wrote: >> >> Hi Matti, Tony, >> >> On 9/21/21 2:47 AM, Tony Lindgren wrote: >>> * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: >>>> Finally, adding the udelay(100); (as Tony suggested) at the end of the >>>> omap_reset_deassert() did make the oops go away even when pruss_tm was >>>> enabled. I don't know what would be a proper fix though. >> >> I have been able to boot v5.15-rc1 just fine on my BBB without any additional >> changes [1]. >> >> May I ask what is your BBB board version? My board is rev.A5C. > > That rev is quite old [1]. Would you be able to try a Rev C? It has > been in production since around 2014 with the move from 2GB to 4GB > eMMC. I don't have any rev.C boards handy to try. I am curious to see if there is some correlation between failures and board versions. I see that there is a minor processor change to AM3358 from rev.B onwards compared to the AM3359 that I would have on my board. PRU-ICSS IP would be present and supported on both though. regards Suman > > Thanks, > Drew > [1] https://elinux.org/Beagleboard:BeagleBoneBlack#Revision_A5C > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-21 21:49 ` Suman Anna @ 2021-09-21 22:00 ` Robert Nelson 2021-09-21 23:53 ` Suman Anna 0 siblings, 1 reply; 24+ messages in thread From: Robert Nelson @ 2021-09-21 22:00 UTC (permalink / raw) To: Suman Anna Cc: Drew Fustini, Tony Lindgren, Matti Vaittinen, Grygorii Strashko, Vaittinen, Matti, linux-omap, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel On Tue, Sep 21, 2021 at 4:54 PM Suman Anna <s-anna@ti.com> wrote: > > On 9/21/21 3:29 PM, Drew Fustini wrote: > > On Tue, Sep 21, 2021 at 9:09 AM Suman Anna <s-anna@ti.com> wrote: > >> > >> Hi Matti, Tony, > >> > >> On 9/21/21 2:47 AM, Tony Lindgren wrote: > >>> * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: > >>>> Finally, adding the udelay(100); (as Tony suggested) at the end of the > >>>> omap_reset_deassert() did make the oops go away even when pruss_tm was > >>>> enabled. I don't know what would be a proper fix though. > >> > >> I have been able to boot v5.15-rc1 just fine on my BBB without any additional > >> changes [1]. > >> > >> May I ask what is your BBB board version? My board is rev.A5C. > > > > That rev is quite old [1]. Would you be able to try a Rev C? It has > > been in production since around 2014 with the move from 2GB to 4GB > > eMMC. > > I don't have any rev.C boards handy to try. > > I am curious to see if there is some correlation between failures and board > versions. I see that there is a minor processor change to AM3358 from rev.B > onwards compared to the AM3359 that I would have on my board. PRU-ICSS IP would > be present and supported on both though. Rev B vs Rev C shouldn't matter.. I don't think I even have a Rev "B".. A6A, B, to C* was done very quickly at CIrcuitCo at that time.. https://elinux.org/Beagleboard:BeagleBoneBlack#Revision_B "This version moves to the AM3358BZCZ100 processor as we are no longer able to get the limited production version of the AM3359AZCZ100." I'm assuming the AM3358 had the pru enabled.. Regards, -- Robert Nelson https://rcn-ee.com/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-21 22:00 ` Robert Nelson @ 2021-09-21 23:53 ` Suman Anna 0 siblings, 0 replies; 24+ messages in thread From: Suman Anna @ 2021-09-21 23:53 UTC (permalink / raw) To: Robert Nelson Cc: Drew Fustini, Tony Lindgren, Matti Vaittinen, Grygorii Strashko, Vaittinen, Matti, linux-omap, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel On 9/21/21 5:00 PM, Robert Nelson wrote: > On Tue, Sep 21, 2021 at 4:54 PM Suman Anna <s-anna@ti.com> wrote: >> >> On 9/21/21 3:29 PM, Drew Fustini wrote: >>> On Tue, Sep 21, 2021 at 9:09 AM Suman Anna <s-anna@ti.com> wrote: >>>> >>>> Hi Matti, Tony, >>>> >>>> On 9/21/21 2:47 AM, Tony Lindgren wrote: >>>>> * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: >>>>>> Finally, adding the udelay(100); (as Tony suggested) at the end of the >>>>>> omap_reset_deassert() did make the oops go away even when pruss_tm was >>>>>> enabled. I don't know what would be a proper fix though. >>>> >>>> I have been able to boot v5.15-rc1 just fine on my BBB without any additional >>>> changes [1]. >>>> >>>> May I ask what is your BBB board version? My board is rev.A5C. >>> >>> That rev is quite old [1]. Would you be able to try a Rev C? It has >>> been in production since around 2014 with the move from 2GB to 4GB >>> eMMC. >> >> I don't have any rev.C boards handy to try. >> >> I am curious to see if there is some correlation between failures and board >> versions. I see that there is a minor processor change to AM3358 from rev.B >> onwards compared to the AM3359 that I would have on my board. PRU-ICSS IP would >> be present and supported on both though. > > Rev B vs Rev C shouldn't matter.. I don't think I even have a Rev > "B".. A6A, B, to C* was done very quickly at CIrcuitCo at that time.. > > https://elinux.org/Beagleboard:BeagleBoneBlack#Revision_B > > "This version moves to the AM3358BZCZ100 processor as we are no longer > able to get the limited production version of the AM3359AZCZ100." > > I'm assuming the AM3358 had the pru enabled.. Yes, PRU-ICSS is present on AM3356 and above. regards Suman ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-21 7:47 ` Tony Lindgren 2021-09-21 16:07 ` Suman Anna @ 2021-09-22 8:44 ` Vaittinen, Matti 2021-09-22 8:48 ` Tony Lindgren 1 sibling, 1 reply; 24+ messages in thread From: Vaittinen, Matti @ 2021-09-22 8:44 UTC (permalink / raw) To: Tony Lindgren, Matti Vaittinen Cc: Grygorii Strashko, linux-omap, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel Hi Tony & All, On 9/21/21 10:47, Tony Lindgren wrote: > * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: > > It also allows leaving out the udelay for dra7 iva reset. Care to try > this and see if it helps? Thanks Tony. I applied your patch on top of v5.15-rc1 and my BBB booted up successfully. I didn't give it more than few attempts though. Do you think that could merged as a fix to mainline? If so - feel free to add a Tested-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Best Regards --Matti Vaittinen ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-22 8:44 ` Vaittinen, Matti @ 2021-09-22 8:48 ` Tony Lindgren 2021-09-30 8:06 ` Tony Lindgren 0 siblings, 1 reply; 24+ messages in thread From: Tony Lindgren @ 2021-09-22 8:48 UTC (permalink / raw) To: Vaittinen, Matti Cc: Matti Vaittinen, Grygorii Strashko, linux-omap, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel * Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> [210922 08:45]: > Hi Tony & All, > > > On 9/21/21 10:47, Tony Lindgren wrote: > > * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: > > > > It also allows leaving out the udelay for dra7 iva reset. Care to try > > this and see if it helps? > > Thanks Tony. I applied your patch on top of v5.15-rc1 and my BBB booted > up successfully. I didn't give it more than few attempts though. Do you > think that could merged as a fix to mainline? > > If so - feel free to add a > Tested-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> OK great, good to hear! And thanks for testing :) Yeah I'll post a proper fix for mainline. But one thing to consider though.. I'm wondering if we should always wait for the rstctrl bit to go down before we even attempt to check the rststs bit if a rststs registe exists. Regards, Tony ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: beaglebone black boot failure Linux v5.15.rc1 2021-09-22 8:48 ` Tony Lindgren @ 2021-09-30 8:06 ` Tony Lindgren 0 siblings, 0 replies; 24+ messages in thread From: Tony Lindgren @ 2021-09-30 8:06 UTC (permalink / raw) To: Vaittinen, Matti Cc: Matti Vaittinen, Grygorii Strashko, linux-omap, Suman Anna, Paul Barker, Peter Ujfalusi, Benoît Cousson, linux-kernel * Tony Lindgren <tony@atomide.com> [210922 08:49]: > * Vaittinen, Matti <Matti.Vaittinen@fi.rohmeurope.com> [210922 08:45]: > > Hi Tony & All, > > > > > > On 9/21/21 10:47, Tony Lindgren wrote: > > > * Matti Vaittinen <mazziesaccount@gmail.com> [210920 08:23]: > > > > > > It also allows leaving out the udelay for dra7 iva reset. Care to try > > > this and see if it helps? > > > > Thanks Tony. I applied your patch on top of v5.15-rc1 and my BBB booted > > up successfully. I didn't give it more than few attempts though. Do you > > think that could merged as a fix to mainline? > > > > If so - feel free to add a > > Tested-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> > > OK great, good to hear! And thanks for testing :) Yeah I'll post a proper > fix for mainline. But one thing to consider though.. > > I'm wondering if we should always wait for the rstctrl bit to go down > before we even attempt to check the rststs bit if a rststs registe > exists. I've sent out a proper patch for this at [0] below, please review and test. Regards, Tony [0] [PATCH] soc: ti: omap-prm: Fix external abort for am335x pruss https://lore.kernel.org/linux-omap/20210930080100.56820-1-tony@atomide.com/T/#u ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2021-09-30 9:41 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-16 9:15 beaglebone black boot failure Linux v5.15.rc1 Vaittinen, Matti 2021-09-17 6:14 ` Tony Lindgren 2021-09-17 10:28 ` Vaittinen, Matti 2021-09-17 10:47 ` Tony Lindgren 2021-09-17 10:57 ` Grygorii Strashko 2021-09-17 11:01 ` Grygorii Strashko 2021-09-17 11:34 ` Vaittinen, Matti 2021-09-17 12:36 ` Grygorii Strashko 2021-09-20 10:05 ` Matti Vaittinen 2021-09-21 7:47 ` Tony Lindgren 2021-09-21 16:07 ` Suman Anna 2021-09-21 16:40 ` H. Nikolaus Schaller 2021-09-21 16:49 ` Suman Anna 2021-09-22 9:27 ` Vaittinen, Matti 2021-09-24 18:40 ` Robert Nelson 2021-09-30 8:10 ` Tony Lindgren 2021-09-30 9:41 ` Vaittinen, Matti 2021-09-21 20:29 ` Drew Fustini 2021-09-21 21:49 ` Suman Anna 2021-09-21 22:00 ` Robert Nelson 2021-09-21 23:53 ` Suman Anna 2021-09-22 8:44 ` Vaittinen, Matti 2021-09-22 8:48 ` Tony Lindgren 2021-09-30 8:06 ` Tony Lindgren
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.