Another year, another look at Fiasco-OC! ;-)
I've been looking again at Fiasco-OC.UX and trying to make sense of the documentation. In particular, I'd like to be able to get the framebuffer examples working with the UX graphical console, but it isn't clear to me what I need to do.
One thing I discovered straight away was that I needed to provide the -F option as part of the UX_OPTIONS variable when running UX via make. For example:
cd src/l4 make O=mybuild ux E=hello MODULE_SEARCH_PATH=../kernel/fiasco/mybuild \ UX_OPTIONS='-G 800x600@24 -F ../kernel/fiasco/mybuild/ux_con'
I suspect that to run a framebuffer example, such as the one in src/l4/conf/examples/x86-fb.list, I need to specify E=x86-fb-example and specify the list file using MODULES_LIST:
make O=mybuild ux E=x86-fb-example \ MODULES_LIST=conf/examples/x86-fb.list \ MODULE_SEARCH_PATH=../kernel/fiasco/mybuild \ UX_OPTIONS='-G 800x600@24 -F ../kernel/fiasco/mybuild/ux_con'
But this naive attempt gives me the following:
Could not find 'x86-fb.cfg' with path '../kernel/fiasco/mybuild:/home/paulb/L4/src/l4/mybuild/bin/x86_prescott:...
I imagine that I need to more effectively specify paths to various things and to check that they even make sense in the context of the UX environment. Should I even be using this x86-related stuff?
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.
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?
(As mentioned last year on this list, I'm running everything under Debian on x86, and UX does work with the "hello" example.)
Thanks in advance,
Paul
P.S. I've also found that various links on l4re.org to things like the "getting started" details are broken. For example:
http://l4re.org/build.html -> http://l4re.org/doc/l4re_getting_started.html
Hi,
On Thu Jan 14, 2016 at 23:07:43 +0100, Paul Boddie wrote:
Another year, another look at Fiasco-OC! ;-)
I've been looking again at Fiasco-OC.UX and trying to make sense of the documentation. In particular, I'd like to be able to get the framebuffer examples working with the UX graphical console, but it isn't clear to me what I need to do.
One thing I discovered straight away was that I needed to provide the -F option as part of the UX_OPTIONS variable when running UX via make. For example:
cd src/l4 make O=mybuild ux E=hello MODULE_SEARCH_PATH=../kernel/fiasco/mybuild \ UX_OPTIONS='-G 800x600@24 -F ../kernel/fiasco/mybuild/ux_con'
I suspect that to run a framebuffer example, such as the one in src/l4/conf/examples/x86-fb.list, I need to specify E=x86-fb-example and specify the list file using MODULES_LIST:
make O=mybuild ux E=x86-fb-example \ MODULES_LIST=conf/examples/x86-fb.list \ MODULE_SEARCH_PATH=../kernel/fiasco/mybuild \ UX_OPTIONS='-G 800x600@24 -F ../kernel/fiasco/mybuild/ux_con'
But this naive attempt gives me the following:
Could not find 'x86-fb.cfg' with path '../kernel/fiasco/mybuild:/home/paulb/L4/src/l4/mybuild/bin/x86_prescott:...
I imagine that I need to more effectively specify paths to various things and to check that they even make sense in the context of the UX environment. Should I even be using this x86-related stuff?
That's ok this way. And yes, when doing all step by step you'll also need to specify all search paths.
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.
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.
(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@24 statement, plus add the path to your kernel build to MODULE_SEARCH_PATH. Then a "make ux E=.." should suffice.
P.S. I've also found that various links on l4re.org to things like the "getting started" details are broken. For example:
Thanks! I've fixed the 2 locations I've found to be wrong.
Adam
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.
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.
(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@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.
P.S. I've also found that various links on l4re.org to things like the
"getting started" details are broken. For example:
Thanks! I've fixed the 2 locations I've found to be wrong.
Great! Thanks for your help!
Paul
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@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
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
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
On Thursday 21. January 2016 23.59.16 Adam Lackorzynski wrote:
On Wed Jan 20, 2016 at 16:40:38 +0100, Paul Boddie wrote:
...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.
OK, I've commented out the following in x86-fb.cfg:
l:startv({ caps = { vbus = io_buses.fbdrv, fb = fbdrv_fb:svr(), }, log = { "fbdrv", "r" }, l4re_dbg = L4.Dbg.Warn, }, "rom/fb-drv");
And I removed the following line from x86-fb.list:
module fb-drv
Now, I don't see this...
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
...which is probably a positive sign, but with UX_GFX set to 800x600@24, I still see this...
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
[...]
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.
However, if I follow this advice - in my case, changing UX_GFX to 800x600@32 - it solves the problem and I see a nice colourful demo. :-)
Interestingly, though, I still get this line in the output log:
spectrum| x:640 y:480 bit/pixel:24 bytes/line:2560
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 :)
Well, I think I've picked up some knowledge working through this. Hopefully, this may push me to the next level, which could involve trying to get the framebuffer working on a MIPS32 device (for which the setup code is already available in Linux and is something I've worked with already without Linux being involved), but there may need to be some smaller steps on the way there.
Thanks once again!
Paul
l4-hackers@os.inf.tu-dresden.de