8xx-2.6 | Prolog

8xx-2.6 | Prolog

[Pantelis Antoniou]

Hi

The patches that follow are against the linuxppc-2.5 tree and
are tested to work on my NETTA board.

Awaiting comments.

Pantelis


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

Re: 8xx-2.6 | Prolog

[Dan Malek]

On May 26, 2004, at 8:05 AM, Pantelis Antoniou wrote:


> The patches that follow are against the linuxppc-2.5 tree and
> are tested to work on my NETTA board.

Thanks.  I'll work on them this evening, get it running on my 8xx
boards and check them in.


	-- Dan


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

Re: 8xx-2.6 | Prolog

[Tom Rini]

On Wed, May 26, 2004 at 11:36:52AM -0400, Dan Malek wrote:

>
> On May 26, 2004, at 8:05 AM, Pantelis Antoniou wrote:
>
>
> >The patches that follow are against the linuxppc-2.5 tree and
> >are tested to work on my NETTA board.
>
> Thanks.  I'll work on them this evening, get it running on my 8xx
> boards and check them in.

Actually, I can start reworking and feeding to Andrew Morton now, iff
you'll be OK with me sending along the new serial driver.

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

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

Re: 8xx-2.6 | Prolog

[Dan Malek]

On May 26, 2004, at 11:55 AM, Tom Rini wrote:

> Actually, I can start reworking and feeding to Andrew Morton now, iff
> you'll be OK with me sending along the new serial driver.

I'm so swamped with real work today I have not looked at any
of the patches.  I don't think a few more hours is going to make a
big difference considering how long it's been not working :-)

Thanks.


	-- Dan


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

Re: 8xx-2.6 | Prolog

[Marcelo Tosatti]

On Wed, May 26, 2004 at 03:05:31PM +0300, Pantelis Antoniou wrote:
>
> Hi
>
> The patches that follow are against the linuxppc-2.5 tree and
> are tested to work on my NETTA board.
>
> Awaiting comments.

Excellent, I'll try this out on MPC855T.

Should it work?


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

Re: 8xx-2.6 | Prolog

[Dan Malek]

On May 26, 2004, at 8:05 AM, Pantelis Antoniou wrote:

> Awaiting comments.

The interrupt stuff in patch 1 was wrong when it was done in 2.4
and I'm disappointed to see it again in 2.6.  Unfortunately, I
don't have time to fix it now, but it will get done properly when I
implement the similar thing for the 8560.

In patch 4, get rid of that #if 0 around the machine check exception.
If the code works, just check it in.  We can't define update_mmu_cache
as a null function.  It performs a necessary function of cache
management.  We may just be lucky because the caches on the 8xx
are small, but this is a subtle bug waiting to happen.

Why did you need to include patch 5 and 6?  These should have
been done and checked into the trees long ago.

In patch 8, why is the 8xx FEC driver dependent upon NETTA and
NETPHONE?  All 8xx boards should use this driver, and it would have
been nice if you would have done board specific files for all other
8xx boards that are supported, even if they couldn't be tested.  The
price of making such major changes that affect everyone :-)

I did not check these in.  Tom can you do so and make sure other
8xx boards will at least compile?  I'll fix up the stuff I don't like
later :-)

Thanks.

	-- Dan

>
> Pantelis
>


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

RE: 8xx-2.6 | Prolog

[Joakim Tjernlund]

> In patch 4, get rid of that #if 0 around the machine check exception.
> If the code works, just check it in.

The machine check part has already been checked in by Paul.

   Jocke

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

Re: 8xx-2.6 | Prolog

[Tom Rini]

On Thu, May 27, 2004 at 11:44:21AM -0400, Dan Malek wrote:

>
> On May 26, 2004, at 8:05 AM, Pantelis Antoniou wrote:
>
> >Awaiting comments.
[snip]
> ... We can't define update_mmu_cache
> as a null function.  It performs a necessary function of cache
> management.  We may just be lucky because the caches on the 8xx
> are small, but this is a subtle bug waiting to happen.

Are you certain?  This is something in 2.4, and while I am having weird
problems locally (that I can't rule out as being hw issues), adding that
change in is what gets me a working init=/bin/bash.

> I did not check these in.  Tom can you do so and make sure other
> 8xx boards will at least compile?  I'll fix up the stuff I don't like
> later :-)

I'm going to be checking this all in momentarily.  On my system right
now, I can get both of my rpxlite's to init=/bin/bash, mostly working,
if and only if I use the new uart driver and if I configure it for SMC1
AND SCC1 (which seems wrong).

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

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

Re: 8xx-2.6 | Prolog

[Pantelis Antoniou]

Dan Malek wrote:

>
> On May 26, 2004, at 8:05 AM, Pantelis Antoniou wrote:
>
>> Awaiting comments.
>
>
> The interrupt stuff in patch 1 was wrong when it was done in 2.4
> and I'm disappointed to see it again in 2.6.  Unfortunately, I
> don't have time to fix it now, but it will get done properly when I
> implement the similar thing for the 8560.

Well, I had to do something. request_8xxirq & friends are unusable.

>
> In patch 4, get rid of that #if 0 around the machine check exception.
> If the code works, just check it in.  We can't define update_mmu_cache
> as a null function.  It performs a necessary function of cache
> management.  We may just be lucky because the caches on the 8xx
> are small, but this is a subtle bug waiting to happen.

OK for the #if 0.
I don't know what update_mmu_cache really does that screws up so bad.
Didn't really had to look into the matter.

>
> Why did you need to include patch 5 and 6?  These should have
> been done and checked into the trees long ago.

For completeness. So that with the patches in it would at least compile.

>
> In patch 8, why is the 8xx FEC driver dependent upon NETTA and
> NETPHONE?  All 8xx boards should use this driver, and it would have
> been nice if you would have done board specific files for all other
> 8xx boards that are supported, even if they couldn't be tested.  The
> price of making such major changes that affect everyone :-)

Well, as I explained to Tom, that was intentional :).

How many of the boards in the kernel are working,
or have someone working on them?

IMHO it's time to clean up the mess a bit.

>
> I did not check these in.  Tom can you do so and make sure other
> 8xx boards will at least compile?  I'll fix up the stuff I don't like
> later :-)
>
> Thanks.
>
>     -- Dan
>
Regards

Pantelis


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

Re: 8xx-2.6 | Prolog

[Song Sam]

Pantelis Antoniou <panto@intracom.gr> wrote:

> > Dan Malek wrote:

> > The interrupt stuff in patch 1 was wrong when it was done in 2.4 and
> > I'm disappointed to see it again in 2.6. Unfortunately, I don't have
> > time to fix it now, but it will get done properly when I implement
> > the similar thing for the 8560.
>
> Well, I had to do something. request_8xxirq & friends are unusable.

I tested External Interrupt of 823e with
request_8xxirq on IRQ1-IRQ7 in 2.4.18(MVL3.0-rpxlite
BSP) last night.It did work.But I failed many times to
make PCMCIA IP_B7 interrupt work,which should be
treated as External Interrupt--registered fine but
without any response to IP_B7 change.

I wonder whether "interrupt stuff" as you metioned had

any relation with my case.

Sorry for disturbing you all! :-)

Sam

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

Re: 8xx-2.6 | Prolog

[Pantelis Antoniou]

Tom Rini wrote:

>On Thu, May 27, 2004 at 11:44:21AM -0400, Dan Malek wrote:
>
>
>
>>On May 26, 2004, at 8:05 AM, Pantelis Antoniou wrote:
>>
>>
>>
>>>Awaiting comments.
>>>
>>>
>[snip]
>
>
>>... We can't define update_mmu_cache
>>as a null function.  It performs a necessary function of cache
>>management.  We may just be lucky because the caches on the 8xx
>>are small, but this is a subtle bug waiting to happen.
>>
>>
>
>Are you certain?  This is something in 2.4, and while I am having weird
>problems locally (that I can't rule out as being hw issues), adding that
>change in is what gets me a working init=/bin/bash.
>
>
>
>>I did not check these in.  Tom can you do so and make sure other
>>8xx boards will at least compile?  I'll fix up the stuff I don't like
>>later :-)
>>
>>
>
>I'm going to be checking this all in momentarily.  On my system right
>now, I can get both of my rpxlite's to init=/bin/bash, mostly working,
>if and only if I use the new uart driver and if I configure it for SMC1
>AND SCC1 (which seems wrong).
>
>
>
Problem persists.

While it no longer crashes it is unbearably slow.

I suspect that it does not update properly the page
tables on a data/instruction access fault.

Regards

Pantelis

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