linux-mips
[Top] [All Lists]

Re: 2.6.28 will not boot on 24K processor, ebase incorrectly modified in

To: "David VomLehn (dvomlehn)" <dvomlehn@cisco.com>
Subject: Re: 2.6.28 will not boot on 24K processor, ebase incorrectly modified in set_uncached_handler
From: "Kevin D. Kissell" <kevink@paralogos.com>
Date: Sun, 25 Jan 2009 04:18:23 -0600
Cc: linux-mips@linux-mips.org, "Dezhong Diao (dediao)" <dediao@cisco.com>, "Victor Williams Jr (williavi)" <williavi@cisco.com>, "Michael Sundius -X (msundius - Yoh Services LLC at Cisco)" <msundius@cisco.com>
In-reply-to: <FF038EB85946AA46B18DFEE6E6F8A28976825D@xmb-rtp-218.amer.cisco.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <FF038EB85946AA46B18DFEE6E6F8A28976825D@xmb-rtp-218.amer.cisco.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.19 (Windows/20081209)
David VomLehn (dvomlehn) wrote:
The 2.6.28 kernel dies in memcpy when called from set_vi_srs_handler on
a
24K processor. The problem is that ebase has an invalid value. The
original
value of ebase comes from a bootmem allocation, but the following code
in
set_uncached_handler takes a perfectly good kseg0 address and turns it
into
an invalid kseg1 address.

        if (cpu_has_mips_r2)
                ebase += (read_c0_ebase() & 0x3ffff000);

This code was added in commit 566f74f6b2f8b85d5b8d6caaf97e5672cecd3e3e.
I remember worrying about why it was "+=" and not "=" when others had problems with that patch. See the thread "NXP STB225 board support" from January 8 or so. When I asked about that, I got a comment that the add operation was correct, but that patch *should* have said "uncached_ebase += (read_c0_ebase() & 0x3ffff000);" I guess uncache_ebase is assumed to contain something interesting in some non-address bits. Try pre-pending "uncached_" to that "ebase"...

         Regards,

         Kevin K.

<Prev in Thread] Current Thread [Next in Thread>