Development in the current LinuxBIOS tree is starting to get difficult because of the sheer number of backward compatible interfaces we retain even when better code is introduced into the tree.
For the 1.1.x development branch leading to the stable 2.0.x series it is my intention remove all of the old interfaces and put LinuxBIOS back together using the current best of breed techniques.
- Use the elf bootloader - Use romcc so we can remove most of the assembly. - Use the generic pci setup mechanism. It needs a little work to make initialization as easy as the superio case but it should work for everything. - Make hardwaremain architecture independent. - Native interrupt routing. (We don't have code but...) - Documented interfaces (I suck at doing this but it needs to happen)...
I am still in the final stages of prototyping the cleanups to hardwaremain. But my first draft is below.
The function that still needs things worked out is enumerate static devices. One or two boards need to be ported and the issues worked out before everything else comes along. The goal is a hardwaremain() function that does not change.
Once there is a stable port in the 1.1. development branch my goal is to call that enough development make it the 2.0 branch and any future disruptive work needs to go on a new development branch. When the 2.0 branch can continue to accumulate working ports.
To implement this I have started a freebios2 tree at sourceforge and I will gradually populating this tree. I am taking the expedient of copying old code over as needed. Leaving old code for now unneeded functionality to just fade away. It is the only easy incremental way I can see to make the sweeping changes I want to see in the LinuxBIOS tree.
I am going to start with the Hammer port and possibly with the p4dpr, to seed the tree and work out most of the issues with the new infrastructure. After that it is moving to 2.0 and collecting additional ports, I suspect.
Eric
void hardwaremain(int boot_complete) { /* Processor ID of the BOOT cpu (i.e. the one running this code) */ unsigned long boot_cpu; int boot_index;
/* the order here is a bit tricky. We don't want to do much of * anything that uses config registers until after PciAllocateResources * since that function also figures out what kind of config strategy * to use (type 1 or type 2). * so we turn on cache, then worry about PCI setup, then do other * things, so that the other work can use the PciRead* and PciWrite* * functions. */ struct mem_range *mem, *tmem; unsigned long totalmem;
// we don't call post code for this one -- since serial post could cause real
// trouble. outb(0x38, 0x80); /* displayinit MUST PRECEDE ALL PRINTK! */ displayinit(); post_code(0x39); printk_notice("LinuxBIOS-%s%s %s %s...\n", linuxbios_version, linuxbios_extra_version, linuxbios_build, (boot_complete)?"rebooting":"booting");
post_code(0x40);
/* If we have already booted attempt a hard reboot */ if (boot_complete) { hard_reset(); }
// pick how to scan the bus. This is first so we can get at memory size.
printk_info("Finding PCI configuration type.\n"); pci_set_method(); post_code(0x5f); enumerate_static_devices(); pci_enumerate(); post_code(0x66); // Now do the real bus // we round the total ram up a lot for thing like the SISFB, which // shares high memory with the CPU. pci_configure(); post_code(0x88);
pci_enable(); pci_initialize(); post_code(0x89);
mem = get_ramsize(); post_code(0x70); totalmem = 0; for(tmem = mem; tmem->sizek; tmem++) { totalmem += tmem->sizek; } printk_info("totalram: %ldM\n", (totalmem + 512) >> 10); /* Round to the nearest meg */
/* Fully initialize the cpu before configuring the bus */ boot_cpu = cpu_initialize(mem); boot_index = processor_index(boot_cpu); printk_spew("BOOT CPU is %d\n", boot_cpu); processor_map[boot_index] = CPU_BOOTPROCESSOR|CPU_ENABLED;
/* Now start the other cpus initializing * The sooner they start the sooner they stop. */ post_code(0x75); startup_other_cpus(processor_map); post_code(0x77);
/* make certain we are the only cpu running in linuxBIOS */ wait_for_other_cpus();
/* Now that we have collected all of our information * write our configuration tables. */ write_tables(mem);
elfboot(streams, get_lb_mem()); }
----- Original Message ----- From: "Eric W. Biederman" ebiederman@lnxi.com To: "LinuxBIOS" linuxbios@clustermatic.org Sent: Tuesday, April 15, 2003 11:41 AM Subject: 1.1 development release targets.
To implement this I have started a freebios2 tree at sourceforge and I will gradually populating this tree. I am taking the expedient of copying old code over as needed. Leaving old code for now unneeded functionality to just fade away. It is the only easy
Have you considered using the branch facility of CVS?
Cheers,
Jeremy
"Jeremy Jackson" jerj@coplanar.net writes:
To implement this I have started a freebios2 tree at sourceforge and I will gradually populating this tree. I am taking the expedient of copying old code over as needed. Leaving old code for now unneeded functionality to just fade away. It is the only easy
Have you considered using the branch facility of CVS?
Thought about it.
I don't much care about the CVS history. And where there are several trees it is less then correct a number of times. I am about ready to rip out all of the $Id$ tags from the tree they are a consistent source of noise when you have two different repositories and you are comparing the differences.
In addition. By pulling in source modules in on demand I have a real nice way of filtering out old dead code and showing which code works in the new development tree. With my radical changes to hardwaremain everything breaks until it gets fixed up.
So I guess I don't see an advantage in using the cvs branch feature, at this point.
Eric
----- Original Message ----- From: "Eric W. Biederman" ebiederman@lnxi.com To: "Jeremy Jackson" jerj@coplanar.net Cc: "LinuxBIOS" linuxbios@clustermatic.org Sent: Tuesday, April 15, 2003 2:04 PM Subject: Re: 1.1 development release targets.
"Jeremy Jackson" jerj@coplanar.net writes:
To implement this I have started a freebios2 tree at sourceforge and I will gradually populating this tree. I am taking the expedient of copying old code over as needed. Leaving old code for now unneeded functionality to just fade away. It is the only easy
Have you considered using the branch facility of CVS?
Thought about it.
I don't much care about the CVS history. And where there are several trees it is less then correct a number of times. I am about ready to rip out all of the $Id$ tags from the tree they are a consistent source of noise when you have two different repositories and you are comparing the differences.
There is the -kk keyword substitution mode. But you have to rid the repository (at least HEAD version) of any -kb (binary) files first.
In addition. By pulling in source modules in on demand I have a real nice way of filtering out old dead code and showing which code works in the new development tree. With my radical changes to hardwaremain everything breaks until it gets fixed up.
There are Exp/Stable version labels, which nobody uses, or (never done this though) you could check in an empty branch, then pull the files in one at a time.
So I guess I don't see an advantage in using the cvs branch feature, at this point.
Probably not. CVS doesn't handle chaos very well (moving files, renaming dirs, etc). But if Ron it to start creating releases at some point, CVS is definitely your friend. With production code, being able to branch an old release and merge *just* the fixes to a bug from the HEAD branch, then tag it and push out a build is smooth, like butta, it's something I've used on a production system and it just works.
So not using CVS to branch probably isn't hurting anything at this point, but I think it's a good idea to start thinking about the issues. I think getting rid of binary files in the repository is pretty important. It's ok for .jpg files on a website project, where nobody uses branches (or as most web monkeys operate even release tags), but it's not good for serious projects.
Regards,
Jeremy
Eric W. Biederman wrote:
- Use the elf bootloader
What about the alternative floppy/ide routines? There are a lot of people using this, although I think it could be made better by using the bzImage and jumping to startup_32 etc.
-Steve
Steve Gehlbach steve@nexpath.com writes:
Eric W. Biederman wrote:
- Use the elf bootloader
What about the alternative floppy/ide routines?
Given that there are several types of rom chips we will need to continue to support several types of loaders, not just loading from a classic x86 rom chip. I think the floppy/ide routines may be a bit of unnecessary but there is no real impact on the rest of the code base.
Note: All of these drivers are currently in etherboot and you can compile them into the same etherboot binary.
There are a lot of people using this, although I think it could be made better by using the bzImage and jumping to startup_32 etc.
Not at all. Jumping straight to startup_32 is a very bad idea.
First because most times LinuxBIOS is ported people don't have enough time, the code base needs to be optimized for to make simple fast ports. To achieve this everything that can be reused and is motherboard independent needs to be split off into it's own separate binary. And drawing a line at elfboot and saying no further features beyond this point keeps the code bloat down.
Second startup_32 is not an officially supported kernel entry point and so it is subject to change whenever someone sees a better way of making it work. This means for example the code in the tree does not work with the redhat 9 kernel for example. A little bit of wrapper code in mkelfImage that we can change when the kernel changes and not cause people to need to reflash their BIOS is a good thing.
Third people have a lot of ideas on how the user interface to a BIOS should look: Openfirmware, EFI, PCBIOS, etherboot, redboot, the baremetal toolkit, etc. And it just does not make sense to support all of these as build options of LinuxBIOS. It works a lot better to have the LinuxBIOS table with information describing the hardware, and a simple general purpose bootloader that can load any of them. And then the Interface just needs to be built.
Right now with etherboot we have one very good option that the ELF loader can load. And with ADLO, we have a second option on the way. The bare metal toolkit has demonstrated how you can take cute little features like directly loading the Linux kernel still support them, but have the code loaded with the ELF bootloader.
In the 1.0.x release we won't remove code but for the development release I don't see how supporting anything except the ELF bootloader makes sense. The concept has proved itself sound. And it allows us to seriously talk about things like support for the BSDs.
Eric
On 15 Apr 2003, Eric W. Biederman wrote:
Steve Gehlbach steve@nexpath.com writes:
What about the alternative floppy/ide routines?
Given that there are several types of rom chips we will need to continue to support several types of loaders, not just loading from a classic x86 rom chip. I think the floppy/ide routines may be a bit of unnecessary but there is no real impact on the rest of the code base.
I think there is going to be continued use of the ide/floppy stuff without etherboot. I have requests for that all the time. It's going to have to stay.
I support only loading elfboot images from linuxbios. It just makes too much sense.
ron
ron minnich rminnich@lanl.gov writes:
On 15 Apr 2003, Eric W. Biederman wrote:
Steve Gehlbach steve@nexpath.com writes:
What about the alternative floppy/ide routines?
Given that there are several types of rom chips we will need to continue to support several types of loaders, not just loading from a classic x86 rom chip. I think the floppy/ide routines may be a bit of unnecessary but there is no real impact on the rest of the code base.
I think there is going to be continued use of the ide/floppy stuff without etherboot. I have requests for that all the time. It's going to have to stay.
That is fine. As long as we can keep the restriction on only one compiled into the code.
Beyond the infrastructure level I really don't care.
I support only loading elfboot images from linuxbios. It just makes too much sense.
Eric
ron minnich wrote:
I think there is going to be continued use of the ide/floppy stuff without etherboot. I have requests for that all the time. It's going to have to stay.
I support only loading elfboot images from linuxbios. It just makes too much sense.
Does linuxbios in the current version support elfboot images from ide/floppy (directly, without etherboot)? I guess if it does I don't see it.
One issue I have with elfboot images is the inability to dynamically pass parameters to the zero page (specifically the vga cursor location). I understand the idea of not locking the boot mechanism into the bios, but there are pros and cons.
The final step of booting Linux is pretty independent of the other linuxbios code, though, so it is easy to patch in an alternate technique for someone (like me) that has specific requirements.
-Steve
On Wed, 16 Apr 2003, Steve Gehlbach wrote:
One issue I have with elfboot images is the inability to dynamically pass parameters to the zero page (specifically the vga cursor location). I understand the idea of not locking the boot mechanism into the bios, but there are pros and cons.
that is a good point. I think it can be resolved via the linuxbios tables that Eric has been pushing, and done in a way that will work with other OSes (e.g. freebsd).
ron
Steve Gehlbach steve@nexpath.com writes:
ron minnich wrote:
I think there is going to be continued use of the ide/floppy stuff without etherboot. I have requests for that all the time. It's going to have to stay. I support only loading elfboot images from linuxbios. It just makes too much sense.
Does linuxbios in the current version support elfboot images from ide/floppy (directly, without etherboot)? I guess if it does I don't see it.
Yes. The switch on the ``rom loader'' is the same on code, for either the elf loader or the other one.
One issue I have with elfboot images is the inability to dynamically pass parameters to the zero page (specifically the vga cursor location). I understand the idea of not locking the boot mechanism into the bios, but there are pros and cons.
As ron mentioned putting enough information in the LinuxBIOS table so the code in mkelfImage can properly position the vga cursor location is straight forward.
The final step of booting Linux is pretty independent of the other linuxbios code, though, so it is easy to patch in an alternate technique for someone (like me) that has specific requirements.
Right. But before we give up on a common mechanism I would like to see if we can figure out how to build a general purpose solution.
Eric
Does linuxbios in the current version support elfboot images from ide/floppy (directly, without etherboot)? I guess if it does I don't see it.
Yes. The switch on the ``rom loader'' is the same on code, for either the elf loader or the other one.
Thanks, I guess I never tried it since I needed to fiddle with the zero page parameters.
One issue I have with elfboot images is the inability to dynamically pass parameters to the zero page (specifically the vga cursor location). I understand the idea of not locking the boot mechanism into the bios, but there are pros and cons.
As ron mentioned putting enough information in the LinuxBIOS table so the code in mkelfImage can properly position the vga cursor location is straight forward.
I don't understand. Which linuxbios table are you referring to? Is this a proposal or currently implemented?
-Steve
Steve Gehlbach steve@nexpath.com writes:
Does linuxbios in the current version support elfboot images from ide/floppy (directly, without etherboot)? I guess if it does I don't see it.
Yes. The switch on the ``rom loader'' is the same on code, for either the elf loader or the other one.
Thanks, I guess I never tried it since I needed to fiddle with the zero page parameters.
I have found that most of the time it is enough to simply tell the kernel it has a VGA adapter. And the rest it seems to handle properly. That is what I currently do in mkelfImage.
One issue I have with elfboot images is the inability to dynamically pass parameters to the zero page (specifically the vga cursor location). I
understand
the idea of not locking the boot mechanism into the bios, but there are pros
and
cons.
As ron mentioned putting enough information in the LinuxBIOS table so the code in mkelfImage can properly position the vga cursor location is straight forward.
I don't understand. Which linuxbios table are you referring to? Is this a proposal or currently implemented?
Currently implemented.
see src/include/boot/linuxbios_tables.h
The LinuxBIOS table on x86 is located near address 0, or around 0xF0000 - 0x100000. It is a binary table of tagged data so it can be grown and expanded while still retaining backwards compatibility. It is at a fixed address so we don't need to pass it explicitly to anyone, but the data in it is position independent in case the table needs to be moved. In addition the table is composed of fixed size data types so it can be used on dual 32/64 bit platforms without surprises. This is how we currently pass memory size information.
We have mptables and irq tables setup separately mostly for historical reasons. As we rework things in 1.1. for LinuxBIOS to assign irqs I want to get those in there as well and generate the other tables from the LinuxBIOS table.
Any binary loaded under LinuxBIOS can go out look for and find the LinuxBIOS table. We tried passing parameters explicitly but the LinuxBIOS table is much more stable, for large vary amounts of data. Especially when you interpose something like etherboot in between your BIOS and your loaded kernel.
Eric