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> 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> > 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> 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> *On Behalf Of *Richi Dubey >>> *Sent:* Wednesday, April 14, 2021 3:22 PM >>> *To:* Kinsey Moore <kinsey.mo...@oarcorp.com> >>> *Cc:* rtems-de...@rtems.org <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> >>> 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> >>> *Sent:* Wednesday, April 14, 2021 01:01 >>> *To:* Kinsey Moore <kinsey.mo...@oarcorp.com>; rtems-de...@rtems.org < >>> 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
