Hello Alan, I have gone through all your Docker files again. Tried it with the commits you used, without success. BUT: mkimage without "-O rtems” does the trick.
mkimage.py -A arm -T kernel -a 0x80000000 -e 0x80000000 -n “Hello Posix” -d hello.gz hello.img -> boot ok Bytes transferred = 71997 (1193d hex) link up on port 0, speed 100, full duplex Using cpsw device TFTP from server 141.14.128.9; our IP address is 141.14.128.37 Filename 'rtems.img'. Load address: 0x80800000 Loading: ##### 4 MiB/s done Bytes transferred = 71997 (1193d hex) 33325 bytes read in 4 ms (7.9 MiB/s) ## Booting kernel from Legacy Image at 80800000 ... Image Name: Hello Posix Created: 2022-06-06 9:20:27 UTC Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 71933 Bytes = 70.2 KiB Load Address: 80000000 Entry Point: 80000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Uncompressing Kernel Image ... OK Loading Device Tree to 8fff4000, end 8ffff22c ... OK Starting kernel ... RTEMS Beagleboard: am335x-based ARM Debug: 0x4b141000 *** HELLO WORLD TEST *** Hello World *** END OF HELLO WORLD TEST *** [ RTEMS shutdown ] RTEMS version: 6.0.0.a26b9936ff8405d6e0c8d62ac04fbce64ee6e5cc RTEMS tools: 12.1.1 20220509 (RTEMS 6, RSB e73a258a3aa4af8735b589a2d770571b2105a c5f, Newlib 64b2081) executing thread ID: 0x08b010001 executing thread name: mkimage.py -A arm -T kernel -O rtems -a 0x80000000 -e 0x80000000 -n “Hello Posix” -d hello.gz hello.img -> boot fails Bytes transferred = 71997 (1193d hex) 33325 bytes read in 4 ms (7.9 MiB/s) ## Booting kernel from Legacy Image at 80800000 ... Image Name: Hello Posix Created: 2022-06-06 10:01:12 UTC Image Type: ARM RTEMS Kernel Image (gzip compressed) Data Size: 71933 Bytes = 70.2 KiB Load Address: 80000000 Entry Point: 80000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Transferring control to RTEMS (at address 80000000) ... RTEMS Beagleboard: am335x-based ARM Debug: 0x4b141000 *** FATAL *** fatal source: 1 (INTERNAL_ERROR_RTEMS_API) fatal code: 22 (0x00000016) RTEMS version: 6.0.0.a26b9936ff8405d6e0c8d62ac04fbce64ee6e5cc RTEMS tools: 12.1.1 20220509 (RTEMS 6, RSB e73a258a3aa4af8735b589a2d770571b2105ac5f, Newlib 64b2081) executing thread ID: 0x089010001 executing thread name: IDLE I have no idea if this is a bug in the U-boot: U-Boot 2018.09-00002-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500), Build: jenkins-github_Bootloader-Builder-65 Heinz > On 2. Jun 2022, at 18:00, Heinz Junkes <jun...@fhi-berlin.mpg.de> wrote: > > Yes, I can start an rtems image (RTEMS 5.1) on beaglebone (bboted by tftp in > u-boot): > > *** HELLO WORLD TEST *** > executing thread name: (Sep 10 2018 - 19:41:39 -0500), Build: PU : AM335X-GP > rev 2.1 > > > But it looks to me like there is no ethernet device driver for RTEMS5.1 and > LEGACY_STACK available. > So I can't use Ethernet here. > > So I have to switch to libbsd. I will now try again with RTEMS-master (6). > > Viele Grüße > Heinz Junkes > -- > Experience directly varies with equipment ruined. > > > >> On 1. Jun 2022, at 22:37, Alan Cudmore <alan.cudm...@gmail.com> wrote: >> >> I see you are trying RTEMS 5.1. I don’t think I tested that repository on >> RTEMS 5.1, but I do recall having a similar application working 5.1. I >> should be able to try a similar build on my Beaglebone. >> Were you able to successfully boot a RTEMS image from u-boot without libbsd? >> The first problem was booting the RTEMS 6 u-boot .img file, correct? >> >> Regards, >> Alan >> >> From: Heinz Junkes >> Sent: Wednesday, June 1, 2022 11:14 AM >> To: Alan Cudmore >> Cc: users@rtems.org >> Subject: Re: Try to load and run RTEMS Image on Cora-z7-10 >> >> I can add something directly. I found in your example (rki) how you talk to >> the network device. >> I have implemented it in a similar way. >> >> Unfortunately, I can't even get to the point. >> >> The programme breaks off in rtems_bsd_initialize() at mi_startup() >> >> ***** RTEMS Version: rtems-5.1.0 (ARM/ARMv4/beagleboneblack) ***** >> >> ***** Initializing network (libbsd, dhcpcd) ***** >> create directory /etc >> create timer ... >> mutex init ... >> mi startup ... >> >> *** FATAL *** >> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION) >> >> R0 = 0x00000000 R8 = 0x00000000 >> R1 = 0x802ec93c R9 = 0x00000000 >> R2 = 0x00000007 R10 = 0x00000064 >> R3 = 0x006e6573 R11 = 0x8052e7e0 >> R4 = 0x00000007 R12 = 0x01010101 >> R5 = 0xfffffff7 SP = 0x80553f30 >> R6 = 0x802ec93c LR = 0x8022fcb4 >> R7 = 0x00000000 PC = 0x8022ef68 >> CPSR = 0x00000113 VEC = 0x00000004 >> RTEMS version: 5.1.0 >> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5.1, Newlib 7947581) >> executing thread ID: 0x08b010001 >> executing thread name: >> >> Viele Grüße >> Heinz Junkes >> -- >> Experience directly varies with equipment ruined. >> >> >> >>> On 1. Jun 2022, at 15:30, Heinz Junkes <jun...@fhi-berlin.mpg.de> wrote: >>> >>> Hi Alan, >>> Thanks for the feedback. Did you also use the Ethernet of the >>> beagleboneblack in your demo. I can't see which if is implemented in the >>> BSP. >>> >>> Danke Heinz >>> >>> >>>> On 31. May 2022, at 14:43, Alan Cudmore <alan.cudm...@gmail.com> wrote: >>>> >>>> If it helps, I have a demo where I built and ran RTEMS 6 with libbsd on >>>> the beaglebone black in January. I used specific commits from the >>>> repositories in an effort to make it reproducible, so if there was a >>>> regression that may help. My build used -O linux when creating the u-boot >>>> image file. >>>> The repo is here: >>>> https://github.com/alanc98/rtems-cfs-demo >>>> >>>> I still have the board setup. As soon as I have time, I can build a new >>>> toolchain and BSP to see if it still works. >>>> Alan >>>> >>> >>> _______________________________________________ >>> users mailing list >>> users@rtems.org >>> http://lists.rtems.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users