[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] build 32-bit Linux loader as `linux', rename legacy loader t

From: Yoshinori K. Okuji
Subject: Re: [PATCH] build 32-bit Linux loader as `linux', rename legacy loader to `linux16'
Date: Tue, 31 Mar 2009 01:06:25 +0900
User-agent: KMail/1.9.10

On Monday 30 March 2009 23:35:52 phcoder wrote:
> Pavel Roskin wrote:
> > On Sat, 2009-03-28 at 13:53 +0100, Robert Millan wrote:
> >>> Here's a patch to rename `linux' to `linux16' and build the 32-bit
> >>> loader as simply `linux'.
> >>
> >> Committed.
> >
> > Just for your information.  With the old loader, booting an x86_64
> > kernel in qemu emulating i386 would result in a kernel message:
> >
> > "This kernel requires an x86-64 CPU but only detected an i686 CPU
> > Unable to boot - please use a kernel appropriate for your CPU"
> >
> > With the new loader, the kernel hands without showing any messages.  It
> > can be a kernel bug.  Linux 2.6.29, current GRUB.
> I confirm. I suppose that this check and message is bypassed with 32-bit
> loading mode. IMO grub2 should provide an equivlent of this check. We
> already have cpuid code. Does anyone know how to determine if kernel is
> i386 or amd64?

I don't know any reliable way. Some candidates:

- The ramdisk max value. On 32-bit, initrd may not be loaded onto over 2GB. 
This is hard to change in Linux, so we can expect that this will not change. 
On 64-bit, currently, the max is 4GB-1. It is likely that this value will not 
change, but who knows.

- The long mode panic message. This exists only for x86_64. But the message 
might change some day.

- Otherwise, we could probe some opcodes and see if 64-bit opcodes are used. 
This would be error-prone.

After all, the best way might be to just ask Linux developers to add a new 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]