Re: 2.4.0-test3

Now imagine here that IBAT3U is zero (I think the code is executing in
1:1 mapped mode here). You just have set IBATL on a 601 hence the valid
flag and you temporarily have a mapping that says:

(1st 8 Mb of virtual address space) -> video memory

what happens if the instruction fetcher decides to start loading a cache
line (executing from video memory) ? Might it also depending on firmware,
create a multiple BAT match (which is a definitive no-no) ?

Well, in theory, this code is run with MMU off.

That's a single instruction slot, yes, but it may hurt. Simply swapping
these instructions might solve the problem since you are not supposed to
access the display virtual address at this time, it will have a transient
mapping:

(video memory) -> first 8 Mb of physical memory

but it sounds harmless.

Ok, I'll flip them anyway.

Oh and please add an isync before and after touching the BATS, this is
required by the architecture (as I've indicated with my hand made pseudo
unified diffs).

The fact that the valid bits are BATL on 601 and BATU on the other makes
all the BAT manipulation extremely delicate. Maybe it would be better for
robustness not to try to save a few instructions and have 2 completely
different code paths...

Well, I'll try that. But again, the MMU is supposed to be off at this point.

Besides looking at load_bat macros, the comment does not quite exactly
reflect the code and might crash on 601:
/* 601 only have IBAT cr0.eq is set on 601 when using this macro */
It should be reordered, even if slightly bigger. I believe that, once upon
a time, there was a LOAD_601_BAT macro.
#define LOAD_BAT(n, offset, reg, RA, RB) \
       /* see the comment for clear_bats() -- Cort */ \
       li      RA,0;                   \
       mtspr   IBAT##n##U,RA;          \
       mtspr   DBAT##n##U,RA;          \   <-- Wrong, might crash 601 !
       lwz     RA,offset+0(reg);       \
       lwz     RB,offset+4(reg);       \
       mtspr   IBAT##n##U,RA;          \
       mtspr   IBAT##n##L,RB;          \
       beq     1f;                     \

This should be fixed but it seems to be there since so long...

I don't know whether one of the chunks of code that I suspect is the
source of the problem, but they might well be.

Ok, that would cause a crash when loading the BAT after MMU is re-
enabled. Cort, what's your explanation ?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/