Fiasco-OC.UX, ux_con and the framebuffer examples

[Adam Lackorzynski]

On Mon Jan 18, 2016 at 16:45:58 +0100, Paul Boddie wrote:
> On Monday 18. January 2016 00.33.57 Adam Lackorzynski wrote:
> > 
> > On Thu Jan 14, 2016 at 23:07:43 +0100, Paul Boddie wrote:
> > > 
> > > Copying the different x86-fb files into one of my existing
> > > MODULE_SEARCH_PATH directories did seem to resolve the above immediate
> > > error, however, but I then appear to need to build various drivers. This
> > > seems to require chasing dependencies as they are reported as missing by
> > > the build system, and that makes me wonder whether I've overlooked a
> > > command that recursively checks out all dependencies for a given
> > > component.
> > 
> > As of now there's no such tool that downloads components as required by
> > other components. However, there are subset definitions defined in
> > repomgr but they're coarse.
> 
> OK. I actually encountered a related situation when trying to build the MIPS32 
> port of Fiasco.OC that has been made available here:
> 
> https://github.com/MIPS/fiasco-l4re
> 
> 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.

> > > 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
> > > 
> > > ...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.
> 
> 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.

> > > (As mentioned last year on this list, I'm running everything under Debian
> > > on x86, and UX does work with the "hello" example.)
> > 
> > More generally, there's also some automatism. Add a
> > l4/conf/Makeconf.boot file (from l4/conf/Makeconf.boot.example) and add
> > a UX_GFX=800x600 at 24 statement, plus add the path to your kernel build to
> > MODULE_SEARCH_PATH.
> > Then a "make ux E=.." should suffice.
> 
> I did discover the Makeconf.boot file after the MIPS32 port documentation 
> mentioned it, and it occurred to me afterwards that this would offer a 
> shortcut or two.

Yes, that's why it's there :)





Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/