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

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.

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:

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.

Sorry if this is all trivial stuff that I should have figured out myself! And 
thanks for the guidance so far. :-)

Paul