status of linuxppc_2_4_devel for ppc405gp

status of linuxppc_2_4_devel for ppc405gp

[Stefan Roese]

Hi,

I recently noticed that some new stuff for the ppc4xx found its way into the
linuxppc_2_4_devel tree (thanks dan).

So I tried to port this linux-tree to our custom ppc405gp board. Up to now
we are using the MontaVista Linux for the ppc405gp (walnut) from 03-2001.

Within this process I found some problems:

Our system crashes in the function "ppc4xx_gdb_init()" in file
"ppc4xx_setup.c". Without this call bootup look much better ;-). Any
comments on this?

I noticed that the ppc405_enet driver is not compiled and not started
(Makefile and Space.c in drivers/net). Is there a patch missing?

Is anybody running this linuxppc_2_4_devel on a walnut board or custom
ppc405 board? What is the "official status" of the ppc405 support in this
linux tree?

Thanks and best regards,
Stefan Roese


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

Re: status of linuxppc_2_4_devel for ppc405gp

[Kenneth Johansson]

Stefan Roese wrote:
>
> Hi,
>
>
> Is anybody running this linuxppc_2_4_devel on a walnut board or custom
> ppc405 board? What is the "official status" of the ppc405 support in this
> linux tree?

Well I was waiting on Dan making some kind of statement that his merge was
ready. Are you saying that he got in enough to actually run the kernel on a
405 ?


--
Kenneth Johansson
Ericsson Business Innovation AB   Tel: +46 8 404 71 83
Viderögatan 3                     Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@inn.ericsson.se

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

Re: status of linuxppc_2_4_devel for ppc405gp

[Dan Malek]

Kenneth Johansson wrote:

> Well I was waiting on Dan making some kind of statement that his merge was
> ready. Are you saying that he got in enough to actually run the kernel on a
> 405 ?

Almost all of the kernel proper is structurally sound.  I needed to
get the files there so others could also start making their updates.
I'm sure I missed a few little details, so when you see something
let me know.  Some of the patches I have are nearly six months old
and don't apply as well as they should :-).......then I wandered
into bootloader land where nothing works for the 4xx right now.  If
you don't need a 'treeboot' loader, or can stuff an image with a
JTAG debugger, you can get the kernel to boot.


	-- Dan

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

Re: status of linuxppc_2_4_devel for ppc405gp

[Phillip Lougher]

Dan Malek wrote:
>
> Almost all of the kernel proper is structurally sound.  I needed to
> get the files there so others could also start making their updates.
> I'm sure I missed a few little details, so when you see something
> let me know.  Some of the patches I have are nearly six months old
> and don't apply as well as they should :-).......then I wandered
> into bootloader land where nothing works for the 4xx right now.  If
> you don't need a 'treeboot' loader, or can stuff an image with a
> JTAG debugger, you can get the kernel to boot.
>

What doesn't work with the treeboot loader?  From what I've seen,
there's nothing much to break?

Phil Lougher

>
> 	-- Dan
>
>


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

Re: status of linuxppc_2_4_devel for ppc405gp

[Dan Malek]

Phillip Lougher wrote:

> What doesn't work with the treeboot loader?  From what I've seen,
> there's nothing much to break?

The 4xx stuff wasn't kept up to date in the linuxppc_2_4 tree.
I have new things to check in there, and along with other bootloader
changes we want to accomplish I'm just trying to merge it with
others.  There are more 4xx processors than Walnut boards with
the treeboot rom, and we have to accomodate those as well.


	-- Dan

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

Re: status of linuxppc_2_4_devel for ppc405gp

[Benjamin Herrenschmidt]

>
>Our system crashes in the function "ppc4xx_gdb_init()" in file
>"ppc4xx_setup.c". Without this call bootup look much better ;-). Any
>comments on this?

The function dereferences the regs of the init.task which no longer
exist. (And was previously not properly initialized anyway).

>I noticed that the ppc405_enet driver is not compiled and not started
>(Makefile and Space.c in drivers/net). Is there a patch missing?

Probably. In my tree, I changed it to use the initcalls.

>Is anybody running this linuxppc_2_4_devel on a walnut board or custom
>ppc405 board? What is the "official status" of the ppc405 support in this
>linux tree?

I have the kernel booting with a custom board but userland doesn't work,
I'm still tracking this.

Ben.


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

Physically mapped FLASH

[David Updegraff]

Hi.

Is there a reason why the physical-mapping setup (drivers/mtd/maps/physmap.c)
is coded to ONLY talk to CFI chips?  For example I have some 405gp things
that have AMD Flash chips that are physically mapped to the top of memory
and could be driven by the algorithms in drivers/mtd/chips/amd_flash.c.

I've patched it and it appears to work ok; is it a bad idea?  is it good idea?
Any interest in incorporating in?

--
Dave Updegraff / dave@cray.com / 218-525-1154


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

Re: Physically mapped FLASH

[Matt Porter]

On Wed, Aug 22, 2001 at 08:32:28AM -0500, David Updegraff wrote:
>
> Hi.
>
> Is there a reason why the physical-mapping setup (drivers/mtd/maps/physmap.c)
> is coded to ONLY talk to CFI chips?  For example I have some 405gp things
> that have AMD Flash chips that are physically mapped to the top of memory
> and could be driven by the algorithms in drivers/mtd/chips/amd_flash.c.

It's the same reason why any obvious limitation exists in Linux.  The
original developer was only interested in implementing something that
suited his task at hand.  It's been sitting there waiting for you to
come along fix it for all of us. :)

> I've patched it and it appears to work ok; is it a bad idea?  is it good idea?
> Any interest in incorporating in?

Post your patch here and on the MTD list. Send it to the MTD maintainers
directly.  I have cPCI boards that can make use of it, it's just been
low on my priority list.

Regards,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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

Re: status of linuxppc_2_4_devel for ppc405gp

[Dan Malek]

Benjamin Herrenschmidt wrote:

> The function dereferences the regs of the init.task which no longer
> exist. (And was previously not properly initialized anyway).

Oh, now don't say that, it used to work :-).  At least for now,
don't enable KGDB.

> Probably. In my tree, I changed it to use the initcalls.

Will you please check that in?  I pused the files but couldn't
decide which method of initialization was "current" :-).

I'm still sorting out the bootloader stuff.

Thanks.


	-- Dan

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

Re: status of linuxppc_2_4_devel for ppc405gp

[Dan Malek]

Scott Anderson wrote:

> Stefan was talking about ppc4xx_gdb_init(), not kgdb stuff.  The problem
> I ran into in that function was that it turned off external debug
> support.

Ahhh....OK.  I kinda sorta remember a conversation with you about
this.

> ...  As a temporary workaround I ifdef'ed out the code that touched
> DBCR0 and DBCR1

>From Ben's comment it sounded like we are touching data structures
that don't exist anymore, or that I forgot to add as part of the
405 debugger support.  I'll check on it right now......


	-- Dan

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

Re: status of linuxppc_2_4_devel for ppc405gp

[Benjamin Herrenschmidt]

>
>Will you please check that in?  I pused the files but couldn't
>decide which method of initialization was "current" :-).
>
>I'm still sorting out the bootloader stuff.

I'll do tomorrow when I'm at work.

Note that I still didn't manage to get userland to work on
my 405GP. I'm suspecting an issue between Paulus/DaveM new
cache flush avoidance code and the weird cache design of the
405. But it might not...

If I understand correctly the 405GP docs the instruction cache
is indexed with a sort of mixup of virtual & physical addresses,
which has the side effect of causing aliasing problems if the
page size is lower than 16k (which is our case).

I'm not sure I get it completely yet, but it appears that with
a 4k size, we are supposed to invalidate a line _and_ the line
with bit 29 xor'ed whenever we want a given address to be safe
for instructions. Since the "shadow" line may not be in the same
page and that same page is not necessarily mapped when we do
the invalidate, the best solution, for now, would be to have
_all_ of the instruction cache invalidate functions inval. the
entire instruction cache. (You currently do it only on one of
"callbacks" in asm/pgtable.h, not in the other routines in
the .S files). That would be true for userland as well.

Ben.


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

Re: status of linuxppc_2_4_devel for ppc405gp

[David Gibson]

On Wed, Aug 22, 2001 at 10:04:04PM +0200, Benjamin Herrenschmidt wrote:
>
> >
> >Will you please check that in?  I pused the files but couldn't
> >decide which method of initialization was "current" :-).
> >
> >I'm still sorting out the bootloader stuff.
>
> I'll do tomorrow when I'm at work.
>
> Note that I still didn't manage to get userland to work on
> my 405GP. I'm suspecting an issue between Paulus/DaveM new
> cache flush avoidance code and the weird cache design of the
> 405. But it might not...

I'm working on this at the moment too.  The first problem I found was
that the ELF loader would refuse to exec() init, which turned out to
be because bytes 16-32 (and possibly later ones too, I forget) of
binprm->buf were junk.  The data was correct in the page cache.  I
found this was fixed by removing the dcbz from copy_tofrom_user(),
although I don't see why yet since the cache line size appears to be
ok.

I'm now able to run a very simple binary as init - basically "Hello,
world!" implemented with one write() syscall, and none of the libc
initialisation junk present.  A one write hello world with the normal
crt0 (statically linked) fails.

--
David Gibson			| Microsoft: Making the easy things hard
david@gibson.dropbear.id.au	| and the hard things buggy
http://www.ozlabs.org/people/dgibson


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

Re: status of linuxppc_2_4_devel for ppc405gp

[Benjamin Herrenschmidt]

>
>I'm working on this at the moment too.  The first problem I found was
>that the ELF loader would refuse to exec() init, which turned out to
>be because bytes 16-32 (and possibly later ones too, I forget) of
>binprm->buf were junk.  The data was correct in the page cache.  I
>found this was fixed by removing the dcbz from copy_tofrom_user(),
>although I don't see why yet since the cache line size appears to be
>ok.

Ok, I didn't have this one as I removed all the cache tricks from
copy_tofrom_user & copy_page in my version, at least until I get
it working.
I had copy_tofrom_user failing earlier causing ipconfig to fail,
that's why I took this drastic workaround ;)

>I'm now able to run a very simple binary as init - basically "Hello,
>world!" implemented with one write() syscall, and none of the libc
>initialisation junk present.  A one write hello world with the normal
>crt0 (statically linked) fails.

Ok. So this would mean the problem is with the libc junk ? Hrm.
I didn't trace that far yet, but I suspect the libc I've been
using (the "normal" 6xx one) lacks some cache stuffs. I'm
pretty convinced that we must inval the entire instructions cache
each time we used to do icbi's (either that or handle the cache
aliasing issues specific to the 405GP weird icache design).

I'll do more experiments later today.

Ben.


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

Re: status of linuxppc_2_4_devel for ppc405gp

[Benjamin Herrenschmidt]

>>I'm now able to run a very simple binary as init - basically "Hello,
>>world!" implemented with one write() syscall, and none of the libc
>>initialisation junk present.  A one write hello world with the normal
>>crt0 (statically linked) fails.
>
>Ok. So this would mean the problem is with the libc junk ? Hrm.
>I didn't trace that far yet, but I suspect the libc I've been
>using (the "normal" 6xx one) lacks some cache stuffs. I'm
>pretty convinced that we must inval the entire instructions cache
>each time we used to do icbi's (either that or handle the cache
>aliasing issues specific to the 405GP weird icache design).
>
>I'll do more experiments later today.

I found at least one other problem: The kernel is happily doing
tlbie's on the 405 (which doesn't support them). Among other places,
calls to flush_HPTE are turned into _tlbie which is not redefined
to do a tlbia, causing at least ioremap to break.

I'll push a fix for that today.

Ben.


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

Re: status of linuxppc_2_4_devel for ppc405gp

[David Gibson]

On Thu, Aug 23, 2001 at 01:08:18PM +0200, Benjamin Herrenschmidt wrote:
>
> >>I'm now able to run a very simple binary as init - basically "Hello,
> >>world!" implemented with one write() syscall, and none of the libc
> >>initialisation junk present.  A one write hello world with the normal
> >>crt0 (statically linked) fails.
> >
> >Ok. So this would mean the problem is with the libc junk ? Hrm.
> >I didn't trace that far yet, but I suspect the libc I've been
> >using (the "normal" 6xx one) lacks some cache stuffs. I'm
> >pretty convinced that we must inval the entire instructions cache
> >each time we used to do icbi's (either that or handle the cache
> >aliasing issues specific to the 405GP weird icache design).
> >
> >I'll do more experiments later today.
>
> I found at least one other problem: The kernel is happily doing
> tlbie's on the 405 (which doesn't support them). Among other places,
> calls to flush_HPTE are turned into _tlbie which is not redefined
> to do a tlbia, causing at least ioremap to break.

Ah yes, I ran into that one when I started converting the ppc405_enet
driver to use ioremap() and in_beXX() instead of the godawful mess of
direct access and explicit eieio()s it uses now.

--
David Gibson			| Microsoft: Making the easy things hard
david@gibson.dropbear.id.au	| and the hard things buggy
http://www.ozlabs.org/people/dgibson


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

Re: status of linuxppc_2_4_devel for ppc405gp

[Dan Malek]

David Gibson wrote:
to break.
>
> Ah yes, I ran into that one when I started converting the ppc405_enet
> driver to use ioremap() and in_beXX() instead of the godawful mess of
> direct access and explicit eieio()s it uses now.

Umm....what are you doing?  Those registers are already mapped via
ioremap(), so that isn't necessary.  What you consider a "godawful mess"
is a personal preference, and I prefer the programming style that
currently exists.  I don't have any love for the driver, but it
certainly isn't a patch I would check in.......

The only modification that _should_ be done is moving the generic
on-board I/O mapping done during board initialization to be a specific
ioremap() in the driver, and actually looking at the eieio() to ensure
they are really necessary.



	-- Dan

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

Re: status of linuxppc_2_4_devel for ppc405gp

[David Gibson]

On Fri, Aug 24, 2001 at 01:06:26AM -0400, Dan Malek wrote:
>
> David Gibson wrote:
> to break.
> >
> > Ah yes, I ran into that one when I started converting the ppc405_enet
> > driver to use ioremap() and in_beXX() instead of the godawful mess of
> > direct access and explicit eieio()s it uses now.
>
> Umm....what are you doing?  Those registers are already mapped via
> ioremap(), so that isn't necessary.  What you consider a "godawful mess"
> is a personal preference, and I prefer the programming style that
> currently exists.  I don't have any love for the driver, but it
> certainly isn't a patch I would check in.......
>
> The only modification that _should_ be done is moving the generic
> on-board I/O mapping done during board initialization to be a specific
> ioremap() in the driver, and actually looking at the eieio() to ensure
> they are really necessary.

By "use ioremap()" I mean moving the mapping into an explicit
ioremap() in the driver and away from board setup just as you suggest
- in the process removing the assumption that the registers are always
mapped at a fixed virtual address (not particularly problematic, but
not necessary either). (I couldn't find where the mapping was made in
the board setup during a brief search, but I assume it is more-or-less
the equivalent of an io_block_mapping()).

Now, as a general rule registers which are accessed through ioremap()
should be accessed only with {in,out}_*() rather than assuming the
addresses can be dereferenced directly.  Obviously the portability
reasons for this don't apply in the case of the ppc405 EMAC, but to my
mind it still makes sense to keep that convention for clarity.  I
guess "godawful mess" is a bit of an overstatement in the case of this
driver - but anyone coming from the generic parts of the kernel is
likely to be conditioned to think that way, since in any portable
driver directly dereferencing pointers from ioremap() or equivalent
would be Just Plain Wrong.

Of course using in*() and out*() would generate more eieio()s than
necessary, and I could be convinced that's a problem, but my first
instinct is to suspect that they wouldn't make a significant
difference.

--
David Gibson			| Microsoft: Making the easy things hard
david@gibson.dropbear.id.au	| and the hard things buggy
http://www.ozlabs.org/people/dgibson


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

Re: status of linuxppc_2_4_devel for ppc405gp

[Benjamin Herrenschmidt]

Some more progress (well, no much luck actually)

After discussing with Paulus,

I've removed the special case for flush_icache_page() in pgtable.h
for 4xx, and moved the flush to set_pte. The PG_arch_1 bit is used
to determine if a page is cache clean or not, so we use it.

We should even be able to not flush all the cache here but only
the possible "synonyms" as we know the real address.

It still doesn't work :(

When I try to boot a MV "Journeyman" distro, it dies in ld.so, with
the error

BUG IN DYNAMIC LINKER ld.so: rtld.c: 614: dl_main: Assertion
'dl_rtld_map.l_libname' failed!

I still have to look in the ld.so source what it means exactly,
but something is definitely wrong here.


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

Re: status of linuxppc_2_4_devel for ppc405gp

[Dan Malek]

Benjamin Herrenschmidt wrote:

> We should even be able to not flush all the cache here but only
> the possible "synonyms" as we know the real address.

Right.  We can do some of this due to the recent MM rework by Paulus.
I know the complete flush will work, and once we get the kernel
running again we can fine tune the synonym search.  We have to be
careful about some of these complex functions to do these operations,
they could very well run mode code and do more hard to the cache
that just flushing it and getting on with life :-).

> It still doesn't work :(

Hang on, we'll get it.


	-- Dan

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