arm nfs boot uvm_fail error

Hi,everyone.

I am trying to boot MPCore EB which has 4 arm core from nfs root file
system.
That is to say I want to boot this arm board diskless.
The nfs root file system sucessfully booted the Armadillo-9 Board,
So the root file system and the configuration is ok for the evbarm platform.

But MPCore EB fail to boot from this nfs server.
We try to boot the MPCore in the following steps:
1.Download the nfs netbsd image to the MPCore board by RealView ICE  to
0x00200000
2.go 0x00200000 
3.The NIC is working and sending the nfs request to the nfs server(We verify
it by using tcpdump to watch the nfs packets)
4.The kernel goes wrong at sys/kern/kern_exec.c execve1 function with
path="/sbin/init"

The error message is 
"uvm_fail (0xc28a8ee0, bffff000, 1)"

We have trace to the following line that invoke this error 
"vm = p->p_vmspace;"

The Context of this line is as following(Our source is based on 3.99.17):
627         /*
628          * Do whatever is necessary to prepare the address space
629          * for remapping.  Note that this might replace the current
630          * vmspace with another!
631          */

Re: arm nfs boot uvm_fail error

On Fri, 2006-06-02 at 13:43, FengXiagen <at> Kobe wrote:
> Hi,everyone.
> 
> I am trying to boot MPCore EB which has 4 arm core from nfs root file
> system.
> That is to say I want to boot this arm board diskless.
> The nfs root file system sucessfully booted the Armadillo-9 Board,
> So the root file system and the configuration is ok for the evbarm platform.
> 
> But MPCore EB fail to boot from this nfs server.
> We try to boot the MPCore in the following steps:
> 1.Download the nfs netbsd image to the MPCore board by RealView ICE  to
> 0x00200000
> 2.go 0x00200000 
> 3.The NIC is working and sending the nfs request to the nfs server(We verify
> it by using tcpdump to watch the nfs packets)
> 4.The kernel goes wrong at sys/kern/kern_exec.c execve1 function with
> path="/sbin/init"

MPcore is (IIRC) an ARMv6K implementation.  NetBSD doesn't really
support ARMv6 yet (although I have run it on an ARM1136 it wasn't
particularly stable, since I didn't rework the code for the v6 cache
layout (VIPT)).

I think you'll need to address that before you can really get things
running on this board.

R.

Kernel does not boot on an XDP425 board

Hi guys.

I got an XDP425 board, an Avila GW2348-4 Network Platform boards from:
http://www.gateworks.com/avila_gw2348_4.htm
I read thread started by Franck Baudin at 
http://comments.gmane.org/gmane.os.netbsd.ports.arm/804
where he succeded booting NetBSD on an XDP425 board.

I followed his summary, compiled a new kernel but it does not boot.
Redboot shows :
Trying NPE-B...success. Using NPE-B with PHY 0.
... waiting for BOOTP information
Ethernet eth0: MAC address 00:d0:12:02:35:30
IP: 192.168.3.20/255.255.255.0, Gateway: 192.168.3.10
Default server: 192.168.3.10

RedBoot(tm) bootstrap and debug environment [ROM]
Gateworks certified release, version 2.02 - built 05:22:19, Mar  3 2006

Platform: Gateworks Avila GW234X (IXP42X 533MHz) BE
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
Copyright (C) 2004, 2005 Gateworks Corporation

RAM: 0x00000000-0x04000000, [0x000298b0-0x03fc1000] available
FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.
== Executing boot script in 2.500 seconds - enter ^C to abort
^C
RedBoot> load -r -b 0x00200000 kernel
Using default protocol (TFTP)
Raw file loaded 0x00200000-0x00565eb2, assumed entry at 0x00200000

Re: arm nfs boot uvm_fail error

Richard Earnshaw wrote;

> NetBSD doesn't really support ARMv6 yet

My guess is that the error cause is rather simple; the initial address space layout
is mashed.  My experience shows that porting NetBSD/arm is as easy as to
complete initarm(); no change necessary for other parts.  Most errors come from
the lack of understanding about they way how the target ARM SoC address layout is 
adapted for NetBSD, in particular, where RAM paddr resides and where DEV registers
are vaddr'ed.

FengXiagen said;

> We have wonder whether there is something wrong with uvmspace_exec function,
> Because the pack.ep_vm_minaddr and pack.ep_vm_maxaddr is set by check_exec
> function to 4K to 3G defaultly.

It's pretty normal.  Kernel is trying there to craft virtual address space for the very
first user process.

Toru Nishimura/ALKYL Technology

Re: Kernel does not boot on an XDP425 board

>> RedBoot> load -r -b 0x00200000 kernel
>> Using default protocol (TFTP)
>> Raw file loaded 0x00200000-0x00565eb2, assumed entry at 0x00200000
>> RedBoot> go
>> $T050f:00200000;0d:03fc0fec;#d9

CPU got wrecked during 'running before dawn'

> Am I wrong using 0x00200000 to boot the kernel ?
> I am not sure what memory address use here.

Being occupied by RedBoot itself?

ARM SoCs have a habit of inconsistent RAM paddr.  It's definitely a trap for new
comers since the fact imposes horrible complications for OS initialization steps.
When completed correctly, initarm() finishes the entire NetBSD address space; kernel
in upper vaddr (at 0xC000'0000 in most cases) and user process in rest of it.  RAM
paddr varies wildly and DEV registers are vaddr'ed somewhere at far beyond kernel
end, KVA 0xF000'0000 or some.  It's simple, isn't it?

The issue is how to get there.  RedBoot provides a comfortable illusion as if
RAM is populated at address range bottom.  But, during OS initialization steps
CPU have to kill anyway MMU to see "naked HW paddr layout" and constructs
new address space tailored for the booting OS.  So, it's very important where
the CPU thinks itself running around.

Another complication is zImage; self-decompressing kernel binary scheme
inherited from ISA PC.  NetBSD reluctantly (happily?) introduced gzboot to
cope with RedBoot.  Decompress requires intermediate working memory
before the target kernel image is populated at the target place.  Lack of

Re: arm nfs boot uvm_fail error

I am sorry to reply late, 
because I can't use the company email in home.

TO->Richard Earnshaw

>MPcore is (IIRC) an ARMv6K implementation.  NetBSD doesn't really
>support ARMv6 yet (although I have run it on an ARM1136 it wasn't
>particularly stable, since I didn't rework the code for the v6 cache
>layout (VIPT)).

>I think you'll need to address that before you can really get things
>running on this board.

Thanks for your pmap.c support of the arm platform for NetBSD.
Our MPCore NetBSD transplant is based on the arch/evbarm/integrator which you had contributed.
We have considered the difference of cache architecture between ARM11(VIPT) and MPCore(PIPT).
We really left the cache support code untouched till now. 
But it successfully boots from RAMDISK rootfs with only one core , serial and NIC.
In the RAMDisk rootfs, the init and sh is running properly and We can set IP with ifconfig,
and get the ICMP response from the MPCore EB.

We will look into the cache support soon.

TO->Toru Nishimura
>My guess is that the error cause is rather simple; the initial address space layout
>is mashed.  My experience shows that porting NetBSD/arm is as easy as to
>complete initarm(); no change necessary for other parts.  Most errors come from
>the lack of understanding about they way how the target ARM SoC address layout is 
>adapted for NetBSD, in particular, where RAM paddr resides and where DEV registers
>are vaddr'ed.

Porting NetBSD to new arm architecture procedures

Hello,

I want to port NetBSD to OMAP

Procedures about porting NetBSD to new arm arch

Hello,

I want to port NetBSD to OMAP 1510. Because I'm new to NetBSD,
does anyone tell me the porting procedures? Thank you.

Warm regards,
Doug.

Re: a question about arm-gcc

a question about arm-gcc