topic Re: Kernel panic boot fsl-image-full on p1020rdb boards in QorIQ

Kernel panic boot fsl-image-full on p1020rdb boards

binh — Thu, 16 Oct 2014 11:18:11 GMT

Hi,

I finally got the image to build but ran into the following problem when booting it:

U-Boot 2013.01 (Jan 21 2014 - 15:16:45)

CPU0: P1020E, Version: 1.1, (0x80ec0011)

Core: E500, Version: 5.1, (0x80212051)

Clock Configuration:

CPU0:800 MHz, CPU1:800 MHz,

CCB:400 MHz,

DDR:400 MHz (800 MT/s data rate) (Asynchronous), LBC:25 MHz

L1: D-cache 32 kB enabled

I-cache 32 kB enabled

Board: P1020RDB RevD

I2C: ready

SPI: ready

DRAM: Configuring DDR for 800 MT/s data rate

512 MiB (DDR2, 32-bit, CL=6, ECC off)

NOR Flash Bank : Primary

SD/MMC : 4-bit Mode

eSPI : Enabled

Flash: 16 MiB

L2: 256 KB enabled

NAND: 32 MiB

MMC: FSL_SDHC: 0

EEPROM: Invalid ID (87 87 87 87)

PCIe1: Root Complex of Slot 2, no link, regs @ 0xffe0a000

PCIe1: Bus 00 - 00

PCIe2: Root Complex of Slot 1, no link, regs @ 0xffe09000

PCIe2: Bus 01 - 01

In: serial

Out: eserial0

Err: serial

Net: eTSEC3 is in sgmii mode.

uploading VSC7385 microcode from ef000000

PHY reset timed out

eTSEC1, eTSEC2, eTSEC3

Hit any key to stop autoboot: 0

Partition Map for MMC device 0 -- Partition Type: DOS

Part Start Sector Num Sectors UUID Type

1 2048 3909632 00000000-01 83

Device: FSL_SDHC

Manufacturer ID: 1b

OEM: 534d

Name: 00000

Tran Speed: 50000000

Rd Block Len: 512

SD version 2.0

High Capacity: No

Capacity: 1.9 GiB

Bus Width: 4-bit

4195062 bytes read in 530 ms (7.5 MiB/s)

13842 bytes read in 260 ms (51.8 KiB/s)

## Booting kernel from Legacy Image at 01000000 ...

Image Name: Linux-3.12.19-rt30-QorIQ-SDK-V1.

Created: 2014-10-13 18:40:42 UTC

Image Type: PowerPC Linux Kernel Image (gzip compressed)

Data Size: 4194998 Bytes = 4 MiB

Load Address: 00000000

Entry Point: 00000000

Verifying Checksum ... OK

## Flattened Device Tree blob at 02000000

Booting using the fdt blob at 0x02000000

Uncompressing Kernel Image ... OK

Loading Device Tree to 03ff9000, end 03fff611 ... OK

Using P1020RDB-PD machine description

Memory CAM mapping: 256/256 Mb, residual: 0Mb

Linux version 3.12.19-rt30-QorIQ-SDK-V1.6+gc29fe1a (shadow@orcas) (gcc version 4.8.1 (GCC) ) #1 SMP Mon Oct 13 13:39:34 CDT 2014

CPU maps initialized for 1 thread per core

bootconsole [udbg0] enabled

setup_arch: bootmem

mpc85xx_rdb_setup_arch()

mpc85xx_qe_init: Could not find Quicc Engine node

MPC85xx RDB board from Freescale Semiconductor

arch: exit

Zone ranges:

DMA [mem 0x00000000-0x1fffffff]

Normal empty

HighMem empty

Movable zone start for each node

Early memory node ranges

node 0: [mem 0x00000000-0x1fffffff]

MMU: Allocated 1088 bytes of context maps for 255 contexts

PERCPU: Embedded 7 pages/cpu @c0d69000 s7104 r8192 d13376 u32768

Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048

Kernel command line: ip=10.8.118.167::10.8.119.254:255.255.254.0:p1020_eval3:eth0:off root=/dev/mmcblk0p1 rootfstype=ext2 rw init=/sbin/init rootdelay=3 console=ttyS0,115200

PID hash table entries: 2048 (order: 1, 8192 bytes)

Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)

Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)

Sorting __ex_table...

Memory: 444016K/524288K available (6000K kernel code, 316K rwdata, 1792K rodata, 268K init, 1217K bss, 80272K reserved, 0K highmem)

Kernel virtual memory layout:

* 0xfff5f000..0xfffff000 : fixmap

* 0xffc00000..0xffe00000 : highmem PTEs

* 0xffbfc000..0xffc00000 : early ioremap

* 0xe1000000..0xffbfc000 : vmalloc & ioremap

SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1

Hierarchical RCU implementation.

RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.

NR_IRQS:512 nr_irqs:512 16

mpic: Setting up MPIC " OpenPIC " version 1.2 at ffe40000, max 2 CPUs

mpic: ISU size: 256, shift: 8, mask: ff

mpic: Initializing for 256 sources

mpc85xx_rdb_pic_init: Could not find qe-ic node

clocksource: timebase mult[14000000] shift[24] registered

Console: colour dummy device 80x25

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

mpic: requesting IPIs...

Brought up 2 CPUs

devtmpfs: initialized

NET: Registered protocol family 16

Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->0

PCI host bridge /pcie@ffe09000 (primary) ranges:

MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000

IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000

/pcie@ffe09000: PCICSRBAR @ 0xfff00000

Found FSL PCI host bridge at 0x00000000ffe0a000. Firmware bus number: 0->0

PCI host bridge /pcie@ffe0a000 ranges:

MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000

IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000

/pcie@ffe0a000: PCICSRBAR @ 0xfff00000

PCI: Probing PCI hardware

fsl-pci ffe09000.pcie: PCI host bridge to bus 0000:00

pci_bus 0000:00: root bus resource [io 0x0000-0xffff]

pci_bus 0000:00: root bus resource [mem 0xa0000000-0xbfffffff]

pci_bus 0000:00: root bus resource [bus 00-ff]

pci 0000:00:00.0: ignoring class 0x0b2000 (doesn't match header type 01)

pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring

pci 0000:00:00.0: PCI bridge to [bus 01-ff]

fsl-pci ffe0a000.pcie: PCI host bridge to bus 0001:02

pci_bus 0001:02: root bus resource [io 0x20000-0x2ffff] (bus address [0x0000-0xffff])

pci_bus 0001:02: root bus resource [mem 0x80000000-0x9fffffff]

pci_bus 0001:02: root bus resource [bus 02-ff]

pci 0001:02:00.0: ignoring class 0x0b2000 (doesn't match header type 01)

pci 0001:02:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring

pci 0001:02:00.0: PCI bridge to [bus 03-ff]

pci 0000:00:00.0: PCI bridge to [bus 01]

pci 0000:00:00.0: bridge window [io 0x0000-0xffff]

pci 0000:00:00.0: bridge window [mem 0xa0000000-0xbfffffff]

pci 0001:02:00.0: PCI bridge to [bus 03]

pci 0001:02:00.0: bridge window [io 0x20000-0x2ffff]

pci 0001:02:00.0: bridge window [mem 0x80000000-0x9fffffff]

fsl-l2ctlr ffe20000.l2-cache-controller: Entire L2 as cache, provide valid sram address and size

fsl-l2ctlr: probe of ffe20000.l2-cache-controller failed with error -22

bio: create slab <bio-0> at 0

Freescale Elo series DMA driver

fsl-elo-dma ffe21300.dma: #0 (fsl,eloplus-dma-channel), irq 20

fsl-elo-dma ffe21300.dma: #1 (fsl,eloplus-dma-channel), irq 21

fsl-elo-dma ffe21300.dma: #2 (fsl,eloplus-dma-channel), irq 22

fsl-elo-dma ffe21300.dma: #3 (fsl,eloplus-dma-channel), irq 23

vgaarb: loaded

SCSI subsystem initialized

usbcore: registered new interface driver usbfs

usbcore: registered new interface driver hub

usbcore: registered new device driver usb

pps_core: LinuxPPS API ver. 1 registered

PTP clock support registered

EDAC MC: Ver: 3.0.0

Advanced Linux Sound Architecture Driver Initialized.

Switched to clocksource timebase

NET: Registered protocol family 2

TCP established hash table entries: 4096 (order: 3, 32768 bytes)

TCP bind hash table entries: 4096 (order: 3, 32768 bytes)

TCP: Hash tables configured (established 4096 bind 4096)

TCP: reno registered

UDP hash table entries: 256 (order: 1, 8192 bytes)

UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)

NET: Registered protocol family 1

RPC: Registered named UNIX socket transport module.

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

RPC: Registered tcp NFSv4.1 backchannel transport module.

Freescale PMC driver

audit: initializing netlink socket (disabled)

type=2000 audit(0.296:1): initialized

HugeTLB registered 1 MB page size, pre-allocated 0 pages

HugeTLB registered 4 MB page size, pre-allocated 0 pages

HugeTLB registered 16 MB page size, pre-allocated 0 pages

HugeTLB registered 64 MB page size, pre-allocated 0 pages

HugeTLB registered 256 MB page size, pre-allocated 0 pages

HugeTLB registered 1 GB page size, pre-allocated 0 pages

NFS: Registering the id_resolver key type

Key type id_resolver registered

Key type id_legacy registered

NTFS driver 2.1.30 [Flags: R/O].

msgmni has been set to 998

io scheduler noop registered

io scheduler deadline registered

io scheduler cfq registered (default)

Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled

serial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42, base_baud = 24999999) is a 16550A

console [ttyS0] enabled, bootconsole disabled

serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 42, base_baud = 24999999) is a 16550A

Generic non-volatile memory driver v1.1

brd: module loaded

loop: module loaded

nbd: registered device at major 43

st: Version 20101219, fixed bufsize 32768, s/g segs 256

Machine check in kernel mode.

Caused by (from MCSR=10008): Bus - Read Data Bus Error

Oops: Machine check, sig: 7 [#1]

SMP NR_CPUS=8 P1020RDB-PD

Modules linked in:

CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.12.19-rt30-QorIQ-SDK-V1.6+gc29fe1a #1

task: df050000 ti: dffec000 task.ti: df04c000

NIP: c036b9b0 LR: c036bb20 CTR: c036a7dc

REGS: dffedf10 TRAP: 0204 Not tainted (3.12.19-rt30-QorIQ-SDK-V1.6+gc29fe1a)

MSR: 00029000 <CE,EE,ME> CR: 22808922 XER: 00000000

GPR00: 00000001 df04dc50 df050000 df23dca0 00000020 00005959 00005151 00000002

GPR08: 00000022 e1100000 00000002 00005252 00005200 00000000 df23dca0 c0732dfc

GPR16: c0608c48 c0733c54 c0733c90 c0733bdc c07e98d0 00000000 df1651f8 00000000

GPR24: c0732df0 df23dc90 df23dca0 00000001 df04dcb8 00000000 df04dcb8 df23dca0

NIP [c036b9b0] cfi_qry_present+0x228/0x248

LR [c036bb20] cfi_qry_mode_on+0x150/0xdd0

Call Trace:

[df04dc50] [c0476058] of_find_property+0x40/0x68 (unreliable)

[df04dc60] [00000001] 0x1

[df04dc80] [c036a824] cfi_probe_chip+0x48/0xc20

[df04dcb0] [c0379b84] mtd_do_chip_probe+0x94/0x3a4

[df04dd30] [c036a718] do_map_probe+0x34/0x98

[df04dd50] [c037a18c] of_flash_probe+0x220/0x5e0

[df04dde0] [c0303b1c] really_probe+0x78/0x25c

[df04de00] [c0303e48] __driver_attach+0xc8/0xcc

[df04de20] [c0301b04] bus_for_each_dev+0x6c/0xb8

[df04de50] [c0303150] bus_add_driver+0x204/0x2c8

[df04de70] [c030459c] driver_register+0x88/0x138

[df04de80] [c00021d8] do_one_initcall+0x154/0x1a4

[df04def0] [c07a08ec] kernel_init_freeable+0x134/0x1d4

[df04df20] [c00027dc] kernel_init+0x18/0x174

[df04df40] [c000efc8] ret_from_kernel_thread+0x5c/0x64

Instruction dump:

40bdfec0 2f850003 41befeb8 3ca05900 4bfffeb4 7d043a14 7d4920ae 7ce83a14

7d0940ae 7c6938ae 4bfffeec 7d043a14 <7d49222e> 7ce74214 7d09422e 7c693a2e

---[ end trace cc7a1101673bbbc9 ]---

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007

Rebooting in 180 seconds..

Any one know what's wrong? It seems like something with the flash.

So I thought it might be an old u-boot not being able to boot the newer kernels. When I tried

to update u-boot, I get this problem:

=> setenv uboot u-boot-P1020RDB-PD-2014.01+fslgit-r0.bin
=> tftpboot $loadaddr 10.7.12.154:$uboot

Speed: 1000, full duplex

Using eTSEC1 device

TFTP from server 10.7.12.154; our IP address is 10.8.118.167; sending through gateway 10.8.119.254

Filename 'u-boot-P1020RDB-PD-2014.01+fslgit-r0.bin'.

Load address: 0x1000000

Loading: ######################################################

1.6 MiB/s

done

Bytes transferred = 786432 (c0000 hex)

=> protect off 0xeff80000 +$filesize

Error: end address (0xf003ffff) not in flash!

Bad address format

It seems the u-boot image that got created are too big for the flash on the p1020rdb boards.

[shadow@orcas]$ ls -l build_p1020rdb_release/tmp/deploy/images/p1020rdb/u-boot*

-rwxr-xr-x 1 shadow shadow 786432 Oct 13 17:42 build_p1020rdb_release/tmp/deploy/images/p1020rdb/u-boot-P1020RDB-PD-2014.01+fslgit-r0.bin

lrwxrwxrwx 1 shadow shadow 40 Oct 13 17:42 build_p1020rdb_release/tmp/deploy/images/p1020rdb/u-boot-P1020RDB-PD.bin -> u-boot-P1020RDB-PD-2014.01+fslgit-r0.bin

-rwxr-xr-x 1 shadow shadow 740260 Oct 13 17:42 build_p1020rdb_release/tmp/deploy/images/p1020rdb/u-boot-nand-P1020RDB-PD_NAND-2014.01+fslgit-r0.bin

lrwxrwxrwx 1 shadow shadow 50 Oct 13 17:42 build_p1020rdb_release/tmp/deploy/images/p1020rdb/u-boot-nand-P1020RDB-PD_NAND.bin -> u-boot-nand-P1020RDB-PD_NAND-2014.01+fslgit-r0.bin

-rwxr-xr-x 1 shadow shadow 609140 Oct 13 17:42 build_p1020rdb_release/tmp/deploy/images/p1020rdb/u-boot-sd-P1020RDB-PD_SDCARD-2014.01+fslgit-r0.bin

lrwxrwxrwx 1 shadow shadow 50 Oct 13 17:42 build_p1020rdb_release/tmp/deploy/images/p1020rdb/u-boot-sd-P1020RDB-PD_SDCARD.bin -> u-boot-sd-P1020RDB-PD_SDCARD-2014.01+fslgit-r0.bin

-rwxr-xr-x 1 shadow shadow 610304 Oct 13 17:42 build_p1020rdb_release/tmp/deploy/images/p1020rdb/u-boot-spi-P1020RDB-PD_SPIFLASH-2014.01+fslgit-r0.bin

lrwxrwxrwx 1 shadow shadow 53 Oct 13 17:42 build_p1020rdb_release/tmp/deploy/images/p1020rdb/u-boot-spi-P1020RDB-PD_SPIFLASH.bin -> u-boot-spi-P1020RDB-PD_SPIFLASH-2014.01+fslgit-r0.bin

Any way to reduce the size of u-boot?

Thanks,

- binh

Re: Kernel panic boot fsl-image-full on p1020rdb boards

danielglasser — Wed, 05 Nov 2014 19:08:06 GMT

The newer U-Boot gets programmed 256K earlier, so instead of 0xeff80000, it goes at 0xeff40000, so it becomes:

You may wish to try:

=> protect off 0xeff40000 +$filesize
=> erase 0xeff40000 +$filesize
=> cp.b $loadaddr 0xeff40000 $filesize

Hope that this helps.

Re: Kernel panic boot fsl-image-full on p1020rdb boards

binh — Wed, 05 Nov 2014 19:17:09 GMT

Re: Kernel panic boot fsl-image-full on p1020rdb boards

danielglasser — Wed, 05 Nov 2014 23:20:31 GMT

While I appreciate blank verse as much as anyone, it is open to interpretation.

I hope that was either a "Thanks, but I've already solved this", or "I'll try that", and not a "You bricked my box!"

Re: Kernel panic boot fsl-image-full on p1020rdb boards

binh — Wed, 05 Nov 2014 23:32:51 GMT

Sorry, guess email reply didn't go through.

Thanks, I'll give that a try.

- binh

Re: Kernel panic boot fsl-image-full on p1020rdb boards

peterzheng — Sat, 28 Feb 2015 08:20:09 GMT

Hi Daniel,

I was faced with similar problem. My P4080DS shows "[0] panic: fdt too large: 4294967294 bytes .

So I followed your suggested command. Now it seems I have erased the image in the p4080ds. And now I cannot see the terminal from minicom. Did I accidentally brick the machine? Any suggestion?

Regards,

Peter Zheng

Re: Kernel panic boot fsl-image-full on p1020rdb boards

danielglasser — Mon, 02 Mar 2015 16:53:54 GMT

Peter:

My advice had been for the P1020RDB boards. Not sure what's going on with the P4080DS. I noticed that the NOR Flash allocation layout for the P1025TWR module is almost entirely different between what is shipped on it and what the FDT in the latest SDK from Freescale has for that board. If u-boot does not start when you apply power/reset the P4080DS, you may need to use JTAG to recover the module, otherwise you should look at the environment (or look at the "dts" (Device Tree Source) file that came along with the "u-boot.bin" and "uImage.dts" from the SDK where you got your new u-boot image. If u-boot is assuming the FDT to be at a new location, but there is random code/data at that location, the attempted interpretation of that data as an FDT might result in what you're seeing.

The documentation with the Freescale SDKs seems to be a bit sparse, and not always as clear or tutorial as one would like. I've pretty much given up on the SDK for my P1020RDB work because it does not support the revision of the module that we have a dozen or so of here an my workplace. The newest SDK does work for the P1025TWR module I have, however the u-boot that comes on the card does not support USB (I've not updated it yet), the kernel from the SDK does not seem to properly support the uSD card, but that's not going to help you solve your problem. The main thing to do is to look closely at the artifacts that the SDK does provide for your system, and reconfigure things according to the information embedded in those artifacts. The u-boot source itself may need to be consulted to determine where it expects the firmware/FDT/Root FS image/kernel and itself to be stored in NOR Flash, though it's easier to look at the ".dts" file. The addresses within NOR Flash in the .dts will be offsets from the beginning of NOR Flash, so you have to add that base address to the partition offset to get the actual values. In addition, the default environment set up for u-boot does not always match the layout of the system. On the P1025TWR, the original environment had the wrong value for the FDT NOR Flash address (along with a few other things), which caused it not to boot from NOR Flash on power-up. Took me a week to figure that one out.

I don't know about the P4080DS, but the P1020RDB has multiple boot options, each with its own copy of the boot software. Change a few switches and the board boots from a different memory technology device.

I'm sorry if my instructions caused you some grief.

Good luck!

Daniel

Re: Kernel panic boot fsl-image-full on p1020rdb boards

464438140 — Thu, 13 Aug 2020 02:03:04 GMT

I have a same qustion,how to deal with?Call me:464438140@qq.com