[Fwd: ppc4xx Ports]

[Fwd: ppc4xx Ports]

[Jon Masters]

[-- Attachment #1: Type: text/plain, Size: 90 bytes --]


Hi there,

Thanks to Matt Porter for suggesting I might care to try here.

Cheers,

Jon.

[-- Attachment #2: ppc4xx Ports --]
[-- Type: message/rfc822, Size: 1376 bytes --]

From: Jon Masters <jonathan@jonmasters.org>
To: linux-kernel@vger.kernel.org
Subject: ppc4xx Ports
Date: Thu, 13 Nov 2003 23:20:06 +0000
Message-ID: <3FB411A6.9030608@jonmasters.org>


Hi there,

I am working on a 405D port using a base kernel of originally 2.4.20 and
now 2.4.21 from kernel.org rather than Montavista etc.

There are several 4xx ports kicking around and each bodges the tlb stuff
in pgtable.h and elsewhere makes simple fixes to make the stock kernel
actually work...though there are several different offerings by now.
Would someone care to share experiences privately about 4xx ports?

Cheers,

Jon.

P.S. The stock 2.4.21 kernel on has a bunch of very trivial bugs (from
losing a register in the syscall handler to breaking shared ptes) and
will not compile correctly out of the box so to speak. A lot of people
seem to be using the Montavista tree as a result. Now rather than
whining I would also like to help so am asking to make contact with
whoever co-ordinates merging these trees together etc.

Re: [Fwd: ppc4xx Ports]

[Dan Kegel]

Jon Masters wrote:
> I am working on a 405D port using a base kernel of originally 2.4.20 and
> now 2.4.21 from kernel.org rather than Montavista etc.
>
> There are several 4xx ports kicking around and each bodges the tlb stuff
> in pgtable.h and elsewhere makes simple fixes to make the stock kernel
> actually work...though there are several different offerings by now.
> Would someone care to share experiences privately about 4xx ports?
>
> Cheers,
>
> Jon.
>
> P.S. The stock 2.4.21 kernel on has a bunch of very trivial bugs (from
> losing a register in the syscall handler to breaking shared ptes) and
> will not compile correctly out of the box so to speak. A lot of people
> seem to be using the Montavista tree as a result. Now rather than
> whining I would also like to help so am asking to make contact with
> whoever co-ordinates merging these trees together etc.

We've been using the linuxppc_2_4_devel tree for ppc405.
I would really love to see its fixes merged into the vanilla
tree, but haven't had occasion to do more than whine about it myself.
- Dan


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

Re: [Fwd: ppc4xx Ports]

[Jon Masters]

Dan Kegel wrote:

| We've been using the linuxppc_2_4_devel tree for ppc405.
| I would really love to see its fixes merged into the vanilla
| tree, but haven't had occasion to do more than whine about it myself.
| - Dan

Situation basically is that the port nearly works now (I can ellaborate
obviously but not until the work is finished for commerical reasons)
and it is not using the Montavista tree so I have already made some
progress with the stock kernel and could carry on in my spare time.

Jon.


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

Re: [Fwd: ppc4xx Ports]

[Eugene Surovegin]

On Thu, Nov 13, 2003 at 11:42:49PM +0000, Jon Masters wrote:
> I am working on a 405D port using a base kernel of originally 2.4.20 and
> now 2.4.21 from kernel.org rather than Montavista etc.
>
> There are several 4xx ports kicking around and each bodges the tlb stuff
> in pgtable.h and elsewhere makes simple fixes to make the stock kernel
> actually work...though there are several different offerings by now.
> Would someone care to share experiences privately about 4xx ports?
>
> Cheers,
>
> Jon.
>
> P.S. The stock 2.4.21 kernel on has a bunch of very trivial bugs (from
> losing a register in the syscall handler to breaking shared ptes) and
> will not compile correctly out of the box so to speak. A lot of people
> seem to be using the Montavista tree as a result. Now rather than
> whining I would also like to help so am asking to make contact with
> whoever co-ordinates merging these trees together etc.
>

I use linuxppc-2.4 based tree in our 40x based products. I haven't
checked the most recent version of this tree though (mine is based on
2.4.21 version + some stuff from more recent one (mostly for 440)).

If you have problems with linuxppc-2.4 on 40x hw, report them here :)

Eugene.


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

Re: [Fwd: ppc4xx Ports]

[Jon Masters]

Eugene Surovegin wrote:

| If you have problems with linuxppc-2.4 on 40x hw, report them here :)

Only problem at the moment is that I am reworking some of the pte stuff
to kludge in some of the Montavista code in to 2.4.21 rather than the
homebrew solution I have been using which modifies the bits in hardware
TLB entries from everyone else :-). Some random other bugs too which
amuse me like I can only use half of the TLBs due a known errata with
the Virtex II Pro. The other ports seem to have missed that errata...

Fun.

Cheers,

Jon.


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

Re: [Fwd: ppc4xx Ports]

[Eugene Surovegin]

On Fri, Nov 14, 2003 at 12:36:59AM +0000, Jon Masters wrote:
> | If you have problems with linuxppc-2.4 on 40x hw, report them here :)
>
> Only problem at the moment is that I am reworking some of the pte stuff
> to kludge in some of the Montavista code in to 2.4.21 rather than the
> homebrew solution I have been using which modifies the bits in hardware
> TLB entries from everyone else :-).

Could you elaborate on that? What bugs are present in current
linuxppc-2.4? Why are you reworking PTE stuff?

I don't have any PTE/TLB related problems on 405GP/405GPr.

Eugene

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

Re: [Fwd: ppc4xx Ports]

[Jon Masters]

Eugene Surovegin wrote:

| Could you elaborate on that? What bugs are present in current
| linuxppc-2.4? Why are you reworking PTE stuff?

As I said before I am not using linuxppc-2.4 tree so I need to fix up
the stock kernel tree.

Jon.


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

Re: [Fwd: ppc4xx Ports]

[Peter Vandenabeele]

On Thu, Nov 13, 2003 at 04:48:05PM -0800, Eugene Surovegin wrote:
[...]
> I don't have any PTE/TLB related problems on 405GP/405GPr.

On the PowerPC 405 in the Virtex-II Pro, we needed to turn off
half of the TLB entries as per "Solution 12" on
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14052

"... Limit TLB depth to 32 entries by only using even entries in the TLB ...."

Peter

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

Re: [Fwd: ppc4xx Ports]

[Jon Masters]

Peter Vandenabeele wrote:

| On Thu, Nov 13, 2003 at 04:48:05PM -0800, Eugene Surovegin wrote:
| [...]
|
|>I don't have any PTE/TLB related problems on 405GP/405GPr.
|
|
| On the PowerPC 405 in the Virtex-II Pro, we needed to turn off
| half of the TLB entries as per "Solution 12" on
|
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14052
|
| "... Limit TLB depth to 32 entries by only using even entries in the
TLB ...."
|
| Peter
|

Hi there,

I think I mentioned before that I already fixed that for the port I am
working on by incrementing next TLB entry by 2 if on Virtex II Pro.
Actually if you check a post I made to comp.arch.fpga over the summer...
I call it CONFIG_BROKEN_XILINX_TLB or something like that (other ports
are now starting to fix that too) - several other errata too.

[ Like I said before we have two similar ports now so once I can release
the modifications then we should look at how this can help us. The stuff
I am working on at the moment is not going out yet and for various
commercial reasons I prefer not to disclose who it is for, etc. ]

The problem I currently have was traced when using the dynamic linker
library from my Powerbook Debian on my test NFS filesystem and then
running up something compiled against the main normal libc with floating
point register save restore context stuff. So this leads me on to...

...there is something wrong with the trapping and handling of stfd and
similar operations on my port when the kernel tries to do the
copy_to_user to actually change the saved floating point register set.
Now that I know where the bug is I can fix it next week[0].

Jon.

[0] I work a 3 day week but take work home with me too much so tracked
this down today when debugging in Starbucks without the hardware but
with my Powerbook and various printouts...using 9600bps dialup proxied
through my Zaurus wifi because no IR on Powerbook revision. ;-).


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

Re: [Fwd: ppc4xx Ports]

[Jon Masters]

Jon Masters wrote:

| I think I mentioned before that I already fixed that for the port I am
| working on by incrementing next TLB entry by 2 if on Virtex II Pro.
| Actually if you check a post I made to comp.arch.fpga over the summer...
| I call it CONFIG_BROKEN_XILINX_TLB or something like that (other ports
| are now starting to fix that too) - several other errata too.

I also force TLB pinning on my port and modify where the kernel TLB
entries go while also forcing in a pinning for serial early on.

Montavista or someone added a patch to do that anyway now but remember I
am using stock kernels and none of the Montavista trees :-).

Cheers,

Jon.


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

Re: [Fwd: ppc4xx Ports]

[Peter Ryser]

The TLB errata for the Virtex-II Pro FPGA was not pushed out to the
source trees because there have basically no chips been shipped to
customers that will expose this problem. Newer mask sets of the
Virtex-II Pro FPGA have this problem fixed.

Solution record 14052 explains the problem, provides a work-around, has
a link to a Linux kernel patch, and lists the PVR values of chips for
which the problem might occur. Please note that even if you have a chip
with a matching PVR it is very unlikely that you will actually see the
problem.

- Peter


Jon Masters wrote:

>
>
> Peter Vandenabeele wrote:
>
> | On Thu, Nov 13, 2003 at 04:48:05PM -0800, Eugene Surovegin wrote:
> | [...]
> |
> |>I don't have any PTE/TLB related problems on 405GP/405GPr.
> |
> |
> | On the PowerPC 405 in the Virtex-II Pro, we needed to turn off
> | half of the TLB entries as per "Solution 12" on
> |
> http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14052
>
> |
> | "... Limit TLB depth to 32 entries by only using even entries in the
> TLB ...."
> |
> | Peter
> |
>
> Hi there,
>
> I think I mentioned before that I already fixed that for the port I am
> working on by incrementing next TLB entry by 2 if on Virtex II Pro.
> Actually if you check a post I made to comp.arch.fpga over the summer...
> I call it CONFIG_BROKEN_XILINX_TLB or something like that (other ports
> are now starting to fix that too) - several other errata too.
>
> [ Like I said before we have two similar ports now so once I can release
> the modifications then we should look at how this can help us. The stuff
> I am working on at the moment is not going out yet and for various
> commercial reasons I prefer not to disclose who it is for, etc. ]
>
> The problem I currently have was traced when using the dynamic linker
> library from my Powerbook Debian on my test NFS filesystem and then
> running up something compiled against the main normal libc with floating
> point register save restore context stuff. So this leads me on to...
>
> ...there is something wrong with the trapping and handling of stfd and
> similar operations on my port when the kernel tries to do the
> copy_to_user to actually change the saved floating point register set.
> Now that I know where the bug is I can fix it next week[0].
>
> Jon.
>
> [0] I work a 3 day week but take work home with me too much so tracked
> this down today when debugging in Starbucks without the hardware but
> with my Powerbook and various printouts...using 9600bps dialup proxied
> through my Zaurus wifi because no IR on Powerbook revision. ;-).
>
>
>
>


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

Re: [Fwd: ppc4xx Ports]

[Jon Masters]

Hi there,

Just quickly to add that I switched my email provider last night and
this might have resulted in a couple of lost messages.

If you replied to this message yet please resend.

Jon.


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

The wonders of 2.4.23 [WAS: Re: [Fwd: ppc4xx Ports]]

[Jon Masters]

Hi Peter,

I changed kernel versions on my in house working port to 2.4.23 having
spent too long doing:

	* Getting my head around the 405 TLB code in Linux[0].
	* Fixing lots of pointless bits in 2.4.21.

[ The kernel was upgraded to 2.4.21 at some point. ]

So having realised the pointlessness of fixing stuff which is now in
2.4.23 I switched over and magically things are improved[1]. This is
fantastic because I no longer need to fix up the system call handler to
save register number 7 or add in tlbia stuff or many other things.

This kernel also adds fixed TLB entries for serial uart and I finally
decided that a lot of old changes to head_4xx.S were now in the true
stock kernel so I could switch to those instead. I still need to do
kludging for the MSR (!ME here) and cacheing weirdness but hey.

I think we can soon start talking about the stuff we are doing and get
some basic support for 405D PVR, xintc and random other bits in the
stock kernel even if there is not full support for Virtex II Pro.
Finally we can probably do with adding the UTLB errata fixes.

Hopefully it will not be long before I am able to do a lot of this stuff
now that the system I am working on is approaching stability with only
busybox init troubles and a custom distribution I am working on left
prior to the holidays. Hmmm... it is 03:00 now so back to bed.

Anyway here is another happy 2.4.23 user.

Jon.

[0] My copy of UTLK and various other documentation is now completely
covered in pen marks, probably coffee stains etc.

[1] I did track down the problem I was having with floating point which
cunningly turned out not to be a problem with that but with the UTLB
faults following a SHARED page not actually being shared correctly,
generating a later instruction fault on the second access.


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