linux-mips
[Top] [All Lists]

Re: initramfs breakage with 64-bits kernels?

To: Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: initramfs breakage with 64-bits kernels?
From: "Kevin D. Kissell" <kevink@paralogos.com>
Date: Sun, 03 May 2009 11:42:46 +0200
Cc: Florian Fainelli <florian@openwrt.org>, linux-mips@linux-mips.org
In-reply-to: <49FD62D5.5000803@paralogos.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <200904302141.53025.florian@openwrt.org> <10f740e80905030119u6f196b6bqe63003d502f9f731@mail.gmail.com> <49FD62D5.5000803@paralogos.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)
Kevin D. Kissell wrote:
Geert Uytterhoeven wrote:
You mean the test for initrd_start being non-zero? Is your initramfs really at address zero?
I'm not set up to verify this, but I have a nagging suspicion that a big-endian 64-bit kernel build could store an initrd_start address with 32 or fewer significant bits (i.e. it starts in the first 4GB) as a 64-bit pointer, but that the code in initramfs.c is testing the value as a 32-bit scalar type.  I don't know about lmo but in kernel.org 2.6.29, it's declared in include/linux/initrd.h as an extern unsigned long, not a void *.
And yes, I know that MIPS64 builds *should* have data type equivalence for longs and pointers, but this behavior just smells like a data typing mismatch problem, at some level.

          Kevin K.
<Prev in Thread] Current Thread [Next in Thread>