Re: evbppc reserved-tlb cleanup

Hi Jachym Holecek,

   http://mail-index.netbsd.org/port-powerpc/2006/09/24/0000.html
   http://mail-index.netbsd.org/port-powerpc/2006/09/24/0006.html

These two patch is not enough for OpenBlockS266.

I've added following fixes,

- change arch/powerpc/ibm4xx/openbios/locore.S too for OBS266
- use OBS405_CONADDR instead of 0xef000000
- don't call consinit() in obs2{00,66}_machdep.c because consinit() is
   already called in ibm4xx_init() (but I'm not sure which place is  
good)
- do bus_space_map() to get bus space handle in emacs_attach() (!!!)

then OpenBlockS266 boots correctly.

Attached patch is your 2 patch + my fixes. s/0x74000000/BASE_ISA/ is not
included. (sorry)

--
FUKAUMI Naoki

diff -ur src.orig/sys/arch/evbppc/explora/machdep.c src/sys/arch/evbppc/explora/machdep.c
--- src.orig/sys/arch/evbppc/explora/machdep.c	2006-09-19 07:05:47.000000000 +0900
+++ src/sys/arch/evbppc/explora/machdep.c	2006-10-06 13:49:44.000000000 +0900
 <at>  <at>  -134,26 +134,6  <at>  <at> 
 #endif /* DDB */

Re: evbppc reserved-tlb cleanup

Hi! all,

From: FUKAUMI Naoki <naoki <at> fukaumi.org>
Date: Fri, 6 Oct 2006 15:45:57 +0900

> Hi Jachym Holecek,
> 
>    http://mail-index.netbsd.org/port-powerpc/2006/09/24/0000.html
>    http://mail-index.netbsd.org/port-powerpc/2006/09/24/0006.html
> 
> These two patch is not enough for OpenBlockS266.

Yes sure.
My OpenBlockS266 panics on -current source when boot time.  X-<

> I've added following fixes,
> 
> - change arch/powerpc/ibm4xx/openbios/locore.S too for OBS266
> - use OBS405_CONADDR instead of 0xef000000
> - don't call consinit() in obs2{00,66}_machdep.c because consinit() is
>    already called in ibm4xx_init() (but I'm not sure which place is  
> good)
> - do bus_space_map() to get bus space handle in emacs_attach() (!!!)
> 
> then OpenBlockS266 boots correctly.
> 
> Attached patch is your 2 patch + my fixes. s/0x74000000/BASE_ISA/ is not
> included. (sorry)

I patched that.  My OpenBlockS266 booted, doesn't panic.  

Re: evbppc reserved-tlb cleanup

> I patched that.  My OpenBlockS266 booted, doesn't panic.  
> However I don't test on other boards.

Hmm.  My board did panic.  The log attached.

Some executables linked with shared libraries (e.g., /bin/sh) didn't
work.  /rescue/sh and some executables worked.

Masao

Subject: > I patched that. My OpenBlockS266 booted, doesn't panic. > However I don't test on other boards. Hmm. My board did panic. The log attached. Some executables linked with shared libraries (e.g., /bin/sh) didn't work. /rescue/sh and some executables worked. Masao

Script started on Mon Oct  9 15:51:43 2006
$ tip U0-9600
connected

[...]

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993

Re: evbppc reserved-tlb cleanup

> Hmm.  My board did panic.  The log attached.
> 
> Some executables linked with shared libraries (e.g., /bin/sh) didn't
> work.  /rescue/sh and some executables worked.

Never mind - my box seems to have some hardware problems.

Masao

Re: CVS commit: src/sys/arch

Hi!
# Add cc: port-powerpc <at> , and remove source-chenges <at> 

From: Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp>
Date: Tue, 17 Oct 2006 18:46:15 +0900

> Also could you please change explora/machdep.c to use a proper
> macro as hannken <at>  suggested?
> http://mail-index.netbsd.org/port-powerpc/2006/09/24/0005.html

Oops...

I'm going to commit this patch next week end.

Thanks,
--
kiyohara

? compile/WORLD
? conf/WORLD
? conf/WORLD.diff
Index: explora/machdep.c
===================================================================
RCS file: /cvsroot/src/sys/arch/evbppc/explora/machdep.c,v
retrieving revision 1.14
diff -u -r1.14 machdep.c
--- explora/machdep.c	16 Oct 2006 18:14:35 -0000	1.14
+++ explora/machdep.c	18 Oct 2006 17:30:13 -0000

Build fix after recent gcc update

Hi,

the new gcc propagates const-ness from structs to struct members.
This exposes a build problem, in that an assignment in
sig_machdep.c's cpu_setmcontext() loses a qualification, and that
gets turned into an error with -Werror.

Nick Hudson suggested that the passed mcontext should probably
not be modified, only the trap frame should get the result of the
"masked MSR" register value.

Since I'm not intimate with the powerpc code, I have to ask if
this looks reasonable:

Index: sig_machdep.c
===================================================================
RCS file: /u/nb/src/sys/arch/powerpc/powerpc/sig_machdep.c,v
retrieving revision 1.25
diff -u -r1.25 sig_machdep.c
--- sig_machdep.c       26 Mar 2006 16:15:57 -0000      1.25
+++ sig_machdep.c       24 Oct 2006 10:33:38 -0000
 <at>  <at>  -216,20 +216,13  <at>  <at> 
 cpu_setmcontext(struct lwp *l, const mcontext_t *mcp, unsigned int flags)
 {
        struct trapframe *tf = trapframe(l);
-       __greg_t *gr = mcp->__gregs;
+       const __greg_t *gr = mcp->__gregs;
 #ifdef PPC_HAVE_FPU
        struct pcb *pcb = &l->l_addr->u_pcb;
 #endif

Re: Build fix after recent gcc update

On Oct 24, 2006, at 3:41 AM, Havard Eidnes wrote:

> Hi,
>
> the new gcc propagates const-ness from structs to struct members.
> This exposes a build problem, in that an assignment in
> sig_machdep.c's cpu_setmcontext() loses a qualification, and that
> gets turned into an error with -Werror.
>
> Nick Hudson suggested that the passed mcontext should probably
> not be modified, only the trap frame should get the result of the
> "masked MSR" register value.
>
> Since I'm not intimate with the powerpc code, I have to ask if
> this looks reasonable:

This patch looks OK to me.

>
>
> Index: sig_machdep.c
> ===================================================================
> RCS file: /u/nb/src/sys/arch/powerpc/powerpc/sig_machdep.c,v
> retrieving revision 1.25
> diff -u -r1.25 sig_machdep.c
> --- sig_machdep.c       26 Mar 2006 16:15:57 -0000      1.25
> +++ sig_machdep.c       24 Oct 2006 10:33:38 -0000
>  <at>  <at>  -216,20 +216,13  <at>  <at> 
>  cpu_setmcontext(struct lwp *l, const mcontext_t *mcp, unsigned int  

Re: Build fix after recent gcc update

Havard Eidnes <he <at> NetBSD.org> writes:

> Nick Hudson suggested that the passed mcontext should probably
> not be modified, only the trap frame should get the result of the
> "masked MSR" register value.
> 
> Since I'm not intimate with the powerpc code, I have to ask if
> this looks reasonable:

This seems entirely reasonable. Go for it.

        - Nathan

Pegasos port progress

Hi,

I haven't heard from you in a while, and I was just wondering how things
are going.  Please keep me informed as to your progress. Also, please let
me know if there is anything that I can do to help.

Thanks,
Al

Re: evbppc reserved-tlb cleanup

Jachym Holecek wrote:

> the patch below converts ibm4xx-based evbppc from static reserved-TLB
> entry allocation to recently introduced ppc4xx_tlb_reserve() API (and
> fixes a stupid bug therein, too . Some side effects:
> 
>   o ibm405gp UART0 used to be linear mapped. The VA happens to be
>     inside kernel segment, giving us the possibility of multiple
>     VA matches in the TLB. This is considered "programming error"
>     by 405 core and results in "undefined behaviour". We now avoid
>     mapping peripherals in kernel segment.
> 
>   o Some boards used to map hardwired RAM size. We now use the real
>     size as passed in by boot firmware.
> 
>   o TLB_NRESERVED is (finally) gone.
> 
> I don't have any of the affected boards to play with, so it would be
> great to know how it works on Walnut, Explora451 and OpenBlocks.

With this change, or at least the version of it that got committed on
16th October, my Walnut with a 256MB DIMM now has 17 wired TLB entries
(1 for each 16MB of ram, and an extra for the OPB devices).  I have run
this in the past with 512MB, which would have made half the available
TLBs wired.

Previously, pmap_tlbmiss() added 16MB page table entries on the fly
if there was a kernel page miss.  I haven't measured the impact of
this, but I suspect that wiring that percentage of TLBs will have some
negative effect on overall performance, even though we'd be taking