2.6-7-rc1 8xx - No go

2.6-7-rc1 8xx - No go

[Pantelis Antoniou]

Hi there.

I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
does not work any more.

Currently investigating why.

Regards

Pantelis


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

Re: 2.6-7-rc1 8xx - No go

[Pantelis Antoniou]

Pantelis Antoniou wrote:

> Hi there.
>
> I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
> does not work any more.
>
> Currently investigating why.
>
> Regards
>
> Pantelis
>
>
Update; for some reason the problem seems to be that page faults
are incredibly slow.

Starting a dummy init after a minute it manages to start and operate
correctly.

I suspect a terribly slow page fault.

Regards

Pantelis


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

Re: 2.6-7-rc1 8xx - No go

[rdiz]

Did you actually manage to compile standard (no tweak), 2.6.7-rc1 for 8xx?
If so, what '8xx Machine Type' did you chose?


Regards,
Ricardo Diz

>
> Pantelis Antoniou wrote:
>
>> Hi there.
>>
>> I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
>> does not work any more.
>>
>> Currently investigating why.
>>
>> Regards
>>
>> Pantelis
>>
>>
> Update; for some reason the problem seems to be that page faults
> are incredibly slow.
>
> Starting a dummy init after a minute it manages to start and operate
> correctly.
>
> I suspect a terribly slow page fault.
>
> Regards
>
> Pantelis
>
>
>
>


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

Re: 2.6-7-rc1 8xx - No go

[Robert P. J. Day]

On Fri, 28 May 2004 rdiz@alumni.deec.uc.pt wrote:

> Did you actually manage to compile standard (no tweak), 2.6.7-rc1 for 8xx?
> If so, what '8xx Machine Type' did you chose?

and here's another almost assuredly dumb question on my part -- can
someone clarify the different kernel source trees that are under
discussion here?

the one i'm playing with is ppc.bkbits.net:8080/linuxppc-2.5, while the
posting above suggests a recent version straight from the stock kernel.org
repository.

what's the protocol for patches and updates?  do first attempts at patches
go into the 2.5 tree and, from there, get pushed up to the stock tree?
just curious about the proper way i should be updating my source tree and
testing.

thanks.

rday

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

Re: 2.6-7-rc1 8xx - No go

[Pantelis Antoniou]

Robert P. J. Day wrote:

>On Fri, 28 May 2004 rdiz@alumni.deec.uc.pt wrote:
>
>
>>Did you actually manage to compile standard (no tweak), 2.6.7-rc1 for 8xx?
>>If so, what '8xx Machine Type' did you chose?
>>
>
>and here's another almost assuredly dumb question on my part -- can
>someone clarify the different kernel source trees that are under
>discussion here?
>
I could try but I'm not insane yet :). Tom?

>
>the one i'm playing with is ppc.bkbits.net:8080/linuxppc-2.5, while the
>posting above suggests a recent version straight from the stock kernel.org
>repository.
>
that's the one I working one too.

>
>what's the protocol for patches and updates?  do first attempts at patches
>go into the 2.5 tree and, from there, get pushed up to the stock tree?
>just curious about the proper way i should be updating my source tree and
>testing.
>
>thanks.
>
>rday
>
>
>
>
>
Regards

Pantelis


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

Re: 2.6-7-rc1 8xx - No go

[Pantelis Antoniou]

rdiz@alumni.deec.uc.pt wrote:

>Did you actually manage to compile standard (no tweak), 2.6.7-rc1 for 8xx?
>If so, what '8xx Machine Type' did you chose?
>
>
>Regards,
>Ricardo Diz
>
>
>>Pantelis Antoniou wrote:
>>
>>
>>>Hi there.
>>>
>>>I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
>>>does not work any more.
>>>
>>>Currently investigating why.
>>>
>>>Regards
>>>
>>>Pantelis
>>>
>>>
>>>
>>Update; for some reason the problem seems to be that page faults
>>are incredibly slow.
>>
>>Starting a dummy init after a minute it manages to start and operate
>>correctly.
>>
>>I suspect a terribly slow page fault.
>>
>>Regards
>>
>>Pantelis
>>
>>
>>
>>
>>
>
>
>
>
>
>
It's the linuxppc-2.5 tree. Plus my own modifications.

Regards

Pantelis


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

RTC no longer exist on the 866/87x/88x

[David Ho]

Hi 8xx gurus,

I just noticed the RTC is no longer documented/tested/supported on the
duet.  How does this impact the current 2.4 8xx tree?

I know the /dev/rtc still uses RTC on the processor, it appears to work
fine, but I wouldn't bet my life on it for production units.

How about the kernel's timing service and scheduling, does it use the
timebase register instead?  Are these services effected at all?

Thanks a lot,

David Ho
Nanometrics Inc.


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

Re: RTC no longer exist on the 866/87x/88x

[Pantelis Antoniou]

David Ho wrote:

>
>
>
>Hi 8xx gurus,
>
>I just noticed the RTC is no longer documented/tested/supported on the
>duet.  How does this impact the current 2.4 8xx tree?
>
>I know the /dev/rtc still uses RTC on the processor, it appears to work
>fine, but I wouldn't bet my life on it for production units.
>
I believe there's a problem with increased power consumption
by the RTC so that's why Motorola removed it from the docs.

>
>How about the kernel's timing service and scheduling, does it use the
>timebase register instead?  Are these services effected at all?
>
>
Don't worry, they're not affected at all.

>Thanks a lot,
>
>David Ho
>Nanometrics Inc.
>
>
>
>
>
Regards

Pantelis


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

Re: RTC no longer exist on the 866/87x/88x

[Mark Chambers]

> >I know the /dev/rtc still uses RTC on the processor, it appears to work
> >fine, but I wouldn't bet my life on it for production units.
> >

It may simply be a testing issue:  I was told by a Motorola rep that there
are two things responsible for the cost of an IC (other than the size of the
die) - the cost of the packaging and the cost of test.  So some of these 8xx
variants are simply minimally tested versions of the parent processor.  Or
in the case of the 852, some pins that aren't connected.

Mark Chambers


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

Re: 2.6-7-rc1 8xx - No go

[Paul Mackerras]

Pantelis Antoniou writes:

> I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
> does not work any more.

You probably need this patch.  I changed things a bit so that we get
the full registers set dumped on an oops due to a bad address in the
kernel.

Paul.

diff -urN linuxppc-2.5/arch/ppc/kernel/head_8xx.S pmac-2.5/arch/ppc/kernel/head_8xx.S
--- linuxppc-2.5/arch/ppc/kernel/head_8xx.S	2004-05-25 21:48:41.000000000 +1000
+++ pmac-2.5/arch/ppc/kernel/head_8xx.S	2004-05-29 09:22:18.828955856 +1000
@@ -228,9 +228,7 @@
 	stw	r10,_DSISR(r11)
 	mr	r5,r10
 	mfspr	r4,DAR
-	stw	r4,_DAR(r11)
-	addi	r3,r1,STACK_FRAME_OVERHEAD
-	EXC_XFER_EE_LITE(0x300, do_page_fault)
+	EXC_XFER_EE_LITE(0x300, handle_page_fault)

 /* Instruction access exception.
  * This is "never generated" by the MPC8xx.  We jump to it for other
@@ -242,7 +240,7 @@
 	addi	r3,r1,STACK_FRAME_OVERHEAD
 	mr	r4,r12
 	mr	r5,r9
-	EXC_XFER_EE_LITE(0x400, do_page_fault)
+	EXC_XFER_EE_LITE(0x400, handle_page_fault)

 /* External interrupt */
 	EXCEPTION(0x500, HardwareInterrupt, do_IRQ, EXC_XFER_LITE)

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

Re: 2.6-7-rc1 8xx - No go

[Tom Rini]

On Sat, May 29, 2004 at 09:23:33AM +1000, Paul Mackerras wrote:

> Pantelis Antoniou writes:
>
> > I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
> > does not work any more.
>
> You probably need this patch.  I changed things a bit so that we get
> the full registers set dumped on an oops due to a bad address in the
> kernel.
>
> Paul.
>
> diff -urN linuxppc-2.5/arch/ppc/kernel/head_8xx.S pmac-2.5/arch/ppc/kernel/head_8xx.S
> --- linuxppc-2.5/arch/ppc/kernel/head_8xx.S	2004-05-25 21:48:41.000000000 +1000
> +++ pmac-2.5/arch/ppc/kernel/head_8xx.S	2004-05-29 09:22:18.828955856 +1000
> @@ -228,9 +228,7 @@
>  	stw	r10,_DSISR(r11)
>  	mr	r5,r10
>  	mfspr	r4,DAR
> -	stw	r4,_DAR(r11)
> -	addi	r3,r1,STACK_FRAME_OVERHEAD
> -	EXC_XFER_EE_LITE(0x300, do_page_fault)
> +	EXC_XFER_EE_LITE(0x300, handle_page_fault)
>
>  /* Instruction access exception.
>   * This is "never generated" by the MPC8xx.  We jump to it for other
> @@ -242,7 +240,7 @@
>  	addi	r3,r1,STACK_FRAME_OVERHEAD
>  	mr	r4,r12
>  	mr	r5,r9
> -	EXC_XFER_EE_LITE(0x400, do_page_fault)
> +	EXC_XFER_EE_LITE(0x400, handle_page_fault)
>
>  /* External interrupt */
>  	EXCEPTION(0x500, HardwareInterrupt, do_IRQ, EXC_XFER_LITE)

It actually needs to remove that 'addi' as well.  We found that ~30
minutes ago.

--
Tom Rini
http://gate.crashing.org/~trini/

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