There's no current standard way to communicate memory size info from linuxbios boot code to the kernel. My kernel was dying because of a hard-coded size in arch/i386/kernel/setup.c:
ALT_MEM_K = 254*1024;
The quick fix for now:
ALT_MEM_K = 62*1024;
I was about to test this when my flash ram stopped programming, I am now waiting on an order for more.
Try it on your version.
We need a standard way to get PARAM to the kernel, now that the BIOS is no longer there to do it. The 0x90000 PARAM won't work, since that set of locations is managed in code we don't even run (from arch/i386/boot). Ideas welcome.
ron p.s. I'd appreciate seeing 'make' errors from anybody. Please remember though that for linuxbios you have to: cd freebios/linuxbios/<mainboard-name>, e.g. cd freebios/linuxbios/SIS630
Then type make
Make from the top level of freebios does not work.
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
Ronald G Minnich wrote:
There's no current standard way to communicate memory size info from linuxbios boot code to the kernel. My kernel was dying because of a hard-coded size in arch/i386/kernel/setup.c:
ALT_MEM_K = 254*1024;The quick fix for now:
ALT_MEM_K = 62*1024;I was about to test this when my flash ram stopped programming, I am now waiting on an order for more.
Try it on your version.
We need a standard way to get PARAM to the kernel, now that the BIOS is no longer there to do it. The 0x90000 PARAM won't work, since that set of locations is managed in code we don't even run (from arch/i386/boot). Ideas welcome.
Can you steal code from LILO to patch the in-core kernel image with values it needs?
Right now the Linux kernel depends on a memory map read from BIOS. One solution -- which I think should belong in the official kernel -- might be to create our own memory map, and then pass the physical address of that map into the kernel image.
Jeff
On Thu, 1 Jun 2000, Jeff Garzik wrote:
Can you steal code from LILO to patch the in-core kernel image with values it needs?
Right now the Linux kernel depends on a memory map read from BIOS. One solution -- which I think should belong in the official kernel -- might be to create our own memory map, and then pass the physical address of that map into the kernel image.
Some values come into the kernel now from page zero. Page zero is made inaccessible early in the boot process. Since its not used, it seems like a good place to put the PARAM variables. What I was wondering was whether we could have the initial boot code put a PARAM struct at page 0 and let linux bcopy it in to its own empty_zero_page, which is where the regular BIOS stuff is put by the code in arch/i386/boot (if my memory is correct).
It's also long past time that PARAM was made a struct :-)
On a different not: Now that I've seen how you init a keyboard, I've got no problem with leaving that code in :-)
ron
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
|<><><><><> Original message from Ronald G Minnich <><><><><> |On Thu, 1 Jun 2000, Jeff Garzik wrote: | |> Can you steal code from LILO to patch the in-core kernel image with |> values it needs? |> |> Right now the Linux kernel depends on a memory map read from BIOS. One |> solution -- which I think should belong in the official kernel -- might |> be to create our own memory map, and then pass the physical address of |> that map into the kernel image. | |Some values come into the kernel now from page zero. Page zero is made |inaccessible early in the boot process. Since its not used, it seems like |a good place to put the PARAM variables. What I was wondering was whether |we could have the initial boot code put a PARAM struct at page 0 and let |linux bcopy it in to its own empty_zero_page, which is where the regular |BIOS stuff is put by the code in arch/i386/boot (if my memory is correct). | |It's also long past time that PARAM was made a struct :-) | |On a different not: Now that I've seen how you init a keyboard, I've got |no problem with leaving that code in :-)
Ron, Given that your running C code prior to branching to the Linux kernel entry point, there is really no reason that you can't have a nice C environment already setup before calling the Linux kernel. With C code calling C code you can then use C calling conventions for passing information to the kernel. My recommendation is to use something along the lines of
int linux_kernel_entrypoint(int argc, char **argv, char **envp) { .... }
You then don't need to hard code any locations. Linux when it is ready to take over and has enough info can then discard what ever remains of the linuxbios environment. To pass information about the system to the kernel use envp. This actually works pretty cleanly and you won't have a struct that is out of sync between the kernel and linuxbios. C calling conventions don't change very quickly so it is a pretty safe bet.
Here is an example of how things might be called. In addition you might want to look at some of the NetBSD and OpenBSD ports that do similar things.
char *envp[MAX_ENVP];
envp[0] = "BIOS=linuxbios"; /* this must be the first parameter */ envp[1] = "bios_rev=xx.xx"; envp[2] = "manufacture=Joe's computers"; envp[3] = "motherboard=JC2000"; envp[4] = "chipset=SiS630" envp[5] = memsize; sprintf(memsize, "memsize=%d", available_memory); envp[6] = ...
/* call the kernel entry point */ (*loadfile->entrypoint)(argc, argv, envp);
If the kernel needs to deal with being booted from different environments, it can relatively easily probe for the 'BIOS=linuxbios' string at the begining of envp. If it ain't there then it ain't linuxbios and it will have to deal. If it is linuxbios then a whole assortment of assumptions can then be made.
If you do opt to go this route then I would like to give you some recommendations on what envp variables you should define and what there names should be for compatability with other BIOSes.
TJ Merritt tjm@codegen.com 1-415-834-9111 - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
"Thomas J. Merritt" wrote:
|<><><><><> Original message from Ronald G Minnich <><><><><> |On Thu, 1 Jun 2000, Jeff Garzik wrote: | |> Can you steal code from LILO to patch the in-core kernel image with |> values it needs? |> |> Right now the Linux kernel depends on a memory map read from BIOS. One |> solution -- which I think should belong in the official kernel -- might |> be to create our own memory map, and then pass the physical address of |> that map into the kernel image.
Just a thought - ignore me if it's daft - loadlin takes command line params and passes them to the kernel - why not use the same method...?
-- Yours
Matthew
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Damn Sig's can be vulgar, un-sightly or just plain damn rude... So can I so whats new?
On Fri, 2 Jun 2000, Matthew Sullivan wrote:
Just a thought - ignore me if it's daft - loadlin takes command line params and passes them to the kernel - why not use the same method...?
not daft as far as I can tell. I am getting too hung up on PARAM. The biggest problem is the kernel expects all this stuff to be on the empty_zero_page. linuxbios boot code doesn't know where in the kernel that is -- because linux setup code (arch/i386/boot/*.S) copies stuff from 0x90000 and other places to the empty_zero_page.
ron
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
Hi,
Ronald G Minnich wrote:
On Fri, 2 Jun 2000, Matthew Sullivan wrote:
Just a thought - ignore me if it's daft - loadlin takes command line params and passes them to the kernel - why not use the same method...?
not daft as far as I can tell. I am getting too hung up on PARAM. The biggest problem is the kernel expects all this stuff to be on the empty_zero_page. linuxbios boot code doesn't know where in the kernel that is -- because linux setup code (arch/i386/boot/*.S) copies stuff from 0x90000 and other places to the empty_zero_page.
I am assuming you mean:
/* * This is set up by the setup-routine at boot-time */ #define EXT_MEM_K (*(unsigned short *)0x90002) #define DRIVE_INFO (*(struct drive_info *)0x90080) #define SCREEN_INFO (*(struct screen_info *)0x90000) #define RAMDISK_SIZE (*(unsigned short *)0x901F8) #define ORIG_ROOT_DEV (*(unsigned short *)0x901FC) #define AUX_DEVICE_INFO (*(unsigned char *)0x901FF)
extracted from: Loadlin:padjust.c - stolen from: arch/i386/boot/compressed/misc.c
.... you cannot use these addresses...?
/ Mat
PS I have been following the list but only loosly and have not been able to take a look at the code (or even use my dev machine) for a couple of months now - so I maybe way off course... feel free to point me in the right direction :-)
-- Yours
Matthew
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- More Computer Terminology -=-=-=-=-=-=-=-=-=-=-=-=- Cursor: A computer user who is abusive to his machine.
On Thu, 1 Jun 2000, Thomas J. Merritt wrote:
Given that your running C code prior to branching to the Linux kernel entry point, there is really no reason that you can't have a nice C environment already setup before calling the Linux kernel. With C code calling C code you can then use C calling conventions for passing information to the kernel. My recommendation is to use something along the lines of
geez, why don't I think of this stuff? This is GREAT!
If you do opt to go this route then I would like to give you some recommendations on what envp variables you should define and what there names should be for compatability with other BIOSes.
tell me what you want!
I like it.
ron
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
-
Jeff Garzik -
Matthew Sullivan -
Ronald G Minnich -
Thomas J. Merritt