Fiasco-OC.UX, ux_con and the framebuffer examples
adam at os.inf.tu-dresden.de
Thu Jan 21 23:59:16 CET 2016
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
> 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 at 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
> 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 at 16 or
800x600 at 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 adam at os.inf.tu-dresden.de
More information about the l4-hackers