Angstrom for DE1-SoC

Can anyone point me at WORKING instructions (in October 2015) on how to build Angstrom to run on the DE1-SoC board? Ideally I’d like it to also build a 3.13 kernel.


As far as I know, there is nothing specifically used and tested for the DE1-SoC (at least on here). The closest relative is the SoCKit instructions.

Most instructions need to fully specify all component versions, download versions, tool versions, etc, and the full build process, in order to get “WORKING” instructions. This can be quite a large task, and no one knows when some innocent looking patch is going to break things along the way.

So you may need to be more specific about the version of Quartus/SoCEDS that you require as a minimum. For example, are you using Quartus/SoCEDS version 14.0 or later? If so, then as far as I know, the 3.13 kernel won’t work with it (unpatched) due to changes to the preloader. I’d recommend the 3.17 kernel as a minimum, and I use Quartus/SoCEDS version 14.1.

Otherwise, the “Build U-Boot, Kernel and Rootfs Using Yocto Recipes” subsection of “Compiling Linux - Arrow SoCKit Edition”:

is probably the closest existing instructions for just the “Angstrom” part. I haven’t re-run it recently, so I don’t know if it still works from the ground-up. Yocto may be in the title, but it’s for Angstrom. The default kernel is, AFAIK, a patched 3.10 one.

I use this as the basis for several hardware platforms, including the SoCKit and the DE1-SoC. However, I manually substitute in a 3.17 kernel into my SD card image, which I build outside the Angstrom tree. I got mine from git:// and picked the origin/socfpga-3.17 branch. The branch head might have moved on since I last acquired it - so no guarantees.

As the DE1-SoC hardware is slightly different to the SoCKit, you won’t be able to use the hardware design part of the instructions as-is. The HPS configuration and the pin-assignments are slightly different amongst other things. You may find that “de1_soc_GHRD” on the DE1-SoC System CD (available for download from Terasic ) is sufficient to get you going:

You’ll also NEED a modified device tree for the U-Boot stage - which is also kernel version sensitive. You could reverse compile the SoCKit dtb file to a dts file using the “dtc” tool (one comes with Ubuntu but you may need to install it), strip out the incompatible parts - such as the buttons and LEDs assignments, and recompile it to a dtb file. Don’t sort or otherwise re-order the dts file acquired in this way, because it breaks the clock tree and your kernel won’t boot. There are other ways to achieve a working dtb, but the details are kernel and tool specific.


Hello Iain,
Firstly, many thanks for your reply. I guess the main problem I am having is understanding the generation of the dtb file. I’m using version 15.0 of Quartus and have used the board xml files posted in this thread

to generate a dtb file that allows a 3.17 kernel to boot, however there is no Ethernet support (and probably no fpgabridges) which I guess means the dtb file is incomplete.
I now understand that the dtb file is Linux kernel version specific (with some major changes after 3.1x?) but what I struggle to see is how the use of “sopc2dts” and “dtc” take into account the Linux Kernel version? I’m also aware that the generation of the kernel produces what seems to be some board specific (although unfortunately not for the DE1-Soc) dts files. Can you point me in the right direction to understand how both the sopc2dts dts/dtb files and kernel dts/dtb files are married up to produce the kernel version specific dtb file?

Best wishes,


You’re correct that the DTB file is kernel version specific. It is usually the XML files that implement those differences. The sopc2dts tool (and the dtc) are, in the main, just tools to create the DTB file from various sources.

The sopc2dts tool takes an “.sopcinfo” file created by QuartusII from your hardware design, combines that information with the XML files supplied, and produces your DTB file. The XML files provide fixup information that the sopc2dts tool can’t derive from information in the “.sopcinfo” file, or that it derives incorrectly or incompletely, for the kernel version that you wish to use.

Here are the two files I use for creating a DTB file for the 3.17 kernel using QuartusII 14.1. I use hps_common3.17.xml file with the DE1-SoC and the SoCKit board, and provide DE1-SoC specific customizations in the de1soc3.17.xml file. I don’t currently use the HPS LEDs and GPIOs, but if I did, they would be defined in the de1soc3.17.xml.

My hardware design, and hence my “.sopcinfo” file, contains a HPS component configured for the board I’m using. Hence the availability of HPS Ethernet / SPI / I2C etc, comes from there. But some additional information also comes from the XML files, which is required to get the Ethernet working.

I use the following command to create the DTB file. You will have to fixup the paths to find the input files:

sopc2dts --input soc_system.sopcinfo\
 --output soc_system.dtb --type dtb\
 --board hps_common3.17.xml --board de1soc3.17.xml\
 --bridge-removal all\

This should be sufficient to get you going.
If you want to produce a DTS file, i.e. human-readable DTB file, I use:

sopc2dts --input soc_system.sopcinfo\
 --output soc_system.dts --type dts\
 --board hps_common3.17.xml --board de1soc3.17.xml\
 --bridge-removal all\

If you wanted to, you could manually edit the DTS file, then use the dtc tool to convert it to a DTB.

Hope this helps!


Hello Lain,

Is there any good webs / tutorials / guides on how to modify XML file?
How did you get to know about it?
And I’m wondering what additional information that QSYS can’t provide about the processor that it can’t generate DTB automatically?