Hi Stefan,
On 2017-07-24 15:17, Stefan Kalkowski wrote:
Hi Alexander,
On 07/06/2017 03:10 PM, Alexander Weidinger wrote:
Hello,
I was finally able to get the RPi to boot completely by adding the following lines from foc r72: https://github.com/skalk/foc/blob/r72/l4/pkg/bootstrap/server/src/platform_c...
What still seems odd to me is, that when I'm using genode.img I can use the kernel_addr_r address (0x01000000) stored in u-boot to successfully boot the RPi. For the image.elf I have to use a different address - something like 0x8000 - otherwise the RPi just resets itself.
I'm not sure whether I understand you correctly. When using Genode 16.08 I do not get a "genode.img" file out of the build process.
The 'genode.img' file was created using the genode-arm-objcopy binary, according to [0].
I assume that your genode.img is equivalent to the uImage file built when enabling the u-boot run-tool plugin?
I must admit, I didn't try out the u-boot run-tool plugin for the rpi, since we normally use the image.elf files to boot our platforms. But I assume, that it basically does the same thing?
Given that in u-boot you are loading the OS via "bootm XXX" you have to use an u-boot compliant image and not an ELF file. When using an u-boot image, u-boot copies everything (except the header) to the physical address given in the u-boot image header, and then jumps to the entrypoint address given by the same header. In contrast, when using an ELF file, you have to use the "bootelf" command within the u-boot commandline.
I did use 'bootm' for the genode.img and 'bootelf' for the image.elf. Is there any advantage of using u-boot img files in comparison to using the *.elf file(s) generated by Genode?
Anyway, the u-boot image is generated by our run-tool (when enabled via RUN_OPT) out of the image.elf file. Thereby, the used memory areas after the process of loading by u-boot, should be the same. The loading itself should succeed, as long as you are using the memory area to hand over the image to u-boot (either ELF or u-boot image)
Since now I'm also aware of
When booting images that have been loaded to RAM (for instance using TFTP download) you have to be careful that the locations where the (compressed) images were stored do not overlap with the memory needed to load the uncompressed kernel.
[1], I assume I simply overwrote my *.img in the RAM and it therefore lead to system crashes as promised by U-Boot? Even if the *.img files generated by Genode are/were not compressed, I assume the copying in the RAM overwrote the *.img file in my case.
Regards Stefan
Thanks for all the clarifications and sorry for the late response.
Regards, Alexander
[0] https://genode.org/documentation/release-notes/13.11#Raspberry_Pi [1] https://www.denx.de/wiki/DULG/UBootCmdGroupExec
Some insight on this would be very helpful!
Regards, Alexander
On 2017-07-05 18:09, Alexander Weidinger wrote:
Dear Genode community,
we are currently trying to get a Raspberry Pi 1 Model B running with Genode 16.08 and Fiasco.OC r67 from https://github.com/skalk/foc/.
We made changes to both, genode and foc but the basis are the two mentioned versions.
Trying to boot the RPi, we are left with the following message, the board resets itself? and again tries to boot:
... reading genode.img 2060288 bytes read in 331 ms (5.9 MiB/s) Kernel image @ 0x1000000 [ 0x1000000 - 0x11f7000 ]
Starting k L4 Bootstrapper Build: #5 Wed Jul 5 17:34:36 CEST 2017, 4.9.2 Scanning up to 512 MB RAM, starting at offset 32MB
U-Boot 2014.07-rc3-gd4614d4 (Jun 14 2014 - 01:23:23) ...
(Trying to boot vanilla genode 16.08 with vanilla foc r67 (from skalk) leads to the same behavior.)
We were successful in running our setup (foc r67 and genode 16.08 both with our changes) on a pandaboard (real hardware) and on pbxa9 (qemu). Additionally we are able to successfully boot the RPi using vanilla genode 16.08 with the provided foc version (r56), using our u-boot configuration.
Do we need to make additional changes to foc and/or genode to be able to boot the RPi using r67 of foc? Any hints or information are very welcomed!
Regards, Alexander
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main