headers
charles | 26 Apr 2005 01:28
Favicon

Building NetBSD for MIPS using Cygwin

Hi,
I am trying to evaluate Linux vs. NetBSD for a MIPS based "Set-top" project.
I am using currently Win2KPro / Cygwin as the development platform.  I can
successfully build Linux following the Linux 'cross-compile' instructions,
but I have been unable to get NetBSD to complete the configure process using
the 'Build.sh' instructions.  Has anyone been able to perform this recently?
If so, can you tell me how you did it or point me in the proper direction?

Best Regards,

Charles L. Nelson
Permalink | Reply | 3 comments |
headers
Christos Zoulas | 26 Apr 2005 03:23

Re: Building NetBSD for MIPS using Cygwin

In article <DPEJKBIMHGLHACKBHHEJAEDLCFAA.charles <at> embsyspro.com>,
 <charles <at> embsyspro.com> wrote:
>Hi,
>I am trying to evaluate Linux vs. NetBSD for a MIPS based "Set-top" project.
>I am using currently Win2KPro / Cygwin as the development platform.  I can
>successfully build Linux following the Linux 'cross-compile' instructions,
>but I have been unable to get NetBSD to complete the configure process using
>the 'Build.sh' instructions.  Has anyone been able to perform this recently?
>If so, can you tell me how you did it or point me in the proper direction?

How are you trying to do it and where/how does it fail?

christos
Permalink | Reply | 2 comments |
headers
charles | 26 Apr 2005 05:23
Favicon

RE: Building NetBSD for MIPS using Cygwin

Here is the sequence that I am following as outlined in 'The NetBSD Guide',
Part V. Building the system, Chapter 25. Crosscompiling NetBSD with build.sh

1.) I have the source installed at '/cygdrive/c/NetBSD/usr/src'
2.) I invoke the Bash shell
3.) If I issue the following command...  '$ ./build.sh -m mipsco tools'

I get the following...

shift: Illegal number: + 3 -1?

build.sh: Unknown operation `-m'

4.) If I issue the command as such... '$ bash ./build.sh -m mipsco tools'

I get the following...

$ bash ./build.sh -m mipsco tools
===> build.sh command: ./build.sh -m mipsco tools
===> build.sh started: Mon Apr 25 20:12:57 PDT 2005
===> No nonexistent/bin/nbmake, needs building.
===> Bootstrapping nbmake
/tools/make/configure: Can't open /tools/make/configure: No such file or
directory

ERROR: Configure of nbmake failed
*** BUILD ABORTED ***

5.) If I alter the $TOP variable within Build.sh from 'TOP=$(/bin/pwd -P
2>/dev/null)'  to 'TOP=/cygdrive/c/NetBSD/usr/src'
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christos Zoulas | 26 Apr 2005 05:33

RE: Building NetBSD for MIPS using Cygwin

On Apr 25,  8:23pm, charles <at> embsyspro.com (<charles <at> embsyspro.com>) wrote:
-- Subject: RE: Building NetBSD for MIPS using Cygwin

Hmm, there is PR21494 about building under cygwin but nobody has applied
it. There might be more lossage introduced by other recent changes. It
would be nice if someone fixed all of that, but it seems that there has
not been a lot of interest fixing all the issues. My guess is that there
are portability problems in the scripts that prevent things from working
properly, and it is just a few hours of work for someone who is familiar
with the tools to fix them.

christos

| Here is the sequence that I am following as outlined in 'The NetBSD Guide',
| Part V. Building the system, Chapter 25. Crosscompiling NetBSD with build.sh
| 
| 1.) I have the source installed at '/cygdrive/c/NetBSD/usr/src'
| 2.) I invoke the Bash shell
| 3.) If I issue the following command...  '$ ./build.sh -m mipsco tools'
| 
| I get the following...
| 
| shift: Illegal number: + 3 -1?
| 
| build.sh: Unknown operation `-m'
| 
| 4.) If I issue the command as such... '$ bash ./build.sh -m mipsco tools'
| 
| I get the following...
|
(Continue reading)

Permalink | Reply | 0 comments |
headers
Justin Newcomer | 30 Apr 2005 20:00
Picon

data corruption and pmap and such

Sorry if this is a bad question, but I subscribe to the mailing lists
for port-cobalt and port-mips and i remember all the problems people
were having with data corruption and the pmap_unwire errors.

so my question is, i am running a cobalt qube 2 with the netbsd 2.0 kernel
01:47:08 ~ # uname -a
NetBSD caspar 2.0 NetBSD 2.0 (QUBE) #0: Sun Mar 20 01:20:03 UTC 2005 
root <at> caspar:/usr/src/sys/arch/cobalt/compile/QUBE cobalt

every now and then i see the pmap_unwire error come up on the serial
terminal prompt
01:56:15 /stuff # cat messages.1 | grep unwire
Apr  5 10:56:26 caspar /netbsd: pmap_unwire: wiring for pmap
0x80643460 va 0x7fff8000 didn't change!
Apr  5 10:56:31 caspar /netbsd: pmap_unwire: wiring for pmap
0x80643460 va 0x7fff8000 didn't change!
Apr 12 03:30:19 caspar /netbsd: pmap_unwire: wiring for pmap
0x80643320 va 0x10056000 didn't change!
Apr 12 03:31:16 caspar /netbsd: pmap_unwire: wiring for pmap
0x80643320 va 0x10106000 didn't change!
Apr 14 01:10:05 caspar /netbsd: pmap_unwire: wiring for pmap
0x80643640 va 0x10024000 didn't change!

What should the normal netbsd user do to fix this problem, is there a fix?
is the current and or the 2.0 kernel sources from netbsd fixed?

I have obviously recompiled my kernel once, but that was to fix other things
will recompiling again with the -current fix any issues?

i read all the messages in the "pmap_unwire: wiring ... didn't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Markus W Kilbinger | 30 Apr 2005 20:24
Picon

Re: data corruption and pmap and such

>>>>> "Justin" == Justin Newcomer <liquidice5 <at> gmail.com> writes:

    Justin> Sorry if this is a bad question, but I subscribe to the
    Justin> mailing lists for port-cobalt and port-mips and i remember
    Justin> all the problems people were having with data corruption
    Justin> and the pmap_unwire errors.

    Justin> so my question is, i am running a cobalt qube 2 with the
    Justin> netbsd 2.0 kernel 01:47:08 ~ # uname -a NetBSD caspar 2.0
    Justin> NetBSD 2.0 (QUBE) #0: Sun Mar 20 01:20:03 UTC 2005
    Justin> root <at> caspar:/usr/src/sys/arch/cobalt/compile/QUBE cobalt

    Justin> every now and then i see the pmap_unwire error come up on
    Justin> the serial terminal prompt 01:56:15 /stuff # cat
    Justin> messages.1 | grep unwire Apr 5 10:56:26 caspar /netbsd:
    Justin> pmap_unwire: wiring for pmap 0x80643460 va 0x7fff8000
    Justin> didn't change! [...]

    Justin> What should the normal netbsd user do to fix this problem,
    Justin> is there a fix?

Yes, in -current, checked in some minutes ago:

  http://mail-index.netbsd.org/source-changes/2005/04/30/0007.html

    Justin> is the current and or the 2.0 kernel sources from netbsd
    Justin> fixed?

More severe r5k cache problems got a much better workaround in
-current on 03/26/2005:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chuck Silvers | 1 May 2005 00:33
Favicon

Re: "pmap_unwire: wiring ... didn't change!"

hi again,

I checked in the #2 approach from below earlier today.
I'll request pullups to release branches in a few days
if no one reports any problems.

-Chuck

On Sat, Feb 12, 2005 at 04:32:47PM -0800, Chuck Silvers wrote:
> hi,
> 
> I looked into the "pmap_unwire: wiring ... didn't change!" problem.
> what's happening is that sometimes we're going through uvm_fault() again
> for one of the wired pages, and the pmap_enter() which results from that
> replaces the wired pmap entry with non-wired one.  so why would we go through
> uvm_fault() again?  that's happening because sometimes the TLB entry is
> recycled after the page mapped by one side of the entry is wired and before
> the other page is wired.  and when MachTLBUpdate() is called for the second
> page, the entry it creates only has the second side filled in.  this causes
> us to get a "TLB invalid" trap when we access the other half of the TLB entry
> instead of the "TLB miss" trap that we would get if there were no TLB entry
> at all.  the handler for "TLB invalid" traps from usermode always calls
> trap() instead of looking at the PTEs.
> 
> so the problem is that the PTEs and the TLB get out of sync, and the trap
> handlers aren't expecting that.  I see several possible fixes, in
> approximate decreasing order of preference:
> 
>  - change MachTLBUpdate() to take both PTEs for the TLB entry for MIPS3.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane