lkml.org 
[lkml]   [2002]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] x86 boot enhancements, Clean up the 32bit entry points 6/11
From
Date
Etienne Lorrain <etienne_lorrain@yahoo.fr> writes:

> Seems that previous message did not go through, rewrite.
>
> I am sorry I did not check enough your patch.
> You are speaking of: arch/i386/boot/compressed/head.S

That is what you quoted, so I assumed that is what you were
talking about.

> I am speaking of: arch/i386/kernel/head.S
>
> Gujin skip completely arch/i386/boot/compressed/* and really
> boots the file '$$tmppiggy.gz' line 44 of file:
> arch/i386/boot/compressed/Makefile
>
> So you can do whatever you want with the "first" 32 bits entry point,
> I am just concerned by the "second" kernel 32 bits entry point, in
> arch/i386/kernel/head.S
>
> I still have a problem to detect the size of your decompressor, and that
> is my use of the "lss" instruction.
> This "lss SYMBOL_NAME(stack_start),%esp" gives an access to the symbol
> 'stack_start', so it is quite easy to find back the GZIP signature
> of the initial '$$tmppiggy.gz' in what I call my "compatibility" mode,
> i.e. booting the legacy vmlinuz files - and skipping all of the real mode
> code and the decompressor code.

Well it should be easier I put an explicit pointer to it.

> This "lss" line has not always been at the same offset, but is around
> since maybe even the 0.01 kernel, it is quite easy to find it from its
> hexadecimal form. (function vmlinuz_header_treat() in vmlinuz.c of
> Gujin).
>
> The loaded high/loaded low stuff is just to know if I have to remove
> 0x100000 or 0x1000 from this symbol to have the number of bytes
> to skip on the file.
> By the way, the bit in the kernel header is set by the bootloader to say
> where it has loaded the kernel, not by the compiler/linker chain.

Nope. LOADED_HIGH in loadflags is set at compile time. It determines
where the bootloader must load the compressed part of the kernel.

> So is it possible to write somewhere how much code to skip or the offset
> of the kernel GZIP signature?

Already done.

> Something like:
> jmp next
> lss SYMBOL_NAME(stack_start),%esp
> next:
> Would make me really happy, but is dirty.
> Changing the 'tmppiggy.lnk' in the Makefile can be done, but the value
> (to know the length of the decompressor code) has to be _before_ the code
> itself in the raw file.

Yep.

> Else whatever signature at whatever fixed address with the code+rodata
> size following would make me happy.

Check out the code.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.028 / U:1.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site