Hi Lluis, Have pretty much the same as you sad - can't load both qemu for unknown memory address, neither for grub2 for Ubuntu 13.04, but it compiles well. I`ll ask what happens tomorrow on upcoming russian Fiasco/Virtualization school with Bjorn Doebel at al. and tell you what happens. Probably the best choose is Qemu emulator, if you don't have already written software, not to reload system every time you need. I compiled with i386 option both FiascoOC/L4RE and them works well. just as here: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2011/004894.html http://os.inf.tu-dresden.de/pipermail/l4-hackers/2011/http://os.inf.tu-dresden.de/pipermail/l4-hackers/2011/004894.html 004894.htmlhttp://os.inf.tu-dresden.de/pipermail/l4-hackers/2011/004894.html I have 4.7 compiler too.
Best wishes,
2013/8/5 l4-hackers-request@os.inf.tu-dresden.de
Send l4-hackers mailing list submissions to l4-hackers@os.inf.tu-dresden.de
To subscribe or unsubscribe via the World Wide Web, visit http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers or, via email, send a message with subject or body 'help' to l4-hackers-request@os.inf.tu-dresden.de
You can reach the person managing the list at l4-hackers-owner@os.inf.tu-dresden.de
When replying, please edit your Subject line so it is more specific than "Re: Contents of l4-hackers digest..."
Today's Topics:
- Unable to boot Fiasco.OC on amd64 (Llu?s Vilanova)
Message: 1 Date: Sun, 04 Aug 2013 22:44:24 +0300 From: Llu?s Vilanova vilanova@ac.upc.edu To: l4-hackers@os.inf.tu-dresden.de Subject: Unable to boot Fiasco.OC on amd64 Message-ID: 87eha95jhj.fsf@fimbulvetr.bsc.es Content-Type: text/plain; charset="us-ascii"
Hi there,
After having to play with the load addresses of both fiasco and some of the modules [1], I've been able to boot fiasco, but only to find it chokes on some assertion, immediately following a pager warning (see error.jpg screenshot).
Sorry for using a screenshot, but I've been unable to make the serial console work, so no copy&paste is available.
As I'm new to L4, I don't know if the error is due to my changes or due to some other mis-configuration on the boot process. See the attached grub2.txt for the GRUB2 entries I've tried (the error corresponds to the first entry).
I'm using the l4re-core-2013060718 tarball, all compiled on a debian testing (gcc 4.7.3).
Any help on the boot or the serial console support is much appreciated.
Thanks a lot, Lluis
[1] To avoid some region overlaps, see attached l4.patch, and memory.jpg for the memory range configuration of the machine.
Hey, thanks for the response and the offer to keep me posted on the problem :)
Last time I tried with QEMU the system was working perfectly fine (with "make qemu"). Unfortunately, I need to run it on a real machine to get some performance measurements.
Thanks, Lluis
Иван Филиппов writes:
Hi Lluis, Have pretty much the same as you sad - can't load both qemu for unknown memory address, neither for grub2 for Ubuntu 13.04, but it compiles well. I`ll ask what happens tomorrow on upcoming russian Fiasco/Virtualization school with Bjorn Doebel at al. and tell you what happens. Probably the best choose is Qemu emulator, if you don't have already written software, not to reload system every time you need. I compiled with i386 option both FiascoOC/L4RE and them works well. just as here: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2011/004894.htmlhttp://os.i... dresden.de/pipermail/l4-hackers/2011/ 004894.html I have 4.7 compiler too.
Best wishes,
Send l4-hackers mailing list submissions to l4-hackers@os.inf.tu-dresden.de
To subscribe or unsubscribe via the World Wide Web, visit http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers or, via email, send a message with subject or body 'help' to l4-hackers-request@os.inf.tu-dresden.de
You can reach the person managing the list at l4-hackers-owner@os.inf.tu-dresden.de
When replying, please edit your Subject line so it is more specific than "Re: Contents of l4-hackers digest..."
Today's Topics:
1. Unable to boot Fiasco.OC on amd64 (Llu?s Vilanova)
----------------------------------------------------------------------
Message: 1 Date: Sun, 04 Aug 2013 22:44:24 +0300 From: Llu?s Vilanova <vilanova@ac.upc.edu> To: l4-hackers@os.inf.tu-dresden.de Subject: Unable to boot Fiasco.OC on amd64 Message-ID: <87eha95jhj.fsf@fimbulvetr.bsc.es> Content-Type: text/plain; charset="us-ascii"
Hi there,
After having to play with the load addresses of both fiasco and some of the modules [1], I've been able to boot fiasco, but only to find it chokes on some assertion, immediately following a pager warning (see error.jpg screenshot).
Sorry for using a screenshot, but I've been unable to make the serial console work, so no copy&paste is available.
As I'm new to L4, I don't know if the error is due to my changes or due to some other mis-configuration on the boot process. See the attached grub2.txt for the GRUB2 entries I've tried (the error corresponds to the first entry).
I'm using the l4re-core-2013060718 tarball, all compiled on a debian testing (gcc 4.7.3).
Any help on the boot or the serial console support is much appreciated.
Thanks a lot, Lluis
[1] To avoid some region overlaps, see attached l4.patch, and memory.jpg for the memory range configuration of the machine.
On Mon Aug 05, 2013 at 01:22:17 +0300, Lluís Vilanova wrote:
Hey, thanks for the response and the offer to keep me posted on the problem :)
Last time I tried with QEMU the system was working perfectly fine (with "make qemu"). Unfortunately, I need to run it on a real machine to get some performance measurements.
Use grub1 is a quick tip, possibly via netboot (pxegrub). A short look at current grub2 shows me some interesting and likely changed behaviour but I didn't check further right now.
https://os.inf.tu-dresden.de/~adam/grub/0.97/
Adam
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 01:22:17 +0300, Lluís Vilanova wrote:
Hey, thanks for the response and the offer to keep me posted on the problem :)
Last time I tried with QEMU the system was working perfectly fine (with "make qemu"). Unfortunately, I need to run it on a real machine to get some performance measurements.
Use grub1 is a quick tip, possibly via netboot (pxegrub). A short look at current grub2 shows me some interesting and likely changed behaviour but I didn't check further right now.
I chainloaded into a grub1 installation on another partition and everything works like a charm.
Just curious, what exactly has changed on grub2? Did the multiboot features change?
Thanks, Lluis
On Mon Aug 05, 2013 at 14:03:48 +0300, Lluís Vilanova wrote:
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 01:22:17 +0300, Lluís Vilanova wrote:
Hey, thanks for the response and the offer to keep me posted on the problem :)
Last time I tried with QEMU the system was working perfectly fine (with "make qemu"). Unfortunately, I need to run it on a real machine to get some performance measurements.
Use grub1 is a quick tip, possibly via netboot (pxegrub). A short look at current grub2 shows me some interesting and likely changed behaviour but I didn't check further right now.
I chainloaded into a grub1 installation on another partition and everything works like a charm.
Just curious, what exactly has changed on grub2? Did the multiboot features change?
It looked to me as there would be an overlap between modules and the bootstrap binary itself which fortunately was caught. Needs more investigation.
Adam
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 14:03:48 +0300, Lluís Vilanova wrote:
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 01:22:17 +0300, Lluís Vilanova wrote:
Hey, thanks for the response and the offer to keep me posted on the problem :)
Last time I tried with QEMU the system was working perfectly fine (with "make qemu"). Unfortunately, I need to run it on a real machine to get some performance measurements.
Use grub1 is a quick tip, possibly via netboot (pxegrub). A short look at current grub2 shows me some interesting and likely changed behaviour but I didn't check further right now.
I chainloaded into a grub1 installation on another partition and everything works like a charm.
Just curious, what exactly has changed on grub2? Did the multiboot features change?
It looked to me as there would be an overlap between modules and the bootstrap binary itself which fortunately was caught. Needs more investigation.
Yes, that's indeed what I found.
Thanks, Lluis
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 01:22:17 +0300, Lluís Vilanova wrote:
Hey, thanks for the response and the offer to keep me posted on the problem :)
Last time I tried with QEMU the system was working perfectly fine (with "make qemu"). Unfortunately, I need to run it on a real machine to get some performance measurements.
Use grub1 is a quick tip, possibly via netboot (pxegrub). A short look at current grub2 shows me some interesting and likely changed behaviour but I didn't check further right now.
Oh! I forgot to add that everything but the serial console works. I suppose I'll have to manually copy any timing numbers I print from my experiments.
Just in case, here's my grub1 entry:
title L4 (original) root (hd1,0) kernel /l4-orig/bootstrap -serial module /l4-orig/fiasco -serial_esc -comspeed 115200 -comport 0 module /l4-orig/l4f/sigma0 module /l4-orig/l4f/moe --init=rom/hello module /l4-orig/l4f/l4re module /l4-orig/l4f/hello
Thanks, Lluis
On Mon Aug 05, 2013 at 14:08:40 +0300, Lluís Vilanova wrote:
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 01:22:17 +0300, Lluís Vilanova wrote:
Hey, thanks for the response and the offer to keep me posted on the problem :)
Last time I tried with QEMU the system was working perfectly fine (with "make qemu"). Unfortunately, I need to run it on a real machine to get some performance measurements.
Use grub1 is a quick tip, possibly via netboot (pxegrub). A short look at current grub2 shows me some interesting and likely changed behaviour but I didn't check further right now.
Oh! I forgot to add that everything but the serial console works. I suppose I'll have to manually copy any timing numbers I print from my experiments.
Just in case, here's my grub1 entry:
title L4 (original) root (hd1,0) kernel /l4-orig/bootstrap -serial module /l4-orig/fiasco -serial_esc -comspeed 115200 -comport 0 module /l4-orig/l4f/sigma0 module /l4-orig/l4f/moe --init=rom/hello module /l4-orig/l4f/l4re module /l4-orig/l4f/hello
That looks ok and should just work. Does it work under Qemu? Is it a plain normal serial? Is it working in Grub?
Adam
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 14:08:40 +0300, Lluís Vilanova wrote:
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 01:22:17 +0300, Lluís Vilanova wrote:
Hey, thanks for the response and the offer to keep me posted on the problem :)
Last time I tried with QEMU the system was working perfectly fine (with "make qemu"). Unfortunately, I need to run it on a real machine to get some performance measurements.
Use grub1 is a quick tip, possibly via netboot (pxegrub). A short look at current grub2 shows me some interesting and likely changed behaviour but I didn't check further right now.
Oh! I forgot to add that everything but the serial console works. I suppose I'll have to manually copy any timing numbers I print from my experiments.
Just in case, here's my grub1 entry:
title L4 (original) root (hd1,0) kernel /l4-orig/bootstrap -serial module /l4-orig/fiasco -serial_esc -comspeed 115200 -comport 0 module /l4-orig/l4f/sigma0 module /l4-orig/l4f/moe --init=rom/hello module /l4-orig/l4f/l4re module /l4-orig/l4f/hello
That looks ok and should just work. Does it work under Qemu? Is it a plain normal serial? Is it working in Grub?
It works flawlessly under QEMU. The Grub menu also shows up on the serial console of the real machine, but once bootstrap is started, only the screen works.
In case it might shed some light, I have this on the "/etc/default/grub" file of the real machine (Grub from Debian testing):
GRUB_TERMINAL=console GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
Thanks, Lluis
On Tue Aug 06, 2013 at 12:55:41 +0300, Lluís Vilanova wrote:
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 14:08:40 +0300, Lluís Vilanova wrote:
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 01:22:17 +0300, Lluís Vilanova wrote:
Hey, thanks for the response and the offer to keep me posted on the problem :)
Last time I tried with QEMU the system was working perfectly fine (with "make qemu"). Unfortunately, I need to run it on a real machine to get some performance measurements.
Use grub1 is a quick tip, possibly via netboot (pxegrub). A short look at current grub2 shows me some interesting and likely changed behaviour but I didn't check further right now.
Oh! I forgot to add that everything but the serial console works. I suppose I'll have to manually copy any timing numbers I print from my experiments.
Just in case, here's my grub1 entry:
title L4 (original) root (hd1,0) kernel /l4-orig/bootstrap -serial module /l4-orig/fiasco -serial_esc -comspeed 115200 -comport 0 module /l4-orig/l4f/sigma0 module /l4-orig/l4f/moe --init=rom/hello module /l4-orig/l4f/l4re module /l4-orig/l4f/hello
That looks ok and should just work. Does it work under Qemu? Is it a plain normal serial? Is it working in Grub?
It works flawlessly under QEMU. The Grub menu also shows up on the serial console of the real machine, but once bootstrap is started, only the screen works.
That all looks good to me, and that it works in Qemu also indicates that it's ok. Could you maybe try another machine to see if it works there?
Adam
Adam Lackorzynski writes:
On Tue Aug 06, 2013 at 12:55:41 +0300, Lluís Vilanova wrote:
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 14:08:40 +0300, Lluís Vilanova wrote:
Adam Lackorzynski writes:
On Mon Aug 05, 2013 at 01:22:17 +0300, Lluís Vilanova wrote:
Hey, thanks for the response and the offer to keep me posted on the problem :)
Last time I tried with QEMU the system was working perfectly fine (with "make qemu"). Unfortunately, I need to run it on a real machine to get some performance measurements.
Use grub1 is a quick tip, possibly via netboot (pxegrub). A short look at current grub2 shows me some interesting and likely changed behaviour but I didn't check further right now.
Oh! I forgot to add that everything but the serial console works. I suppose I'll have to manually copy any timing numbers I print from my experiments.
Just in case, here's my grub1 entry:
title L4 (original) root (hd1,0) kernel /l4-orig/bootstrap -serial module /l4-orig/fiasco -serial_esc -comspeed 115200 -comport 0 module /l4-orig/l4f/sigma0 module /l4-orig/l4f/moe --init=rom/hello module /l4-orig/l4f/l4re module /l4-orig/l4f/hello
That looks ok and should just work. Does it work under Qemu? Is it a plain normal serial? Is it working in Grub?
It works flawlessly under QEMU. The Grub menu also shows up on the serial console of the real machine, but once bootstrap is started, only the screen works.
That all looks good to me, and that it works in Qemu also indicates that it's ok. Could you maybe try another machine to see if it works there?
I don't have another machine to easily test it, sorry. For now I'll keep working with the monitor, since the machine has a remote console attached to it.
Thanks a lot for all your help.
Lluis
l4-hackers@os.inf.tu-dresden.de