News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

Generating FSBL for TE0720-04-61Q33MA module

Started by neels, September 10, 2024, 03:48:42 PM

Previous topic - Next topic

neels

I recently got a couple of the following modules and trying to boot them. https://shop.trenz-electronic.de/en/TE0720-04-61Q33MA-SoC-Module-with-AMD-Zynq-7020-1Q-Automotive-1-GByte-DDR3-4-x-5-cm

I am able to boot the module with the reference design provided by Trenz.

When I tried to boot with my custom petalinux build, I found that the module was starting with the FSBL but not progressing beyond it. So I tried to use the reference FSBL provided in the reference design (TE0720-test_board-vivado_2021.2-build_11_20220202131818\test_board\prebuilt\software\1qf_1gb\fsbl.elf) and stitch it with my u-boot and image.ub and generated a BOOT.BIN. The BOOT.BIN progressed beyond FSBL, uboot, kernel and could see the boot prompt.

I wanted to regenerate FSBL myself instead of using the above. So, I checked through the scripts folder (TE0720-test_board-vivado_2021.2-build_11_20220202131818\test_board\scripts) and it appears Trenz generates FSBL using Vitis.   
 
So, I wrote a simple script (refer below) to generate FSBL(with Trenz modifications in TE0720-test_board vivado_2021.2-build_11_20220202131818\test_board\sw_lib\sw_apps\zynq_fsbl\src) using Vitis, integrated it with my u-boot and image.ub and generated an image. The resulting image didn't work pass beyond FSBL stage on TE0720-04-61Q33MA module. I tested the image on a TE0720-03-1CR module and it worked (passed beyond FSBL).

platform create -name {trenz}\
-hw [lindex $argv 0]\
-proc {ps7_cortexa9_0} -os {standalone} -out {.}

# update only the following files
file copy -force te_fsbl_files/te_fsbl_hooks.c trenz/zynq_fsbl/te_fsbl_hooks.c
file copy -force te_fsbl_files/te_fsbl_hooks.h trenz/zynq_fsbl/te_fsbl_hooks.h
file copy -force te_fsbl_files/te_fsbl_hooks_te0720.c trenz/zynq_fsbl/te_fsbl_hooks_te0720.c
file copy -force te_fsbl_files/te_fsbl_hooks_te0720.h trenz/zynq_fsbl/te_fsbl_hooks_te0720.h
file copy -force te_fsbl_files/fsbl_hooks.c trenz/zynq_fsbl/fsbl_hooks.c
file copy -force te_fsbl_files/fsbl_hooks.h trenz/zynq_fsbl/fsbl_hooks.h
file copy -force te_fsbl_files/main.c trenz/zynq_fsbl/main.c

platform write
platform generate -domains
platform active {trenz}
platform generate
bsp reload
bsp setlib -name xilffs -ver 4.6
bsp write
bsp reload
catch {bsp regenerate}
platform generate -domains standalone_domain
platform generate -domains zynq_fsbl

So I am slightly puzzled on why my above FSBL modification works for the TE0720-03-1CR module but not on TE0720-04-61Q33MA module.

I will be happy to know if I have missed something obviously while generating my FSBL, if I need to add anything more for the FSBL generation, and if there is something more that needs to be updated in the FSBL to get the TE0720-04-61Q33MA module working.

JH

Hi,
TE0720-03-1CR  and TE0720-04-61Q33MA use different DDR with different size.
Did you checked that your project use correct PS configuration?

You can import our FSBL with trenz modification as template into Vitis as local repository and use GUI:
https://wiki.trenz-electronic.de/display/PD/Vitis#Vitis-Includelocalrepositories

with newer Vivado/Vitis/Petalinux we offer also a patch for petalinux:
https://wiki.trenz-electronic.de/display/PD/TE0720+Test+Board
https://wiki.trenz-electronic.de/display/PD/TE0720+Test+Board#TE0720TestBoard-FSBLpatch(alternativeforvitisfsbltrenzpatch)
But this does work only with corresponding petalinux version.

But at the moment I would expect you use wrong PS configuration for memory.
PS Memmory setup is set to  "MT41J64M16 JT-125G" on TE0720-03-1CR  and "MT41J256M16 RE-125" on TE0720-04-61Q33MA. memory configuration will be done with fsbl and linux only need to know size, that's the reason why it works in the other way(or boot.bin and your linux files) and linux use less ddr.

br
John


neels

Hi John,

Thanks for the suggestion.
The DDR3 memory size was the issue that was preventing the FSBL from booting.
The issue is now fixed.

Thanks,
Neels