03-29-2021 12:16 PM - edited 03-29-2021 12:18 PM
Following the Confluence guidance (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841937/Zynq+UltraScale+MPSoC+Ubuntu+part+2+-+Building+and+Running+the+Ubuntu+Desktop+From+Sources) I have successfully booted Ubuntu from the pre-built image and then from a PetaLinux build of Ubuntu for the ZCU102 (Board rev "D2 PROD") using an SD card. My next step is to be able to include a PL design (bitstream), however when this is included (by building the new BOOT.BIN using the SDK via the "Create Boot Image" menu item) I find that the bitstream is successfully loaded but the Ubuntu system fails to fully boot. Using the serial interface to monitor the boot process I can see that the PS boot stops consistently at the following place:
[ 3.561452] pca954x 1-0075: registered 8 multiplexed busses for I2C switch pca9548
[ 3.569034] cdns-i2c ff030000.i2c: 400 kHz mmio ff030000 irq 34
[ 3.576193] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[ 3.583069] rtc_zynqmp ffa60000.rtc: setting system clock to 2021-03-26 18:07:08 UTC (1616782028)
[ 3.591941] of_cfs_init
[ 3.594407] of_cfs_init: OK
[ 3.597316] clk: Not disabling unused clocks
[ 3.601806] ALSA device list:
[ 3.604766] #0: DisplayPort monitor
I have relentlessly searched these forums for this issue and although there are many Ubuntu boot issues reported, I have not seen anything that resembles this problem.
03-29-2021 07:43 PM
03-30-2021 11:57 AM
I just ask you the followings.
Why are you using different version among FSBL, ATF and PMUFW.
I guess PMUFW is OK. But I guess other are different.
Also, did you change or upgrade DTB ?
Would you make sure them ?
03-30-2021 12:14 PM
I have not knowingly done anything to change versions between FSBL, ATF and PMUFW. As far as I am aware they would have all been generated at the same time by PetaLinux. Do these versions relate to the software that generated them or the target silicon version or something else?
Regarding the DTB, I have not changed this as I used the pre-generated HDF file (design_1_wrapper.hdf) that was supplied with the project download. I am wondering if that was not the right thing to do, although the project guidance notes do suggest that this is a viable option.
03-31-2021 03:03 AM
04-02-2021 12:13 PM
The prebuilt image is a *.img file that is downloaded and simply programmed onto an SD card. However, I cannot use this prebuilt image to then add a bitstream file for PL functionality because the u-boot.elf is not supplied with it. Therefore, I then used PetaLinux to generate my own version of Linux for the ZCU102, which also gives me u-boot.elf. Both the prebuilt and "current" Linux boot successfully from SD card. However, if I then add a bitstream to the "current" Linux and update the SD card, the PL functionality is correctly loaded, however Linux fails to boot (see the boot log that I supplied earlier). In generating the "current" version of Linux I used the pre-built HDF file (supplied with the downloaded material). I have not deliberately changed the DTB. Does this help?
04-05-2021 02:46 PM
04-06-2021 03:05 AM
I'm just trying to understand correctly what you are saying here: "... if your FPGA binary and pre-build image ware different", do you mean that if the target hardware is somehow different between that defined for the pre-build image compared to the hardware that we are now using?
04-08-2021 10:47 AM - edited 04-08-2021 11:10 AM
Maybe I can pose a question that may help to elaborate the issue - having used PetaLinux to successfully generate a Linux image for SD card boot (no PL bitstream included), should it then be possible to include a bitstream into the system by using Bootgen to combine the bitstream with the pre-existing files generated by PetaLinux (i.e. fsbl, pmu, bl31 and u-boot.elf)? The question is relevant because presently this method appears not to be working. For the avoidance of doubt, the bitstream only configures the PL and no changes to the hardware environment as far as Linux is concerned are intended.
04-08-2021 03:02 PM
Even if you change some parameter in PS side not PL side, you have to change/update FPGA binary file.
>My next step is to be able to include a PL design (bitstream), however when this is included (by building the new BOOT.BIN using the SDK via the "Create Boot Image" menu item) I find that the bitstream is successfully loaded but the Ubuntu system fails to fully boot.
However you mentioned above. So I'm little confused.
As you may know, BOOT.bin file has FPGA binary, ARM trusted firmware, PMUFW and u-boot elf file.
So, if there is different between prebuild image and current design, you must build BOOT.bin by ex. Bootgen.
Hope this helps.
04-09-2021 06:49 AM - edited 04-09-2021 06:51 AM
Thanks for your efforts, however I can't say that I'm following your posts very well. However, meanwhile I believe that we have now resolved the issue ourselves. What seems not to be made clear by any of the documentation that I've read is that the PS system hardware definition that is used to generate the HDF file (for inclusion by PetaLinux when building Ubuntu for the ZCU102) must be carried over into subsequent PL designs. This is not obvious because the initial build of Linux described by the Confluence pages does not use a bitstream during the build process (i.e. a bitstream that, at minimum, defines the PS system seems not to be required). Also, Boot.bin can be re-built using Bootgen without requiring any bit file and Linux runs successfully. However, when a bitstream is subsequently introduced, it appears that unless that PL design includes the original PS HW description, then Linux will fail to boot (presumably because some of the PS hardware has been unexpectedly re-defined by the new bitstream). From an academic point of view this raises the question of what (file?) configures the PS hardware in the original Linux build that does not use a bitstream? None-the-less, the important aspect is that we now know how to combine a functional Linux system with a useful bitstream.