P1022:kernel hangs after loading device tree print

[santoshkumaraki]

Hi,

We are using P1022 processor based custom board.

SDKv1.9 is used to bring up Linux on this board.Using SD card interface we are able to run the U-boot.

While running kernel image(uImage) through uboot from SD card,We are getting console prints up to "Loading Device Tree to 004e5000, end 004ebc27 ... OK" and hangs.After enabling DEBUG macro in u-boot,prints are coming up to "## Transferring control to Linux (at address 20000000) ..." and hangs.

LOG:

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

   Image Name:  

   Image Type:   PowerPC Linux Kernel Image (gzip compressed)

   Data Size:    4256593 Bytes = 4.1 MiB

   Load Address: 20000000

   Entry Point:  20000000

   Verifying Checksum ... OK

## Flattened Device Tree blob at 00c00000

     Booting using the fdt blob at 0xc00000

     Uncompressing Kernel Image ... OK

    Loading Device Tree to 004e5000, end 004ebc27 ... OK

## Transferring control to Linux (at address 20000000) ...

   hangs......

By running codewarrior in attach mode,we are getting PC value as 0xe00.

Can any one please help me in this issue.

Regards,
Santosh Kumar.

[timur_tabi]

Sorry, you're going to have to figure that out.  It's the base address of the serial port you're using.  This is basic kernel debugging.

[santoshkumaraki]

We are unable to load u-boot elf to core-1 through debugger due to some issue. On core-0 u-boot is running successfully.

For linux porting whether both the cores should be enabled or not??

Whether this may cause any issue on linux porting???

[adeel]

Hi, What is the full address 0xe00?????? and what is mapped at 0xe00? Is it PCI?

[santoshkumaraki]

Hi Adeel,

Thanks for your replay...

Full address is 0x00000E00.

It is mapped to IVOR14 - instruction TLB error interrupt vector.

Regards,

Santosh Kumar

[adeel]

Santosh, I think there is no instruction at address 0x20000000. Why your Kernel Load address is 0x20000000:

Load Address: 20000000

Entry Point:  20000000

Usually they are 0x00000000.

[santoshkumaraki]

We have tried with default 0x0 address and observed prints are coming up to "Uncompressing Kernel Image ..."(OK print is not coming) getting hanged.

After changing load address and entry point to 0x20000000 using mkimage,uncompressing is working fine.

[scottwood]

0 is the correct address to uncompress the kernel to.  0xc00000 is a bad place to load the fdt, as it can get overwritten by a large kernel.  Move it higher.  Likewise, I would load the uImage higher than 0x01000000.

[santoshkumaraki]

Hi,

Thanks for your replay...

We have tried with default uImage with load address as 0x0 and observed prints are coming up to "Uncompressing Kernel Image ..."(OK print is not coming) and getting hanged.

We have observed u-boot is writing some interrupt vectors from 0x100 to 0xf00 locations.

After changing load address to 0x20000000 using mkimage uncompressing is working fine.

We are not sure whether this vectors causing issue or not...

Please find the screenshot for the interrupt vector address(IVOR) in codewarrior register list..

[adeel]

Scott is also right. Probably your device tree is overwritten by uImage. Download your uImage at 0x08000000.

[santoshkumaraki]

we are running uImage at 0x20000000(Load Address) and changed device tree load address to 0x08000000 and observed console prints are coming up to "Loading Device Tree to 004e5000, end 004ebc27 ... OK" ​and hangs.

[adeel]

Santosh, it is not overwritten problem. Your DRAM doesn't look good. I think you should check with your hardware guys.

[santoshkumaraki]

Ours is 2GB DDR, we performed mtest and observed,except for the memory range  0x100 to 0x1000 (where IVOR 0 to 15) mtest is passed for other memory regions of DDR.

Still it can be a DDR hardware error or we are missing something in configuration or it is expected behavior for IVOR mapped region.

And whether we need to relocate IVOR to some other region?  .

[adeel]

Santosh, If you load uncompressed image at 0x20000000 and the crashed happened then can you print memory content from debugger?

[santoshkumaraki]

We are able to uncompress kernel at 0x0 after fixing DDR intialization issue in u-boot.

Kernel prints are coming but kernel is hanging at "INIT: version 2.88 booting Starting udev udevd[1273]: starting version 182".

Please find the attached log for more details....

We have observing this error in the console:

FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

mmc0: Timeout waiting for hardware interrupt.

mmcblk0: timed out sending r/w cmd command, card status 0x900

Is there any change required in device tree or kernel config as we are using p1022 processor based custom board??

we are using following boot args:

setenv bootcmd 'setenv bootargs root=/dev/mmcblk0p2 rw rootdelay=5 console=$consoledev,$baudrate;mmcinfo;ext2load mmc 0:2 $loadaddr   /boot/$bootfile;ext2load mmc 0:2 $fdtaddr /boot/p1022_rfps.dtb;bootm $loadaddr - $fdtaddr'

please let us know is there any problem in boot args.

[scottwood]

No, you don't need to relocate IVORs.  You should not be taking an exception during the handoff.  That said, if you run a recent upstream U-Boot, IVORs are elsewhere which makes it easier to diagnose crashes during boot handoff.  Otherwise, you need to debug it the hard way to find out why an exception is happening.

[adeel]

Santosh, I think there is some problem with your DRAM. Could you print memory contents @ address 0x0 in u-boot? Also, try to write some dummy data to it. 0x0 is usually the address of mapped DRAM. You can look for the mapped DRAM address in board config file in u-boot.

[santoshkumaraki]

I am able to print memory content of DRAM(0x0) using u-boot.

U-boot is getting stuck after performing write operation from 0x0 to 0xff0.

We have observed u-boot is writing some interrupt vectors from 0x100 to 0xf00 locations.If we are doing write operations to these vector addresses u-boot is getting stuck.

Please find the attached memory dump in log file.

[timur_tabi]

Try enabling early console.  You might get more output.

[santoshkumaraki]

Hi timurtabi​,

Thanks for your replay...

I am not able to find any early printk/console option in kernel hacking in menuconfig..

kernel debugging options are not enabled in menuconfig.

But if we see .config file CONFIG_PPC_EARLY_DEBUG and CONFIG_EARLY_PRINTK are enabled.

Regards,

Santosh Kumar.

[timur_tabi]

You want the 'earlycon' command line parameter.  See https://www.kernel.org/doc/Documentation/kernel-parameters.txt.  I don't remember what the exact parameters would be.  You would need to figure out the physical address of the serial port you're using.