Please check patch attached. It could be applied to mkelfImage cleanly.
Make mkelfImage to take vmlinux in elf64 for amd64
Actually the vmlinux on amd64 is elf64, so parse it and set it back to elf32.
Signed-off-by: Yinghai Lu yinghai.lu@amd.com
"Lu, Yinghai" yinghai.lu@amd.com writes:
Please check patch attached. It could be applied to mkelfImage cleanly.
Make mkelfImage to take vmlinux in elf64 for amd64
Actually the vmlinux on amd64 is elf64, so parse it and set it back to elf32.
Nack.
The 32bit entry point for 64bit kernels is going away. If you want to use vmlinux directly for 64bit kernels please use the 64bit entry point.
That requires a whole new kernel type to be added to mkelfImage, unless I am missing something obvious.
Eric
p.s. Sorry for the delayed reply.
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
The 32bit entry point for 64bit kernels is going away. If you want to use vmlinux directly for 64bit kernels please use the 64bit entry point.
then with the 64bit entry point in 64bit kernel vmlinux, is it ok with elfboot in current 32bit LinuxBIOS?
YH
yhlu yinghailu@gmail.com writes:
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
The 32bit entry point for 64bit kernels is going away. If you want to use vmlinux directly for 64bit kernels please use the 64bit entry point.
then with the 64bit entry point in 64bit kernel vmlinux, is it ok with elfboot in current 32bit LinuxBIOS?
Well you either there needs to be a trampoline to go from 32 to 64bit mode in mkelfImage or that little bit of logic needs to be in elfboot. That logic already exists in etherboot.
Eric
So the start32 will go way in vmlinx 64 bit?
Then you will need 64bit boot loader.
Or can I use entrypoint for start64-0x100 to get the address for start32
YH
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
yhlu yinghailu@gmail.com writes:
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
The 32bit entry point for 64bit kernels is going away. If you want to use vmlinux directly for 64bit kernels please use the 64bit entry point.
then with the 64bit entry point in 64bit kernel vmlinux, is it ok with elfboot in current 32bit LinuxBIOS?
Well you either there needs to be a trampoline to go from 32 to 64bit mode in mkelfImage or that little bit of logic needs to be in elfboot. That logic already exists in etherboot.
Eric
yhlu yinghailu@gmail.com writes:
So the start32 will go way in vmlinx 64 bit?
Then you will need 64bit boot loader.
If you are booting vmlinux yes.
Or can I use entrypoint for start64-0x100 to get the address for start32
Nope. The code will go 64bit in the decompresser.
Eric
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
Then you will need 64bit boot loader.
If you are booting vmlinux yes.
Wow? what happened?
Or can I use entrypoint for start64-0x100 to get the address for start32
Nope. The code will go 64bit in the decompresser.
vmlinux should not include decompressor. or vmlinux will become vmlinuz?
YH
yhlu yinghailu@gmail.com writes:
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
Then you will need 64bit boot loader.
If you are booting vmlinux yes.
Wow? what happened?
Nothing. That is just where it looks like vmlinux on x86_64 is going. There are two separate conversations to take it there.
Or can I use entrypoint for start64-0x100 to get the address for start32
Nope. The code will go 64bit in the decompresser.
vmlinux should not include decompressor. or vmlinux will become vmlinuz?
The standard thing to boot is bzImage.
Like I said the 32bit entry point is really not supported for vmlinux on x86_64 please don't count on it being there.
bzImage will shortly also become ELF but that is another story...
Eric
for x86_64 there will be vmlinux and bzImage. current vmlinux entry point is startup_32, bzImage will be in elf64, and together with vmlinux will not have startup_32.
So we must use 64bit boot loader. Do we have 64bit boot loader except kexec?
but question is for AP, you will still need from 16bit(trampoline.S)-->32bit(startup_32 in head.S )-->64bit (startup_64 in head.S).
are you going to move startup_32 to trampoline.S?
YH
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
yhlu yinghailu@gmail.com writes:
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
Then you will need 64bit boot loader.
If you are booting vmlinux yes.
Wow? what happened?
Nothing. That is just where it looks like vmlinux on x86_64 is going. There are two separate conversations to take it there.
Or can I use entrypoint for start64-0x100 to get the address for start32
Nope. The code will go 64bit in the decompresser.
vmlinux should not include decompressor. or vmlinux will become vmlinuz?
The standard thing to boot is bzImage.
Like I said the 32bit entry point is really not supported for vmlinux on x86_64 please don't count on it being there.
bzImage will shortly also become ELF but that is another story...
Eric
yhlu yinghailu@gmail.com writes:
for x86_64 there will be vmlinux and bzImage. current vmlinux entry point is startup_32, bzImage will be in elf64, and together with vmlinux will not have startup_32.
So we must use 64bit boot loader. Do we have 64bit boot loader except kexec?
Etherboot qualifies. It at least has the necessary code to switch into 64bit mode if it hasn't bit rotted since I added it.
but question is for AP, you will still need from 16bit(trampoline.S)-->32bit(startup_32 in head.S )-->64bit (startup_64 in head.S).
are you going to move startup_32 to trampoline.S?
Yes. Because it allows startup_64 to be above 4G.
Eric
more worse latest one put startup_32 to 0x200000.
and mkelfImage is harded code to call startup_32 or other entry_point in bzImage at 0x100000. # Jump to the linux kernel ljmp $ PROT_CODE_SEG , $ 0x100000
need to make head.S to get into 64bit and use real entry pointer by vmlinux and bzImage in elf64 format.
YH
yhlunb:/home/yhlu/xxx/xx/kernel/linux-2.6 # readelf -hl vmlinux ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x200100 Start of program headers: 64 (bytes into file) Start of section headers: 7192496 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 5 Size of section headers: 64 (bytes) Number of section headers: 42 Section header string table index: 39
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000100000 0xffffffff80200000 0x0000000000200000 0x000000000032f508 0x000000000032f508 R E 100000 LOAD 0x0000000000430000 0xffffffff80530000 0x0000000000530000 0x0000000000148ec8 0x0000000000148ec8 RWE 100000 LOAD 0x0000000000600000 0xffffffffff600000 0x0000000000679000 0x0000000000000c08 0x0000000000000c08 RWE 100000 LOAD 0x000000000067a000 0xffffffff8067a000 0x000000000067a000 0x000000000005dd68 0x00000000000e91c8 RWE 100000 NOTE 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 R 8
yhlu yinghailu@gmail.com writes:
more worse latest one put startup_32 to 0x200000.
and mkelfImage is harded code to call startup_32 or other entry_point in bzImage at 0x100000. # Jump to the linux kernel ljmp $ PROT_CODE_SEG , $ 0x100000
need to make head.S to get into 64bit and use real entry pointer by vmlinux and bzImage in elf64 format.
1M for bzImage remains fine. All bootloaders would break if you changed that. But for vmlinux you pretty much have it nailed.
Eric
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
1M for bzImage remains fine. All bootloaders would break if you changed that. But for vmlinux you pretty much have it nailed.
Actually, we only mkelfImage with bzImage before we are trying to use lzma to compress elf (tiny kernel vmlinux + uncompressed). lzma can get 5% more space than bz2.
I hope you can keep startup_32 in your new arch/x86_64/kernel/head.S. then we don't need to switch from 32bit mode to 64 bit mode in head.s of mkelfImage. and still convert 64elf to 32bit elf. Also it would make other 32 bit bootloader still can load vmlinux64. Then we only need to make sure head.s of mkelfImage can get correct entry_point.
Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need to switch 64bit before load 64bit elf.
YH
* yhlu yinghailu@gmail.com [061105 08:05]:
I hope you can keep startup_32 in your new arch/x86_64/kernel/head.S. then we don't need to switch from 32bit mode to 64 bit mode in head.s of mkelfImage. and still convert 64elf to 32bit elf. Also it would make other 32 bit bootloader still can load vmlinux64.
Are we not going to switch to 64bit mode in LinuxBIOS anyways? Then we just need a 64bit version of mkelfimage.
Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need to switch 64bit before load 64bit elf.
This is the preferred thing I guess, because it will allow us to use other 64bit payloads as well without requiring that they do the same weird 32->64bit trampolining as Linux does...
Stefan Reinauer stepan@coresystems.de writes:
Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need to switch 64bit before load 64bit elf.
This is the preferred thing I guess, because it will allow us to use other 64bit payloads as well without requiring that they do the same weird 32->64bit trampolining as Linux does...
Yes. Not imposing hacks on other solutions is nice.
Linux is important enough we can jump through hoops to get it loaded we shouldn't need that for other things.
Eric
On 11/5/06, Stefan Reinauer stepan@coresystems.de wrote:
Are we not going to switch to 64bit mode in LinuxBIOS anyways? Then we just need a 64bit version of mkelfimage.
Yes. actually the elf64 aware elfboot too.
This is the preferred thing I guess, because it will allow us to use other 64bit payloads as well without requiring that they do the same weird 32->64bit trampolining as Linux does...
depends, you could have two entries, so your payload could be loaded by 32elfboot or 64elfboot.
YH
Are we not going to switch to 64bit mode in LinuxBIOS anyways?
We probably should, PCIe requires 64-bit loads and stores (well most devices don't need those, but hey). It also makes accessing stuff above 4GB way easier, and you can use all 16 regs without needing prefixes.
Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need to switch 64bit before load 64bit elf.
This is the preferred thing I guess, because it will allow us to use other 64bit payloads as well without requiring that they do the same weird 32->64bit trampolining as Linux does...
That trampoline is really simple actually (well, after I sat down with it and a lot of paper for a few hours). A similar thing is needed to start a 32-bit payload from a 64-bit firmware of course.
[OT: want to see *really* simple? On PowerPC it's one bit only to select between 32- and 64-bit mode. I'm sooo spoilt].
Segher
yhlu yinghailu@gmail.com writes:
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
1M for bzImage remains fine. All bootloaders would break if you changed that. But for vmlinux you pretty much have it nailed.
Actually, we only mkelfImage with bzImage before we are trying to use lzma to compress elf (tiny kernel vmlinux + uncompressed). lzma can get 5% more space than bz2.
First a decode of letters, in bzImage the b stands for big and the z stands for gzip. We don't have a bzip2 decompressor in there.
An interesting question is if we make a bImage target that does everything except the decompression (because nothing would be compressed) would that suit your needs?
I hope you can keep startup_32 in your new arch/x86_64/kernel/head.S. then we don't need to switch from 32bit mode to 64 bit mode in head.s of mkelfImage. and still convert 64elf to 32bit elf. Also it would make other 32 bit bootloader still can load vmlinux64. Then we only need to make sure head.s of mkelfImage can get correct entry_point.
Hacks like that are a support pain. I don't have a problem with weird magic compatibility glue in the bzImage format but I don't want to introduce another one.
Or we need to make elfboot in LinuxBIOS to be 64elf aware, and it need to switch 64bit before load 64bit elf.
At least before we jump to the 64bit elf. For size the 32bit kernel should be smaller, so I don't understand the interest in the 64bit kernel at this point. If we do the 32/64bit transition at the last moment like etherboot does this requires about 100-200 extra lines of code.
Eric
On 11/5/06, Eric W. Biederman ebiederm@xmission.com wrote:
First a decode of letters, in bzImage the b stands for big and the z stands for gzip. We don't have a bzip2 decompressor in there.
Thanks for the explanation...
An interesting question is if we make a bImage target that does everything except the decompression (because nothing would be compressed) would that suit your needs?
That could be good for us.
Hacks like that are a support pain. I don't have a problem with weird magic compatibility glue in the bzImage format but I don't want to introduce another one.
But it seems that current boot loader only use first program header's p_addr?
At least before we jump to the 64bit elf. For size the 32bit kernel should be smaller, so I don't understand the interest in the 64bit kernel at this point. If we do the 32/64bit transition at the last moment like etherboot does this requires about 100-200 extra lines of code.
that 256 byte code could be done in elfboot, or head.s of mkelfImage. A: elfboot (not 64bit aware) ---> 32bit elf --->64 bit kernel (head.S startup_32 then startup_64) B: elfboot (not 64bit aware) ---> 32bit elf ( elf do the 32->64 transition) --->64 bit kernel (startup_64) C: elfboot (64bit aware, switch to 64bit) ---> 64bit elf --->64 bit kernel (startup_64)
the A is less work in all.
the reason for using 64bit kernel: 1. don't want to dig i386 arch together with final x86_64 2. for 64bit resource support, the 32bit kernel will ignore or clear that resource.
YH
On 11/5/06, Eric W. Biederman ebiederm@xmission.com wrote:
An interesting question is if we make a bImage target that does everything except the decompression (because nothing would be compressed) would that suit your needs?
because the decompression in bzImage, So could do some selection about compression way or even not compression. That is good point, Eric. So I can use startup_32 in head.S in kernel.
YH
the latest kernel still put startup_32 on the 0x100000.
when will be startup_64/startup_32 be relocatable?
YH
On 11/4/06, Eric W. Biederman ebiederm@xmission.com wrote:
"Lu, Yinghai" yinghai.lu@amd.com writes:
Please check patch attached. It could be applied to mkelfImage cleanly.
Make mkelfImage to take vmlinux in elf64 for amd64
Actually the vmlinux on amd64 is elf64, so parse it and set it back to elf32.
Nack.
The 32bit entry point for 64bit kernels is going away. If you want to use vmlinux directly for 64bit kernels please use the 64bit entry point.
That requires a whole new kernel type to be added to mkelfImage, unless I am missing something obvious.
Eric
p.s. Sorry for the delayed reply.
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
yhlu yinghailu@gmail.com writes:
the latest kernel still put startup_32 on the 0x100000.
when will be startup_64/startup_32 be relocatable?
Well the patches for 32bit relocatability are in Andi Kleen's tree.
The 64bit stuff will come when someone has time to merge the code. It's just a matter of working through a bunch of stupid little things.
Eric
-
ebiederm＠xmission.com -
Lu, Yinghai -
Segher Boessenkool -
Stefan Reinauer -
yhlu