On 11/5/06, Eric W. Biederman <[EMAIL PROTECTED]> 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 _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
