Yes, you read that correctly.
You can run X on your CLE266 based EPIA without having to depend on any non-free software whatsoever.
No non-free drivers. No non-free BIOS. And now no VGA BIOS :)
If you have an EPIA-M, then things are very easy. Well, relatively easy. Well easier than trying to include a VGA ROM in linuxbios anyway :)
X bit: ------
My X driver has been able to run as a non-Primary VGA device for years. All it needed was to become (bios-initialised) scratch register independant, which is something i did late last year, early this year. There was a single, highly trivial bug in the way, and it was something i broke late last year, but now it's just fine.
So just get my driver from git: git-clone git://people.freedesktop.org/~libv/xf86-video-unichrome
* Build it; there's a README in there for manual builds (it's backwards compatible all the way to debian sarge's xfree86-4.3.0), or if you're on debian or ubuntu (with a modular X) then you can just dpkg-buildpackage it. * Install it. * Test it.
Caveats: * You do want to test X and verify that it's the latest version. The log echoes the git SHA-ID. grep for "SHA-ID" and match it with your git tree. * You do want X to start automatically, or you will have to have some other means of logging in (serial, network). * Don't depend on X as your only way in. The driver was written only with "bail out cleanly if something fails" in mind. If it fails, it will restore the console cleanly. But the snag there is that we didn't have a console to begin with (but hang on, i'll get you one ASAP). :) * The driver will complain when trying to parse the scratch registers. But all the necessary ones are handled properly now, and the rest are configurable. So the driver is just whining, nothing more.
BIOS bit (for original 256kB rom): ----------------------------------
Linuxbios already had all the bits necessary to get this working. There's no more voodoo involved anywhere.
* Just use whatever payload you require (normal use will probably be filo), but make sure that this is solid. * Just buildtarget via/epia-m with the standard config, which should only be adjusted for your payload. * flash your rom with the created linuxbios.rom, but do store the old image first, as that takes only a few seconds.
Do not bother with any of the VGA things, as, for X only, they are not necessary, and most of the documentation out there is outdated anyway :)
Caveats: * you do want serial (test this before rebooting), as you don't get a VGA console. If you, for instance, want to touch what filo is booting for you, then you do need serial. * you probably do want to be able to ssh in, this means that you pretty much need to get to the end of the booting process already.
I have deliberately kept the above guide short. Read through the documentation of what you're doing, this will help ensure that you don't get an unbootable machine. But this is not rocket science, there is no voodoo involved.
If you're careful, and spend a bit of time and thought on setting up the payload and linuxbios, then the chance of bricking your EPIA-M is small. But if you do brick it, you will have to find a way to flash your rom from another board (hotswapping) or with a prommer. Nothing lethal, but a rather major inconvenience if you're not prepared for it.
For absolute peace of mind, you might just want to get a PLCC extractor (~5-10EUR) and a 5V PLCC rom (~5EUR) and keep the original rom as is. If you then bugger up, you can just insert the old rom again, edit your BIOS config (CMOS got incompatible changes now), and it'll boot up just fine.
----
Now, if both bits have been done, do some ritual of your own choosing and reboot.
You do want to powercycle to get rid of the original VGA BIOS that's still loaded at 0x000C0000, which doesn't get run at all but just sits there. Also, if you don't powercycle, console will also just keep on existing as if nothing happened, as no registers from the unichrome will get touched in a significant way.
After a short while, X should come up as if nothing's changed :)
And that's it. You've rid yourself of all non-free software. Now you get to trump pretty much everybody who claims to be all free software :)
There is of course no warranty that all of this will not brick your motherboard. If it does, then i'm sorry, but then you've probably done something wrong, as it's all pretty happy here. But it's nothing lethal anyway, just inconvenient :)
The only time i did brick it here is when i did try to run a VGA BIOS (at a wrong, hardcoded offset), so don't worry too much, just be very careful :)
Oh well, true free software geekdom is only for the brave.
Luc Verhaegen. http://unichrome.sf.net/
Ubercool! This is exactly what I myself intended to do, and you have already done it! My next goal is to initialize the display already in LinuxBios. I want it to go into a nice picture/or solid color within less a second after press the ON button. Then, later as the X-server takes over the control, it will know that the display is initialized and can take over without blinking the display.... :-)
Do you think it is possible?
//Fredrik
2007/3/16, Luc Verhaegen libv@skynet.be:
Yes, you read that correctly.
You can run X on your CLE266 based EPIA without having to depend on any non-free software whatsoever.
No non-free drivers. No non-free BIOS. And now no VGA BIOS :)
If you have an EPIA-M, then things are very easy. Well, relatively easy. Well easier than trying to include a VGA ROM in linuxbios anyway :)
X bit:
My X driver has been able to run as a non-Primary VGA device for years. All it needed was to become (bios-initialised) scratch register independant, which is something i did late last year, early this year. There was a single, highly trivial bug in the way, and it was something i broke late last year, but now it's just fine.
So just get my driver from git: git-clone git://people.freedesktop.org/~libv/xf86-video-unichrome
- Build it; there's a README in there for manual builds (it's backwards
compatible all the way to debian sarge's xfree86-4.3.0), or if you're on debian or ubuntu (with a modular X) then you can just dpkg-buildpackage it.
- Install it.
- Test it.
Caveats:
- You do want to test X and verify that it's the latest version. The
log echoes the git SHA-ID. grep for "SHA-ID" and match it with your git tree.
- You do want X to start automatically, or you will have to have some
other means of logging in (serial, network).
- Don't depend on X as your only way in. The driver was written only
with "bail out cleanly if something fails" in mind. If it fails, it will restore the console cleanly. But the snag there is that we didn't have a console to begin with (but hang on, i'll get you one ASAP). :)
- The driver will complain when trying to parse the scratch registers.
But all the necessary ones are handled properly now, and the rest are configurable. So the driver is just whining, nothing more.
BIOS bit (for original 256kB rom):
Linuxbios already had all the bits necessary to get this working. There's no more voodoo involved anywhere.
- Just use whatever payload you require (normal use will probably be
filo), but make sure that this is solid.
- Just buildtarget via/epia-m with the standard config, which should
only be adjusted for your payload.
- flash your rom with the created linuxbios.rom, but do store the old
image first, as that takes only a few seconds.
Do not bother with any of the VGA things, as, for X only, they are not necessary, and most of the documentation out there is outdated anyway :)
Caveats:
- you do want serial (test this before rebooting), as you don't get a
VGA console. If you, for instance, want to touch what filo is booting for you, then you do need serial.
- you probably do want to be able to ssh in, this means that you
pretty much need to get to the end of the booting process already.
I have deliberately kept the above guide short. Read through the documentation of what you're doing, this will help ensure that you don't get an unbootable machine. But this is not rocket science, there is no voodoo involved.
If you're careful, and spend a bit of time and thought on setting up the payload and linuxbios, then the chance of bricking your EPIA-M is small. But if you do brick it, you will have to find a way to flash your rom from another board (hotswapping) or with a prommer. Nothing lethal, but a rather major inconvenience if you're not prepared for it.
For absolute peace of mind, you might just want to get a PLCC extractor (~5-10EUR) and a 5V PLCC rom (~5EUR) and keep the original rom as is. If you then bugger up, you can just insert the old rom again, edit your BIOS config (CMOS got incompatible changes now), and it'll boot up just fine.
Now, if both bits have been done, do some ritual of your own choosing and reboot.
You do want to powercycle to get rid of the original VGA BIOS that's still loaded at 0x000C0000, which doesn't get run at all but just sits there. Also, if you don't powercycle, console will also just keep on existing as if nothing happened, as no registers from the unichrome will get touched in a significant way.
After a short while, X should come up as if nothing's changed :)
And that's it. You've rid yourself of all non-free software. Now you get to trump pretty much everybody who claims to be all free software :)
There is of course no warranty that all of this will not brick your motherboard. If it does, then i'm sorry, but then you've probably done something wrong, as it's all pretty happy here. But it's nothing lethal anyway, just inconvenient :)
The only time i did brick it here is when i did try to run a VGA BIOS (at a wrong, hardcoded offset), so don't worry too much, just be very careful :)
Oh well, true free software geekdom is only for the brave.
Luc Verhaegen. http://unichrome.sf.net/ _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
On Sat, Mar 17, 2007 at 11:44:29AM +0100, Fredrik Ohrstrom wrote:
Ubercool! This is exactly what I myself intended to do, and you have already done it!
This hasn't exactly happened overnight, it is not something one would do in a few days hacking. And i believe that also goes for the work that was already put into the linuxbios part of the story.
This whole story was about 2 completely different and seperate projects doing The Right Thing (tm) all along, totally independant of one another.
All i did now was try to find out what needed to be done for the final bit to work, and was surpised to see that it worked that beautifully, almost from the word go.
This is as much a credit to the linuxbios community as it is to my driver.
My next goal is to initialize the display already in LinuxBios.
Basic VGA text console work is well underway, hope to have a small userspace app working in userspace later today (even though i'm not free to hack most of the evening, i will be tonight though). Userspace app to ease testing as porting should be trivial.
I want it to go into a nice picture/or solid color within less a second after press the ON button.
Yes, people do seem to want to have a pretty bootsplash. This possibility will be given.
Then, later as the X-server takes over the control, it will know that the display is initialized and can take over without blinking the display.... :-)
Do you think it is possible?
Possible... linuxbios is, what, 99% C. So you can pretty much do anything if it fits into your rom. So it is possible.
But the real question is, is it sensible? And the answer there is: absolutely not.
Luc Verhaegen.
* Luc Verhaegen. libv@skynet.be [070317 14:04]:
I want it to go into a nice picture/or solid color within less a second after press the ON button.
Yes, people do seem to want to have a pretty bootsplash. This possibility will be given.
I remember we had some bootsplash in LinuxBIOSv1, but it was never ported over.
There's two things that are potentially time consuming in hw startup:
* dram init (ie. on large machines) * compression (on small machines)
In LinuxBIOSv2 the code that does PCI init (and thus initializes the graphics hardware) is compressed if CONFIG_COMPRESS is set. This means time is wasted before there is any chance to actually init VGA and show a splash screen.
In v3 we completely dropped the VGA console code (NOT the VGA init code!) and leave everything graphical or textual to the payload. LinuxBIOS _console_ will only be on serial or usb debug. This makes the code smaller and the bootup look a lot nicer. VGA output is of no use for debugging because the critical stuff in LinuxBIOS happens before we have it.
Stefan
On Sat, Mar 17, 2007 at 03:03:37PM +0100, Stefan Reinauer wrote:
- Luc Verhaegen. libv@skynet.be [070317 14:04]:
I want it to go into a nice picture/or solid color within less a second after press the ON button.
Yes, people do seem to want to have a pretty bootsplash. This possibility will be given.
I remember we had some bootsplash in LinuxBIOSv1, but it was never ported over.
There's two things that are potentially time consuming in hw startup:
- dram init (ie. on large machines)
- compression (on small machines)
In LinuxBIOSv2 the code that does PCI init (and thus initializes the graphics hardware) is compressed if CONFIG_COMPRESS is set. This means time is wasted before there is any chance to actually init VGA and show a splash screen.
In v3 we completely dropped the VGA console code (NOT the VGA init code!) and leave everything graphical or textual to the payload. LinuxBIOS _console_ will only be on serial or usb debug. This makes the code smaller and the bootup look a lot nicer. VGA output is of no use for debugging because the critical stuff in LinuxBIOS happens before we have it.
Stefan
Are you saying there that, for the likes of filo, grub, etherboot, etc will be forced to set up a full VGA console themselves? Or are you for forcing everybody to use a serial console to: * instruct the bootloader on what to do, what kernel to load from where. * manually fsck your root filesystem after a bad reboot. * or in the most insane case: alter your X setup when X gives up?
I'm sure that there are tons of examples here.
What the unichrome needs for getting a VGA text console will well make up for the space taken by the VGA ROM. And if it wasn't for the font, then this would all take less space than the code used currently in northbridge/via/vt8236/ that's used for running the VGA BIOS.
I understand that this is all happening too late for debugging linuxbios, but this isn't about debugging linuxbios. For me it is about being able to do something useful when it jumps to the bootloader or the kernel. When you force everybody to have serial for this, linuxbios will not be accepted by the masses, even when their full board is directly supported.
Now i'm not overly keen on spending time on a bootsplash myself, it is something everyone can quite easily live without. But in previous conversations i don't remember you being negative towards it :)
I fully understand that you want to push this as far down the linuxbios line as possible. But it would be nice if linuxbios presented a working vga console to the actual payload. Setting up VGA and loading the font could of course be delayed until right before the actual payload. At which time it should be easy to tell users that they have been using linuxbios :)
Luc Verhaegen.
Hi Luc,
2007/3/17, Luc Verhaegen. libv@skynet.be:
Are you saying there that, for the likes of filo, grub, etherboot, etc will be forced to set up a full VGA console themselves? Or are you for forcing everybody to use a serial console to:
- instruct the bootloader on what to do, what kernel to load from where.
- manually fsck your root filesystem after a bad reboot.
- or in the most insane case: alter your X setup when X gives up?
I think you don't understood correctly. LinuxBIOS will still starting VGA card, only the log output will no more be showed on video, only on serial or usb.
Cheers,
Alan
* Luc Verhaegen. libv@skynet.be [070317 15:39]:
Are you saying there that, for the likes of filo, grub, etherboot, etc will be forced to set up a full VGA console themselves?
Not more than at the moment. You need functions that write characters to 0xb8000, more or less. But you need them in v2 as well. LinuxBIOSv2 does not provide a library or anything for console output.
Or are you for forcing everybody to use a serial console to:
- instruct the bootloader on what to do, what kernel to load from where.
- manually fsck your root filesystem after a bad reboot.
- or in the most insane case: alter your X setup when X gives up?
Noooo! ;-) No worries. This is only for everything up to loading the payload. The bootloader (payload) will be able to use an initialized VGA console (and, eventually find out via the linuxbios table whether it is text mode or framebuffer and what address and resolution it is?)
I understand that this is all happening too late for debugging linuxbios, but this isn't about debugging linuxbios. For me it is about being able to do something useful when it jumps to the bootloader or the kernel. When you force everybody to have serial for this, linuxbios will not be accepted by the masses, even when their full board is directly supported.
The idea is just to hide the _LinuxBIOS_ _debug_ messages from VGA console, as it is too late for debugging. In my tests FILO would immediately start printing the grub menu in text mode, but that is the first thing you will see, after a fraction of a second.
Now i'm not overly keen on spending time on a bootsplash myself, it is something everyone can quite easily live without. But in previous conversations i don't remember you being negative towards it :)
It is one thing I found out during the last few days, starting to work on vm86/x86emu: In v3 we are so fast again that the need of a bootsplash during _LinuxBIOS_ execution might not exist. Maybe the payload should do this, or the CMOS setup menu (to be shown while waiting for the keypress timeout), that some people talked about,.. or....
I am not at all negative. I am just thinking out loud where stuff is done best.
I fully understand that you want to push this as far down the linuxbios line as possible. But it would be nice if linuxbios presented a working vga console to the actual payload.
It does this, but in v3, it will not use it anymore for printing "all devices initialized. looking for payload. etc pp".
Well, v3 currently knows how to init the VGA console by executing an option rom, but we will be changing this soon, I hope (for instance when bringing the Epia port over)
Stefan
On Sat, Mar 17, 2007 at 04:29:50PM +0100, Stefan Reinauer wrote:
- Luc Verhaegen. libv@skynet.be [070317 15:39]:
Are you saying there that, for the likes of filo, grub, etherboot, etc will be forced to set up a full VGA console themselves?
Not more than at the moment. You need functions that write characters to 0xb8000, more or less. But you need them in v2 as well. LinuxBIOSv2 does not provide a library or anything for console output.
Right, but we do need to provide a working mode, with dac and fonts loaded.
Noooo! ;-) No worries. This is only for everything up to loading the payload. The bootloader (payload) will be able to use an initialized VGA console (and, eventually find out via the linuxbios table whether it is text mode or framebuffer and what address and resolution it is?)
Ah, right :)
The idea is just to hide the _LinuxBIOS_ _debug_ messages from VGA console, as it is too late for debugging. In my tests FILO would immediately start printing the grub menu in text mode, but that is the first thing you will see, after a fraction of a second.
Ah, of course, this intention clearly was lost on me :) Yes, this is all very sensible indeed.
It is one thing I found out during the last few days, starting to work on vm86/x86emu: In v3 we are so fast again that the need of a bootsplash during _LinuxBIOS_ execution might not exist. Maybe the payload should do this, or the CMOS setup menu (to be shown while waiting for the keypress timeout), that some people talked about,.. or....
I am not at all negative. I am just thinking out loud where stuff is done best.
Ah, you talked about a possible bootsplash _last_ week :)
It does this, but in v3, it will not use it anymore for printing "all devices initialized. looking for payload. etc pp".
Right.
Well, v3 currently knows how to init the VGA console by executing an option rom, but we will be changing this soon, I hope (for instance when bringing the Epia port over)
Well, i'll soon have rudimentary VGA modesetting + font loading working in a userspace app, that, when ported over, will hopefully get every VGA compatible device a working console quickly and easily. Well, when the hardware gets initialised far enough to allow that.
Luc Verhaegen.
* Luc Verhaegen. libv@skynet.be [070318 03:42]:
I am not at all negative. I am just thinking out loud where stuff is done best.
Ah, you talked about a possible bootsplash _last_ week :)
Yes, that was about one or two days before I got v3 working with VGA in QEMU.
A boot splash screen lives by the time you have to look at it. So usually loading the kernel takes something from 1-5s. This is a good time to show a splash screen (before it is replaced by the Linux bootsplash, ie. www.bootsplash.org)
* Maybe we do want to switch the bootsplash on in the LinuxBIOS part?
* Maybe we want a seperate "stage" that does only that, between pci init and executing the bootloader?
* Maybe the bootloader should take care?
What do you think? I really don't know.
Well, i'll soon have rudimentary VGA modesetting + font loading working in a userspace app, that, when ported over, will hopefully get every VGA compatible device a working console quickly and easily. Well, when the hardware gets initialised far enough to allow that.
yes, we had x86emu for vgabios init running as a userspace application first, too. It is very simple to integrate it into LinuxBIOS later on, if you don't do crazy stuff, like using glibc internationalization ;)
Stefan
On Sun, Mar 18, 2007 at 04:21:22PM +0100, Stefan Reinauer wrote:
- Maybe we do want to switch the bootsplash on in the LinuxBIOS part?
It's a feature, but none that I would use.
- Maybe we want a seperate "stage" that does only that, between pci init and executing the bootloader?
Sounds like an idea. I would definately not want it compiled in unless I choose it in Kconfig though. But one option for which mode, and another for the graphics file would be good. We'd want to convert the image to raw and repack with lzma instead, rather than include a png decoder in ROM, right?
- Maybe the bootloader should take care?
What do you think? I really don't know.
How does GRUB2 feel about it?
//Peter
PS: Could you test the TIMER2/RESET patch on your EPIA and ack if it works?
* Peter Stuge stuge-linuxbios@cdy.org [070318 17:20]:
Sounds like an idea. I would definately not want it compiled in unless I choose it in Kconfig though.
Yes, definitely.
But one option for which mode, and another for the graphics file would be good.
Yes. The picture should be selectable via Kconfig.
For the architecture, I think it should be possible to just add a picture to the lar.
We'd want to convert the image to raw and repack with lzma instead, rather than include a png decoder in ROM, right?
For the Kernel bootsplash, a guy at SUSE wrote a jpeg decoder in roughly 8k. That plus a jpeg will be smaller than a lzmaed raw image in almost all cases.
- Maybe the bootloader should take care?
What do you think? I really don't know.
How does GRUB2 feel about it?
If it's a seperate stage, grub2 (linuxbios version) might want to know how to switch it off anyways. But making it a seperate stage would for sure be a good idea as nobody feels offended by having to maintain that graphics stuff "in their stage" :-)
PS: Could you test the TIMER2/RESET patch on your EPIA and ack if it works?
Oh yes, sorry it takes me so long. Will do so asap.
On Sun, Mar 18, 2007 at 05:48:48PM +0100, Stefan Reinauer wrote:
For the Kernel bootsplash, a guy at SUSE wrote a jpeg decoder in roughly 8k.
Would that be Oliver Fromme? :)
That plus a jpeg will be smaller than a lzmaed raw image in almost all cases.
JPEG is great for photos, not so good for quality of painted graphics, but the size benefit is important.
- Maybe the bootloader should take care?
What do you think? I really don't know.
How does GRUB2 feel about it?
If it's a seperate stage, grub2 (linuxbios version) might want to know how to switch it off anyways. But making it a seperate stage would for sure be a good idea as nobody feels offended by having to maintain that graphics stuff "in their stage" :-)
Yep, nice and isolated.
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [070319 01:35]:
On Sun, Mar 18, 2007 at 05:48:48PM +0100, Stefan Reinauer wrote:
For the Kernel bootsplash, a guy at SUSE wrote a jpeg decoder in roughly 8k.
Would that be Oliver Fromme? :)
Hey, you know "inof"? :-)
Actually it was Michael Schröder.
That plus a jpeg will be smaller than a lzmaed raw image in almost all cases.
JPEG is great for photos, not so good for quality of painted graphics, but the size benefit is important.
Yes. Back then when we chose jpeg it was because we wanted color gradients in the splash pictures - And that completely snafus your compression rate with gzip/bz2. Jpeg is pretty ok if you add some algorithmical cosmetics and do 90 or 100% quality in cjpeg.
Stefan
-
Alan Carvalho de Assis -
Fredrik Ohrstrom -
Luc Verhaegen -
Luc Verhaegen.
-
Peter Stuge -
Stefan Reinauer