Hello all,
Currently I work with the Cyclone V development board from arrow. Now, I have some troubles to create and understand the building flow of this system. I created a new VHDL project with Quartus 13.1 and designed the HPS system in qsys. With the handoff files and the SoC EDS which is installed on a Windows machine, I created the preloader and u-boot files.
On the same machine I created the dts with the .sopcinfo and xml files which I have attached in this post. With the dtc tool, I compiled the device tree blob.
On a Linux machine I compiled the Linux kernel from following git source: https://github.com/altera-opensource/linux-socfpga
For this I used the linaro gcc 4.8. Firstly I used the branch socfpga-3.10-ltsi and loaded the default configuration with “make socfpga_defconfig” then I builded the kernel with “make zImage”
With this files I created an own SD card. Now when I use my own dtb, ant the kernel 3.10, the kernel don’t run (see image V9.png)
When I change only the dtb with the file from “linux-sockit-gsrd-14.1-bin.tar.gz” It works fine. (image V7.png)
After this I tried to use a other kernel version. I checked out the branch socfpga-3.18 and builded this kernel. Now the system is running with my own dtb (image V10) and with the dtb from the gsrd (image V8).
Unfortunately, I don’t see the fpga-bridges on this kernel. My goal is, to understand this problem.
Why run the kernel 3.18 with my own dtb, but the kernel 3.10 does not work?
And why can’t I see the bridges with kernel 3.18? Is something wrong in the default configuration from the kernel build process? Or did I something wrong in the device tree generation?
If you are stuck in situation like on image V9, i.e. “Starting kernel …” and nothing more, you can investigate problem by enabling early printk. It helps me to find a problem on Socrates board. The issue was that I used Linux 3.12 with dtb for Linux 3.9. In newer version some of the properties, related to QSPI, were changed.
Thanks for your support Victor. I tried out to test the early printk function but I didn’t received more information.
After the message “Starting kernel …” follows the message “Uncopressing Linux… done, booting the kernel.”. After this information, I don’t receive more messages. I acctivated the early printk option in the kernel build configuratin. Do I need to change also some configuration in the u-boot?
Furthermore I found some misunderstood changes in the kernel between 3.16 and 3.17. They did some changes in the file: “drivers/misc/fpga-bridge/altera-hps2fpga.c” with the commit message:
misc: bridge: convert bridge driver to reset driver framework
v3.17 enables the reset driver framework for SOCFPGA. Thus, convert the
bridge driver to use it the reset driver instead of syscon. Also, some
cleanup is done for v3.17.
Signed-off-by: Dinh Nguyen dinguyen@opensource.altera.com
Signed-off-by: Alan Tull dinguyen@opensource.altera.com
So after this changes, I don’t need to add the bridges in the device tree and can reload the FPGA from Linux without disabling the bridges? Is this true?
I am having the same issue!
I thought it is DTB files causing this error, that’s why I asked about the XML files in my post.
So, do I use v3.18 instead of 3.10-ltsi_15.07.02_pr (which experienced the problem with)?
Do I need to change also some configuration in the u-boot?
@schnudi
Yes, you need to change bootargs.
I have added earlyprintk option to bootargs, like this
earlyprintk=serial,ttyS0,115200
@sirajmuhammad
Previously I have problems with finding those xml files for my board. The vendor of my board doesn’t supply them now. I was suggested to write dts by hand, using dts from Linux as a starting point.
Looking to you guys I see that I’m not alone. I have many different issues related to using Linux in SoC. I was trying different support approaches. But only one men from EBV helps me a lot. Looks like this forum doesn’t have official support.
@schnudi
Same problem here regarding Kernel 3.10 and version 3.18.
Version 3.10 is not starting the kernel, and version 3.18 is booting but with no ethernet support. I did not check the bridges yet.
Have you figured out the reason?
Board: DE1-SoC
Yes! Thanks @sirajmuhammad for continues the discussion in the other topics. Now I installed Quartus and EDS 15.0 (I used 13.1 before) and builded the system with @roberbot description and the workshop2. Now I have a running system tested with kernel 3.10 and 3.18. Also the Ethernet connection is working.
Only one point I do not understand until now:
The bridges between FPGA and HPS aren’t listen in Linux on /sys/class/fpga-bridge/*
Have some one any idea why this is so?
By building the system following the workshop2, the bridges aren’t listen in any kernel version… By the way, I used the angstrom Linux distribution and not the rootfs from the worksohp.
How did you build the DTB file? using spoc2dts or following the way I described above?
I have compiled kernel version 3.10-ltsi and I am using the original filesystem of the factory image (I believe it’s called Poky… based on Yocto) and using the DTB file from the above procedure I can confirm that I can see fpga2hps hps2fpga lwhps2fpga in /sys/class/fpga-bridge/.
In my opinion, this way is better to have a DTB because the DTS files included with the kernel have the minimum hardware description to run the system, among of which are the FPGA bridges.
Firstly, I had build the dtb with the windows files. Steps descripted in the workshop2…
In this case, both kernel version (3.10 and 3.18) works fine, but without bridges.
In a second step I builded the dtb from the dts included in Linux git (like your description) In this case, both kernel runs but without Ethernet (Maybe I need to add this in the dts). But: kernel 3.10 works with bridges and kernel 3.18 works without bridges…
I don’t know why. I think, it should be possible to use the bridges also in kernel3.18?
I also had problems to build device tree for Socrates from scratch. Linux didn’t boot after this. I finally ended up with decompiling working dtb into dts, patching dts and compiling it again. This might help to find differences in dts/dtb files.
Hi guys i’m working with de1 cyclone v soc for testing and future de0 for application however i need to fully understand so i could change boards and mod the linux perfect … There are some people lost here but i’m going to describe my process so simple and working with this link “https://rocketboards.org/foswiki/view/Documentation/AVCVGSRD160”. From here and using ubuntu 12.04 runing on virtualbox + many updates for apt-get and git + soc eds 16 linux + quartus 16 linux + smargit; i can tell you it works for 3.10… or 4.5 kernel or others releases of socfpga in the linux-socfpga.git, however you need to know a few things before this happens.
When you use quartus to compile hw of your board (https://rocketboards.org/foswiki/view/Documentation/GSRD160CompileHardwareDesign just for socfpga) it generates something that doesn’t matter right now (Forget .rbf, .sopcinfo, preloader and u-boot.scr and others just for a moment keep it simple) cause our goal is to run linux with a nice kernel version on our board, call it beagleboard, socfpga or whatever … we CAN do it with the example images in my case the release 16.0 “http://releases.rocketboards.org/release/2016.05/gsrd/bin/” mentioned inside the flow of gsrd 16.0 above for rootfs and a preloader image from my own quartus proyect and even a already burn SD card from an example image like the basic “DE1_SoC_FB.img” for De1 SoC everything which at least run, you can start from there.
When you do a “sd card updating or creating” there is a file descriptor of your hardware which is *.dts and that is the most important to understand (nowadays i’m trying to understand this file) because it resumes the hardware configs and other stuff to tell the kernel how to start doing stuff so this is the headache when you get “Starting kernel” Stuck!! the DTS!!! (Binary form is a DTB!! but its the same thing so relax these two types dts or dtb).
@sirajmuhammad is right about *.dts being extracted from the kernel compilation which is actually “socfpga_cyclone5.dts” but this one includes “socfpga_cyclone5.dtsi” and this one includes “skeleton.dtsi”, however when you are in an upper branch of the git (in my case a tag with socfpga release 4.5 kernel) there are other includes nested more!!! so it is a headache doing a dtc execution :(. But don’t worry the kernel compilation environmet will make you happy again, please folow gsdr 16.0 and compile “make zImage” as usual with exported ARCH and CROSS_COMPILE variables so you can finally do this “”“make dtbs”"" because THIS!!! will do the job for you and over the path /arch/arm/boot/dts/ you will find the fully final compiled socfpga_cyclone5.dtb!!! so you don’t need dtc headaches from embedded_command_shelll.sh of SOC_EDS 16.0 at the moment ;).
When you have zImage with the mentioned *.dtb from the same kernel compilation, your kernel is never going to get stuck again in “Starting kernel”. To resume i did a burn on my SD card with a default image of CD from terasic “DE1_SoC_FB.img” then i replace socfpga.dts and zImage so now i’m runing angstrom kernel version 4.5!! Sweet.
That was a big week understanding however my ethernet is not working, so maybe dts has something to explain to me because malconfigure my unrepeatable De1SoC hardware so i decompile the dtb file to a dts file from kernel metioned and dts from terasic image “DE1_SoC_FB.img” (Yes from dtb to dts using “dtc” tool from SoCEDS shell using options “-I dtb -O dts” and its really simple cause it is the same exactly file but in other format) i just copy the ethernet parts of one dts (Terasic Image) to the other dts (Kernel extracted dtb converted to a dts through dtc) and finally i convert the modified dts file to dtb again using “dtc -I dts -O dtb” copy this one to the sd card and starting linux again.
WHAT HAPPENED: This new dtb file from a edited dts file makes my ethernet work again over the release 3.10 kernel tag or branch whatever… it doesn’t work with 4.5 kernel release for socfpga tag :(.
REFLECTION: Maybe I need to get more in touch with preloader, u-boot.img over the raw partition A2 of my sd card or even a rootfs/* compiled by me from kernel environment of git, maybe a “make menuconfig” so i’m on it guys.
CONCLUSIONS:
A. At the beginning just use dts files to do a dtb file all from the kernel environment (linux-socfpga.git in my case) and use “make dtbs” with ARCH and CROSS_COMPILE vars exported so this will save you a massive headache.
B. When you have your .dtb you can use embedded_command_shell.sh and the “dtc” tool to get this back to a .dts file that you can edit compare and understand. Do what you want to explore with this file, compile it back to .dts with “dtc” tool again and try to understand how this affect the “Starting kernel …” stuck. Maybe upload a post explaining .dts relation between kernel and hardware stuff “.qsys .sopcinfo for socfpga” maybe sopc2dts is obsolete or not, that will be nice to analyse.
C. When you get your linux runing with your hardware setting up and working well maybe you already understand preloader u-boot dynamics and the relations of these ones with the linux filesystem “rootfs/*”, its necesary to compile the filesystem from the same kernel compilation environment? there is a need to do some configs over the git files? please share what you do :).
so i’m on it guys.