Moving from 16.11 to 17.02 with base-hw kernel

[Bob Stewart]

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

[Stefan Kalkowski]

Hi Bob

Post by Bob Stewart
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.

Post by Bob Stewart
The console log from the boot process (attached) shows some strange
:io_mem_alloc: Allocator 0x910d012c
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.

Post by Bob Stewart
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

Post by Bob Stewart
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
https://lists.sourceforge.net/lists/listinfo/genode-main

[Bob Stewart]

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" <***@genode-labs.com> wrote:










Hi Bob

Post by Bob Stewart
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.

Post by Bob Stewart
The console log from the boot process (attached) shows some strange
:io_mem_alloc: Allocator 0x910d012c
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.

Post by Bob Stewart
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

Post by Bob Stewart
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
https://lists.sourceforge.net/lists/listinfo/genode-main