P1022:kernel hangs after loading device tree print

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

P1022:kernel hangs after loading device tree print

4,217 Views
santoshkumaraki
Contributor II

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.

Labels (1)
0 Kudos
20 Replies

3,469 Views
timur_tabi
Contributor I

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.

0 Kudos

3,465 Views
santoshkumaraki
Contributor II

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???

0 Kudos

3,469 Views
adeel
Contributor III

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

0 Kudos

3,469 Views
santoshkumaraki
Contributor II

Hi Adeel,

Thanks for your replay...

Full address is 0x00000E00.

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

Regards,

Santosh Kumar

0 Kudos

3,466 Views
adeel
Contributor III

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.

0 Kudos

3,466 Views
santoshkumaraki
Contributor II

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.

0 Kudos

3,466 Views
scottwood
NXP Employee
NXP Employee

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.

0 Kudos

3,466 Views
santoshkumaraki
Contributor II

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..

error.jpg

0 Kudos

3,466 Views
adeel
Contributor III

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

0 Kudos

3,466 Views
santoshkumaraki
Contributor II

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.

0 Kudos

3,466 Views
adeel
Contributor III

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

0 Kudos

3,465 Views
santoshkumaraki
Contributor II

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?  .

0 Kudos

3,465 Views
adeel
Contributor III

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

0 Kudos

3,465 Views
santoshkumaraki
Contributor II

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.

0 Kudos

3,465 Views
scottwood
NXP Employee
NXP Employee

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.

0 Kudos

3,468 Views
adeel
Contributor III

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.

0 Kudos

3,470 Views
santoshkumaraki
Contributor II

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.

0 Kudos

3,468 Views
timur_tabi
Contributor I

Try enabling early console.  You might get more output.

0 Kudos

3,469 Views
santoshkumaraki
Contributor II

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.

0 Kudos

3,469 Views
timur_tabi
Contributor I

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.

0 Kudos