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