Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board
Richi Dubey
richidubey at gmail.com
Tue Apr 20 12:00:58 UTC 2021
Thanks!
Can you please tell me more about:
> build a new u-boot that can do what you need and then package it into
> BOOT.bin using bootgen (the code is available on github).
this? How do I build a new uboot that defaults to AArch32 at EL1?
On Mon, Apr 19, 2021 at 6:11 PM Kinsey Moore <kinsey.moore at oarcorp.com>
wrote:
> I'll start by saying that AArch64 RTEMS on QEMU (for which there is a
> ZynqMP hardware model) works great and is what the current BSP targets.
>
> The current status of AArch64 RTEMS on real hardware is not as simple as
> I'd like, but it's possible and I've run the uniprocessor testsuite tests
> on an an Avnet dev board (ZU3EG). The complications are caused by lack of
> support for the MMU on AArch64 leading to all memory requiring strict
> alignment for accesses. Due to this, the toolchain needs to be recompiled
> with additional flags:
>
> --targetcflags="-DPREFER_SIZE_OVER_SPEED -mstrict-align"
> --targetcxxflags="-mstrict-align"
>
> To deal with an EL2 start, optstarthyp.yml needs to be added to the BSP
> definition and -mstrict-align needs to be added to abi.yml.
>
> Unfortunately, these changes are unfit for inclusion in RTEMS and my next
> step is to work on the MMU driver to avoid these alignment problems.
>
>
> Kinsey
> On 4/19/2021 00:19, Richi Dubey wrote:
>
> Thanks!
>
> Can I get rtems to build images as an AArch64 code, so that I don't have
> to change anything for uboot?
>
> On Thu, Apr 15, 2021 at 12:01 AM Kinsey Moore <kinsey.moore at oarcorp.com>
> wrote:
>
>> That exception dump doesn't say a lot other than the ELR pointing at the
>> very first instruction in your image, so I suspect that u-boot is trying to
>> start your image as AArch64 code instead of AArch32/ARMv7 code. The ESR
>> just specifies that it was a 32-bit instruction that blew up (both AArch32
>> and AArch64 use 32-bit instructions) instead of a 16-bit instruction.
>>
>> The u-boot images that come with the PetaLinux distributions default to
>> starting code as AArch64 at EL2, so you either need to figure out how to
>> make u-boot default to AArch32/ARMv7 at EL1 or build a new u-boot that can
>> do what you need and then package it into BOOT.bin using bootgen (the code
>> is available on github). From what I remember, the ARMv7 BSP for ZynqMP
>> mentions booting over JTAG.
>>
>>
>> Kinsey
>> On 4/14/2021 13:18, Richi Dubey wrote:
>>
>> Hi Jan, Kinsey,
>>
>> Thanks for your quick responses.
>>
>> I rebuilt the .img file with -O rtems option, and I think it is the
>> standard uboot available from PetaLinux. It still fails, but I think it is
>> related to RTEMS now:
>> --------------------------------------------
>> Welcome to minicom 2.7.1
>>
>> OPTIONS: I18n
>> Compiled on May 6 2018, 08:02:47.Welcome to minicom 2.7.1
>>
>> OPTIONS: I18n
>> Compiled on May 6 2018, 08:02:47.
>> Port /dev/ttyUSB32, 18:14:14
>>
>> Press CTRL-K Z for help on special keys
>>
>> Xilinx Zynq MP First Stage Boot Loader
>> Release 2020.1 Jan 1 2021 - 07:33:16
>> NOTICE: ATF running on XCZU7EV/silicon v4/RTL5.1 at 0xfffea000
>> NOTICE: BL31: Secure code at 0x60000000
>> NOTICE: BL31: Non secure code at 0x10080000
>> NOTICE: BL31: v2.0(release):xilinx-v2019.1-12-g713dace9
>> NOTICE: BL31: Built : 08:36:10, Sep 1 2020
>> PMUFW: v1.1
>>
>>
>> U-Boot 2019.01 (Sep 01 2020 - 08:36:54 +0000)
>>
>> Model: ZynqMP ZCU106 RevA
>> Board: Xilinx ZynqMP
>> DRAM: 4 GiB
>>
>> EL Level: EL2
>>
>> Chip ID: zu7ev
>>
>> MMC: mmc at ff170000: 0
>>
>> Loading Environment from SPI Flash... SF: Detected n25q512a with page
>> size 512 B
>> ytes, erase size 128 KiB, total 128 MiB
>>
>> OK
>>
>> In: serial at ff000000
>>
>> Out: serial at ff000000
>>
>> Err: serial at ff000000
>>
>> Model: ZynqMP ZCU106 RevA
>>
>> Board: Xilinx ZynqMP
>>
>> Net: ZYNQ GEM: ff0e0000, phyaddr c, interface rgmii-id
>>
>>
>>
>> Warning: ethernet at ff0e0000 MAC addresses don't match:
>>
>> Address in ROM is 00:0a:35:05:2f:ec
>>
>> Address in environment is 00:0a:35:00:22:19
>>
>> eth0: ethernet at ff0e0000
>>
>> Hit any key to stop autoboot: 0
>>
>> ZynqMP> tftpboot 0x3000000 rdubey/sp01new.img
>>
>> Using ethernet at ff0e0000 device
>>
>> TFTP from server 172.19.0.3; our IP address is 172.19.2.40
>>
>> Filename 'rdubey/sp01new.img'.
>>
>> Load address: 0x3000000
>>
>> Loading: ####
>>
>> 1.7 MiB/s
>>
>> done
>>
>> Bytes transferred = 50978 (c722 hex)
>>
>> ZynqMP> bootm 0x3000000 ; reset
>>
>> ## Booting kernel from Legacy Image at 03000000 ...
>>
>> Image Name: RTEMS
>>
>> Image Type: ARM RTEMS Kernel Image (gzip compressed)
>>
>> Data Size: 50914 Bytes = 49.7 KiB
>>
>> Load Address: 00300000
>>
>> Entry Point: 00300000
>>
>> Verifying Checksum ... OK
>>
>> Uncompressing Kernel Image ... OK
>>
>> ## Transferring control to RTEMS (at address 00300000) ...
>>
>> "Synchronous Abort" handler, esr 0x02000000
>>
>> elr: ffffffff90593000 lr : 0000000010097a90 (reloc)
>>
>> elr: 0000000000300000 lr : 000000007fe04a90
>>
>> x0 : 000000007ddacf58 x1 : 0000000000000000
>>
>> x2 : 0000000000006802 x3 : 0000000000000020
>>
>> x4 : 0000000000000000 x5 : 0000000000000030
>>
>> x6 : 000000007fe7e9cd x7 : 000000000000000f
>>
>> x8 : 0000000000000038 x9 : 0000000000000008
>>
>> x10: 000000007ddbd530 x11: 00000000ffffffd0
>>
>> x12: 0000000000000000 x13: 0000000000000200
>>
>> x14: 0000000000000001 x15: 0000000000000008
>>
>> x16: 000000000000003f x17: 000000000000009a
>>
>> x18: 000000007ddacde8 x19: 0000000000300000
>>
>> x20: 000000007fead720 x21: 000000007fe04a20
>>
>> x22: 000000000000071f x23: 000000007fe04a20
>>
>> x24: 0000000000000001 x25: 000000007ddbd2f8
>>
>> x26: 000000007fe9ac18 x27: 0000000000300000
>>
>> x28: 0000000003000040 x29: 000000007dda07c0
>>
>>
>>
>> Resetting CPU ...
>>
>>
>>
>> ### ERROR ### Please RESET the board ###
>>
>> --------------------------------------------
>> Can this be about the load address being at 0x00300000 and the .img being
>> fetched at 0x3000000?
>>
>>
>> On Wed, Apr 14, 2021 at 7:08 PM <Jan.Sommer at dlr.de> wrote:
>>
>>> Hi Richi,
>>>
>>>
>>>
>>> In your log it says:
>>>
>>>
>>>
>>> Image Type: ARM Linux Kernel Image (gzip compressed)
>>>
>>>
>>>
>>> At least for our zedboard devices we use the following main options for
>>> mkimage.
>>>
>>>
>>>
>>> mkimage -A arm -O rtems -T kernel
>>>
>>>
>>>
>>> Which yields for me:
>>>
>>> Image Type: ARM RTEMS Kernel Image (gzip compressed)
>>>
>>>
>>>
>>> IIRC the difference between -O rtems and -O linux is subtle, but maybe
>>> that helps.
>>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> Jan
>>>
>>>
>>>
>>>
>>>
>>> *From:* devel <devel-bounces at rtems.org> *On Behalf Of *Richi Dubey
>>> *Sent:* Wednesday, April 14, 2021 3:22 PM
>>> *To:* Kinsey Moore <kinsey.moore at oarcorp.com>
>>> *Cc:* rtems-devel at rtems.org <devel at rtems.org>
>>> *Subject:* Re: Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106
>>> board
>>>
>>>
>>>
>>> Trying to boot directly from the .img file also fails:
>>>
>>>
>>>
>>> ZynqMP> tftpboot 0x3000000 rdubey/sp01.img
>>>
>>> Using ethernet at ff0e0000 device
>>>
>>> TFTP from server 172.19.0.3; our IP address is 172.19.2.40
>>>
>>> Filename 'rdubey/sp01.img'.
>>>
>>> Load address: 0x3000000
>>>
>>> Loading: ####
>>>
>>> 6.1 MiB/s
>>>
>>> done
>>>
>>> Bytes transferred = 50978 (c722 hex)
>>>
>>> ZynqMP> bootm 0x3000000 ; reset
>>>
>>> ## Booting kernel from Legacy Image at 03000000 ...
>>>
>>> Image Name: RTEMS
>>>
>>> Image Type: ARM Linux Kernel Image (gzip compressed)
>>>
>>> Data Size: 50914 Bytes = 49.7 KiB
>>>
>>> Load Address: 00300000
>>>
>>> Entry Point: 00300000
>>>
>>> Verifying Checksum ... OK
>>>
>>> Uncompressing Kernel Image ... OK
>>>
>>> FDT and ATAGS support not compiled in - hanging
>>>
>>> ### ERROR ### Please RESET the board ###
>>>
>>>
>>>
>>>
>>> What can I do now?
>>>
>>>
>>>
>>> On Wed, Apr 14, 2021 at 6:11 PM Kinsey Moore <kinsey.moore at oarcorp.com>
>>> wrote:
>>>
>>> If you’re only running RTEMS, you should be able to drop the FDT
>>> commands since that what appears to be causing the problem and I don’t
>>> think that the arm/xilinx_zynqmp BSP uses it at all.
>>>
>>>
>>>
>>> Kinsey
>>>
>>>
>>>
>>> *From:* Richi Dubey <richidubey at gmail.com>
>>> *Sent:* Wednesday, April 14, 2021 01:01
>>> *To:* Kinsey Moore <kinsey.moore at oarcorp.com>; rtems-devel at rtems.org <
>>> devel at rtems.org>
>>> *Subject:* Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I followed the 8.2.23 docs
>>> <https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#xilinx-zynqmp> to
>>> build rtems for the xilinx_zynqmp_ultra96 bsp since it was the only bsp
>>> corresponding to xilinx-zynqmp in the rtems-bsp.
>>>
>>>
>>>
>>> Then I followed the boot via Uboot section 8.2.1.1 on docs
>>> <https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#boot-via-u-boot>,
>>> but the uboot on zcu106 does not have a run loadfdt command, and its
>>> alternative is fdt addr [address]. But something is wrong, I cannot run the
>>> sp01.img file:
>>>
>>>
>>>
>>> With fdt:
>>>
>>> ------------------------------
>>>
>>> ZynqMP> tftpboot 0x3000000 rdubey/sp01.img
>>>
>>>
>>> Using ethernet at ff0e0000 device
>>>
>>> TFTP from server 172.19.0.3; our IP address is 172.19.2.40
>>>
>>> Filename 'rdubey/sp01.img'.
>>>
>>> Load address: 0x3000000
>>>
>>> Loading: ####
>>>
>>> 6.9 MiB/s
>>>
>>> done
>>>
>>> Bytes transferred = 50978 (c722 hex)
>>>
>>> ZynqMP> fdt addr 0x2A00000
>>>
>>> ZynqMP> bootm 0x3000000 - 0x2A00000 ; reset
>>>
>>> ## Booting kernel from Legacy Image at 03000000 ...
>>>
>>> Image Name: RTEMS
>>>
>>> Image Type: ARM Linux Kernel Image (gzip compressed)
>>>
>>> Data Size: 50914 Bytes = 49.7 KiB
>>>
>>> Load Address: 00300000
>>>
>>> Entry Point: 00300000
>>>
>>> Verifying Checksum ... OK
>>>
>>> ## Flattened Device Tree blob at 02a00000
>>>
>>> Booting using the fdt blob at 0x2a00000
>>>
>>> Uncompressing Kernel Image ... OK
>>>
>>> Loading Device Tree to 0000000007ff1000, end 0000000007fff257 ... OK
>>>
>>> fdt_find_or_add_subnode: chosen: FDT_ERR_BADSTRUCTURE
>>>
>>> ERROR: /chosen node create failed
>>>
>>> - must RESET the board to recover.
>>>
>>>
>>> FDT creation failed! hanging...### ERROR ### Please RESET the board ###
>>>
>>> ------------------------------
>>>
>>>
>>>
>>> With loading the system.dtb that I generally use for loading yocto linux
>>> images:
>>>
>>>
>>>
>>>
>>>
>>> ---------------------
>>>
>>> ZynqMP> tftpboot 0x2A00000 rdubey/system.dtb
>>>
>>> Using ethernet at ff0e0000 device
>>>
>>> TFTP from server 172.19.0.3; our IP address is 172.19.253.142
>>>
>>> Filename 'rdubey/system.dtb'.
>>>
>>> Load address: 0x2a00000
>>>
>>> Loading: ###T #
>>>
>>> 8.8 KiB/s
>>>
>>> done
>>>
>>> Bytes transferred = 45656 (b258 hex)
>>>
>>> ZynqMP> tftpboot 0x3000000 rdubey/sp01.img
>>>
>>> Using ethernet at ff0e0000 device
>>>
>>> TFTP from server 172.19.0.3; our IP address is 172.19.253.142
>>>
>>> Filename 'rdubey/sp01.img'.
>>>
>>> Load address: 0x3000000
>>>
>>> Loading: ####
>>>
>>> 1.7 MiB/s
>>>
>>> done
>>>
>>> Bytes transferred = 50978 (c722 hex)
>>>
>>> ZynqMP> bootm 0x3000000 - 0x2A00000 ; reset
>>>
>>> ## Booting kernel from Legacy Image at 03000000 ...
>>>
>>> Image Name: RTEMS
>>>
>>> Image Type: ARM Linux Kernel Image (gzip compressed)
>>>
>>> Data Size: 50914 Bytes = 49.7 KiB
>>>
>>> Load Address: 00300000
>>>
>>> Entry Point: 00300000
>>>
>>> Verifying Checksum ... OK
>>>
>>> ## Flattened Device Tree blob at 02a00000
>>>
>>> Booting using the fdt blob at 0x2a00000
>>>
>>> Uncompressing Kernel Image ... OK
>>>
>>> Loading Device Tree to 0000000007ff1000, end 0000000007fff257 ... OK
>>>
>>>
>>> Starting kernel ...
>>>
>>>
>>> "Synchronous Abort" handler, esr 0x02000000
>>>
>>> elr: ffffffff90593000 lr : 0000000010081868 (reloc)
>>>
>>> elr: 0000000000300000 lr : 000000007fdee868
>>>
>>> x0 : 0000000000000000 x1 : 0000000000000000
>>>
>>> x2 : 0000000007ff1000 x3 : 0000000000000000
>>>
>>> x4 : 0000000000300000 x5 : 0000000000000000
>>>
>>> x6 : 0000000000000008 x7 : 0000000000000000
>>>
>>> x8 : 000000007dda0650 x9 : 0000000001008000
>>>
>>> x10: 000000000a200023 x11: 0000000000000002
>>>
>>> x12: 0000000000000002 x13: 00000000000096f4
>>>
>>> x14: 000000007dda06ac x15: 000000007fdee224
>>>
>>> x16: 0000000000000002 x17: 0000000007fff258
>>>
>>> x18: 000000007ddacde8 x19: 000000007fead720
>>>
>>> x20: 0000000000000000 x21: 0000000000000400
>>>
>>> x22: 000000000000071f x23: 000000007fdeedb8
>>>
>>> x24: 0000000000000003 x25: 000000007ddbd378
>>>
>>> x26: 000000007fe9ac18 x27: 0000000000300000
>>>
>>> x28: 0000000003000040 x29: 000000007dda0790
>>>
>>>
>>> Resetting CPU ...
>>>
>>>
>>> ### ERROR ### Please RESET the board ###
>>>
>>>
>>>
>>> ---------------------
>>>
>>>
>>>
>>> What might be going wrong? zcu106 is a multi processor board, so do I
>>> need to do something special to run the sp01 test? I have not tested any
>>> other .exe (or .img) so far.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210420/2339087a/attachment-0001.html>
More information about the devel
mailing list