These are the sources from Adam Agnew and Adam Sulmicki that let you boot OpenBSD, Windows, etc.
ron
On Mon, 2002-11-25 at 10:08, Ronald G. Minnich wrote:
These are the sources from Adam Agnew and Adam Sulmicki that let you boot OpenBSD, Windows, etc.
Is there any HOWTO on this ??
Ollie
These are the sources from Adam Agnew and Adam Sulmicki that let you boot OpenBSD, Windows, etc.
Is there any HOWTO on this ??
Just read throughout the files provied with ADLO. the "INSTALL" file is a fairly good start, README would be next. But you probably want to go over all of them.
Then let us know what/if needs to be changed. I have been pretty much living and breathing ADLO for last few months so something I think may be obvious may actually be not.
This or either way, the target audience for ADLO is experienced LinuxBIOS "users".
These are the sources from Adam Agnew and Adam Sulmicki that let you boot OpenBSD, Windows, etc.
Is this the recommended way to boot a Linux kernel from CompactFlash or should I continue trying to figure out why elfboot won't look at IDE with option BOOT_IDE=1?
The Bochs BIOS is built around the BX chipset IIRC, which isn't far at all from the TX chipset.
Regards, Andrew
Is this the recommended way to boot a Linux kernel from CompactFlash or should I continue trying to figure out why elfboot won't look at IDE with option BOOT_IDE=1?
maybe someone else can answer this.
I'll just add that when ADLO is used an plain linux kernel without any modifications can be used. Ie no need to patch it.
The Bochs BIOS is built around the BX chipset IIRC, which isn't far at all from the TX chipset.
I think it is mostly the Bochs "hardware" not the BIOS itself that's build about the BX chipset. The BIOS itself is fairly generic and pretty adapable for our needs (the big issues related to it is somewhat simplistic hardware model. ex : no delay loops (ATA) or incomlete emulation of hardware (KBD,PIRQ) ).
What's most chipset dependant in our project is the loader it self (loader.s). It must do some preparatory work before it can start bochs bios. One of the key issues is that the address at 0xF0000 has to be ram mapped and it got to be Read/Write.
We still are not sure what's the best way to interface the LinuxBIOS and BOCHS BIOS. There's need for some information to be passed between the two. Those include: Mem size, E820, PIRQ, how to manipulate shadow ram, how to reset chipset (reboot). Of above first 3 are data scrutures, last 2 are functions. If we can do this, we can keep BOCHS BIOS (and ADLO) generic and leave all chipset specific stuff to LinuxBIOS.
What size does all this take up in flash?
LinuxBIOS + BOCHS BIOS + Video BIOS =?
Bari
What size does all this take up in flash?
LinuxBIOS + BOCHS BIOS + Video BIOS =?
BOCHS BIOS standard size is 64kb. If you gzip it it goes down to 20kb.
We are currently using binary only video bios. The video bios as it is with SIS630 is 48kb. For paranoia sake we are using full 64kb. gzipped 64kb bios is at 34kb.
Will this help you get down size of your project?
Adam Sulmicki wrote:
What size does all this take up in flash?
LinuxBIOS + BOCHS BIOS + Video BIOS =?
BOCHS BIOS standard size is 64kb. If you gzip it it goes down to 20kb.
We are currently using binary only video bios. The video bios as it is with SIS630 is 48kb. For paranoia sake we are using full 64kb. gzipped 64kb bios is at 34kb.
Will this help you get down size of your project?
I just wanted to be sure it would all fit into <4Mb of flash. We design several x86 boards a year and most need to boot Win32.
Should Phoenix, AMI and General be worried?
Bari
It fits well under the 256kB of flash. And yes, I should think its about time they got worried. What's not to be worried about? Getting Bochs BIOS to run should be pretty trivial on just about every board LinuxBIOS supports.
Contributions are welcome. It's by no means a completed product. And we'd like to keep Boch's BIOS as generic as possible so it can stay in their sources. My view is we have two very good projects that are beautifully complimentary. The improvement of each individually need not stop now.
- Adam A.
On Sun, 24 Nov 2002, Bari Ari wrote:
Adam Sulmicki wrote:
What size does all this take up in flash?
LinuxBIOS + BOCHS BIOS + Video BIOS =?
BOCHS BIOS standard size is 64kb. If you gzip it it goes down to 20kb.
We are currently using binary only video bios. The video bios as it is with SIS630 is 48kb. For paranoia sake we are using full 64kb. gzipped 64kb bios is at 34kb.
Will this help you get down size of your project?
I just wanted to be sure it would all fit into <4Mb of flash. We design several x86 boards a year and most need to boot Win32.
Should Phoenix, AMI and General be worried?
Bari
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Greetings,
I don't know how Adam feels about it, but if I were Phoenix, AMI, et. al. I'd be worried now, and very interested in getting involved in LinuxBIOS.
G'day, sjames
On Sun, 24 Nov 2002, Bari Ari wrote:
Adam Sulmicki wrote:
What size does all this take up in flash?
LinuxBIOS + BOCHS BIOS + Video BIOS =?
BOCHS BIOS standard size is 64kb. If you gzip it it goes down to 20kb.
We are currently using binary only video bios. The video bios as it is with SIS630 is 48kb. For paranoia sake we are using full 64kb. gzipped 64kb bios is at 34kb.
Will this help you get down size of your project?
I just wanted to be sure it would all fit into <4Mb of flash. We design several x86 boards a year and most need to boot Win32.
Should Phoenix, AMI and General be worried?
Bari
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
I don't know how Adam feels about it, but if I were Phoenix, AMI, et. al. I'd be worried now, and very interested in getting involved in LinuxBIOS.
I agree. Especially with some of the talk about personalities and being able to detect the chipset.
Regards, Andrew
What size does all this take up in flash?
LinuxBIOS + BOCHS BIOS + Video BIOS =?
By the way. It all does not have to be in flash.
For example for the development, I was using LinuxBIOS and EtherBOOT in flash, and I was grabbing the BOCHS BIOS over network from a differnet computer. But you could just put BOCHS BIOS on local hdd or CF.
Not sure if you have any option of external device here.
Greetings,
I've been looking at the issue of LinuxBIOS functions as well. The baremetal toolkit is about 90% code drawn from LinuxBIOS itself. Currently, it is standalone and does not address chipset specifics itself.
One approach I've given some thought to is a simple function table. Another is to use the symbol table somehow. I want to keep that as simple as possable or better yet, figure a way to avoid it alltogether since I agree w/ Ron that we don't really want LinuxBIOS to turn into a mini OS.
It may be that the most versatile approach might be a sort of personality module with a function dispatch table that can be built from the chipset and board specific elements of LinuxBIOS so that at least it is not part of LinuxBIOS itself.
All of that also implys a new memory type description for the LinuxBIOS table, memory that is RAM but shouldn't be overwritten unless there is no intent to return to the previous layer or use it's functions. The bounce buffer and possable future personality module would be located in such an area. The final OS would be free to overwrite all of that since it wouldn't likely return anyway.
G'day, sjames
On Sun, 24 Nov 2002, Adam Sulmicki wrote:
Is this the recommended way to boot a Linux kernel from CompactFlash or should I continue trying to figure out why elfboot won't look at IDE with option BOOT_IDE=1?
maybe someone else can answer this.
I'll just add that when ADLO is used an plain linux kernel without any modifications can be used. Ie no need to patch it.
The Bochs BIOS is built around the BX chipset IIRC, which isn't far at all from the TX chipset.
I think it is mostly the Bochs "hardware" not the BIOS itself that's build about the BX chipset. The BIOS itself is fairly generic and pretty adapable for our needs (the big issues related to it is somewhat simplistic hardware model. ex : no delay loops (ATA) or incomlete emulation of hardware (KBD,PIRQ) ).
What's most chipset dependant in our project is the loader it self (loader.s). It must do some preparatory work before it can start bochs bios. One of the key issues is that the address at 0xF0000 has to be ram mapped and it got to be Read/Write.
We still are not sure what's the best way to interface the LinuxBIOS and BOCHS BIOS. There's need for some information to be passed between the two. Those include: Mem size, E820, PIRQ, how to manipulate shadow ram, how to reset chipset (reboot). Of above first 3 are data scrutures, last 2 are functions. If we can do this, we can keep BOCHS BIOS (and ADLO) generic and leave all chipset specific stuff to LinuxBIOS.
One of the big issues is that for compatibility reasons we have to have our bios at 0xF0000 and video bios at 0xC0000.
However it occured to me that while we keep our bios in RAM, the LinuxBIOS is still out there in the ROM. So perhaps BIOS function could switch on/off some 16kb area in RAM to ROM and get the needed data from there and switch back. (sort of like EMS in DOS days.)
It still does not answer how to do chipset independent control of shadow RAM.
On Mon, 25 Nov 2002, steven james wrote:
Greetings,
I've been looking at the issue of LinuxBIOS functions as well. The baremetal toolkit is about 90% code drawn from LinuxBIOS itself. Currently, it is standalone and does not address chipset specifics itself.
One approach I've given some thought to is a simple function table. Another is to use the symbol table somehow. I want to keep that as simple as possable or better yet, figure a way to avoid it alltogether since I agree w/ Ron that we don't really want LinuxBIOS to turn into a mini OS.
It may be that the most versatile approach might be a sort of personality module with a function dispatch table that can be built from the chipset and board specific elements of LinuxBIOS so that at least it is not part of LinuxBIOS itself.
All of that also implys a new memory type description for the LinuxBIOS table, memory that is RAM but shouldn't be overwritten unless there is no intent to return to the previous layer or use it's functions. The bounce buffer and possable future personality module would be located in such an area. The final OS would be free to overwrite all of that since it wouldn't likely return anyway.
G'day, sjames
On Sun, 24 Nov 2002, Adam Sulmicki wrote:
Is this the recommended way to boot a Linux kernel from CompactFlash or should I continue trying to figure out why elfboot won't look at IDE with option BOOT_IDE=1?
maybe someone else can answer this.
I'll just add that when ADLO is used an plain linux kernel without any modifications can be used. Ie no need to patch it.
The Bochs BIOS is built around the BX chipset IIRC, which isn't far at all from the TX chipset.
I think it is mostly the Bochs "hardware" not the BIOS itself that's build about the BX chipset. The BIOS itself is fairly generic and pretty adapable for our needs (the big issues related to it is somewhat simplistic hardware model. ex : no delay loops (ATA) or incomlete emulation of hardware (KBD,PIRQ) ).
What's most chipset dependant in our project is the loader it self (loader.s). It must do some preparatory work before it can start bochs bios. One of the key issues is that the address at 0xF0000 has to be ram mapped and it got to be Read/Write.
We still are not sure what's the best way to interface the LinuxBIOS and BOCHS BIOS. There's need for some information to be passed between the two. Those include: Mem size, E820, PIRQ, how to manipulate shadow ram, how to reset chipset (reboot). Of above first 3 are data scrutures, last 2 are functions. If we can do this, we can keep BOCHS BIOS (and ADLO) generic and leave all chipset specific stuff to LinuxBIOS.
Greetings,
I was thinking of locating the function table somewhere in ram. Perhaps it and the code itself could go in the 64 K at 0x100000 and A20 could be turned on to access that small highmem area with the segment register set at 0xffff. I hadn't considered that this would be Real mode (though I should have, more coffee needed!). That implys the approach of personality module compiled from LinuxBIOS source rather than direct dispatch into LinuxBIOS.
G'day, sjames
On Mon, 25 Nov 2002, Adam Sulmicki wrote:
One of the big issues is that for compatibility reasons we have to have our bios at 0xF0000 and video bios at 0xC0000.
However it occured to me that while we keep our bios in RAM, the LinuxBIOS is still out there in the ROM. So perhaps BIOS function could switch on/off some 16kb area in RAM to ROM and get the needed data from there and switch back. (sort of like EMS in DOS days.)
It still does not answer how to do chipset independent control of shadow RAM.
On Mon, 25 Nov 2002, steven james wrote:
Greetings,
I've been looking at the issue of LinuxBIOS functions as well. The baremetal toolkit is about 90% code drawn from LinuxBIOS itself. Currently, it is standalone and does not address chipset specifics itself.
One approach I've given some thought to is a simple function table. Another is to use the symbol table somehow. I want to keep that as simple as possable or better yet, figure a way to avoid it alltogether since I agree w/ Ron that we don't really want LinuxBIOS to turn into a mini OS.
It may be that the most versatile approach might be a sort of personality module with a function dispatch table that can be built from the chipset and board specific elements of LinuxBIOS so that at least it is not part of LinuxBIOS itself.
All of that also implys a new memory type description for the LinuxBIOS table, memory that is RAM but shouldn't be overwritten unless there is no intent to return to the previous layer or use it's functions. The bounce buffer and possable future personality module would be located in such an area. The final OS would be free to overwrite all of that since it wouldn't likely return anyway.
G'day, sjames
On Sun, 24 Nov 2002, Adam Sulmicki wrote:
Is this the recommended way to boot a Linux kernel from CompactFlash or should I continue trying to figure out why elfboot won't look at IDE with option BOOT_IDE=1?
maybe someone else can answer this.
I'll just add that when ADLO is used an plain linux kernel without any modifications can be used. Ie no need to patch it.
The Bochs BIOS is built around the BX chipset IIRC, which isn't far at all from the TX chipset.
I think it is mostly the Bochs "hardware" not the BIOS itself that's build about the BX chipset. The BIOS itself is fairly generic and pretty adapable for our needs (the big issues related to it is somewhat simplistic hardware model. ex : no delay loops (ATA) or incomlete emulation of hardware (KBD,PIRQ) ).
What's most chipset dependant in our project is the loader it self (loader.s). It must do some preparatory work before it can start bochs bios. One of the key issues is that the address at 0xF0000 has to be ram mapped and it got to be Read/Write.
We still are not sure what's the best way to interface the LinuxBIOS and BOCHS BIOS. There's need for some information to be passed between the two. Those include: Mem size, E820, PIRQ, how to manipulate shadow ram, how to reset chipset (reboot). Of above first 3 are data scrutures, last 2 are functions. If we can do this, we can keep BOCHS BIOS (and ADLO) generic and leave all chipset specific stuff to LinuxBIOS.
steven james pyro@linuxlabs.com writes:
Greetings,
I was thinking of locating the function table somewhere in ram. Perhaps it and the code itself could go in the 64 K at 0x100000 and A20 could be turned on to access that small highmem area with the segment register set at 0xffff. I hadn't considered that this would be Real mode (though I should have, more coffee needed!). That implys the approach of personality module compiled from LinuxBIOS source rather than direct dispatch into LinuxBIOS.
I am very very much against function tables of any sort. It becomes much, much to easy do something stupid. We are talking about 10 lines of code, it is not a problem to replicate it.
I don't have problems with possibly building from the same sources, if they can be properly extracted. But I would much rather be able to build an ADLO that had drivers for multiple chipsets, detected what it was working against (possibly with the help of the LinuxBIOS table). And did what it needed to do all by itself.
Every firmware function call layer I have seen has had problems. And it is very hard to fix because it is in the firmware.
It is a given that people working on a motherboard will not have much time, before the firmware is burnt. So we need to keep the job of the firmware as simple as possible. Pieces that we can load later like ADLO can be developed after the firmware is settled on. And can be fixed. The firmware is very dangerous to touch once you have a stable configuration.
Ron is correct that firmware services evolve into OS. EFI, the SRM, ROM DOS, etherboot etc. There is justification for having multiple OS's, not all programs run on all OS's, some OS's are smaller and faster, some have drivers for everything under the sun, some have source code, some have excellent support contracts, etc.
If I stare at the Itanium long enough (with it's PAL and SAL) I might get convinced there is some value in some very basic minimal services that are used all of the time. But mostly that seems to be an excuse for not properly documenting things.
My goal is for the LinuxBIOS table to export enough information that things like ADLO can be motherboard independent. In general it is impossible to be hardware independent, but having enough information to know which pieces of hardware you need to talk to does not sound hard. And as time goes there will be more boards without standard hardware, making the work of getting ADLO running usefully harder. This is already the case with Video, SCSI drivers. With the current work on serial ATA IDE drivers may soon follow suite, or at least have several different flavors that need supporting.
I don't even want to think about putting all of those hardware differences behind a function call interface. For most of those I would rather simply not put the support into LinuxBIOS, at all.
Eric
One thing we should keep in mind for the shadow ram thing: Just about every chipset I have seen has shadow ram registers that can correctly be set with the following info:
VendorID, DeviceID, Function, register, AndMask, OrMask.
This rapidly leads to a simple table something like this:
struct shadowram{ int physaddress; u16 VendorID, DeviceID, Function; u8 register; u8 AndMask, OrMask};
struct shadowram s[] = { {0xf0000, 0xabcd, 0x1234, 0x15, 0x40, 0xf8, 0x1}, { etc.} {0,} };
I haven't stumbled across a chipset yet for which this would not work.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
One thing we should keep in mind for the shadow ram thing: Just about every chipset I have seen has shadow ram registers that can correctly be set with the following info:
VendorID, DeviceID, Function, register, AndMask, OrMask.
This rapidly leads to a simple table something like this:
struct shadowram{ int physaddress; u16 VendorID, DeviceID, Function; u8 register; u8 AndMask, OrMask};
struct shadowram s[] = { {0xf0000, 0xabcd, 0x1234, 0x15, 0x40, 0xf8, 0x1}, { etc.} {0,} };
I haven't stumbled across a chipset yet for which this would not work.
Except for the Athlons? Which control this in the CPU?
But that is the basic idea. For the most part we should just enable these area in LinuxBIOS. If the BIOS doesn't need to disable writes to this area of RAM, absolutely nothing needs to happen.
Eric
On 25 Nov 2002, Eric W. Biederman wrote:
Except for the Athlons? Which control this in the CPU?
yes but ... that's a test for cpuid.
For the most part we should just enable these area in LinuxBIOS.
For motherboards that will work if we do that. There are still weirdo ones out there that need some part of the a0000-fffff to not be ram.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On 25 Nov 2002, Eric W. Biederman wrote:
Except for the Athlons? Which control this in the CPU?
yes but ... that's a test for cpuid.
For the most part we should just enable these area in LinuxBIOS.
For motherboards that will work if we do that. There are still weirdo ones out there that need some part of the a0000-fffff to not be ram.
Not being able to make [0xa0000-0xc0000) ram is pretty common.
For the case of ADLO if LinuxBIOS can't make the areas it cares about RAM, than you can't run ADLO. It is as simple as that.
Eric
"Ronald G. Minnich" rminnich@lanl.gov writes:
One thing we should keep in mind for the shadow ram thing: Just about every chipset I have seen has shadow ram registers that can correctly be set with the following info:
VendorID, DeviceID, Function, register, AndMask, OrMask.
This rapidly leads to a simple table something like this:
struct shadowram{ int physaddress; u16 VendorID, DeviceID, Function; u8 register; u8 AndMask, OrMask};
struct shadowram s[] = { {0xf0000, 0xabcd, 0x1234, 0x15, 0x40, 0xf8, 0x1}, { etc.} {0,} };
I haven't stumbled across a chipset yet for which this would not work.
Except for the MediaGX/Geode which has this in the GX_BASE memory region which is not a pci configuration register. :-(
/Christer
One thing we should keep in mind for the shadow ram thing: Just about every chipset I have seen has shadow ram registers that can correctly be set with the following info:
VendorID, DeviceID, Function, register, AndMask, OrMask.
... I haven't stumbled across a chipset yet for which this would not work.
Except for the MediaGX/Geode which has this in the GX_BASE memory region which is not a pci configuration register. :-(
/Christer
Also the stpc, which uses I/O base/index registers, not pci config.
-Steve
On 26 Nov 2002, Christer Weinigel wrote:
"Ronald G. Minnich" rminnich@lanl.gov writes:
One thing we should keep in mind for the shadow ram thing: Just about every chipset I have seen has shadow ram registers that can correctly be set with the following info:
VendorID, DeviceID, Function, register, AndMask, OrMask.
This rapidly leads to a simple table something like this:
struct shadowram{ int physaddress; u16 VendorID, DeviceID, Function; u8 register; u8 AndMask, OrMask};
struct shadowram s[] = { {0xf0000, 0xabcd, 0x1234, 0x15, 0x40, 0xf8, 0x1}, { etc.} {0,} };
I haven't stumbled across a chipset yet for which this would not work.
Except for the MediaGX/Geode which has this in the GX_BASE memory region which is not a pci configuration register. :-(
well, looks like my beautiful theory just got killed by a brutal gang of facts. Now it's somebody else's turn to figure this out :-)
ron
well, looks like my beautiful theory just got killed by a brutal gang of facts. Now it's somebody else's turn to figure this out :-)
well it always could be intermediate solution. In this way we only have 4 data structures and no functions.
On Tue, 26 Nov 2002, Adam Sulmicki wrote:
well it always could be intermediate solution. In this way we only have 4 data structures and no functions.
sounds like we need a union, with a tag, and then the descriptors. In the limit, the tag can be TAG_CODE, meaning you have to call the attached data blob:
enum {TAG_CODE, TAG_PCI_CONFIG, TAG_ISA, TAG_CPU} ;
typedef struct { unsigned short vendor, device; u8 function, register; u8 and, or; } pci_config_data;
typedef struct { u16 iobase; u8 and, or; } isa;
typedef struct { unsigned long msr; unsigned long long and, or; } cpu;
// has to be PIC. typedef struct { unsigned long len; char code; } code;
typedef struct { u8 tag; union { pci_config_data pci; isa isa; cpu cpu; code code; } data; };
Would this do it?
ron
On Tue, 26 Nov 2002, Ronald G. Minnich wrote:
On Tue, 26 Nov 2002, Adam Sulmicki wrote:
well it always could be intermediate solution. In this way we only have 4 data structures and no functions.
sounds like we need a union, with a tag, and then the descriptors. In the limit, the tag can be TAG_CODE, meaning you have to call the attached data blob:
enum {TAG_CODE, TAG_PCI_CONFIG, TAG_ISA, TAG_CPU} ;
typedef struct { unsigned short vendor, device; u8 function, register; u8 and, or; } pci_config_data;
typedef struct { u16 iobase; u8 and, or; } isa;
typedef struct { unsigned long msr; unsigned long long and, or; } cpu;
// has to be PIC. typedef struct { unsigned long len; char code; } code;
typedef struct { u8 tag; union { pci_config_data pci; isa isa; cpu cpu; code code; } data; };
Would this do it?
I'm willing to write some of this if nobody else can, and if it would work.
ron
Adam Sulmicki adam@cfar.umd.edu writes:
Is this the recommended way to boot a Linux kernel from CompactFlash or should I continue trying to figure out why elfboot won't look at IDE with option BOOT_IDE=1?
maybe someone else can answer this.
I'll just add that when ADLO is used an plain linux kernel without any modifications can be used. Ie no need to patch it.
This isn't specific to ADLO. In most cases mkelfImage does all of the strange things that are needed.
The Bochs BIOS is built around the BX chipset IIRC, which isn't far at all from the TX chipset.
I think it is mostly the Bochs "hardware" not the BIOS itself that's build about the BX chipset. The BIOS itself is fairly generic and pretty adapable for our needs (the big issues related to it is somewhat simplistic hardware model. ex : no delay loops (ATA) or incomlete emulation of hardware (KBD,PIRQ) ).
What's most chipset dependant in our project is the loader it self (loader.s). It must do some preparatory work before it can start bochs bios. One of the key issues is that the address at 0xF0000 has to be ram mapped and it got to be Read/Write.
LinuxBIOS should do this, and report that it is ram mapped in the LinuxBIOS table. It is perfectly fine to refuse to load if that is not the case.
We still are not sure what's the best way to interface the LinuxBIOS and BOCHS BIOS. There's need for some information to be passed between the two. Those include: Mem size, E820, PIRQ, how to manipulate shadow ram, how to reset chipset (reboot). Of above first 3 are data scrutures, last 2 are functions. If we can do this, we can keep BOCHS BIOS (and ADLO) generic and leave all chipset specific stuff to LinuxBIOS.
On the platforms where there is some code to handle reboot in LinuxBIOS you get to it by tripple faulting the CPU.
The shadow ram should just be setup by default by LinuxBIOS so you should not need to do anything there. (Unless you need it read only, but we can cross that bridge when we find the program that cares).
The rest are tables that are already present so should not be to hard to work with.
Eric
On Sun, 24 Nov 2002, Andrew Kohlsmith wrote:
Is this the recommended way to boot a Linux kernel from CompactFlash or should I continue trying to figure out why elfboot won't look at IDE with option BOOT_IDE=1?
I would like to know that. I think it is useful.
ron
I saw this over at OSNews, and it seems like a cool project.
Andrew Kohlsmith akohlsmith-linuxbios@benshaw.com writes:
These are the sources from Adam Agnew and Adam Sulmicki that let you boot OpenBSD, Windows, etc.
Is this the recommended way to boot a Linux kernel from CompactFlash or should I continue trying to figure out why elfboot won't look at IDE with option BOOT_IDE=1?
I would wait a little bit for ADLO to stabalize. Unless I have missed something it really isn't board independent yet. I guess I would recommend using the drivers in etherboot-5.1.x for IDE booting. I believe that is the most stable path.
Eric
-
Adam Agnew -
Adam Sulmicki -
Andrew Kohlsmith -
Bari Ari -
Christer Weinigel -
ebiederman＠lnxi.com -
ollie lho -
Ronald G. Minnich -
Steve M. Gehlbach -
steven james