Changing the device tree blob

[Altera_Forum]

Hi all, 

 I'm new to the Cyclone 5 and have beeen trying to familiarize myself with the process of creating an sd card to boot linux.  Starting with a known good image I have been able to change the preloader and uboot boot files and still boot fine. However, if I make any changes to the device tree blob file to using soc2dts and then try to boot it only gets to the 'Starting kernel...' part and then hangs. I have noticed that the address that the device tree gets loaded to is different to that which the working device tree blob is loaded to (starting at 0fff9000 instead of 0fffa000). I thought I would be able to change the dtb independently of the uImage, is that the case?  I can revert back to the supplied device tree blob and that one will boot. Does anybody know what I might be doing wrong?

[Altera_Forum]

Hi 

To restore the original sd-card image.  Supposing you are using 13.0 or 13.0 SP1 Quartus versions the factory default .dtb file can be found under: <altera_install_dir>\embedded\embeddedsw\socfpga\prebuilt_images  see also: alterawiki.com (Key: "Compiling_u-boot_and_Linux_Kernel_for_Cyclone_V_SoC") ug_soc_eds.pdf ug_soc_gsrd.pdf  I hope it will help.  Regards,  ZS.V.

[Altera_Forum]

Thanks for the reply, 

 I have found that the element that was causing the kernel to hang was the sysid module that was added in qsys. When this section is removed from the dtb I can then successfully boot linux. I'm not yet sure what this module is for or why this is the case. It was only present because it came with the tutorial I based my work on.

[Altera_Forum]

--- Quote Start ---  Thanks for the reply,  I have found that the element that was causing the kernel to hang was the sysid module that was added in qsys. When this section is removed from the dtb I can then successfully boot linux. I'm not yet sure what this module is for or why this is the case. It was only present because it came with the tutorial I based my work on.  --- Quote End ---    As Altera Quartus/Qsys docs stated, the System ID peripheral is a "very important" peripheral to include in your system if you use Nios II soft-processor core. It allows the software development tools to validate that the software application is being built for the correct hardware system. Basically, it will not allow software to be executed on an incompatible hardware configuration (.sof). I have no information, what will cause, if it is eliminated from a HPS based FW design.

[Altera_Forum]

I'm not using Nios II so sysid is not necessary for my design. 

 The goal I need to achieve at the moment is to access the FPGA memory from the HPS under linux. I have looked everywhere I can think of and cannot find an example of where this happens. Does anybody know of such a design I could look at?   In pursuit of this goal, I started by using the GHRD for the arrow sockit to produce my own preloader and Uboot images. I found that the device tree provided in the arrow labs is not the same as the device tree that is generated if you use the sopcinfo file (and the board_info.xml file) from the lab, in fact they are completely different. I have attached the dts versions of both files; it seems to me that the working one has been written by hand. If you use the generated dt, the system hangs when starting the kernel.   I managed to create my own uImage that had the debug messages switched on and found that there were a variety of things wrong with the dt I had created. In short, unless I am missing something, using the sopcinfo file to generate a dt is probably a waste of time and I am better off modifying the supplied dt file. Has anybody else found the same issue?

[Altera_Forum]

I'm also having this issue with the kernel stalling when I try to use a generated dt. I'm using the altera cyclone V soc dev board and when I look at the dt provided on the supplied SD card it does not match what comes out of the sopc2dts tool. The dt on the sd card also appears to be handwritten too. I have also tried using the newest sopc2dts from the git repo, with no luck.

[Altera_Forum]

I have also had this issue. I used the .dts source file from rocket boards here: http://www.crashcourse.ca/wiki/index.php/sockit_device_tree_files 

 I have confirmed that this .dts code matches the factory binary image by using u-boot to inspect the binary file conversion to text.  I then used the 'dtc' command to compile the .dts file into a binary .dtb file. I load the new .dtb binary onto sd card and turn on the board. I pause the boot sequence and use u-boot commands to look at the binary to text output of the .dtb and it does not match the factory binary to text output.

[Altera_Forum]

Hello, 

 same problem here with EBV SoCrates Board... the precompiled dtb works good - but compiling the dtb (compiler is up to date from git repo!) from the sopcinfo out of the provided project leads __not__ to the original file. Any help appreciated! Do I have to write the dts by hand - I hope not?!

[Altera_Forum]

@guinea, not sure if you got it working - I have successfully used the board info xml for the ghrd for the SoCrates board: 

 C:\altera\13.1\embedded\examples\hardware\cv_soc_devkit_ghrd\soc_system_board_info.xml  I have compiled it (along with the sopcinfo generated by Qsys). If you use Quaturs 13.1 you also need to include the clock xml file. For Quartus 13.0sp1 there is no clock xml.

[Altera_Forum]

--- Quote Start ---  @guinea, not sure if you got it working - I have successfully used the board info xml for the ghrd for the SoCrates board:  C:\altera\13.1\embedded\examples\hardware\cv_soc_devkit_ghrd\soc_system_board_info.xml  I have compiled it (along with the sopcinfo generated by Qsys). If you use Quaturs 13.1 you also need to include the clock xml file. For Quartus 13.0sp1 there is no clock xml.  --- Quote End ---    Hi, I am also having difficulties here using the Socrates board. Did you check to see if the ehternet port worked when you did this? The soc_system_board_info.xml file that is used to create the .dtb file is from the rocket boards GRHD and is putting erroneous data such that the Ethernet port does not work, since the GRHD uses a different Ethernet interface chip micrel and the Socrates has lantiq chip. I thought the soc_system_board_info.xml were compatible. The dtb I created does allow me some control e.g. I can toggle the leds on Socrates, but the eth0 fails with the following boot error... Configuring network interfaces... eth0: device MAC address c6:3a:1e:1a:9a:6d libphy: PHY stmmac-0:00 not found eth0: Could not attach to PHY stmmac_open: Cannot attach to PHY (error: -19). Can someone send me the correct soc_system_board_info.xml for the Socrates design, and also the equivalent hps_clock_info.xml. The lines in the soc_system_board_info.xml that cause the problem are: <DTAppend name="micrel-ksz9021rlrn-clk-skew" type="hex" parentlabel="hps_0_gmac1" val="0xa0e0"/> <DTAppend name="micrel-ksz9021rlrn-rx-skew" type="hex" parentlabel="hps_0_gmac1" val="0x0"/>  I have not tried to adjust/remove them yet.  I could play with the soc_system_board_info.xml file to get the Ethernet going, but there may be other issues that cause problems that will trip me up later. Maybe that is all that is different, but I'm guessing someone knows the answer. Anybody help?   Thanks Rik