Hello,
The Gujin bootloader (now at version 1.8) can natively load
compressed ELF files, and these three patches enable to generate
this "linux-2.6.20.kgz" file format.
Just as a remainder, to generate a bzImage file, those steps
are needed:
1- Compile the core kernel and link it into the ELF file vmlinux
at the top of the directory. Also compile and link modules.
2- Create a binary image of the kernel memory.
3- Compress this binary image with GZIP.
4- Assemble and link in an independant file the bootsector, the
setup and the real-mode code (in assembler) to start and gather
BIOS information.
5- Compile the protected mode code to decompress the kernel,
and re-adjust relocation defined at step 1 after decompression.
6- Get the binary image for real-mode and protected-mode parts
7- Mix the 3 parts in the same file named bzImage.
The previous version of Gujin were loading Linux kernel as after
step 3, the new one is basically able to load after step 1.
The ELF image is still better stripped of its debugging information
(to reduce time to load from disk) and compressed by GZIP to be able
to check its CRC32.
The BIOS information gathering did not evolve that much since the
first version of this patch - still written in C and included in
the initial link at load address 0 (no conflict with linux code at
address 0xC0000000).
The standard comment field of the GZIP is still used to describe this
kernel (processor, license...) but no more needs address references
because all needed information (address to load, address and size of
the real-mode code to gather information from the BIOS) is taken from
the ELF program header table (if real-mode code is not found it is
also searched in the section table).
Gujin real-mode C BIOS gathering code is automatically removed by
the "objdump" at step 2 when generating a bzImage, so there is no
need to disable anything to continue using Lilo/Grub/Syslinux...
The first two patch contains the interesting parts, that is files
realmode.[ch] to gather the BIOS informations, a small modification
to the command line (treating the first words as the pathname and
kernel name if present) which help Gujin autodetect the root
partition, the linker modifications (there is a single link with
Gujin kernel file "/boot/linux-2.6.20.kgz") and the Makefile
modifications.
The third patch just adds two files as independant commands,
gzcopy.c to view/edit/modify Gzip files (BSD like licensed) and
gzparam.c to display a single line used as the GZIP comment,
to forbid to load ia64 kernels on ia32 and this kind of
restrictions.
For me, these patchs are ready to be included in the kernel,
but I am ready for (or even waiting) any interesting discussion
about them.
I most like the simplicity of the generation system / load
process after the patch, just execute:
make /boot/linux-2.6.20.kgz
(recompile the modules if you have some) and reboot...
More info about Gujin at:
http://gujin.org
Have fun,
Etienne.
___________________________________________________________________________
D?couvrez une nouvelle fa?on d'obtenir des r?ponses ? toutes vos questions !
Profitez des connaissances, des opinions et des exp?riences des internautes sur Yahoo! Questions/R?ponses
http://fr.answers.yahoo.com
First of all, if sending attached patches, *MAKE SURE* they're text/plain.
> diff -uprN -X linux-2.6.20/Documentation/dontdiff linux-2.6.20/arch/i386/kernel/setup.c linux-2.6.20-gujin/arch/i386/kernel/setup.c
> --- linux-2.6.20/arch/i386/kernel/setup.c 2007-02-04 18:44:54.000000000 +0000
> +++ linux-2.6.20-gujin/arch/i386/kernel/setup.c 2007-02-05 21:27:01.000000000 +0000
> @@ -579,6 +579,19 @@ void __init setup_arch(char **cmdline_p)
> strlcpy(command_line, saved_command_line, COMMAND_LINE_SIZE);
> *cmdline_p = command_line;
>
> + /*
> + * If the command line begin with '/', it is the filename of the
> + * kernel file - like a shell command line. That can be used to
> + * deduce where root was located when the kernel was compiled,
> + * inside a directory of root named /boot, inside a small partition
> + * mounted on a directory of root named /boot or in the root
> + * directory itself.
> + */
> + if (**cmdline_p == '/')
> + while (**cmdline_p != ' ' && **cmdline_p != '\t'
> + && **cmdline_p != '\n' && **cmdline_p != '\0')
> + ++*cmdline_p;
> +
> max_low_pfn = setup_memory();
>
> /*
The standard way to do this is to have a command line argument named
BOOT_IMAGE (as in BOOT_IMAGE=/foo/bar/baz). There is no reason to do
this differently from every other bootloader.
Why build the real-mode code as part of the kernel binary? If you have
to reference kernel symbols, you can do that with the -R option to ld.
Bundling it into the kernel binary just to then extract it later is
silly at best.
> @@ -1106,6 +1179,9 @@ help:
> @echo 'Other generic targets:'
> @echo ' all - Build all targets marked with [*]'
> @echo '* vmlinux - Build the bare kernel'
> + @echo " /boot/linux-$(KERNELRELEASE).kgz - create a boot kernel for the Gujin bootloader"
> + @echo ' /boot/linux.kgz ROOT=/dev/hda1 - do not autodetect root filesystem at boot time'
> + @echo ' /boot/linux.kgz ROOT=auto - root filesystem from current /proc/cmdline'
> @echo '* modules - Build all modules'
> @echo ' modules_install - Install all modules to INSTALL_MOD_PATH (default: /)'
> @echo ' dir/ - Build all files in dir and below'
This doesn't exactly fit very well the standard pattern. Something like
make gujin TARGET=... would be more like it.
Given how many of your files are highly Gujin-specific, and have generic
names, please put them in a subdirectory (e.g. arch/i386/boot/gujin/).
-hpa
On Mon, Feb 05, 2007 at 04:37:43PM -0800, H. Peter Anvin wrote:
> First of all, if sending attached patches, *MAKE SURE* they're text/plain.
>
> >diff -uprN -X linux-2.6.20/Documentation/dontdiff
> >linux-2.6.20/arch/i386/kernel/setup.c
> >linux-2.6.20-gujin/arch/i386/kernel/setup.c
> >--- linux-2.6.20/arch/i386/kernel/setup.c 2007-02-04
> >18:44:54.000000000 +0000
> >+++ linux-2.6.20-gujin/arch/i386/kernel/setup.c 2007-02-05
> >21:27:01.000000000 +0000
> >@@ -579,6 +579,19 @@ void __init setup_arch(char **cmdline_p)
> > strlcpy(command_line, saved_command_line, COMMAND_LINE_SIZE);
> > *cmdline_p = command_line;
> >
> >+ /*
> >+ * If the command line begin with '/', it is the filename of the
> >+ * kernel file - like a shell command line. That can be used to
> >+ * deduce where root was located when the kernel was compiled,
> >+ * inside a directory of root named /boot, inside a small partition
> >+ * mounted on a directory of root named /boot or in the root
> >+ * directory itself.
> >+ */
> >+ if (**cmdline_p == '/')
> >+ while (**cmdline_p != ' ' && **cmdline_p != '\t'
> >+ && **cmdline_p != '\n' && **cmdline_p != '\0')
> >+ ++*cmdline_p;
> >+
> > max_low_pfn = setup_memory();
> >
> > /*
>
> The standard way to do this is to have a command line argument named
> BOOT_IMAGE (as in BOOT_IMAGE=/foo/bar/baz). There is no reason to do
> this differently from every other bootloader.
>
> Why build the real-mode code as part of the kernel binary? If you have
> to reference kernel symbols, you can do that with the -R option to ld.
> Bundling it into the kernel binary just to then extract it later is
> silly at best.
>
Building real mode code with kernel binary (vmlinux) has got another
disadvantage that it breaks using vmlinux for kdump purposes. One compiles
the kernel binary to execute from a different address but real mode code/data
will continue to be at virtual/physical addr 0 and kexec can not load it
as that physical memory is not available at all. Kdump skips the real mode
code execution.
I don't know much about Gujin, but advantage here seems to be that it has
capability to load elf files and that's why the attempt to turn kernel binary
into a compressed elf image. Why don't we then simply add an ELF header to
bzImage and Gujin and any ELF loader including Gujin, should be able to load
it? (As Eric had done in one of the implementations in the past?) Why to
create the new infrastructure?
Thanks
Vivek
Vivek Goyal wrote:
>
> I don't know much about Gujin, but advantage here seems to be that it has
> capability to load elf files and that's why the attempt to turn kernel binary
> into a compressed elf image. Why don't we then simply add an ELF header to
> bzImage and Gujin and any ELF loader including Gujin, should be able to load
> it? (As Eric had done in one of the implementations in the past?) Why to
> create the new infrastructure?
>
Well, Gujin wants additional code too.
Putting an ELF header on bzImage broke some bootloaders (GRUB, I
believe), so that's not going to happen again. See the relocatable
bzImage thread...
-hpa
On Mon, Feb 05, 2007 at 10:16:59PM -0800, H. Peter Anvin wrote:
> Vivek Goyal wrote:
> >
> >I don't know much about Gujin, but advantage here seems to be that it has
> >capability to load elf files and that's why the attempt to turn kernel
> >binary
> >into a compressed elf image. Why don't we then simply add an ELF header to
> >bzImage and Gujin and any ELF loader including Gujin, should be able to
> >load
> >it? (As Eric had done in one of the implementations in the past?) Why to
> >create the new infrastructure?
> >
>
> Well, Gujin wants additional code too.
>
> Putting an ELF header on bzImage broke some bootloaders (GRUB, I
> believe), so that's not going to happen again. See the relocatable
> bzImage thread...
>
That time, grub was working fine but lilo had broken on one of Andrew's
machine. I could not reproduce the problem on my setup and had no clue what
was the issue. Hence got rid of ELF header from bzImage which was non-essential
stuff for relocatable kernel. But that issue should be fixable.
Thanks
Vivek
Vivek Goyal wrote:
>
> That time, grub was working fine but lilo had broken on one of Andrew's
> machine. I could not reproduce the problem on my setup and had no clue what
> was the issue. Hence got rid of ELF header from bzImage which was non-essential
> stuff for relocatable kernel. But that issue should be fixable.
>
Either way, though, putting Gujin-specific code in the main kernel
output is a pretty dull thud.
-hpa
On Mon, Feb 05, 2007 at 10:38:30PM -0800, H. Peter Anvin wrote:
> Vivek Goyal wrote:
> >
> >That time, grub was working fine but lilo had broken on one of Andrew's
> >machine. I could not reproduce the problem on my setup and had no clue what
> >was the issue. Hence got rid of ELF header from bzImage which was
> >non-essential
> >stuff for relocatable kernel. But that issue should be fixable.
> >
>
> Either way, though, putting Gujin-specific code in the main kernel
> output is a pretty dull thud.
>
Agreed.
Thanks
Vivek
Vivek Goyal <[email protected]> writes:
> On Mon, Feb 05, 2007 at 10:38:30PM -0800, H. Peter Anvin wrote:
>> Vivek Goyal wrote:
>> >
>> >That time, grub was working fine but lilo had broken on one of Andrew's
>> >machine. I could not reproduce the problem on my setup and had no clue what
>> >was the issue. Hence got rid of ELF header from bzImage which was
>> >non-essential
>> >stuff for relocatable kernel. But that issue should be fixable.
>> >
>>
>> Either way, though, putting Gujin-specific code in the main kernel
>> output is a pretty dull thud.
>>
>
> Agreed.
Just for documentation the current interface is you come in through
the kernels 16bit entry point and get all of it's BIOS calls, or your
bootloader is responsible for getting the equivalent information
somehow.
>From what little I skimmed part of what Gujin wanted to do was sane
at first glance. Just boot a gziped vmlinux like the other
architectures. The problem was the 16bit code.
So there may be some good ideas buried in there somewhere, but it
likely to take some doing, and patches that I have to save before
I read them are a real pain!
Eric
Eric W. Biederman wrote:
>
> Just for documentation the current interface is you come in through
> the kernels 16bit entry point and get all of it's BIOS calls, or your
> bootloader is responsible for getting the equivalent information
> somehow.
>
> From what little I skimmed part of what Gujin wanted to do was sane
> at first glance. Just boot a gziped vmlinux like the other
> architectures. The problem was the 16bit code.
>
> So there may be some good ideas buried in there somewhere, but it
> likely to take some doing, and patches that I have to save before
> I read them are a real pain!
>
Actually, as far as I can see, he has re-invented having a real-mode
code chunk which then gets run before the protected-mode kernel. We
already have that! You can even intercept between running real-mode and
protected-mode if you really want to.
I don't really see anything new here. The one thing that he does which
we might want to consider emulating is writing the real-mode code in C.
Right now, the assembly code is very cluttered, and with the size
limit having been, long ago, raised from 2K to 32K we should be able to
fit a fair bit of code even if we use C.
-hpa