What follows is a longish description of what I discovered worked for me
after running into similar problems migrating from the 3.10ltsi kernel to
4.x. I am not a device tree expert by any stretch, so there¹s almost
certainly a better way than this, but it¹s working for me. I wound up
abandoning the sopc2dts almost entirely, and using the dtsi files from the
kernel. It is kind of tedious to start with, and required a bit of
sleuthing to get everything working.

Here¹s what I did: 

Copy the following out of the kernel¹s dts area into a working directory
(you¹ll have to make minor changes):
 
/arch/arm/boot/dts/skeleton.dtsi              (this is your base file for
starting a device tree. There¹s not much here)
/arch/arm/boot/dts/socfpga.dtsi               (this is the base file for
Altera SOC devices. It has all the ARM stuff in it, with most of the
peripherals disabled)

/arch/arm/boot/dts/socfpga_cyclone5.dtsi      (this is the cyclone5
specific include file, it turns on some peripherals and sets up some base
settings)       

In socfpga.dtsi change the following lines:


#include ³skeleton.dtsi²                        --> /include/
"skeleton.dtsi"
#include <dt-bindings/reset/altr,rst-mgr.h>     --> // #include
<dt-bindings/reset/altr,rst-mgr.h>


Changing the #include to /include/ is required to make it work with the
stand-alone device tree compiler instead of the kernel makefile.
I commented out the #include <dt-bindings/Š Line because the .h is not
part of the device tree, and leaving it in broke the device tree compile.
There could be a better way, but it¹s working for me.

In socfpga_cyclone5.dtsi change the include line similarly:

#include ³socfpga.dtsi²           -->     /include/ "socfpga.dtsi"


Now you need to create the top level dts file for your board. To see the
type of things to make sure you include, look at
/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts. This is the top level dts
file for the Altera SoC dev kit. This file includes the
socfpga_cyclone5.dtsi, which includes the socfpga.dtsi, which includes
skeleton.dtsi.
In this file, the board settings that you normally find in the .xml files
are created, as are any other system specific things, including FPGA
fabric mappings. 

In the dev kit dts file there¹s no FPGA fabric example to follow, so to
save yourself some trouble, generate a dts file for your board using the
socpc2dts tool. You¹ll find the line:


  hps_0_bridges: bridge@0xc0000000 {


This is the start of your FPGA fabric. You want to copy everything from
that line to the closing brace, and put it in your top-level dts file. In
the socfpga2dts generated file it¹s a sub-module to

  sopc0: sopc@0 {

You do not need to do the same in your dts file. The FPGA fabric is
stand-alone.


You¹ll likely have clocks in your fabric that are not part of the ARM
clock tree, and so not defined in socfpga.dtsi. You¹ll need to include
those as well. You¹ll also need to enable any ARM peripherals that were
not enabled in the dtsi files. In the socfpga_cyclone5_socdk.dts, the can0
bus is enabled with the following entry:

&can0 {
  status = "okay";
};

You¹ll need to do similar for the ARM peripherals you¹re using.


If you¹ve got I2C devices, follow the example in
socfpga_cyclone5_socdk.dts to add them, their addresses and compatible
drivers.

To be sure you¹ve got everything from the .xml files, search all the dtsi
files, and your dts file for each name in the DTAppend lines of the xml
files. Many are already there in the socfpga.dtsi and the
socfpga_cyclone5.dtsi. Others you¹ll have to add. Use the socfpga2dts
generated dts file as an example for the syntax. Also, you¹ll likely be
modifying entries for things defined in the kernel dts files, don¹t change
those files (any more than the include lines above) just add entries in
your dts file to update the settings.

Lastly you¹ll need to compile this all to a dtb file with the dtc tool.
Get it from the kernel git repo:
https://git.kernel.org/cgit/utils/dtc/dtc.git/
You should get the version that works with the kernel version you¹re
using. For kernel 4.x, dtc version 1.4.1 works (for me). Download it and
build it locally.
To compile your dts file:

        dtc -I dts -O dtb -o <yourfile>.dtb <yourfile>.dts

For more info:


        dtc -help 


I¹ve undoubtedly left something out, but thats the basics of what you need
to do. Once. After you have your dts file for your board working, when you
make changes only your dts file needs to be updated, and recompiled to a
dtb. If you want to change to a different kernel, you can get the dtsi
files from the kernel tree and follow the same process to tweak them to
work with the dtc tool directly, making any changes in your dts file to
accommodate the kernel changes.

I know there¹s a way to get your own dts file to build with the kernel,
and that would seem to be the best way, but I haven¹t investigated it.


‹ Tim

Tim Kennedy
G5 Infrared
603/204.5722 x33
www.g5ir.com





On 6/6/16, 4:43 PM, "Walter Goossens" <waltergooss...@home.nl> wrote:

>Hi all,
>
>could you elaborate a bit on what you're missing?
>I haven't focused much on sopc2dts and the latest kernels lately so I'm
>not entirely up to speed I'm afraid.
>When you give me some concrete examples, I might be able to decrease the
>size of your xml files ;)
>
>Walter
>
>On 06/06/2016 03:22 PM, Lowell Gilbert wrote:
>> Phil Reid <pr...@electromag.com.au> writes:
>>
>>> On 3/06/2016 18:34, Lukas Jünger wrote:
>>>> Hello,
>>>>
>>>> I have been trying for a long time to generate a bootable device
>>>> tree for my fpga hardware on my DE0-nano-SoC. However, anyhow I try
>>>> I fail. I can build a
>>>> device tree without problems using make dtbs, but of course that
>>>> doesn't include my custom fpga hardware. I made a very simple design
>>>> now just with a timer that
>>>> should generate an interrupt but it doesn't work. When i follow the
>>>> instructions and use sopc2dts my 4.1ltsi-rt kernel just hangs after
>>>> unzipping. I tried
>>>> different kernel versions, I tried to use earlyprintk to debug. I
>>>> get some errors with sopc2dts though. I use the one form
>>>> altera-opensource github repository
>>>> like this:
>>>>
>>>> java -jar /home/lukas/sopc2dts/sopc2dts.jar -v --input
>>>>receiver.sopcinfo --output socfpga.dts --type dts --board
>>>> atlas-soc-ghrd/board_info/board_info_ATLAS_SOC_GHRD.xml --board
>>>> atlas-soc-ghrd/board_info/hps_common_board_info.xml --bridge-removal
>>>> all --clocks
>>>> alias ethernet0 /sopc/ethernet@0xff702000
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Try to eliminate hps_bridge_avalon: hps_0_bridges_f2h
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> Component generic_timer_0 of class generic_timer is unknown
>>>> dts memory section: No memory nodes specified. Blindly adding them all
>>>>
>>>> When I compare the device tree generated to the one coming from the
>>>> kernel git, it uses different syntax and layout, so no surprise that
>>>> it doesn't work.
>>>> What am I doing wrong? Is there a tutorial on how to just get a
>>>> basic design working with interrupts in the linux kernel?
>>>>
>>> G'day Lukas,
>>>
>>> You're not doing anything wrong.
>>> The device tree from the sopc2dts doesn't work.
>>> What I've done is setup scripts to:
>>> - Use sopc2dts to generate dts.
>>> - Process it thru a script to strip out everything other than the fpga
>>>stuff converting it to a dtsi.
>>> - Modified the kernel dts and then use it and the sopc2dts to to
>>>create a usuable dtb.
>>>
>>> I found the altera tools package with the quartus install lag too far
>>> behind the kernel development to give you something that boots.
>>> The dts from the kernel source is generally more correct than the
>>> sopc2dts one. However depending on you platform you may have different
>>> periphals enabled.
>> It's not really that sopc2dts doesn't work, it's just that they need
>> more entries for more recent kernels. I'm up to nearly a thousand lines
>> in my XML files.
>>
>>> Also don't forget that the spl / uboot need to be updated if you
>>>change HPS pin muxes.
>>> This includes fpga bridges etc.
>>>
>>>
>>> Also does the generic timer you add have the necessary _hw.tcl code to
>>>add entries into the dts?
>> It's easier to check this in the dts file than the tcl file, but adds up
>> to the same thing.
>> _______________________________________________
>> Rfi mailing list
>> Rfi@lists.rocketboards.org
>> http://lists.rocketboards.org/cgi-bin/mailman/listinfo/rfi
>>
>
>
>_______________________________________________
>Rfi mailing list
>Rfi@lists.rocketboards.org
>http://lists.rocketboards.org/cgi-bin/mailman/listinfo/rfi

_______________________________________________
Rfi mailing list
Rfi@lists.rocketboards.org
http://lists.rocketboards.org/cgi-bin/mailman/listinfo/rfi

Reply via email to