Cool, I tried building uboot for the board from this repo: https://github.com/Xilinx/u-boot-xlnx, and the instructions for zcu106 are here: https://github.com/Xilinx/u-boot-xlnx/blob/master/doc/board/xilinx/zynqmp.rst. But I tried a lot and could not find <https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads> anything like AArch32 or ARMv7.
I have these toolchains available: $ ls /tools/arm/toolchains/8.3/ gcc-arm-8.3-2019.03-x86_64-aarch64-elf gcc-arm-8.3-2019.03-x86_64-arm-eabi zips gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf $ ls /tools/arm/toolchains/9.2/ gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf gcc-arm-9.2-2019.12-x86_64-arm-none-eabi zips gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf Which one should I use to build uboot? On Tue, Apr 20, 2021 at 5:54 PM Kinsey Moore <kinsey.mo...@oarcorp.com> wrote: > 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> > 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