On Wed, 2010-10-06 at 22:05 -0400, Albert Cahalan wrote:
> On Tue, Oct 5, 2010 at 11:31 AM, Segher Boessenkool
> wrote:
>
> > An OS shouldn't expect to have more than its own program image
> > RAM mapped, in general.
>
> Linux actually makes calls to allocate more. I'm thankful
> that Linux alwa
On Tue, Oct 5, 2010 at 11:31 AM, Segher Boessenkool
wrote:
> An OS shouldn't expect to have more than its own program image
> RAM mapped, in general.
Linux actually makes calls to allocate more. I'm thankful
that Linux always specifies an address, so I was able to
get away with simply returning
The PowerPC OF binding requires the firmware to save and restore
the BATs on entry to / exit from the firmware.
That would defeat the purpose of setting them.
They are used to provide Linux with mappings.
The initial state the OS has for the BATs is what the firmware
provides it with, sure.
A
The PowerPC OF binding requires the firmware to save and restore
the BATs on entry to / exit from the firmware.
I'm not sure he was talking about OF here...
Yeah, I thought I was on a different mailing list. It's still
sort-of relevant though.
In any case, we don't muck
around with BATs unt
> >> The PowerPC OF binding requires the firmware to save and restore
> >> the BATs on entry to / exit from the firmware.
>
> That would defeat the purpose of setting them.
> They are used to provide Linux with mappings.
How so ? As long as they are present when executing Linux code,
I don't see
On Tue, Oct 5, 2010 at 4:10 AM, Benjamin Herrenschmidt
wrote:
> On Mon, 2010-10-04 at 06:25 +0200, Segher Boessenkool wrote:
>> > On the prom boot path, with the firmware supposed to
>> > be managing the MMU, there is a case where:
>> >
>> > 1. Linux changes some BAT registers.
>> > 2. Bits 0x
On Mon, 2010-10-04 at 12:06 -0400, Albert Cahalan wrote:
> On Mon, Oct 4, 2010 at 12:25 AM, Segher Boessenkool
> wrote:
>
> > The PowerPC OF binding requires the firmware to save and restore
> > the BATs on entry to / exit from the firmware.
>
> This sucks, because using the BAT is **much** easi
On Mon, 2010-10-04 at 06:25 +0200, Segher Boessenkool wrote:
> > On the prom boot path, with the firmware supposed to
> > be managing the MMU, there is a case where:
> >
> > 1. Linux changes some BAT registers.
> > 2. Bits 0x0070 are/become set in the MSR.
> > 3. Linux takes an MMU fault.
> > 4
On Sat, 2010-10-02 at 14:32 -0400, Albert Cahalan wrote:
> On the prom boot path, with the firmware supposed to
> be managing the MMU, there is a case where:
>
> 1. Linux changes some BAT registers.
> 2. Bits 0x0070 are/become set in the MSR.
> 3. Linux takes an MMU fault.
Meeep ! Linux shoul
The PowerPC OF binding requires the firmware to save and restore
the BATs on entry to / exit from the firmware.
This sucks, because using the BAT is **much** easier for
the firmware. In my case, it also means I don't need to worry
about Linux stomping on anything -- I have nothing in RAM.
It's
On Mon, Oct 4, 2010 at 12:25 AM, Segher Boessenkool
wrote:
> The PowerPC OF binding requires the firmware to save and restore
> the BATs on entry to / exit from the firmware.
This sucks, because using the BAT is **much** easier for
the firmware. In my case, it also means I don't need to worry
ab
> On the prom boot path, with the firmware supposed to
> be managing the MMU, there is a case where:
>
> 1. Linux changes some BAT registers.
> 2. Bits 0x0070 are/become set in the MSR.
> 3. Linux takes an MMU fault.
> 4. The firmware handles it.
>
> AFAIK, you can't expect the firmware to leav
On the prom boot path, with the firmware supposed to
be managing the MMU, there is a case where:
1. Linux changes some BAT registers.
2. Bits 0x0070 are/become set in the MSR.
3. Linux takes an MMU fault.
4. The firmware handles it.
AFAIK, you can't expect the firmware to leave the BAT alone.
13 matches
Mail list logo
