Trenz Electronic Products > Trenz Electronic FPGA Modules

TE0720 custom carrier - Petalinux (2020.2) issues

(1/3) > >>

bigguiness:
Hello,

I have tested my hardware design using Vitis as far as I can. Now I'm trying to setup a Petalinux system starting from scratch (not using one of the Trenz BSP packages).

I was able to get the hardware to boot, after having an issue with the serial ports and then fixing it, by doing:

--- Code: ---$ source /tools/Xilinx/Petalinux/2020.2/settings.sh
$ petalinux-create --type project --template zynq --name os
$ cd os
$ petalinux-config --get-hw-description ../

# The default config sets up the FSBL and DTG Serial stdin/stdout as (ps7_uart_1). I had to change it to (ps7_uart_0) for the TE0720 board.
$ petalinux-config

$ petalinux-build
$ petalinux-package --boot --fsbl images/linux/zynq_fsbl.elf --fpga images/linux/system.bit --u-boot --force

--- End code ---
(Simple enough, other than having to do it twice because of the serial port issue...)

I then copied to files to a prepared SD-card and was able to boot the system. But after booting I noticed that rtc0 (the ISL12020 chip on the TE0720) was not detected. The necessary driver is not enabled by default in the kernel so I modified the kernel config to build in the driver and then rebuilt petalinux.

--- Code: ---$ petalinux-config -c kernel
$ petalinux-build
--- End code ---
During the petalinux build I get this warning:

--- Code: ---WARNING: .../os/components/yocto/layers/meta-xilinx/meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx_2020.2.bb:do_compile is tainted from a forced run
--- End code ---

When I packaged the output and tried booting the system, rtc0 was still not found.

Is the WARNING telling me that the build did not use the updated kernel config? Or am I missing something else to get the ISL12020 working?

Thanks



bigguiness:
One other thing...

I noticed that I was not seeing the "Xilinx First Stage Boot Loader (TE modified)" stuff when my board powers on. I was just seeing:

--- Code: ---U-Boot 2020.01 (Jan 25 2023 - 18:40:56 +0000)

CPU:   Zynq 7z020
Silicon: v3.1
DRAM:  ECC disabled 1 GiB
Flash: 0 Bytes
NAND:  0 MiB
MMC:   mmc@e0100000: 0, mmc@e0101000: 1
Loading Environment from SPI Flash... SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
*** Warning - bad CRC, using default environment

In:    serial@e0000000
Out:   serial@e0000000
Err:   serial@e0000000
Net:   
ZYNQ GEM: e000b000, mdio bus e000b000, phyaddr -1, interface rgmii-id

Warning: ethernet@e000b000 using MAC address from DT
eth0: ethernet@e000b000
Hit any key to stop autoboot:  0

--- End code ---

In the BSP directory I found that the ./project-spec/meta-user/recipes-bsp/u-boot stuff was a bit different and there is a ./project-spec/meta-user/recipes-bsp/fsbl that was not in my petalinux setup. I copied those two directories to my setup and rebuilt petalinux. Now I see the FSBL stuff when the board powers on:

--- Code: -----------------------------------------------------------------------------------
Xilinx First Stage Boot Loader (TE modified)
Release 2020.2  Jan 25 2023-23:59:51

Device IDCODE: 23727093
Device Name: 7z020 (7)
Device Revision: 2
--------------------------------------------------------------------------------
TE0720 TE_FsblHookBeforeHandoff_Custom

SoM: TE0720-03-1C  F SC REV:05
MAC: D8 80 39 DE 31 20

--------------------------------------------------------------------------------


U-Boot 2020.01 (Jan 25 2023 - 23:59:29 +0000)

CPU:   Zynq 7z020
Silicon: v3.1
DRAM:  ECC disabled 1 GiB
Flash: 0 Bytes
NAND:  0 MiB
MMC:   mmc@e0100000: 0, mmc@e0101000: 1
In:    serial@e0000000
Out:   serial@e0000000
Err:   serial@e0000000
Net:   
ZYNQ GEM: e000b000, mdio bus e000b000, phyaddr -1, interface rgmii-id

Warning: ethernet@e000b000 using MAC address from DT
eth0: ethernet@e000b000
Hit any key to stop autoboot:  0

--- End code ---

But the Ethernet MAC is not getting set correctly. During the kernel boot I see:

--- Code: ---Marvell 88E1510 e000b000.ethernet-ffffffff:00: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=e000b000.ethernet-ffffffff:00, irq=POLL)
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 29 (00:0a:35:00:1e:53)

--- End code ---

And after booting 'ifconfig' shows this:

--- Code: ---root@s6:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0A:35:00:1E:53 
          inet addr:10.168.0.97  Bcast:10.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20a:35ff:fe00:1e53/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:31 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2621 (2.5 KiB)  TX bytes:5328 (5.2 KiB)
          Interrupt:29 Base address:0xb000

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

--- End code ---

What am I missing to get the HWaddr set properly?

Thanks

M Kirberg:

--- Quote ---Is the WARNING telling me that the build did not use the updated kernel config? Or am I missing something else to get the ISL12020 working?
--- End quote ---

yes, you can make a clean of the recipe to avoid this


Regarding the MAC: the passing of FSBL to UBOOT only works if you use the U-Boot settings from

https://wiki.trenz-electronic.de/display/PD/TE0720+Test+Board#TE0720TestBoard-U-Boot



bigguiness:
Thanks for the reply and link.

I have made the configuration changes to petalinux and u-boot as described. I also updated the device tree, that should fix the RTC issue.

What do you mean "make a clean of the recipe"? How do I do that?

When I did a petalinux-build after making the config changes I now get:

--- Code: ---WARNING: .../os/components/yocto/layers/meta-xilinx/meta-xilinx-bsp/recipes-kernel/linux/linux-xlnx_2020.2.bb:do_compile is tainted from a forced run
WARNING: .../os/components/yocto/layers/meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx_2020.2.bb:do_compile is tainted from a forced run

--- End code ---

I just booted the new build and the MAC address is now correct. Also the RTC is working now.

I do see this new message when the kernel boots:

--- Code: ---[Firmware Warn]: /amba/ethernet@e000b000/mdio/phy@0: Whitelisted compatible string. Please remove
--- End code ---

Is this normal?

Also, about the device tree. Where are all the pieces located? The only parts I can find, that do not say they are automatically generated, are in .../os/project-spec/meta-user/recipes-bsp/device-tree/files. Those files are system-user.dtsi and pl-custom.dtsi.

I have an AXI_GPIO block in my design. Two of the outputs from that block drive some LEDs on my board. I want to bind them to gpio-leds in the kernel but can't figure out how to do it.

Thanks

M Kirberg:

--- Quote ---What do you mean "make a clean of the recipe"? How do I do that?
--- End quote ---


--- Code: ---petalinux-build -c kernel -x cleanall
--- End code ---



--- Quote ---I do see this new message when the kernel boots:
Code:
[Firmware Warn]: /amba/ethernet@e000b000/mdio/phy@0: Whitelisted compatible string. Please remove

Is this normal?

--- End quote ---

Yes, you can remove the compatible string in your phy node, as it is no longer needed in newer Kernel versions. This is only a warning and no error.



--- Quote ---Also, about the device tree. Where are all the pieces located? The only parts I can find, that do not say they are automatically generated, are in .../os/project-spec/meta-user/recipes-bsp/device-tree/files. Those files are system-user.dtsi and pl-custom.dtsi.

--- End quote ---

system-user.dtsi is what you specifically add. Xilinx uses automatic generation based on your .xsa file, and therefore already adds stuff in you PL which it knows.
One way to see what is generated is to decompile your devicetree, and inspect it.
On your device you may use


--- Code: ---dtc -I fs /sys/firmware/devicetree/base
--- End code ---
to decompile it.

Navigation

[0] Message Index

[#] Next page

Go to full version