Re: Fiasco-OC.UX, ux_con and the framebuffer examples

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
-- 
Adam                 [email protected]
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/