Hi,
I'm in the process of moving my TI AM437x (Cortex A9) Genode implementation to 17.02 and trying to get familiar with the lower level structural changes (of which there are many) in base-hw as I progress. After cleaning up some of my deprecated usages, correctly wrapping my components that used libc, and ignoring for now the new unified sd_card driver implementation, I got a successful build which unsurprisingly wanders off into oblivion after completing "kernel initialization".
The first question I have is from the build output which includes the line "core link address is 0x91000000" Where is that address generated and what is its purpose? It looks like my load address plus half the available ram.
The console log from the boot process (attached) shows some strange memory allocations for IO memory :
:io_mem_alloc: Allocator 0x910d012c dump: Block: [0x0,0x80449000] size=0x80449000 avail=0x80449000 max_avail=0x80449000 Block: [0x81000000,0x8145d000] size=0x45d000 avail=0x45d000 max_avail=0x8044900 Block: [0xa0000000,0xffffffff] size=0x5fffffff avail=0x5fffffff max_avail=0x5ff => mem_size=3767164927 (3592 MB) / mem_avail=3767164927 (3592 MB) How are the above blocks being allocated as io memory?
In prior releases (the "good-old-days"), a Native_region was declared to exactly define the regions of physical memory that were to be tagged as io memory. There appears to be no equivalent in 17.02. What am I missing?
Bob
Hi Bob
On 03/13/2017 10:23 PM, Bob Stewart wrote:
Hi,
I'm in the process of moving my TI AM437x (Cortex A9) Genode implementation to 17.02 and trying to get familiar with the lower level structural changes (of which there are many) in base-hw as I progress. After cleaning up some of my deprecated usages, correctly wrapping my components that used libc, and ignoring for now the new unified sd_card driver implementation, I got a successful build which unsurprisingly wanders off into oblivion after completing "kernel initialization".
The first question I have is from the build output which includes the line "core link address is 0x91000000" Where is that address generated and what is its purpose? It looks like my load address plus half the available ram.
The linking of core and the new bootstrap component (see issue #2092) is now done within the run tool when constructing a concrete scenario image, see `tool/run/boot_dir/hw` the functions `bootstrap_link_address` and `core_link_address`. The prior system image, namely the core component is linked together out of the core library and all other boot modules, like it was done before. Although, it is now typically linked at another offset (`core_link_address`). The new bootstrap initializes the core/kernel and its virtual memory. It is linked together with the prior system image as one single boot module, and gets loaded by the boot-loader. The motivation behind this is that core/kernel will soon run inside each component's virtual memory space, not paged 1:1 anymore, to circumvent the need for a context switch for each kernel entry. To split the code that runs in physical mode (MMU off) from the later one running with enabled MMU easily, we split it into two designated components. An additional advantage, we can throw away all initialization code afterwards, thereby limiting the attack surface within the kernel.
The console log from the boot process (attached) shows some strange memory allocations for IO memory :
:io_mem_alloc: Allocator 0x910d012c dump: Block: [0x0,0x80449000] size=0x80449000 avail=0x80449000 max_avail=0x80449000 Block: [0x81000000,0x8145d000] size=0x45d000 avail=0x45d000 max_avail=0x8044900 Block: [0xa0000000,0xffffffff] size=0x5fffffff avail=0x5fffffff max_avail=0x5ff => mem_size=3767164927 (3592 MB) / mem_avail=3767164927 (3592 MB) How are the above blocks being allocated as io memory?
What you see are the available I/O memory blocks, and not allocated ones. When initializing the allocator, it simply takes the whole address space and removes the RAM regions from it. To limit the usage of corresponding I/O memory requested at core, it is necessary to implement a related policy on the session establishment level anyway. Therefore, there is no restriction and additional knowledge hard-coded into the I/O memory allocator of core with respect to valid I/O memory regions anymore.
In prior releases (the "good-old-days"), a Native_region was declared to exactly define the regions of physical memory that were to be tagged as io memory. There appears to be no equivalent in 17.02. What am I missing?
An equivalent to `Native_region` is the `Memory_region`. In contrast to the former one it describes memory regions with page granularity in general, either physical or virtual ones. Moreover, it includes alignment checks, printing functionality and an array implementation, thereby limiting the repetitive code, where board specific devices memory descriptions and RAM regions were described.
I hope the new release does not hurt too much. Unfortunately, there will be more changes regarding base-hw in the next release, when the core transformation gets completed. But, analogue to the base API changes, we hope to have a sustainable base afterwards. Anyway, sorry for the inconvenience.
Best regards Stefan
Bob
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
Thanks for the explanations, Stefan. I think I'll wait until the base-hw changes are complete in the May release.
Bob
Get Outlook for Android
On Tue, Mar 14, 2017 at 5:53 AM -0400, "Stefan Kalkowski" <stefan.kalkowski@...1...> wrote:
Hi Bob
On 03/13/2017 10:23 PM, Bob Stewart wrote:
Hi,
I'm in the process of moving my TI AM437x (Cortex A9) Genode implementation to 17.02 and trying to get familiar with the lower level structural changes (of which there are many) in base-hw as I progress. After cleaning up some of my deprecated usages, correctly wrapping my components that used libc, and ignoring for now the new unified sd_card driver implementation, I got a successful build which unsurprisingly wanders off into oblivion after completing "kernel initialization".
The first question I have is from the build output which includes the line "core link address is 0x91000000" Where is that address generated and what is its purpose? It looks like my load address plus half the available ram.
The linking of core and the new bootstrap component (see issue #2092) is now done within the run tool when constructing a concrete scenario image, see `tool/run/boot_dir/hw` the functions `bootstrap_link_address` and `core_link_address`. The prior system image, namely the core component is linked together out of the core library and all other boot modules, like it was done before. Although, it is now typically linked at another offset (`core_link_address`). The new bootstrap initializes the core/kernel and its virtual memory. It is linked together with the prior system image as one single boot module, and gets loaded by the boot-loader. The motivation behind this is that core/kernel will soon run inside each component's virtual memory space, not paged 1:1 anymore, to circumvent the need for a context switch for each kernel entry. To split the code that runs in physical mode (MMU off) from the later one running with enabled MMU easily, we split it into two designated components. An additional advantage, we can throw away all initialization code afterwards, thereby limiting the attack surface within the kernel.
The console log from the boot process (attached) shows some strange memory allocations for IO memory :
:io_mem_alloc: Allocator 0x910d012c dump: Block: [0x0,0x80449000] size=0x80449000 avail=0x80449000 max_avail=0x80449000 Block: [0x81000000,0x8145d000] size=0x45d000 avail=0x45d000 max_avail=0x8044900 Block: [0xa0000000,0xffffffff] size=0x5fffffff avail=0x5fffffff max_avail=0x5ff => mem_size=3767164927 (3592 MB) / mem_avail=3767164927 (3592 MB) How are the above blocks being allocated as io memory?
What you see are the available I/O memory blocks, and not allocated ones. When initializing the allocator, it simply takes the whole address space and removes the RAM regions from it. To limit the usage of corresponding I/O memory requested at core, it is necessary to implement a related policy on the session establishment level anyway. Therefore, there is no restriction and additional knowledge hard-coded into the I/O memory allocator of core with respect to valid I/O memory regions anymore.
In prior releases (the "good-old-days"), a Native_region was declared to exactly define the regions of physical memory that were to be tagged as io memory. There appears to be no equivalent in 17.02. What am I missing?
An equivalent to `Native_region` is the `Memory_region`. In contrast to the former one it describes memory regions with page granularity in general, either physical or virtual ones. Moreover, it includes alignment checks, printing functionality and an array implementation, thereby limiting the repetitive code, where board specific devices memory descriptions and RAM regions were described.
I hope the new release does not hurt too much. Unfortunately, there will be more changes regarding base-hw in the next release, when the core transformation gets completed. But, analogue to the base API changes, we hope to have a sustainable base afterwards. Anyway, sorry for the inconvenience.
Best regards Stefan
Bob
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
-
Bob Stewart -
Stefan Kalkowski