Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

Keeping dts/dtb in sync with latest kernel ( sopc2dts, boardinfo xml)

Hi,

I am trying to upgrade my kernel to 3.13 (from 3.9) and one of the things I need is an updated device tree blob.

Originally I was thinking I just needed an updated soc_system_board_info.xml (which is 3.9 specific as mentioned in the header comments), but after digging deeper I have come to realize that the problem is actually worse because some of the things that need to be updated are in the .sopcinfo file generated by the fpga build process.

So I think the only solution left at the moment (till the fpga build tools are updated) is to manually edit the dts file resulting from the sopc2dts process each time the FPGA changes.

Is that correct or am I missing something .

To illustrate with an example:

One of the dma (in which I am interested) entries changed from

interrupts = <0 104 4>,

<0 105 4>,

<0 106 4>,

<0 107 4>,

<0 108 4>,

<0 109 4>,

<0 110 4>,

<0 111 4>;

to

interrupts = <0 104 4>;

nr-irqs = <9>;

nr-valid-peri = <32>;

( EDIT: I flipped 3.9 and 3.13 versions )

The data for this is in the generated .sopcinfo file , I don't know of a way to 'fix' this once and for all.

Related remark: Before I ran into the above, I tried adding some aliases the the boardinfo xml file, for example:

<alias name="ethernet0" value=&hps_0_gmac0;/>

This gives 2 problems:

[1] He insists that the value part is surrounded by "", but according to the wiki (http://www.alterawiki.com/wiki/sopc2dts) this will also put the "" in the generated result, while I need

aliases {

ethernet0 = &hps_0_gmac1;

...

as end result (not "" around the &gmac0;)

[2] Even if you try it with quotes, he still complains:

[Fatal Error] :296:45: The entity "hps_0_gmac1" was referenced, but not declared.

-> the tool does not understand that hps_0_gmac1 is declared in the .sopcinfo so that would seem like a bug to me.

(EDIT: I think I understand where the limitation comes from, the ePAPR document mentions only aliases to full paths which should be in quotes ("..."), the option to make an alias to a label is not mentioned in that document. But it is possible apparently in the kernel dts'es, but not in te xml.)

Regards

bram

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Hi Bram,

    I am having similar problems. I can never figure out which device tree to use when changing kernel versions. This always confuses me.

    I am not able to get 3.13 to load as I cannot generate the right device tree. This probably doesn't answer your question at all, but wanted to share some related information of what I found so far. Maybe this will be useful. I feel like there might be something obvious that we might be missing. I feel like it shouldn't be this hard to switch to a different kernel version.

    This is what I have been doing to load 3.12: 

    
//How to compile kernel
cd ~
mkdir linux-socfpga-3.12
git clone http://git.rocketboards.org/linux-socfpga.git
cd linux-socfpga
rm .config
git checkout -b socfpga-3.12 origin/socfpga-3.12
export CROSS_COMPILE=/opt/altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/arm-linux-gnueabihf-
// generate the .config file...
make ARCH=arm menuconfig
make ARCH=arm

    This generates all the files I need to get the system to boot.

    arch/arm/boot/dts/socfpga_cyclone5.dtb

    arch/arm/boot/zImage .

    If I do the same thing with 3.13, it doesn't generate a new device tree. This really confuses me?!? Why would it be any different? I cannot get 3.13 to boot.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Hi John,

    I managed to get a booting kernel in the meantime.

    I posted a short overview of what I did in the rocketboards mailinglist (http://lists.rocketboards.org/pipermail/rfi/2014-february/001341.html)

    --- Quote Start ---

    I don't know if this is the perfect way but in case someone else wants to do this here is how I got there (also thanks to Dalon W.):

    - I used the linux-socfpga git repository for building a kernel

    * make ARCH=arm CROSS_COMPILE=xxx/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/arm-linux-gnueabihf- socfpga_defconfig

    * make ARCH=arm CROSS_COMPILE=xxx/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/arm-linux-gnueabihf- uImage LOADADDR=0x8000

    - And for building the modules

    * make ARCH=arm CROSS_COMPILE=xxx/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/arm-linux-gnueabihf- modules

    * make ARCH=arm CROSS_COMPILE=xxx/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin/arm-linux-gnueabihf- INSTALL_MOD_PATH=xxx/rootfspatch/ modules_install

    - I used the rootfs from the yocto release, and added the modules generated by the previous step to that rootfs

    - I merged my old 3.9 dts with the socfpga(_cyclone5)(_socdk).dts(i) files from the 3.13 kernel and generated the dtb from it

    - I had to modify 3.13 dw_mmc-socfpga.c with some 3.9 code to add mci_writel(host, PWREN, pwr_en); to power on / keep powered the SD card [probably not the ideal solution]

    --- Quote End ---

    But now I am running into different problems with the 3.13 kernel so I am not sure my upgrade efforts were worth it ;p

    http://stackoverflow.com/questions/22228347/linux-kernel-asynchronous-aio-do-i-need-to-copy-over-the-struct-iovec-for-later (http://stackoverflow.com/questions/22228347/linux-kernel-asynchronous-aio-do-i-need-to-copy-over-the-struct-iovec-for-later)