2.4.0-test3

2.4.0-test3

[Iain Sandoe]

Hi,

Does anyone know of a source of 2.4.0-test3 that will build for PPC?

I grabbed the bitkeeper 2_3 rsync last night - but it doesn't build...  and
linux-pmac-devel is currently at test1-ac21...

Iain.

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

Re: 2.4.0-test3

[Benjamin Herrenschmidt]

>Does anyone know of a source of 2.4.0-test3 that will build for PPC?
>
>I grabbed the bitkeeper 2_3 rsync last night - but it doesn't build...  and
>linux-pmac-devel is currently at test1-ac21...

Grab the bk tree again, I fixed the build yesterday evening (late)

Ben.


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

Re: 2.4.0-test3

[Andreas Tobler]

Benjamin Herrenschmidt wrote:
>
> >Does anyone know of a source of 2.4.0-test3 that will build for PPC?
> >
> >I grabbed the bitkeeper 2_3 rsync last night - but it doesn't build...  and
> >linux-pmac-devel is currently at test1-ac21...
>
> Grab the bk tree again, I fixed the build yesterday evening (late)

It doesn't compile per se, in pmac_backlight.c asm/pmu.h & asm/adb.h
should be linux/pmu.h & linux/adb.h. This isn't a tragedy.

More problems I get on booting on a wallstreet I. A panic occurs in
combination with mesh. Have to figure out. I removed mesh and 53c94 from
the kernel and now it boots.

A patched 7200 fails completely to boot, it stops on displaying
'booting....'. This kernel is patched with mftb patch from Takashi,
pci-resource & serial-console patch from Michel. (Otherwise a 7200 would
not boot)

In the sccstool I read in prom.c Calc BAT..... this may cause trouble if
the framebuffer is really badly aligned.......
TODO: Check 601 case...

How can I help?


Regards,
Andreas


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

Re: 2.4.0-test3

[Benjamin Herrenschmidt]

>
>It doesn't compile per se, in pmac_backlight.c asm/pmu.h & asm/adb.h
>should be linux/pmu.h & linux/adb.h. This isn't a tragedy.

That's strange, it did compile for me without I push. Looks like bk
didn't push the latest version, or something got screwed up... I'll check
that tonight.

>More problems I get on booting on a wallstreet I. A panic occurs in
>combination with mesh. Have to figure out. I removed mesh and 53c94 from
>the kernel and now it boots.
>
>A patched 7200 fails completely to boot, it stops on displaying
>'booting....'. This kernel is patched with mftb patch from Takashi,
>pci-resource & serial-console patch from Michel. (Otherwise a 7200 would
>not boot)
>
>In the sccstool I read in prom.c Calc BAT..... this may cause trouble if
>the framebuffer is really badly aligned.......
>TODO: Check 601 case...
>
>How can I help?

Well, you can check disabling that (and the call that sets up this BAT in
head.S) but don't forget, if you do that, to also declare
bootx_text_mapped to 0 before leaving prom.c


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

re: 2.4.0-test3

[Iain Sandoe]

----------
>From: "Iain Sandoe" <iain@sandoe.co.uk>
>To: Benjamin Herrenschmidt <bh40@calva.net>
>Subject: Re: 2.4.0-test3
>Date: Mon, Jul 10, 2000, 17:10
>

>
>>>I grabbed the bitkeeper 2_3 rsync last night - but it doesn't build...  and
>>>linux-pmac-devel is currently at test1-ac21...
>>
>> Grab the bk tree again, I fixed the build yesterday evening (late)
>
> ok it built...
>
> good news - atyfb is ok & I think it boots faster...
>
> bad news - mesh crashes on init & no sound :-(
>
> working on getting some debug info...
>
> iain

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

Re: 2.4.0-test3

[Andreas Tobler]

Benjamin Herrenschmidt wrote:

> >In the sccstool I read in prom.c Calc BAT..... this may cause trouble if
> >the framebuffer is really badly aligned.......
> >TODO: Check 601 case...
> >
> >How can I help?
>
> Well, you can check disabling that (and the call that sets up this BAT in
> head.S) but don't forget, if you do that, to also declare
> bootx_text_mapped to 0 before leaving prom.c

I did so, in head.S I if'ed 0 the setup_disp_bat part. In prom.c I
commented out the prepare_disp_BAT(two times) and I set
bootx_text_mapped in these sections to zero. I also put out mesh.
Now the machine comes up again.
But on shutting down I get a terrible nfsd panic with lots of crash
code. (dump available)

So far my experiences......

Andreas

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

Re: 2.4.0-test3

[Takashi Oe]

On Mon, 10 Jul 2000, Benjamin Herrenschmidt wrote:

> >
> >It doesn't compile per se, in pmac_backlight.c asm/pmu.h & asm/adb.h
> >should be linux/pmu.h & linux/adb.h. This isn't a tragedy.
>
> That's strange, it did compile for me without I push. Looks like bk
> didn't push the latest version, or something got screwed up... I'll check
> that tonight.

Why is pmac_backlight.c compiled in for CONFIG_ALL_PPC?  Isn't it
PowerBook only thing?

>
> >More problems I get on booting on a wallstreet I. A panic occurs in
> >combination with mesh. Have to figure out. I removed mesh and 53c94 from
> >the kernel and now it boots.
> >
> >A patched 7200 fails completely to boot, it stops on displaying
> >'booting....'. This kernel is patched with mftb patch from Takashi,
> >pci-resource & serial-console patch from Michel. (Otherwise a 7200 would
> >not boot)
> >
> >In the sccstool I read in prom.c Calc BAT..... this may cause trouble if
> >the framebuffer is really badly aligned.......
> >TODO: Check 601 case...
> >
> >How can I help?
>
> Well, you can check disabling that (and the call that sets up this BAT in
> head.S) but don't forget, if you do that, to also declare
> bootx_text_mapped to 0 before leaving prom.c

601's BAT doesn't have G bit.  Maybe that's the problem?


Takashi Oe


--- linuxppc_2_3-vanilla/arch/ppc/kernel/Makefile	Mon Jul 10 02:18:42 2000
+++ linuxppc_2_3-nubus/arch/ppc/kernel/Makefile	Mon Jul 10 05:53:54 2000
@@ -55,7 +55,7 @@
 endif

 ifdef CONFIG_PMAC_PBOOK
-O_OBJS += sleep.o
+O_OBJS += sleep.o pmac_backlight.o
 endif

 ifdef CONFIG_SMP
@@ -99,8 +99,7 @@
 ifeq ($(CONFIG_ALL_PPC),y)
   O_OBJS += pmac_pic.o pmac_setup.o pmac_time.o feature.o pmac_pci.o prom.o \
 	chrp_setup.o chrp_time.o chrp_pci.o open_pic.o indirect_pci.o \
-	prep_pci.o i8259.o prep_nvram.o prep_time.o residual.o \
-	pmac_backlight.o
+	prep_pci.o i8259.o prep_nvram.o prep_time.o residual.o
   OX_OBJS += prep_setup.o
 endif
 ifeq ($(CONFIG_GEMINI),y)
--- linuxppc_2_3-vanilla/arch/ppc/kernel/prom.c	Mon Jul 10 02:18:43 2000
+++ linuxppc_2_3-nubus/arch/ppc/kernel/prom.c	Mon Jul 10 05:51:03 2000
@@ -867,7 +925,7 @@
 	} else {
 		/* 601 */
 		addr &= 0xFF800000UL;
-		RELOC(disp_BATU) = addr | (_PAGE_NO_CACHE | _PAGE_GUARDED | PP_RWXX) | 4;
+		RELOC(disp_BATU) = addr | (_PAGE_NO_CACHE | PP_RWXX) | 4;
 		RELOC(disp_BATL) = addr | BL_8M | 0x40;
 		// -- todo
 	}


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

Re: 2.4.0-test3

[Benjamin Herrenschmidt]

>
>Why is pmac_backlight.c compiled in for CONFIG_ALL_PPC?  Isn't it
>PowerBook only thing?

Well, if you change that, then chipsfb.c, atyfb.c, aty128fb.c and via-
pmu.c must be changed too. It's not completely powerbook only since, at
term, this could driver also external LVDS LCD backlight.

>> Well, you can check disabling that (and the call that sets up this BAT in
>> head.S) but don't forget, if you do that, to also declare
>> bootx_text_mapped to 0 before leaving prom.c
>
>601's BAT doesn't have G bit.  Maybe that's the problem?

Maybe. I'll push a change without it and see


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

Re: 2.4.0-test3

[Takashi Oe]

On Tue, 11 Jul 2000, Benjamin Herrenschmidt wrote:

> >
> >Why is pmac_backlight.c compiled in for CONFIG_ALL_PPC?  Isn't it
> >PowerBook only thing?
>
> Well, if you change that, then chipsfb.c, atyfb.c, aty128fb.c and via-
> pmu.c must be changed too. It's not completely powerbook only since, at
> term, this could driver also external LVDS LCD backlight.

Yes, that's true.  I forgot about that.  Sorry.  In any case, my initial
problem with this was just CONFIG_ADB_PMU thing, and I went too far.


Takashi Oe

--- linuxppc_2_3-vanilla/arch/ppc/kernel/pmac_backlight.c	Mon Jul 10 02:18:43 2000
+++ linuxppc_2_3-nubus/arch/ppc/kernel/pmac_backlight.c	Mon Jul 10 17:16:54 2000
@@ -63,7 +63,8 @@
 		if (backlight_level > BACKLIGHT_MAX)
 			backlight_level = BACKLIGHT_MAX;
 	}
-
+
+#ifdef CONFIG_ADB_PMU
 	backlight_autosave = machine_is_compatible("AAPL,3400/2400")
 		|| machine_is_compatible("AAPL,3500");
 	if (backlight_autosave) {
@@ -73,6 +74,7 @@
 			pmu_poll();
 		backlight_level = req.reply[1] >> 4;
 	}
+#endif /* CONFIG_ADB_PMU */

 	if (!backlighter->set_enable(1, backlight_level, data))
 		backlight_enabled = 1;


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

Re: 2.4.0-test3

[Andreas Tobler]

Takashi Oe wrote:
>
> On Mon, 10 Jul 2000, Benjamin Herrenschmidt wrote:
>
> > >
> > >It doesn't compile per se, in pmac_backlight.c asm/pmu.h & asm/adb.h
> > >should be linux/pmu.h & linux/adb.h. This isn't a tragedy.
> >
> > That's strange, it did compile for me without I push. Looks like bk
> > didn't push the latest version, or something got screwed up... I'll check
> > that tonight.
>
> Why is pmac_backlight.c compiled in for CONFIG_ALL_PPC?  Isn't it
> PowerBook only thing?

I have both a PB and an old 'pm7200' and I build against both.

> > >How can I help?
> >
> > Well, you can check disabling that (and the call that sets up this BAT in
> > head.S) but don't forget, if you do that, to also declare
> > bootx_text_mapped to 0 before leaving prom.c
>
> 601's BAT doesn't have G bit.  Maybe that's the problem?

Don't know, but here on the quick it wasn't the solving hint. Tomorrow..?

Regards,
Andreas

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

Re: 2.4.0-test3

[Gabriel Paubert]

On Mon, 10 Jul 2000, Takashi Oe wrote:

> 601's BAT doesn't have G bit.  Maybe that's the problem?

No 601 BATs are completely different, see the source code in the early
init. The valid bits in not in the same (BATL or BATU), the size (limited
to 8 Mb) and protection encoding are different (only one valid bit, not Vs
and Vu, and WIMGxPP are coded as in the PTE). I think the G bit is
ignored.

Oh, and a last, but not least, point I forgot, the 601 only has the IBAT
since the BAT arrays are unified.

For the rest (i.e. nothing), 601 BAT are absolutely identical to
other PPC BATs :-(

	Gabriel


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

Re: 2.4.0-test3

[Benjamin Herrenschmidt]

>
>No 601 BATs are completely different, see the source code in the early
>init. The valid bits in not in the same (BATL or BATU), the size (limited
>to 8 Mb) and protection encoding are different (only one valid bit, not Vs
>and Vu, and WIMGxPP are coded as in the PTE). I think the G bit is
>ignored.
>
>Oh, and a last, but not least, point I forgot, the 601 only has the IBAT
>since the BAT arrays are unified.
>
>For the rest (i.e. nothing), 601 BAT are absolutely identical to
>other PPC BATs :-(

Well, I do handle them differently, but I can't test. Can you tell me
what you think of this code ?

/* Calc BAT values for mapping the display and store them
 * in disp_BATH and disp_BATL. Those values are then used
 * from head.S to map the display during identify_machine()
 * and MMU_Init()
 *
 * For now, the display is mapped in place (1:1). This should
 * be changed if the display physical address overlaps
 * KERNELBASE, which is fortunately not the case on any machine
 * I know of. This mapping is temporary and will disappear as
 * soon as the setup done by MMU_Init() is applied
 *
 * For now, we align the BAT and then map 8Mb on 601 and 16Mb
 * on other PPCs. This may cause trouble if the framebuffer
 * is really badly aligned, but I didn't encounter this case
 * yet.
 */
__init
static void
prepare_disp_BAT(void)
{
	unsigned long offset = reloc_offset();
	boot_infos_t* bi = PTRRELOC(RELOC(disp_bi));
	unsigned long addr = (unsigned long)bi->dispDeviceBase;

	if ((_get_PVR() >> 16) != 1) {
		/* 603, 604, G3, G4, ... */
		addr &= 0xFF000000UL;
		RELOC(disp_BATU) = addr | (BL_16M<<2) | 2;
		RELOC(disp_BATL) = addr | (_PAGE_NO_CACHE | _PAGE_GUARDED | BPP_RW);
	} else {
		/* 601 */
		addr &= 0xFF800000UL;
		RELOC(disp_BATU) = addr | (_PAGE_NO_CACHE | PP_RWXX) | 4;
		RELOC(disp_BATL) = addr | BL_8M | 0x40;
	}
	bi->logicalDisplayBase = bi->dispDeviceBase;
}

Then, in heqd.S, I do:

setup_disp_bat:
	/*
	 * setup the display bat prepared for us in prom.c
	 */
	mflr	r8
	bl	reloc_offset
	mtlr	r8
	lis	r8, disp_BATL@h
	ori	r8, r8, disp_BATL@l
	add	r8, r3, r8
	lwz	r8, 0(r8)
	lis	r11, disp_BATU@h
	ori	r11, r11, disp_BATU@l
	add	r11, r3, r11
	lwz	r11, 0(r11)
	mtspr	IBAT3L,r8
	mtspr	IBAT3U,r11
	mfspr	r9,PVR
	rlwinm	r9,r9,16,16,31		/* r9 = 1 for 601, 4 for 604 */
	cmpi	0,r9,1
	beq	1f
	mtspr	DBAT3L,r8
	mtspr	DBAT3U,r11
1:
	blr


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

Re: 2.4.0-test3

[Gabriel Paubert]

On Tue, 11 Jul 2000, Benjamin Herrenschmidt wrote:

> >
> >No 601 BATs are completely different, see the source code in the early
> >init. The valid bits in not in the same (BATL or BATU), the size (limited
> >to 8 Mb) and protection encoding are different (only one valid bit, not Vs
> >and Vu, and WIMGxPP are coded as in the PTE). I think the G bit is
> >ignored.

Ok, I was wrong there is no G bit since the Ks bit takes its place, should
have checked first...

> Well, I do handle them differently, but I can't test. Can you tell me
> what you think of this code ?

See the comments below. Note that I've desperately been trying to update
my BK tree this morning but it does not work at all. I'm very patient and
accustomed to this task taking quite along time every day for 2 trees
(yesterday the update for 2.3 took 1 1/2 hour, for 600 kB compressed), but
today it seems unreachable for me...

>
> /* Calc BAT values for mapping the display and store them
>  * in disp_BATH and disp_BATL. Those values are then used
>  * from head.S to map the display during identify_machine()
>  * and MMU_Init()
>  *
>  * For now, the display is mapped in place (1:1). This should
>  * be changed if the display physical address overlaps
>  * KERNELBASE, which is fortunately not the case on any machine
>  * I know of. This mapping is temporary and will disappear as
>  * soon as the setup done by MMU_Init() is applied
>  *
>  * For now, we align the BAT and then map 8Mb on 601 and 16Mb
>  * on other PPCs. This may cause trouble if the framebuffer
>  * is really badly aligned, but I didn't encounter this case
>  * yet.
>  */
> __init
> static void
> prepare_disp_BAT(void)
> {
> 	unsigned long offset = reloc_offset();
> 	boot_infos_t* bi = PTRRELOC(RELOC(disp_bi));
> 	unsigned long addr = (unsigned long)bi->dispDeviceBase;
>
> 	if ((_get_PVR() >> 16) != 1) {
> 		/* 603, 604, G3, G4, ... */
> 		addr &= 0xFF000000UL;
> 		RELOC(disp_BATU) = addr | (BL_16M<<2) | 2;
> 		RELOC(disp_BATL) = addr | (_PAGE_NO_CACHE | _PAGE_GUARDED | BPP_RW);
> 	} else {
> 		/* 601 */
> 		addr &= 0xFF800000UL;
> 		RELOC(disp_BATU) = addr | (_PAGE_NO_CACHE | PP_RWXX) | 4;
> 		RELOC(disp_BATL) = addr | BL_8M | 0x40;
> 	}
> 	bi->logicalDisplayBase = bi->dispDeviceBase;
> }

That part looks OK...

>
> Then, in heqd.S, I do:
>
> setup_disp_bat:
> 	/*
> 	 * setup the display bat prepared for us in prom.c
> 	 */
> 	mflr	r8
> 	bl	reloc_offset
> 	mtlr	r8
> 	lis	r8, disp_BATL@h
> 	ori	r8, r8, disp_BATL@l
> 	add	r8, r3, r8
> 	lwz	r8, 0(r8)
> 	lis	r11, disp_BATU@h
> 	ori	r11, r11, disp_BATU@l
> 	add	r11, r3, r11
> 	lwz	r11, 0(r11)
+	isync
- 	mtspr	IBAT3L,r8

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) ?

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.

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...


> 	mtspr	IBAT3U,r11
+ 	mtspr	IBAT3L,r8
> 	mfspr	r9,PVR
> 	rlwinm	r9,r9,16,16,31		/* r9 = 1 for 601, 4 for 604 */
> 	cmpi	0,r9,1
> 	beq	1f
> 	mtspr	DBAT3L,r8
> 	mtspr	DBAT3U,r11
> 1:
+	isync
> 	blr

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.

	Regards,
	Gabriel.


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

Re: 2.4.0-test3

[Benjamin Herrenschmidt]

>
>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/

Re: 2.4.0-test3

[Takashi Oe]

On Tue, 11 Jul 2000, Gabriel Paubert wrote:

> On Mon, 10 Jul 2000, Takashi Oe wrote:
>
> > 601's BAT doesn't have G bit.  Maybe that's the problem?
>
> No 601 BATs are completely different, see the source code in the early
> init. The valid bits in not in the same (BATL or BATU), the size (limited
> to 8 Mb) and protection encoding are different (only one valid bit, not Vs
> and Vu, and WIMGxPP are coded as in the PTE). I think the G bit is
> ignored.

Yes, that's very true ....  Are the following codes incorrect for 601?

[from prepare_disp_BAT() in prom.c]

		/* 601 */
		addr &= 0xFF800000UL;
		RELOC(disp_BATU) = addr | (_PAGE_NO_CACHE | PP_RWXX) | 4;
		RELOC(disp_BATL) = addr | BL_8M | 0x40;

Previously, it had "_PAGE_GUARDED" for BATU, which I thought was
incorrect.


Takashi Oe


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

Re: 2.4.0-test3

[Gabriel Paubert]

On Tue, 11 Jul 2000, Benjamin Herrenschmidt wrote:

> >
> >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.

Possibly, I'm still trying to access this damned bk repository (anybody
know what happens to the net today or is is just me ?) to see the code.
I don't see how you can run into problems then. But the 601 is known to
occasionally exhibit some strange behaviour. Anyway I don't have any Mac
to test (hope to get an old 601 based one soon).

> 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.

In this case, are we sure that the 601 problems are introduced by this
change ? Historically, there have been other 601 related problems, like
code touching HID0 without checking processor version or so.

Another possibility is an ordering problem, it seems that the code
reloads all the BATs from the BAT array setup by mm/init.c. Is it possible
that the crash happens this late and do you still need BAT3 after this ?

Maybe the fix will be as simple as writing 0 to the IBATL in LOAD_BAT so
that we are sure that the BAT is disabled before being reloaded, or call
again clear_bats before the series of LOAD_BATs.

> >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 ?

Or at any time AFAICS, trying to access a DBAT (a non existent SPR on a
601) is strictly prohibited, the processor can do anything it wants
although my 601 doc says for mtspr that "if the SPR field contains an
invalid value, the instruction is treated as a nop". So the LOAD_BAT macro
looks safe (but not clean and I can't stand comments which obviously
disagree with the code).

	Gabriel.


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

Re: 2.4.0-test3

[Benjamin Herrenschmidt]

>In this case, are we sure that the 601 problems are introduced by this
>change ? Historically, there have been other 601 related problems, like
>code touching HID0 without checking processor version or so.
>
>Another possibility is an ordering problem, it seems that the code
>reloads all the BATs from the BAT array setup by mm/init.c. Is it possible
>that the crash happens this late and do you still need BAT3 after this ?
>
>Maybe the fix will be as simple as writing 0 to the IBATL in LOAD_BAT so
>that we are sure that the BAT is disabled before being reloaded, or call
>again clear_bats before the series of LOAD_BATs.

Well, Andreas re-did the tests with my latest fix (which was to remove
the bogus PAGE_GUARDED in the 601 case) and with the mftb 601 fixes and
his kernel now works.

Ben.


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