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@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@ff000000
Out: serial@ff000000
Err: serial@ff000000
Model: ZynqMP ZCU106 RevA
Board: Xilinx ZynqMP
Net: ZYNQ GEM: ff0e0000, phyaddr c, interface rgmii-id
Warning: ethernet@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@ff0e0000
Hit any key to stop autoboot: 0
ZynqMP> tftpboot 0x3000000 rdubey/sp01new.img
Using ethernet@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.som...@dlr.de
<mailto:jan.som...@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-boun...@rtems.org
<mailto:devel-boun...@rtems.org>> *On Behalf Of *Richi Dubey
*Sent:* Wednesday, April 14, 2021 3:22 PM
*To:* Kinsey Moore <kinsey.mo...@oarcorp.com
<mailto:kinsey.mo...@oarcorp.com>>
*Cc:* rtems-de...@rtems.org <mailto:rtems-de...@rtems.org>
<devel@rtems.org <mailto:devel@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@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.mo...@oarcorp.com <mailto:kinsey.mo...@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 <richidu...@gmail.com
<mailto:richidu...@gmail.com>>
*Sent:* Wednesday, April 14, 2021 01:01
*To:* Kinsey Moore <kinsey.mo...@oarcorp.com
<mailto:kinsey.mo...@oarcorp.com>>; rtems-de...@rtems.org
<mailto:rtems-de...@rtems.org> <devel@rtems.org
<mailto:devel@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@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@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@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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
