I thought rebooting computer as soon has coming to boot line was for old low memories computer only, but I get it with nova.iso burnt on a CD on my Core 2 Duo, 2 GB (well 3 GB, but 2 Gb memory stick recognized as only 1 Gb + one other 1 Gb).
Capture log with null-modem RS232:
Bender: Hello World. Need 05df2000 bytes to relocate modules. Relocating to 7980d000: Copying 483168 bytes... Copying 460412 bytes... Copying 19947520 bytes... Copying 256000 bytes... Copying 552960 bytes... Copying 9390080 bytes... Copying 3553280 bytes... Copying 293864 bytes... Copying 93356 bytes... Copying 404216 bytes... Copying 435168 bytes... Copying 513708 bytes... Copying 422696 bytes... Copying 501760 bytes... Copying 876148 bytes... Copying 93612 bytes... Copying 303800 bytes... Copying 7323460 bytes... Copying 5039116 bytes... Copying 4994372 bytes... Copying 34148 bytes... Copying 229812 bytes... Copying 176200 bytes... Copying 157940 bytes... Copying 23572 bytes... Copying 1078412 bytes... Copying 616068 bytes... Copying 26033700 bytes... Copying 3222864 bytes... Copying 558540 bytes... Copying 434872 bytes... Copying 51200 bytes... Copying 879773 bytes... Copying 582 bytes... Copying 19768 bytes... Copying 94460 bytes... Copying 418916 bytes... Copying 478944 bytes... Copying 164608 bytes... Copying 457964 bytes... Copying 412840 bytes... Copying 544356 bytes... Copying 1253468 bytes... Copying 407104 bytes... Copying 453048 bytes... Copying 607380 bytes... Copying 419008 bytes... Copying 448912 bytes... Copying 381588 bytes... Copying 412840 bytes... Copying 411736 bytes... Copying 534440 bytes... Copying 9589 bytes... Copying 909276 bytes... Copying 114820 bytes...
computer reboots here
paul@...445...:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping : 6 microcode : 0x44 cpu MHz : 1860.497 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow dtherm bugs : bogomips : 3720.99 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping : 6 microcode : 0x44 cpu MHz : 1860.497 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow dtherm bugs : bogomips : 3721.29 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
paul@...445...:~$ cat /proc/meminfo MemTotal: 2041768 kB
Hello Paul,
On Tue, Sep 20, 2016 at 08:54:22PM -0400, Paul Dufresne wrote:
I thought rebooting computer as soon has coming to boot line was for old low memories computer only, but I get it with nova.iso burnt on a CD on my Core 2 Duo, 2 GB (well 3 GB, but 2 Gb memory stick recognized as only 1 Gb + one other 1 Gb).
Capture log with null-modem RS232:
Bender: Hello World. 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@...445...:~$ 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"?
Greets
2016-09-21 8:20 GMT-04:00 Christian Helmuth <christian.helmuth@...1...>:
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@...445...:~$ 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 00100000-7f5ffbff : System RAM 01000000-015cb5d4 : Kernel code 015cb5d5-01b10aff : Kernel data 01c67000-01d34fff : Kernel bss 7f5ffc00-7f601bff : ACPI Non-volatile Storage 7f601c00-7f603bff : RAM buffer 7f603c00-7fffffff : reserved 7f800000-7ff7ffff : 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<void *>(&PAGE_0), 0, PAGE_SIZE); memset (reinterpret_cast<void *>(&PAGE_1), ~0u, PAGE_SIZE); for (void (**func)() = &CTORS_G; func != &CTORS_E; (*func++)()) ; Hip::build (mbi); for (void (**func)() = &CTORS_C; func != &CTORS_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<mword>(&GIT_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)() = &CTORS_C; func != &CTORS_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.
But I seems to have problems on first file compiled when using gcc v6:
In file included from ../src/acpi.cpp:28:0: ../include/acpi_rsdt.hpp:45:26: error: flexible array member in union uint32 rsdt[]; ^ ../include/acpi_rsdt.hpp:46:26: error: flexible array member in union uint64 xsdt[];
This was freshly downloaded zip file from HEAD ( https://github.com/udosteinberg/NOVA ).
Reading "I.e., flexible array members may be defined only in structures, not in unions." In C (don't know about C++). They seems to suggest it should be replaced by zero-sized array (was not aware of that before).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548 https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
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
<genode-dir>/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] <genode-dir>tool/boot/README [1] <genode-dir>contrib/nova-<hash>/src/kernel/nova/src/console_serial.cpp [2] <genode-dir>/tool/run/boot_dir/sel4
On 22.09.2016 00:48, Paul Dufresne wrote:
2016-09-21 8:20 GMT-04:00 Christian Helmuth <christian.helmuth@...1...>:
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@...445...:~$ 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 00100000-7f5ffbff : System RAM 01000000-015cb5d4 : Kernel code 015cb5d5-01b10aff : Kernel data 01c67000-01d34fff : Kernel bss 7f5ffc00-7f601bff : ACPI Non-volatile Storage 7f601c00-7f603bff : RAM buffer 7f603c00-7fffffff : reserved 7f800000-7ff7ffff : 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<void *>(&PAGE_0), 0, PAGE_SIZE); memset (reinterpret_cast<void *>(&PAGE_1), ~0u, PAGE_SIZE); for (void (**func)() = &CTORS_G; func != &CTORS_E; (*func++)()) ; Hip::build (mbi); for (void (**func)() = &CTORS_C; func != &CTORS_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<mword>(&GIT_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)() = &CTORS_C; func != &CTORS_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
Hello again,
On Wed, Sep 21, 2016 at 07:18:15PM -0400, Paul Dufresne wrote:
This was freshly downloaded zip file from HEAD ( https://github.com/udosteinberg/NOVA ).
For Genode, the NOVA version defined in nova.port and prepared by
$(GENODE_DIR)/tool/ports/prepare_port nova
is mandatory and you will run into issues after the kernel bootstrap. Also, the upstream version is rather old (last commit from Jul 2, 2014).
Regards
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.
Well, I have remaster the 16.08 nova.iso to remove bender and put nova as the kernel. Still rebooting as soon as the boot line appears on the screen (did not connect other computer to capture serial port).
Will try install Genode chain and try to generate simple run image with it.
Ok, I think I am pretty much doing things almost like you guys now.
I figure out the line that make my computer reboot : in ~/genode/contrib/nova-8a5f311017becf7becd1dc325a388036b76215fc/src/kernel/nova/src/init.cpp
/**** extern "C" INIT REGPARM (1) void init (mword mbi) {
// Setup 0-page and 1-page memset (reinterpret_cast<void *>(&PAGE_0), 0, PAGE_SIZE); memset (reinterpret_cast<void *>(&PAGE_1), ~0u, PAGE_SIZE);
// Console::print ("paul1"); for (void (**func)() = &CTORS_G; func != &CTORS_E; (*func++)()) ; while(1); ****/
with the while(1) before the for line, the computer 'hang'. with the while(1) after, it reboots.
Now I guess I need help to figure out which function (where are they anyway?).
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.00001)) PROVIDE (CTORS_C = .); KEEP (SORT_BY_INIT_PRIORITY(*)(.init_array.65533 .ctors.00002)) PROVIDE (CTORS_G = .); KEEP (SORT_BY_INIT_PRIORITY(*)(.init_array.* .ctors.*)) KEEP (*(.init_array .ctors)) PROVIDE (CTORS_E = .); } : kern
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.
Hello Paul,
I like the approach of narrowing the issue with 'while(1);' and suggest to go further (see below).
On Thu, Sep 22, 2016 at 10:02:51PM -0400, Paul Dufresne wrote:
/**** extern "C" INIT REGPARM (1) void init (mword mbi) {
// Setup 0-page and 1-page memset (reinterpret_cast<void *>(&PAGE_0), 0, PAGE_SIZE); memset (reinterpret_cast<void *>(&PAGE_1), ~0u, PAGE_SIZE);// Console::print ("paul1"); for (void (**func)() = &CTORS_G; func != &CTORS_E; (*func++)()) ; while(1); ****/
I'd move the 'while(1);' into the for loop like follows.
enum { STOP_AT = 0U }; unsigned i = 0; for (void (**func)() = &CTORS_C; func != &CTORS_G; ) { if (i == STOP_AT) while (1) ; ; (*func++)(); ++i; }
In my case the ctors table has only 2 entries.
Greets
2016-09-23 4:47 GMT-04:00 Christian Helmuth <christian.helmuth@...1...>:
Hello Paul,
I like the approach of narrowing the issue with 'while(1);' and suggest to go further (see below).
On Thu, Sep 22, 2016 at 10:02:51PM -0400, Paul Dufresne wrote:
/**** extern "C" INIT REGPARM (1) void init (mword mbi) {
// Setup 0-page and 1-page memset (reinterpret_cast<void *>(&PAGE_0), 0, PAGE_SIZE); memset (reinterpret_cast<void *>(&PAGE_1), ~0u, PAGE_SIZE);// Console::print ("paul1"); for (void (**func)() = &CTORS_G; func != &CTORS_E; (*func++)()) ; while(1); ****/
I'd move the 'while(1);' into the for loop like follows.
enum { STOP_AT = 0U }; unsigned i = 0; for (void (**func)() = &CTORS_C; func != &CTORS_G; ) { if (i == STOP_AT) while (1) ; ; (*func++)(); ++i; }In my case the ctors table has only 2 entries.
Greets
With STOP_AT == 1 it hangs, With STOP_AT == 2 it reboots.
I think I will mail you my hypervisor file (now compiled with STOP_AT == 1) in case you want to check it.
Hello Paul, On Fri, Sep 23, 2016 at 09:47:49AM -0400, Paul Dufresne wrote:
With STOP_AT == 1 it hangs,
This mean the UART initialization in Console_serial::Console_serial() succeeds.
With STOP_AT == 2 it reboots.
So your reboot is induced by Console_vga::Console_vga() in src/console_vga.cpp. You may now proceed with moving 'while(1);' into the constructor function.
Greets
2016-09-23 14:20 GMT-04:00 Christian Helmuth <christian.helmuth@...1...>: ...
So your reboot is induced by Console_vga::Console_vga() in src/console_vga.cpp. You may now proceed with moving 'while(1);' into the constructor function.
... Good! So it seems to be that line in console_vga.cpp: Pd::kern.Space_mem::insert (Pd::kern.quota, HV_GLOBAL_FBUF, 0, Hpt::HPT_NX | Hpt::HPT_G | Hpt::HPT_UC | Hpt::HPT_W | Hpt::HPT_P, 0xb9000);
I believe 0xb9000 is supposed to be text mode EGA/VGA page 2. Anyway....
in include/space_mem.hpp: the insert become: ALWAYS_INLINE inline void insert (Quota "a, mword virt, unsigned o, mword attr, Paddr phys) { hpt.update (quota, virt, o, phys, attr); } I am beginning to ask myself if I was not expecting the size of a color text video page of 0x80x0x25 for quota...
Hpt constructor seems to inherit from pte
pte.cpp have an update template: template <typename P, typename E, unsigned L, unsigned B, bool F> bool Pte<P,E,L,B,F>::update (Quota "a, E v, mword o, E p, mword a, Type t) { unsigned long l = o / B, n = 1UL << o % B, s;
P *e = walk (quota, v, l, t == TYPE_UP);
if (!e) return false;
if (a) { p |= P::order (o % B) | (l ? P::PTE_S : 0) | a; s = 1UL << (l * B + PAGE_BITS); } else p = s = 0;
bool flush_tlb = false;
for (unsigned long i = 0; i < n; e[i].val = p, i++, p += s) { *********************** I begin to feel lost... might try to put my while(1) in that but I really not sure I am on the right trail.
Looks like I was ok in my previous post.
In fact I seem to have isolated to a line in pte.cpp in function walk: template <typename P, typename E, unsigned L, unsigned B, bool F> P *Pte<P,E,L,B,F>::walk (Quota "a, E v, unsigned long n, bool a) { unsigned long l = L;
for (P *p, *e = static_cast<P *>(this);; e = static_cast<P *>(Buddy::phys_to_ptr (e->addr())) + (v >> (--l * B + PAGE_BITS) & ((1UL << B) - 1))) { //while(1); if (l == n) return e;
if (!e->val) {
if (!a) return nullptr; while(1); if (!e->set (0, Buddy::ptr_to_phys (p = new (quota) P) | (l == L ? 0 : P::PTE_N))) Pte::destroy(p, quota); //while(1); } } }
So I believe the culprit ine is: if (!e->set (0, Buddy::ptr_to_phys (p = new (quota) P) | (l == L ? 0 : P::PTE_N))) Pte::destroy(p, quota);
Guess I need to take time to examine, try to think and see if I can go further.
On Fri, Sep 23, 2016 at 04:10:30PM -0400, Paul Dufresne wrote:
I begin to feel lost... might try to put my while(1) in that but I really not sure I am on the right trail.
It's just a guess but it might be your CPU does not support a feature used in the page table that is set up for VGA. You could try to disable VGA by providing novga on the kernel commandline.
I now think the problem is with the expression: p = new (quota) P
Will try the novga, even if I have doubt nova can react to cmdline arguments, because I belive it ask no information to the boot loader (including not asking the command line arguments).
About not reading any info from the bootloader, since we(now even me) use bender, this is bender that ask info the boot loader, and I will not be surprised if it give it to the nova hypervisor that knows how to read the command line, the list of modules, and the memory map if it is given to it.
But then again, the constructors is called before Hip::build (mbi); in nova init, which reads command line. So novga cannot have effect yet.
That said, if Console_VGA constructor needs to do new, it make sense to me it should have read the memory map before to not allocate reserved memory. Right?
So I am beginning to think that MAYBE we should call the UART constructor before Hip::build, and the VGA_Console after HIB::Build.
Hello,
On Fri, Sep 23, 2016 at 07:21:33PM -0400, Paul Dufresne wrote:
But then again, the constructors is called before Hip::build (mbi); in nova init, which reads command line. So novga cannot have effect yet.
If this would be true the following code makes no sense to me.
src/console_vga.cpp:29
if (Cmdline::novga) return;
You could still just put 'return;' before line 29 to prevent VGA initialization. On the other hand, this does not avoid running into the same issue later during bootstrap. I'm curious what you'll find out about the 'new (quota)' suspicion.
Regards
Well, now that you mentions things that does not seems to make sense in Console_VGA constructor, it ends with: enable() which I would presume is enable interruptions (did not check).
But Idt::build(); (Interrupt Descriptor Table) will be called only after Hip::build too in init.
Sorry, my mistake. that's Console::enable in console.hpp which seems to have nothing with interruptions.
-
Alexander Boettcher -
Christian Helmuth -
Paul Dufresne