On Wed Jan 20, 2016 at 16:40:38 +0100, Paul Boddie wrote:
On Wednesday 20. January 2016 00.13.58 Adam Lackorzynski wrote:
On Mon Jan 18, 2016 at 16:45:58 +0100, Paul Boddie wrote:
In that case, I wanted to prevent a package from being automatically built (the intervm package that seems to be part of the virtualisation emphasis of that work), and ultimately chose to just delete it from the pkg directory. Maybe there's a cleaner way of managing this, though.
Cleaner I don't know but touch l4/pkg/name/broken is at least less destructive.
OK. That's good to know. (Of course, the version control system doesn't forget what was there, anyway.)
Anyway, running the above command with all dependencies compiled and with x86- fb (and x86-legacy.devs) files in the path gives an error like this...
Ned: loading file: 'rom/x86-fb.cfg' IO | Io service IO | Find root Pointer IO | ACPI Error: Could not map memory at 0x000E0000 for length 131072 (20121018/tbxfroot-286) IO | Find root Pointer: 0 IO | Ready. Waiting for request. mag | Hello from MAG fbdrv | Trying execution of ``set VBE mode'' using x86emu fbdrv | L4Re[rm]: unhandled read page fault at 0xfd0 pc=0x1007d49 fbdrv | L4Re: unhandled exception: pc=0x1007d49 (pfa=fd4) fbdrv | L4Re: Global::l4re_aux->ldr_flags=0
I still get this. More details below...
...which probably suggests that I really should be using something other than this x86-related stuff. Does anyone have any suggestions, or am I doing something that no-one thought sensible?
The x86-fb.cfg file is missing some bit for ux here. Please change local fbdrv_fb = l:new_channel(); to local fbdrv_fb = L4.Env.vesa;
I'll fix that accordingly.
I've changed this.
Again, looking at that MIPS32 port was somewhat informative, since there appears to be a special mips-fb.cfg file and related definitions, so I was expecting something like ux-fb.cfg. I guess I don't really have a sufficient overview of the relationships between the different components, however.
There's not really a difference between ux and x86. The difference is in the platform, i.e. x86 is running on x86-standard-hardware while ux is running on Linux. But, for the framebuffer this isn't even the real difference because the framebuffer can also already be set up before L4 runs, e.g. by GRUB. Or, it isn't which means there needs to be someone doing it, and that's where fb-drv comes into play. However, in the ux case, the framebuffer is already there, so we can just use it by taking L4.Env.vesa instead of launching fb-drv to configure it.
I think I understand. I've been playing with some bare-metal programs on a MIPS32 platform (hence the interest in that port), and it makes sense that something must first set up the framebuffer and make it available at a certain region of memory. I suppose that once the region is configured, it can be presented to a user space component and nothing privileged ever need bother with it again.
Yes, very correct.
Anyway, after fixing up my Makeconf.boot file to use the necessary paths and options...
ux: MODULE_SEARCH_PATH += $(L4DIR_ABS)/../kernel/fiasco/mybuild ux: MODULE_SEARCH_PATH += $(L4DIR_ABS)/conf/examples ux: MODULE_SEARCH_PATH += $(L4DIR_ABS)/pkg/io/io/config UX_OPTIONS = -m 128 UX_GFX = 800x600@24 UX_GFX_CMD = $(L4DIR_ABS)/../kernel/fiasco/mybuild/ux_con
...I start UX using the following command:
make O=mybuild ux E=x86-fb-example MODULES_LIST=conf/examples/x86-fb.list
Then I get the following log information:
Well, I probably forgot to mention, do not start fb-drv.
MOE: Starting: rom/ned rom/x86-fb.cfg MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/x86-fb.cfg' IO | Io service IO | Find root Pointer IO | ACPI Error: Could not map memory at 0x000E0000 for length 131072 (20121018/tbxfroot-286) IO | Find root Pointer: 0 IO | Ready. Waiting for request. fbdrv | Trying execution of ``set VBE mode'' using x86emu fbdrv | L4Re[rm]: unhandled read page fault at 0xfd0 pc=0x1007d49 fbdrv | L4Re: unhandled exception: pc=0x1007d49 (pfa=fd0) fbdrv | L4Re: Global::l4re_aux->ldr_flags=0 mag | Hello from MAG mag | mapped frame buffer at 0x400000 mag | View::Info: mag | flags: 0 mag | size: 800x600 mag | pos: 0x0 mag | bytes_per_line: 2400 mag | buffer_offset: 0 mag | RGBA(3):8(16):8(8):8(0):0(0) mag | memory 0x400000 - 0x800000 mag | Plugin: Mag_client service started mag | Plugin: Frame-buffer service started mag | L4INPUT native mode activated mag | L4INPUT: !!! W A R N I N G !!! mag | L4INPUT: Please, do not use Fiasco's "-esc" with L4INPUT. mag | L4INPUT: !!! W A R N I N G !!! mag | /home/paulb/L4/src/l4/pkg/input/lib/src/init.c:110: failed l4input_internal_i8042_init(): -16 spectrum| x:640 y:480 bit/pixel:24 bytes/line:1920 spectrum| L4Re[rm]: unhandled write page fault at 0x4e1000 pc=0x10011b0 spectrum| L4Re: unhandled exception: pc=0x10011b0 (pfa=4e1002) spectrum| L4Re: Global::l4re_aux->ldr_flags=0
It looks like fbdrv fails in some way, and although IO complains about mapping memory, I interpret that as being tangential to this particular situation. On screen, the console is opened, and within it there is something resembling a window, with a light grey horizontal strip across the top of a dark rectangular region.
Ok, if there's something on the screen like this, this sounds like a mismatch in the graphics config path somewhere, try 800x600@16 or 800x600@32. For the page-fault I don't know right away, is it gone when not starting fb-drv? I tried it a few days back and it worked for me.
Sorry if this is all trivial stuff that I should have figured out myself! And thanks for the guidance so far. :-)
Nah, I'd not call this exactly trivial :)
Adam