Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board
Richi Dubey
richidubey at gmail.com
Wed Apr 14 18:18:38 UTC 2021
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/20210414/12d88746/attachment-0001.html>
More information about the devel
mailing list