Stuck on black and white "XILLYBUS" screen while booting

[Guest]

Hello,

I am using Xillinux 1.3c. I tested the xillydemo bundle and it all worked very well. The only thing I was lacking was I need a 2nd UART from one of the PMOD connectors. In the xillydemo build in Vivado 2014.4, I added UART0 through EMIO, made a design wrapper for the uart_tx and rx, and changed the xillydemo.xdc by replacing GPIO ports 54 and 55 to the uart_rx and uart_tx ports. It is my understanding that if a peripheral is added using a bus connector that already existed (gpio 54 and 55), then there is no need to re-generate boot.bin, just to replace the new .bit and .dtb on the SD card. I was able to successfully re-generate a new xillydemo.bit file and updated the devicetree.dtb accordingly, but I get stuck on the screen that just says XILLYBUS in black and white when trying to boot. That change is the only one I made. For such a change, will I have to re-generate boot.bin? I get stuck here because while I am able to get a new FSBL.elf for my build through the SDK, the u-boot.elf I tried using is not working. Can anyone help? If I provide all the necessary files (fsbl.elf, xillydemo.bit), could someone generate the boot.bin for me? Any help would be appreciated.

Thank you,
Chris

[support]

Hello,

Changes made in the processor's configuration (adding a UART in your case) require a rebuild of the FSBL and hence also the boot.bin. The way that the processor is informed on how it should treat its I/O wires is through software configuration setting registers, which is done by the FSBL.

As the original FSBL was built in the ISE suite, the recommended flow for obtaining a new one is to make the changes in XPS (part of the ISE suite) and build the FSBL file using the SDK attached to XPS. As for creating the boot.bin file, the u-boot binary used in Xillinux-1.3 can be downloaded from this link:

http://xillybus.com/downloads/u-boot-xi ... .3.elf.zip

If you want to rebuild U-boot yourself, please refer to /usr/src/xillinux/uboot-patches/README.TXT in Xillinux distribution's file system for how to obtain the sources used to compile U-boot for Xillinux. It's recommended to use Xilinx' cross compiler for this.

Regards,
Eli

[Guest]

Eli,

Thank you very much for your reply! I had a feeling I would need to re-generate boot.bin but wasn't entirely sure. I am using Vivado 2014.4 and the Xilinx SDK, but I am pretty familiar with the process for creating a new FSBL. The part I was worried about was obtaining the u-boot binary because I wasn't sure exactly where/how to obtain/build the same version; I feared a different version would mess things up. Thank you very much for providing the link! Xillybus/Xillinux has been extremely useful to me, so thanks for all your hard work!

Regards,
Chris

[Guest]

Hate to double post, but I'm stuck and could really use some help. I generated a new xillydemo.bit, a new boot.bin (with updated fsbl, .bit, and the uboot you provided), and updated my device tree to include the newly added UART. It starts the kernel, uncompresses Linux and boots the kernel, and starts loading modules, initalizing things, etc, but then it hangs on me. I notice I have the following 4 lines in the console output:

Code: Select all

[    0.558311] xuartps e0000000.serial: aper_clk clock not found.
[    0.558689] xuartps: probe of e0000000.serial failed with error -2
[    0.564890] xuartps e0001000.serial: aper_clk clock not found.
[    0.570769] xuartps: probe of e0001000.serial failed with error -2

I've done some reading and it seems aper_clk has been deprecated, but the odd thing is, in my device tree, neither of the UARTs use aper_clk, but rather just pclk. I have what appears to be the appropriate dts (and dtb). Since I've replaced everything else (devicetree, and boot.bin), it seems the problem lies in my xillydemo.bit file. I'm assuming that the way I added the UART in Vivado is wrong, but I'm not sure what else to change. It's almost certainly the way I added it in the verilog files (I created a new design wrapper solely for the UART rather than figure out where to add it in xillydemo.v or system.v). By replacing 2 of the GPIO's with the UART rx and tx, I assume that the way I edited the xillydemo.v and system.v files to account for the 2 less GPIO connections and add the UARTs is causing the problem because the output is obviously saying my UARTs aren't initializing correctly. Is there any chance you could guide me on how to properly add UART0 to my xillydemo bundle in Vivado? I would really appreciate it.

Thanks,
Chris

[support]

Hi,

I can't see a chance that doing anything wrong on the pure logic side would cause these errors or Linux to hang. Even if you connected those two GPIOs to nothing on the logic side, the kernel would initialize properly regardless, setting up a useless UART interface.

So I would put my money on the software side. If you used the FSBL generated in Vivado, please re-generate it with XPS. There is no guarantee that the FSBL generated in VIvado is worth anything (or more precisely, that the processor's configuration in Vivado's fileset is accurate enough for obtaining an FSBL from it).

Or even before that, maybe verify that there's nothing fishy in your updated device tree.

But either way, I bet the solution is on the software side.

Regards,
Eli

[Guest]

Hello,

Well that's slightly reassuring that it's not on the logic side. The bitstream generated properly so I was hopeful that everything was good on that end but wasn't entirely sure.

Since it seems to be on the software side, I've compared my current devicetree to a previous devicetree I used on Xillinux 1.3b in which I had an additional UART enabled and completely functional. My current one almost identically matches the previous functioning one's UART entries.

As far as the FSBL, I'm a bit confused as to your suggestion here. I'm using Vivado 2014.4, and once the logic side design is complete, I export the hardware into the Xilinx SDK 2014.4 which is where I generate the FSBL. Vivado does not generate the FSBL. And from what I'm looking at online, it seems that the Xilinx XPS is similar. It uses the ISE for the logic design, but in the end, the very same Xilinx SDK is used?

I feel ashamed asking this, but I'm really on my last leg here. Would you be willing to generate a xillydemo build that has the additional UART0 configured through a PMOD for me? Any 2 PMOD pins would do (I used JE last time, pins T17 and V17). I'm at wit's end, and this additional UART is the only thing keeping me from completing a extremely important academic project. You are the only person I've found that has such expertise in the particular problem I am having and I would be willing to do anything to get it to work at this point.

Thanks,
Chris

[support]

Hello,

Again -- please download the ISE suite and use XPS to make the change in the design, and then SDK that is started from XPS to create the FSBL.

That should solve your problem.

Regards,
Eli

[bobdxcool]

Hello,

Again -- please download the ISE suite and use XPS to make the change in the design, and then SDK that is started from XPS to create the FSBL.

That should solve your problem.

Regards,
Eli

Hi,

I added a second UART port based on your help here and microzed forums. Please read below.

These are the steps I followed below.

cd /usr/src/kernels/3.12.0-xillinux-3.0/
scripts/dtc/dtc -I fs -O dts -o ~/devicetree.dts /proc/device-tree/

The devicetree.dts file was then found in the root directory. I added the following lines to the code

serial@e0000000 {
clock-names = "ref_clk", "aper_clk";
clocks = <0x3 0x17 0x3 0x28>;
compatible = "xlnx,ps7-uart-1.00.a", "xlnx,xuartps";
current-speed = <0x1c200>;
device_type = "serial";
interrupt-parent = <0x2>;
interrupts = <0x0 0x1B 0x4>;
port-number = <0x1>;
reg = <0xe0000000 0x1000>;
xlnx,has-modem = <0x0>;
};

Then compiled it using the command below:

scripts/dtc/dtc -I dts -O dtb -o /root/devicetree.dtb /root/devicetree.dts

Then copied the new dtb file to a flash drive. Replaced the new .dtb file on the SD card.

I had already generated a new bit file in vivado for the extra serial port UART0. Although the new port ttyPS1 was being detected, the communication wasnt happening properly. SO, I realized that I need to generate a new boot.bin file. So using thr SDK i generated a new FSBL, and then the boot.bin file. This part was a little tricky as there were no repositories available for xillinux modules (while creating new BSP file) on the SDK software. SO, I used standalone platform. These were the set of steps I followed to generate a new boot.bin file.

1.) After the bit file generation in vivado, I selected export project to SDK. On the SDK, I selected new application project and selected standalone as OS and selected ZC702 hardware and then cortexa9 processor.
2.) Then, I clicked on create a new BSP package. Chose standalone OS again.
3.) The from the project folder after right clicking on it, clicked on create boot image. Here, I selected create new bif file. I selected the primary partition as type bootloader and chose the .elf file generated from this poject. The second parition (data file) I added the elf file from here (http://xillybus.com/downloads/u-boot-xi ... .3.elf.zip)
4.) I created a boot.bin file and added it to the SD card.

After all this I was able to read and write to ttyPS1 (With tx n rx shorted, whatever I wrote to ttyPS1 was reflected back in the read statement in the code) without any issues. Now, I will write multithreaded python programs on the ubuntu based xillinux. I just wanted to make sure this is the right way of generating the boot.bin file from you so that the next time I make any changes to hardware which needs me to generate a new boot.bin I follow this method. Please correct the above steps if I missed out on any.

Also, another doubt I had is regarding the SD card. When I burnt the img.gz of xillinux from this page (http://xillybus.com/xillinux), I was analysing the two partitions on linux gparted software. It had two partitions, one was FAT16 and another was ext4 which is different from what they say on page 11 of this document (http://xillybus.com/downloads/doc/xilly ... d_zynq.pdf) where they say FAT32 and ext4. Is this normal ?
Also, A 4GB SD card is sufficient rigght ? 16MB for FAT 16 and the rest for ext4 partition.

[support]

Hi,

The first partition is marked as FAT32 in the partition table, but indeed formatted as FAT16. I suppose FAT32 would work as well.

As for the size of the SD card -- actually, 2 GB is enough.

Regards,
Eli

[bobdxcool]

Hi,

The first partition is marked as FAT32 in the partition table, but indeed formatted as FAT16. I suppose FAT32 would work as well.

As for the size of the SD card -- actually, 2 GB is enough.

Regards,
Eli

Thank you.

I was using gparted in linux to create new partitions for writing an image to an SD card using DD. So, I choose both partitions as primary partitions, one for FAT16 and one for ext4. Assign 16MB to FAT 16 and rest for ext4. Does it matter which partition I create first ?

Also, in the above post my way of creating boot.bin file is correct, right ? I want to make sure I dint get anything as a fluke. Especially using standalone as no BSP repositories were available for xillinux.