Hello.
As my understanding, current LinuxBIOS can not boot Windows and the reason for it is that it depends on 16bit bios feature much. So far is right? If right, how about this way. Have you noticed already?
First, LinuxBIOS is loaded from flash ROM. Then, it moves itself to uppder 16M area. and it loads some free 16bit BIOS image from somewhere ( e.g. HDD, USB memory or even network) to under 1M area. And LinuxBIOS jumps to 16bit BIOS. Of course, this sequence should not be invoked automatically but by user command, e.g. run_windows or such.
Or, can you add function to load FreeDOS from LinuxBIOS? if it is possible, we can run at least Win95/98/Me with LOADLIN.exe. and I would think maybe there is a way to boot Win2K/XP from FreeDOS.
--- Okajima, Jun. Tokyo, Japan.
Memory map: ----4G-------- LinuxBIOS ----16M------- Reserved for HIMEM.SYS ----1M-------- 16bitBIOS --------------
Note: if you understand Japanese, it is also welcome to mail me privately with Japanese.
* Digital Infra, Inc. okajima@digitalinfra.co.jp [050126 13:51]:
Hello.
As my understanding, current LinuxBIOS can not boot Windows and the reason for it is that it depends on 16bit bios feature much. So far is right? If right, how about this way. Have you noticed already?
First, LinuxBIOS is loaded from flash ROM. Then, it moves itself to uppder 16M area. and it loads some free 16bit BIOS image from somewhere ( e.g. HDD, USB memory or even network) to under 1M area. And LinuxBIOS jumps to 16bit BIOS. Of course, this sequence should not be invoked automatically but by user command, e.g. run_windows or such.
Something like this has been done before, it's called ADLO. Check the mailinglist archives for more information...
Stefan
Thanks! I did just reinvent the wheel. BTW, how it has progressed? these two URLs get not found. http://www.missl.cs.umd.edu/Projects/sebos/main.shtml http://www.missl.cs.umd.edu/Projects/sebos/phase2.shtml
--- Okajima.
- Digital Infra, Inc. okajima@digitalinfra.co.jp [050126 13:51]:
Hello.
As my understanding, current LinuxBIOS can not boot Windows and the reason for it is that it depends on 16bit bios feature much. So far is right? If right, how about this way. Have you noticed already?
First, LinuxBIOS is loaded from flash ROM. Then, it moves itself to uppder 16M area. and it loads some free 16bit BIOS image from somewhere ( e.g. HDD, USB memory or even network) to under 1M area. And LinuxBIOS jumps to 16bit BIOS. Of course, this sequence should not be invoked automatically but by user command, e.g. run_windows or such.
Something like this has been done before, it's called ADLO. Check the mailinglist archives for more information...
Stefan
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
And it boots Windows XP?
---- Thanks! I did just reinvent the wheel. BTW, how it has progressed? these two URLs get not found. http://www.missl.cs.umd.edu/Projects/sebos/main.shtml http://www.missl.cs.umd.edu/Projects/sebos/phase2.shtml
--- Okajima.
- Digital Infra, Inc. okajima@digitalinfra.co.jp [050126 13:51]:
Hello.
As my understanding, current LinuxBIOS can not boot Windows and the reason for it is that it depends on 16bit bios feature much. So far is right? If right, how about this way. Have you noticed already?
First, LinuxBIOS is loaded from flash ROM. Then, it moves itself to uppder 16M area. and it loads some free 16bit BIOS image from somewhere ( e.g. HDD, USB memory or even network) to under 1M area. And LinuxBIOS jumps to 16bit BIOS. Of course, this sequence should not be invoked automatically but by user command, e.g. run_windows or such.
Something like this has been done before, it's called ADLO. Check the mailinglist archives for more information...
Stefan
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
* Digital Infra, Inc. okajima@digitalinfra.co.jp [050126 15:20]:
And it boots Windows XP?
AFAIK only Win2k, but it could be advanced.
The current URL is http://www.missl.cs.umd.edu/sebos.html
The code is in LinuxBIOS v1 CVS
Stefan
On Wed, 26 Jan 2005, Digital Infra, Inc. wrote:
First, LinuxBIOS is loaded from flash ROM. Then, it moves itself to uppder 16M area. and it loads some free 16bit BIOS image from somewhere ( e.g. HDD, USB memory or even network) to under 1M area. And LinuxBIOS jumps to 16bit BIOS. Of course, this sequence should not be invoked automatically but by user command, e.g. run_windows or such.
Look at Adam Sulmicki's ADLO work, he did something very similar to this.
ron
Look at Adam Sulmicki's ADLO work, he did something very similar to this.
I currently use ADLO so I might be able to answer your questions.
I've only sucessfully booted linux via LILO under ADLO. I mostly use ADLO to get the video bios up and going.
I've tried to boot a MSDOS compact flash but it seems to hang somewhere so I didn't progress any further.
I don't see any reason that ADLO sould not be able to boot FreeDOS. ADLO is a deriative of the bios from the bochs project so if you can get bochs to boot FreeDOS or MSDOS then the same should be possible under ADLO.
At one point I tried to sync up ADLO with the current version of the bochs bios but it would not boot. The IDE routines in ADLO seem to be more correct than the stock stuff in bochs.
ADLO is currently only in V1 but I don't see any reason why it wouldn't work in V2 as well. Its just a payload. One thing about ADLO is that the loader has to be customized to the chipset. The loader has to enable the shadow ram section and copy itself into that range. Since there is no mechanism to do this across payloads you have to do it explicitly in the loader.
On Wed, 26 Jan 2005, Richard Smith wrote:
I don't see any reason that ADLO sould not be able to boot FreeDOS. ADLO is a deriative of the bios from the bochs project so if you can get bochs to boot FreeDOS or MSDOS then the same should be possible under ADLO.
starting with FreeDOS is probably a good idea since it will be easier to figure out what the problems are. You could compile FreeDOS with debugging, or something like that so you know why it is failing. etc.
(be sure to be fixing bochs bios, not FreeDOS).
At one point I tried to sync up ADLO with the current version of the bochs bios but it would not boot. The IDE routines in ADLO seem to be more correct than the stock stuff in bochs.
or perhaps to put it other way around; 95% of current problems with BOCHS bios is related to the ide driver. Get IDE driver right and it is quite possible most of the stuff will work.
if anyone cares here's current change log for bios from the bochs project.
http://bochs.sourceforge.net/cgi-bin/topper.pl?name=Project+Page&url=htt...
ADLO is currently only in V1 but I don't see any reason why it wouldn't work in V2 as well. Its just a payload. One thing about ADLO is that the loader has to be customized to the chipset. The loader has to enable the shadow ram section and copy itself into that range. Since there is no mechanism to do this across payloads you have to do it explicitly in the loader.
or perhaps to put it other way around; 95% of current problems with BOCHS bios is related to the ide driver. Get IDE driver right and it is quite possible most of the stuff will work.
I think that I when I remeber looking at the diff between ADLO and the latest bochs stuff that the ADLO stuff payed attention to some status bits that the stock bochs stuff didn't.
Plus the ADLO IDE stuff worked where the latest bochs stuff did not.
On Wed, 26 Jan 2005, Richard Smith wrote:
I think that I when I remeber looking at the diff between ADLO and the latest bochs stuff that the ADLO stuff payed attention to some status bits that the stock bochs stuff didn't.
Plus the ADLO IDE stuff worked where the latest bochs stuff did not.
I vaguely remembering Adam dealing with this mess years ago, and it was painful, but yes his IDE code works where bochs failed.
ron
-Ron (Linuxbios team) Humm, had one of my strange ideas. Would it be possible to use the linuxbios kernel as the system kernel?? So instead of calling a new kernel through FILO or booting from etherboot, could I just have Linux bios call INIT, like a normal kernel. I am looking to get the best possible boot time. 1 kernel loads MUCH faster then 2 kernels. You thoughts??
-Adam Talbot talbotx@comcast.net
* Adam Talbot talbotx@comcast.net [050127 06:52]:
-Ron (Linuxbios team) Humm, had one of my strange ideas. Would it be possible to use the linuxbios kernel as the system kernel?? So instead of calling a new kernel through FILO or booting from etherboot, could I just have Linux bios call INIT, like a normal kernel. I am looking to get the best possible boot time. 1 kernel loads MUCH faster then 2 kernels. You thoughts??
It has no scheduler, but otherwise the payload is pretty much "init". No libc and such, too
Stefan
On Wed, Jan 26, 2005 at 09:52:11PM -0800, Adam Talbot wrote:
-Ron (Linuxbios team) Humm, had one of my strange ideas. Would it be possible to use the linuxbios kernel as the system kernel?? So instead of calling a new kernel through FILO or booting from etherboot, could I just have Linux bios call INIT, like a normal kernel. I am looking to get the best possible boot time. 1 kernel loads MUCH faster then 2 kernels. You thoughts??
That's how LinuxBIOS was initially designed.
LinuxBIOS in itself is "only" minimal code for initializing a mainboard with peripherals just enough for a Linux kernel to take over and to the rest.
LinuxBIOS does not contain a kernel per se.
After the initialization, LinuxBIOS jumps to a payload and while there has been discussion about stacking payloads that's currently not in practice.
The payload was originally intended to be a Linux kernel stored in flash. Flash ROM grow rate was anticipated optimistically however, today there are not many mainboards that actually have enough flash ROM room for a kernel. 512KB can be seen here-and-there and a few boards come with 1MB. Recent kernels really want that MB, and then you'll only have room for 3-400 KB of initial ramdisk, which could be too small too, depending on the application.
So, other payloads are used; the two major ones are FILO and Etherboot. FILE loads a kernel from a filesystem on an IDE device and Etherboot loads a kernel from the network or from a filesystem on an IDE device.
If you're using FILO there is no Linux kernel until FILO loads it, and the kernel loaded by FILO (or Etherboot) can absolutely be the one you want to run in your system. Just set it up with the correct root and init commandline so that it can start init.
Another option is to chain two kernels after each other, this is useful for loading a system kernel from some place that FILO or Etherboot can not reach, but which a Linux kernel can. Imagine all sorts of "strange" storage ranging from local JFS to "unusual" network systems and beyond. This uses the kexec feature in 2.6, where a kernel can execute another kernel.
Hope this helps.
//Peter
On Thu, 27 Jan 2005, Peter Stuge wrote:
That's how LinuxBIOS was initially designed.
LinuxBIOS in itself is "only" minimal code for initializing a mainboard with peripherals just enough for a Linux kernel to take over and to the rest.
LinuxBIOS does not contain a kernel per se.
After the initialization, LinuxBIOS jumps to a payload and while there has been discussion about stacking payloads that's currently not in practice.
The payload was originally intended to be a Linux kernel stored in flash. Flash ROM grow rate was anticipated optimistically however, today there are not many mainboards that actually have enough flash ROM room for a kernel. 512KB can be seen here-and-there and a few boards come with 1MB. Recent kernels really want that MB, and then you'll only have room for 3-400 KB of initial ramdisk, which could be too small too, depending on the application.
So, other payloads are used; the two major ones are FILO and Etherboot. FILE loads a kernel from a filesystem on an IDE device and Etherboot loads a kernel from the network or from a filesystem on an IDE device.
If you're using FILO there is no Linux kernel until FILO loads it, and the kernel loaded by FILO (or Etherboot) can absolutely be the one you want to run in your system. Just set it up with the correct root and init commandline so that it can start init.
Another option is to chain two kernels after each other, this is useful for loading a system kernel from some place that FILO or Etherboot can not reach, but which a Linux kernel can. Imagine all sorts of "strange" storage ranging from local JFS to "unusual" network systems and beyond. This uses the kexec feature in 2.6, where a kernel can execute another kernel.
Hope this helps.
looks like a great FAQ entry to me
ron
-Linuxbios Team I one loud voice you guys said yes. :-) But I did notice, and you have pointed out, that the linuxbios kernel is missing some key parts. OK, the end goal is an embedded car computer. For that I need so function not offered by the 2.4 kernel. Suspend-to-disk (Hibernate for the Windows people). So I went to http://www.selenic.com/tiny-about/ and took a look at there 2.6 kernel. I will have to patch it to add suspend-to-disk, but that's not hard. Now what else do I need to do to turn this kernel into a "linuxbios" kernel?? Do to size constraints I will be unable to add a fallback image, no great loss. I am loadding this onto an EPIA-MII with a 512kb SST 39SF040 bios chip. -Adam Talbot
----- Original Message ----- From: "Ronald G. Minnich" rminnich@lanl.gov To: "Peter Stuge" stuge-linuxbios@cdy.org Cc: linuxbios@clustermatic.org Sent: Thursday, January 27, 2005 7:49 AM Subject: Re: Boot Windows Please!
On Thu, 27 Jan 2005, Peter Stuge wrote:
That's how LinuxBIOS was initially designed.
LinuxBIOS in itself is "only" minimal code for initializing a mainboard with peripherals just enough for a Linux kernel to take over and to the rest.
LinuxBIOS does not contain a kernel per se.
After the initialization, LinuxBIOS jumps to a payload and while there has been discussion about stacking payloads that's currently not in practice.
The payload was originally intended to be a Linux kernel stored in flash. Flash ROM grow rate was anticipated optimistically however, today there are not many mainboards that actually have enough flash ROM room for a kernel. 512KB can be seen here-and-there and a few boards come with 1MB. Recent kernels really want that MB, and then you'll only have room for 3-400 KB of initial ramdisk, which could be too small too, depending on the application.
So, other payloads are used; the two major ones are FILO and Etherboot. FILE loads a kernel from a filesystem on an IDE device and Etherboot loads a kernel from the network or from a filesystem on an IDE device.
If you're using FILO there is no Linux kernel until FILO loads it, and the kernel loaded by FILO (or Etherboot) can absolutely be the one you want to run in your system. Just set it up with the correct root and init commandline so that it can start init.
Another option is to chain two kernels after each other, this is useful for loading a system kernel from some place that FILO or Etherboot can not reach, but which a Linux kernel can. Imagine all sorts of "strange" storage ranging from local JFS to "unusual" network systems and beyond. This uses the kexec feature in 2.6, where a kernel can execute another kernel.
Hope this helps.
looks like a great FAQ entry to me
ron _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
just make sure you have the absolute min device drivers and your suspend and you ought to be ok
ron
On Wed, 26 Jan 2005, Adam Talbot wrote:
Humm, had one of my strange ideas. Would it be possible to use the linuxbios kernel as the system kernel??
sure, people have been doing that for years.
ron
Humm, had one of my strange ideas. Would it be possible to use the linuxbios kernel as the system kernel?? So instead of calling a new kernel through FILO or booting from etherboot, could I just have Linux bios call INIT, like a normal kernel. I am looking to get the best possible boot time. 1 kernel loads MUCH faster then 2 kernels.
umm, sure if you can find flash big enough to fit it.
-
Adam Sulmicki -
Adam Talbot -
Digital Infra, Inc. -
Peter Stuge -
Richard Smith -
Ronald G. Minnich -
Stefan Reinauer