Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board
Richi Dubey
richidubey at gmail.com
Wed Apr 21 04:37:33 UTC 2021
Cool, I tried building uboot for the board from this repo:
https://github.com/Xilinx/u-boot-xlnx, and the instructions for zcu106 are
here:
https://github.com/Xilinx/u-boot-xlnx/blob/master/doc/board/xilinx/zynqmp.rst.
But I tried a lot and could not find
<https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads>
anything like AArch32 or ARMv7.
I have these toolchains available:
$ ls /tools/arm/toolchains/8.3/
gcc-arm-8.3-2019.03-x86_64-aarch64-elf
gcc-arm-8.3-2019.03-x86_64-arm-eabi zips
gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu
gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf
$ ls /tools/arm/toolchains/9.2/
gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf
gcc-arm-9.2-2019.12-x86_64-arm-none-eabi zips
gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu
gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf
Which one should I use to build uboot?
On Tue, Apr 20, 2021 at 5:54 PM Kinsey Moore <kinsey.moore at oarcorp.com>
wrote:
> 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>
> 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/20210421/9fbb1fd8/attachment-0001.html>
More information about the devel
mailing list