Re: Genode 16.08 nova.iso rebooting on real Core 2 Duo after relocating modules

[Paul Dufresne]

Oh well, I guess I get the very big picture.
As Nova is written in C++, not C, the code contains constructors that
somehow must be called
almost as the first thing the hypervisor do. It seems the compilers
make an array of function pointers
to constructors functions (pointing inside .text I presume) that it
puts inside a .ctors section of the .elf
file. Guess I need to use nm and/or readelf on the hypervisor file to know more.

--
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Genode 16.08 nova.iso rebooting on real Core 2 Duo after relocating modules

[Paul Dufresne]

I see the following in hypervisor.ld but it is beyond my understanding:
.init_array : AT (ADDR (.init_array) - OFFSET)
{
PROVIDE (CTORS_L = .);
KEEP (SORT_BY_INIT_PRIORITY(*)(.init_array.65534 .ctors.1))
PROVIDE (CTORS_C = .);
KEEP (SORT_BY_INIT_PRIORITY(*)(.init_array.65533 .ctors.2))
PROVIDE (CTORS_G = .);
KEEP (SORT_BY_INIT_PRIORITY(*)(.init_array.* .ctors.*))
KEEP (*(.init_array .ctors))
PROVIDE (CTORS_E = .);
} : kern

--
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Genode 16.08 nova.iso rebooting on real Core 2 Duo after relocating modules

[Alexander Boettcher]

Hello,

we use as a chained-boot loader bender[0], which relocates the boot
modules before the NOVA kernel actually starts. You may try to remove it
and see whether this changes things. For this you have to edit in

/tool/run/boot_dir/nova

the lines where bender is used and make the hypervisor the first entry.

Than recompile some simple setup like printf.run and start it on your
target machine. If you don't see any serial messages anymore, you may
have to add the i/o ports of your serial device manually to the NOVA
kernel source code [1]. Bender has also now a option 'norelocate' as
used for sel4 [2], which you may also try.

Cheers,

Alex.

[0] tool/boot/README
[1] contrib/nova-/src/kernel/nova/src/console_serial.cpp
[2] /tool/run/boot_dir/sel4

On 22.09.2016 00:48, Paul Dufresne wrote:
> 2016-09-21 8:20 GMT-04:00 Christian Helmuth 
> :
>>> Need 05df2000 bytes to relocate modules.
>>> Relocating to 7980d000:
>>> Copying 483168 bytes...
>> [...]
>>> Copying 114820 bytes...
>>
>> If my calculations from this output are correct the boot modules cover
>> RAM from 0x7980d000 to 0x7f5e9000. Maybe there's a collision in this
>> region?
>>
>>> paul@arcturus:~$ cat /proc/meminfo
>>> MemTotal:2041768 kB
>>
>> Could you please compare the region above against
>>
>>   cat /proc/iomem'
>>
>> and check if it fits completely into "System RAM"?
> Ehhh... At first I thought there was a problem... but i think it goes
> just before ACPI Non-volatile Storage
> 0010-7f5ffbff : System RAM
>   0100-015cb5d4 : Kernel code
>   015cb5d5-01b10aff : Kernel data
>   01c67000-01d34fff : Kernel bss
> 7f5ffc00-7f601bff : ACPI Non-volatile Storage
> 7f601c00-7f603bff : RAM buffer
> 7f603c00-7fff : reserved
>   7f80-7ff7 : Graphics Stolen Memory
> 
> It sure looks like a Nova bug (had time to load modules, but not to
> show Nova welcome message).
> In src/init I see:
> void init (mword mbi)
> {
> // Setup 0-page and 1-page
> memset (reinterpret_cast(_0), 0, PAGE_SIZE);
> memset (reinterpret_cast(_1), ~0u, PAGE_SIZE);
> for (void (**func)() = _G; func != _E; (*func++)()) ;
> Hip::build (mbi);
> for (void (**func)() = _C; func != _G; (*func++)()) ;
> // Now we're ready to talk to the world
> Console::print ("\fNOVA Microhypervisor v%d-%07lx (%s): %s %s [%s]\n",
> CFG_VER, reinterpret_cast(_VER), ARCH, __DATE__, __TIME__,
> COMPILER_STRING);
> Idt::build();
> Gsi::setup();
> Acpi::setup();
> Console_vga::con.setup();
> Keyb::init();
> }
> 
> I believe Hip::(build(mbr) reads the module, and I suppose do the
> relocations shown.
> 
> I am thinking about adding some Console::print inside the loop:
> for (void (**func)() = _C; func != _G; (*func++)()) ;
> which I barely understand as calling each functions in an array of
> Constructors (CTORS_C).
> 
> Wish I would knew where CTORS_C is defined, but I guess I need not to know.
> I am not so good with coding... so it might be just to the limit of my
> abilities to do and test that.
> 
> --
> ___
> genode-main mailing list
> genode-main@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 


-- 
Alexander Boettcher
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

--
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main

Re: Nova multiboot v.1 flags == 0 ???

[Christian Helmuth]

Hello Paul,

On Wed, Sep 21, 2016 at 08:12:38PM -0400, Paul Dufresne wrote:
> I think I have a problem with Nova multiboot specification.
[...]

Sorry but I currently have no time to read your details about the
Multiboot spec. Therefore, I'd like to ask you for a short summary of
the issue you experience.

Greets
-- 
Christian Helmuth
Genode Labs

https://www.genode-labs.com/ · https://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

--
___
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main