cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
415 Views
Registered: ‎12-20-2017

Petalinux software needs to switching from one platform to another

I have a petalinux project that I'd like to be able to switch from one hardware definition file to another.

More specifically, I'd like to be able to build my software sometimes for a Trenz TE0808 ultrascale module, and other times for a zcu102 development board.  

The trenz module has a different meta-user/recipes-bsp/device-tree/files/system-user.dtsi and meta-user/recipes-bsp/u-boot/files/platform-top.h - though I have my own changes to system-user.dtsi that need to play nicely with whatever trenz needs.

I currently use petalinux, and in between each build-type I remove build/ components/ and project-spec/meta-plnx-generated/.  I then have to manually place the appropriate platform-top.h and system-user.dtsi files.

I've procrastinated looking in to yocto.  I'm not really familiar with it, but I wonder if it might be able to handle these types of changes more easily?  

 

 

0 Kudos
5 Replies
Highlighted
Moderator
Moderator
388 Views
Registered: ‎02-07-2018

HI @aaron_b1 

 

Please create a two petalinux projects, so that it will easy to build & no need to copy required files every  build.  and we can avoid unneccessary issues.

 

Thanks & regadrs

Aarvind

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

0 Kudos
Highlighted
Moderator
Moderator
384 Views
Registered: ‎09-12-2007

If the only difference is devicetree nodes then you could patch the dtg to include your dtsi file ( like is done for dev boards). Then just reference this in the petalinux-config -> DTG settings.

 

Same would apply for yocto 

0 Kudos
Highlighted
Explorer
Explorer
370 Views
Registered: ‎12-20-2017

I'm sorry, I really don't understand your answer.

"patch the dtg to include your dtsi file"
By putting a system-user.dtsi in recipes-bsp/device-tree, aren't I already doing this?

"Then just reference this in the petalinux-config -> DTG settings"

I'm not familiar with this.  What does "DTG" stand for here, and what does selecting this do in the petalinux config?

0 Kudos
Highlighted
Moderator
Moderator
365 Views
Registered: ‎09-12-2007

DTG is the device tree generator. You can update this in the system-user.dtsi. However, if you want to automate this per board. You can add your board.dtsi to the dtg and create a patch

git clone https://github.com/Xilinx/device-tree-xlnx

cd device-tree-xlnx

git checkout xilinx-v2018.3

Place your board dtsi files here

device_tree/data/kernel_dtsi/2018.3/BOARDS

git diff xilinx_v2018.3 < 0001_add_custom_dtsi.patch

 

Place this patch in the files dir in fsbl recipe and update the fsbl  bbappend to use this SRC_URI_append += " file://0001_add_custom_dtsi.patch"

0 Kudos
Highlighted
Explorer
Explorer
347 Views
Registered: ‎12-20-2017

Thanks,  This sounds handy.

Does this patching technique work if the device tree information I have is a small segment of a device tree?  For instance, when building for the ZCU102, all I have is a fragment in system-user.dtsi that would tell the PTP driver what frequency the timestamping clock is.

/include/ "system-conf.dtsi"
/ {
};
/ {
        amba {
                ethernet@ff0e0000 {
                        tsu-clk = <250000000>;
                };
    };
};

In the other board, based on a Trenz module, I keep the previous little segment, and add a bunch of text provided by the trenz sample project.  I have no idea how much  of it is critical

/* default */
/* SD */
&sdhci1 {
        // disable-wp;
        no-1-8-v;
};
/* ETH PHY */

&gem3 {
        phy-handle = <&phy0>;
        phy0: phy0@1 {
                device_type = "ethernet-phy";
                reg = <1>;
        };
};

/* QSPI */
&qspi {
    #address-cells = <1>;
    #size-cells = <0>;
    status = "okay";
    flash0: flash@0 {
        // compatible = "n25q256a";
        reg = <0x0>;
        #address-cells = <1>;
        #size-cells = <1>;
    };
};

/* I2C */
&i2c0 {
    i2cswitch@73 { // u
        compatible = "nxp,pca9548";
        #address-cells = <1>;
        #size-cells = <0>;
        reg = <0x73>;
        i2c-mux-idle-disconnect;
...

The *.dtsi in device_tree/data/kernel_dtsi/2017.3/BOARD/ look like they are FULL device trees.

0 Kudos