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.mo...@oarcorp.com
<mailto:kinsey.mo...@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.mo...@oarcorp.com <mailto:kinsey.mo...@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@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
