Moving from 16.11 to 17.02 with base-hw kernel

[Stefan Kalkowski]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 

-- 
Stefan Kalkowski
Genode Labs

https://github.com/skalk · http://genode.org/