Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board
Kinsey Moore
kinsey.moore at oarcorp.com
Tue Apr 20 12:24:14 UTC 2021
Unfortunately, that's not something I've done so I don't have any
particular guidance or instructions for you at this point other than
recommending that you find the generic build instructions for u-boot on
the ZynqMP platform.
Kinsey
On 4/20/2021 07:00, Richi Dubey wrote:
> 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
> <mailto: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 <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/20210420/e14ece38/attachment-0001.html>
More information about the devel
mailing list