Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board
Kinsey Moore
kinsey.moore at oarcorp.com
Mon Apr 19 12:41:05 UTC 2021
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 <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto:kinsey.moore at oarcorp.com>>
>> *Cc:* rtems-devel at rtems.org <mailto:rtems-devel at rtems.org>
>> <devel at rtems.org <mailto: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 <mailto: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
>> <mailto:richidubey at gmail.com>>
>> *Sent:* Wednesday, April 14, 2021 01:01
>> *To:* Kinsey Moore <kinsey.moore at oarcorp.com
>> <mailto:kinsey.moore at oarcorp.com>>; rtems-devel at rtems.org
>> <mailto:rtems-devel at rtems.org> <devel at rtems.org
>> <mailto: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/20210419/b7d06872/attachment-0001.html>
More information about the devel
mailing list