Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board

Richi Dubey richidubey at gmail.com
Mon Apr 19 05:19:03 UTC 2021


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/20210419/ef1c9f21/attachment-0001.html>


More information about the devel mailing list