Hello Genodians
Is there a limit to the size (number of bytes or number of files) that can be added via import_from_depot (ARCH: imx6, KERNEL: hw)?
I had a problem with a run script that sometimes hung (mkfs never completing) or sometimes crashed in different components (ip pointing to Genode::ipc_reply_wait() in ld.lib.so) after upgrading from 19.05 to 19.07.
To debug the error I created a small version and step by step increased its size until it was identical to the one with the error.
The last difference I found was that the script with the error imported more depot archives. After reducing the list of imported archives the run script now works well.
What I think is even stranger, at first I bisected the problem with the original run script. This resulted in commit ac0ecdf855f61 triggering the problem. But as non of my other run scripts showed this kind of error, I suspected that it only uncovered a hidden error in my run script.
Could it be, that this is related to the size of the resulting image (about 50MiB for image.elf and 26MiB for uImage)?
Best regards, Pirmin
Hello Pirmin,
On Thu, Jul 18, 2019 at 03:50:26PM +0200, Duss Pirmin wrote:
Hello Genodians
Is there a limit to the size (number of bytes or number of files) that can be added via import_from_depot (ARCH: imx6, KERNEL: hw)?
I had a problem with a run script that sometimes hung (mkfs never completing) or sometimes crashed in different components (ip pointing to Genode::ipc_reply_wait() in ld.lib.so) after upgrading from 19.05 to 19.07.
To debug the error I created a small version and step by step increased its size until it was identical to the one with the error.
The last difference I found was that the script with the error imported more depot archives. After reducing the list of imported archives the run script now works well.
What I think is even stranger, at first I bisected the problem with the original run script. This resulted in commit ac0ecdf855f61 triggering the problem. But as non of my other run scripts showed this kind of error, I suspected that it only uncovered a hidden error in my run script.
Could it be, that this is related to the size of the resulting image (about 50MiB for image.elf and 26MiB for uImage)?
can you check whether you might get an overlap of your uImage when loaded to memory (from sd-card or network) and the final system image copied to bootstrap's linking address?
You might check your final uImage with: 'mkimage -l uImage' and the 'loadaddr' your u-boot boot-script finally uses as argument for 'bootm'.
Regards Stefan
Best regards, Pirmin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Heello Stefan
Thanks for the information.
On 19.07.19 10:24, Stefan Kalkowski wrote:
can you check whether you might get an overlap of your uImage when loaded to memory (from sd-card or network) and the final system image copied to bootstrap's linking address?
You might check your final uImage with: 'mkimage -l uImage' and the 'loadaddr' your u-boot boot-script finally uses as argument for 'bootm'.
'mkimage -l uImage' Data Size: 27421011 Bytes = 26778.33 KiB = 26.15 MiB Load Address: 10001000 Entry Point: 10001000
Load address (u-boot): 0x14000000 (320MiB) => end of loaded uImage in memory: 0x15a26953 (347MiB) => uncompressed modules in memory: 0x10130000 (257MiB) ... 0x13354000 (308MiB)
If I interpret this numbers correct, then there seems to be no overlap.
Best regards, Pirmin
Hello Pirmin,
I was on vacation, so sorry for my late response.
On Mon, Jul 22, 2019 at 08:09:47AM +0200, Duss Pirmin wrote:
Heello Stefan
Thanks for the information.
On 19.07.19 10:24, Stefan Kalkowski wrote:
can you check whether you might get an overlap of your uImage when loaded to memory (from sd-card or network) and the final system image copied to bootstrap's linking address?
You might check your final uImage with: 'mkimage -l uImage' and the 'loadaddr' your u-boot boot-script finally uses as argument for 'bootm'.
'mkimage -l uImage' Data Size: 27421011 Bytes = 26778.33 KiB = 26.15 MiB Load Address: 10001000 Entry Point: 10001000
Load address (u-boot): 0x14000000 (320MiB) => end of loaded uImage in memory: 0x15a26953 (347MiB) => uncompressed modules in memory: 0x10130000 (257MiB) ... 0x13354000 (308MiB)
If I interpret this numbers correct, then there seems to be no overlap.
I don't know exactly what the last two lines denote, but given that the link address of bootstrap is 0x10001000 and you load the uImage via u-boot to 0x14000000, there is only ~64MiB for the uncompressed system image including all boot modules left. Your (normally compressed) uImage is more than 26 MiB in size, so uncompressed probably much bigger than 64 MiB. So in my eyes there is a big chance for an overlap. Sadly, u-boot won't warn you about it.
To exclude an overlap, please change your uImage loadaddr to something like 0x30000000.
Best regards Stefan
Best regards, Pirmin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Stefan
On 05.08.19 10:58, Stefan Kalkowski wrote:
Hello Pirmin,
I was on vacation, so sorry for my late response.
No problem, I hope you had a good time.
On Mon, Jul 22, 2019 at 08:09:47AM +0200, Duss Pirmin wrote:
Heello Stefan
Thanks for the information.
On 19.07.19 10:24, Stefan Kalkowski wrote:
I don't know exactly what the last two lines denote, but given that the link address of bootstrap is 0x10001000 and you load the uImage via u-boot to 0x14000000, there is only ~64MiB for the uncompressed system image including all boot modules left. Your (normally compressed) uImage is more than 26 MiB in size, so uncompressed probably much bigger than 64 MiB. So in my eyes there is a big chance for an overlap. Sadly, u-boot won't warn you about it.
To exclude an overlap, please change your uImage loadaddr to something like 0x30000000.
The last two lines are the addresses of the ROM modules that are printed when the system starts (I assume this is where u-boot uncompressed the content to, and that core prints the addresses while parsing the elf).
If my assumptions, that u-boot decompressed uImage to 0x10001000 and up, and that the list of modules printed at startup is the uncompressed location and size of the ROM modules, then you are right, the possibility for an overlap is relatively high.
As I currently have a working setup, and know what to keep an eye on, you may regard this as solved for the moment. I will keep in mind, to check for overlap of memory regions in the future, when booting the system fails.
Best regards Pirmin
-
Duss Pirmin -
Stefan Kalkowski