Is device tree kernel specific?

I'm attempting to compile a new kernel for my Zedboard (3.4.41), and since I can't find a Xilinx or Digilent version of this kernel, I have to do it from scratch.

I untarred it to a directory, copied over the config files from arch/arm/configs, and then built using the following steps:

make ARCH=arm xilinx_zynq_defconfig
make ARCH=arm menuconfig
make ARCH=arm UIMAGE_LOADADDR=0x8000 uImage

the kernel compiled cleanly, and mkimage made me a nice uImage file. I generated BOOT.bin via:
bootgen -image boot.bif -o i boot.bin -w

I copied BOOT.bin, and uImage to my sdcard. (After renaming uImage.bin to uImage).

When I boot my board, I get:

## Booting kernel from Legacy Image at 03000000 ...
   Image Name:   Linux-3.4.41-xilinx
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2286112 Bytes = 2.2 MiB
   Load Address: 00008000
   Entry Point: 00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 02000000 ...
   Image Name:
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    5309954 Bytes = 5.1 MiB
   Load Address: 00000000
   Entry Point: 00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a00000
   Booting using the fdt blob at 0x2a00000
   Loading Kernel Image ... OK
   Loading Ramdisk to 1f642000, end 1fb52602 ... OK
   Loading Device Tree to 1f63d000, end 1f641d46 ... OK

Starting kernel ...

and it hangs. Is this a device tree issue? If not, any ideas anyone?

0 Former Member over 11 years ago

Hey Fred, I can answer PART of that question. The Device Tree is an OS independent data file and should be the same for ANY kernel version that you compile up. Since the platform that the kernel runs on will be the same (Zedboard), then the hardware descriptions should be the same.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 zedhed over 11 years ago

Hi FredFlintstone,

Is there a specific reason that is forcing you to use a 3.4.41 kernel instead of one of the kernel versions from the published Linux releases on the Xilinx Wiki?

http://www.wiki.xilinx.com/Zynq+Releases

Those releases are made against specific git tags which are supposed to work okay for ZedBoard.

Regards,

-Kevin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Former Member over 11 years ago

Hey Kevin,

My project stipulates that all work will be done on 3.4.41, so I have no choice really.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 zedhed over 11 years ago

Hi FredFlintstone,

That is a tough position to be in since AFAIK there is not an official Xilinx release tag which covers that specific kernel version.

However, I did happen to notice that you are loading your kernel to location 0x8000 in memory. After that, your (5.1MB compressed) RAM disk image is getting loaded to 0x00000000 which seems to indicate your loaded kernel is getting clobbered during the RAM disk load. If this is indeed happening, that would explain why you cannot start the kernel since the kernel code is no longer loaded to memory in it's entirety.

Have you tried spacing these two pieces of memory further apart?

Regards,

-Kevin
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Former Member over 11 years ago

Hey Kevin,

I have a "backup" version of all the files on the SD card named *.old. And I can flip back and forth between them. Using the same ramdisk, and a bigger kernel image, it works fine. So, I don't think that's the issue.

As a matter of fact, after a hard day of assembly debugging, I have located what the problem IS. As for the WHY, I'm still working on that.

It's "putc".

<Speculation!>
It's waiting on a "space available" but to toggle on the UART. If that never happens, you are HUNG. In a nice tight 3 instruction loop.
</Speculation!>

The putstr("Uncompressing Linux..."); from misc.c is where it hangs. putstr calls putc to print the characters, and putc is hung in a loop waiting for a bit to change. So, to ME, that sounds like it's looking for the UART bit in the wrong place, or something similar to that.

Any suggestions are welcome!
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Former Member over 11 years ago

It has tossed all the characters in the UARTs buffer, it's now just waiting on UART_SR_TXEMPTY to be set.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Former Member over 11 years ago

Are you using arch/arm/boot/dts/zynq-zed.dts to generate your .dtb or are you using Xilinx SDK to make the .dts?

I've had the same issue for a ZC706 when using the .dts from SDK. The culprit was clkc. If I copied over armpll, ddrpll, iopll, & ps_clk I was able to get passed it.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel