Fiasco-OC.UX, ux_con and the framebuffer examples
paul at boddie.org.uk
Wed Jan 20 16:40:38 CET 2016
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
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
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:
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
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
Sorry if this is all trivial stuff that I should have figured out myself! And
thanks for the guidance so far. :-)
More information about the l4-hackers