Actions
Forum Thread Details
  • State Not Answered
  • Replies 2 replies
  • Subscribers 339 subscribers
  • Views 331 views
  • Users 0 members are here
Related

Linaro not booting on Zed after modifying HW reference design

Former Member

Hi everyone,

I'm able to boot Linaro on ZedBoard revD using a BOOT.BIN made out of the files [zynq_fsbl_0.elf + system.bit + u-boot.elf] provided by Digilent in the "ZedBoard Linux Hardware Design", using Vivado SDK.

After that, I took the "HDMI Bare Metal Reference Design Using ADV7511 and ADI IP" and made some changes using Vivado in order to include some video processing IPs generated with HLS. After generating the new bitstream, I export the hardware (including .bit) to SDK and generate a Zynq FSBL. Then, I create a BOOT.BIN out of the FSBL (also tried with the original one working from Digilent), the new bitstream and the original working u-boot.elf.

When trying to boot the system, it hangs at "uncompressing linux... done booting the kernel".

If I only change my new 'system_top.bit' by the original 'system.bit' given by Digilent, it boots fine (so I think the fsbl, u-boot.elf and kernel image are right). I've also tried a new devicetree.dtb, generating a .dts with SDK and compiling it with dtc, but same problem happens.

I'm using Vivado, HLS and SDK 2015.3.

Any help? Thanks in advance!!

Parents
  • 0

    Hi Angel,

    There are a lot of things that could be going wrong here, and I think the easiest way to isolate the issue is to revert back to a working platform and take one step at a time until you get it working platform at your current level.  There are many reasons why the system might appear to hang at that point in the boot, including an incompatible kernel build, a device tree that doesn't correctly represent the hardware, missing device drivers, missing driver associations (in the device tree) and even issues with the hardware design loaded to the programmable logic.

    You validated that actual hardware by booting the board with the Out-of-box Linux included with the kit.  So the next step should be to boot the HDMI Bare Metal Ref Design and validate that the color bars are working correctly, using the pre-built files supplied.  Next, build the design using the same tool version as the working design and boot that.  If all is well, you can update the hardware and software platforms to 2015.3 and see if that still works.

    With success here, you can try running the Linaro kernel supplied with the HDMI Linux design, which uses the same hw platform.  I'd recommend rebuilding the kernel from scratch so you have a good understanding of how this is done, because you will likely need to change the configuraton and device tree for your hardware modifications.  Note that using the device tree generator often does not provide a complete, working device tree source file, as there is no way to detect innumerable devices that don't have a direct connection to the Zynq device, but may require an associated driver (SPI sensors, for example).

    Finally, update your hardware design, and load the same kernel to make sure it boots without changing anything.  Linux won't recognize the new IP blocks, but it should still ignore them and boot fine.   At that point you can start reconfiguring the kernel and adding in devices and driver associations to the device tree, validating the boot at each step along the way.

    Ron

  • 0 in reply to Former Member

    Hi Ron,

    Thanks for your time and help.

    Today I found a solution (perhaps not the only/best possible) for the problem. I was able to boot Linux with my bitstream using the kernel in "uImage" format and manually running "bootm <uImage> - <devicetree>" on the u-boot prompt (instead of using "zImage" format and default "go <0x8000>" instruction). The u-boot and fsbl are the same in both cases. Any ideas about the reason for that?

    To find out how to solve the issue using a zImage, I probably should go step by step as you recommend - thanks for the checkpoints you suggest.

    Talking about the devicetree, the one of the reference design fails (memory map issue). The one generated with SDK works, but not with video output capabilities. Another one modified from the reference works, but it says kernel panic - which I solved setting an environment variable fdt_high=0x10000000 (http://zedboard.org/content/linux-kernel-panic-boot-mem256m). Why are the devicetrees moved to different addresses, so that one of them needs this variable?

    Regards,

    Angel

Reply
  • 0 in reply to Former Member

    Hi Ron,

    Thanks for your time and help.

    Today I found a solution (perhaps not the only/best possible) for the problem. I was able to boot Linux with my bitstream using the kernel in "uImage" format and manually running "bootm <uImage> - <devicetree>" on the u-boot prompt (instead of using "zImage" format and default "go <0x8000>" instruction). The u-boot and fsbl are the same in both cases. Any ideas about the reason for that?

    To find out how to solve the issue using a zImage, I probably should go step by step as you recommend - thanks for the checkpoints you suggest.

    Talking about the devicetree, the one of the reference design fails (memory map issue). The one generated with SDK works, but not with video output capabilities. Another one modified from the reference works, but it says kernel panic - which I solved setting an environment variable fdt_high=0x10000000 (http://zedboard.org/content/linux-kernel-panic-boot-mem256m). Why are the devicetrees moved to different addresses, so that one of them needs this variable?

    Regards,

    Angel

Children
No Data