Jump to content
  • 0

zybo won't boot on sd card FSBL LED D4 (LD_MIO)


toastedcpu

Question

Hello,

On the ZYBO, does the green LD4 (LED_MIO) play a role at boot up?

While working on http://www.instructables.com/id/Embedded-Linux-Tutorial-Zybo/, I made two BOOT.BINs. One of them boots the SD card properly, so I get the green DONE LD10 lit up with serial terminal activity. The other BOOT.BIN will not light up the green DONE and the LD4 (LED_MIO) goes on. 

Also, what could be wrong in my BOOT.BIN? I did the FSBL.elf (bootloader partition), system.bit(data file) and u-boot.elf(data file) in the order of the tutorial.

Frank

Link to comment
Share on other sites

2 answers to this question

Recommended Posts

Hi Frank,

LD4 is a software controlled LED. Its most common use is to indicate CPU or Disk activity when running Linux. This is handled entirely in the device tree, and you can tell if one of your designs is doing this by searching the dts and dtsi files for a gpio-leds node (or reverse compiling the dtb), as described here: https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt . Back to the point, I'm not really sure what it is doing in the design that is failing to boot.

LD10 indicates that the PL (FPGA) portion of the Zynq has been configured. Though it is possible to boot into Linux without programming the PL, I doubt this is the intention. With that in mind, it is likely that either (1) your FSBL is failing and hanging somewhere in an error state or (2) The FSBL was created with .bit by accident, and your program is hanging early in the boot process, because the CPU tends to hang when it tries to access a peripheral in the PL that isn't there (because the FPGA isn't programmed). 

Does your second BOOT.BIN include a .bit file? If it already is, you could try to get some additional debugging messages from the FSBL. I recall being able to do this by defining an additional preprocessor symbol for the fsbl project in Xilinx SDK, DEBUG I think (you should probably search around the fsbl source to make sure the symbol is actually DEBUG). You can make sure gcc adds the symbol by adding -DDEBUG to the command line (the extra 'D' is on purpose here). I think you can do this by right-clicking your project, choosing C/C++ Build options, choosing compiler options, and looking for a place to add in "misc" settings (sorry this is all from memory). Then just add -DDEBUG

Edit: I see you mentioned that you are using a .bitfile. So I expect the issue is your FSBL failing. You should definitely try to add the debugging messages. Also, make sure your bitfile can successfully program your board over JTAG (you can do this using the program FPGA button in Xilinx SDK, or the Hardware manager in Vivado).

Link to comment
Share on other sites

Hello,

Thanks for the response!

> This is handled entirely in the device tree, and you can tell if one of your designs is doing this by searching the dts and dtsi files for a gpio-leds node (or reverse compiling the dtb

Very cool.

 The problem was that I made two tutorials and got mixed up in the directories. I was putting a compiled FSBL for the Zedboard into a Zybo, so I put the FSBL elf into the BIN. At one point, I got a warning of the FPGA mismatch when I put the debug flag and tried to run the FSBL from the SDK. There is a difference in a clock frequency, so when I did try to see what would happen when stepping the code in SDK with the mismatch, the serial terminal was getting garbage characters because the baud rate was wrong. 

I got it to boot and run with the Easybox ramdisk, I am nearing the end.

Frank

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...