Stephen Borrill | 3 Sep 16:17 2007
Picon

Acorn RiscPCs anyone?

I've just been offered a number of Acorn RiscPCs of various ages. They are 
all StrongARM and RISCOS 4 with (mainly) nic-slot EtherH network.

I'm taking a couple for spares, but if you are interested in any for free 
(just postage costs), let me know by Thursday.

--

-- 
Stephen

ah liang | 2 Sep 12:44 2007
Picon

porting netBSD to pxa270 evaluation board

can anyone help me with steps on how i can port netBSD to an arm evaluation board running a pxa270 processor
board is from www.voipac.com
its the baseboard with the pxa270 processor sodimm

any help would be much appreciated. i'm trying to learn this for my final year project at uni

thank you very much

andrew

Julio M. Merino Vidal | 11 Sep 17:43 2007
Picon

Re: Is pccons of any use in shark?

On Jul 30, 2007, at 3:17 PM, Izumi Tsutsui wrote:

> jmmv84 <at> gmail.com wrote:
>
>> 2. After the above, any reason not to kill pccons and remove it from
>>     the tree?
>
> I left pccons when I wrote wscons support for shark because
> - i386 still had it (for INSTALL_TINY)
> - there were few report about wscons
> - I'm not sure if there is any size restriction for openfirmware
>   to load a.out kernels

So, can we kill it?  I don't like the fact that the pccons code is  
duplicated all over the tree.  E.g. I found a bug in shark's pccons  
that had long been fixed in i386; I'm afraid there may be other  
instances of similar problems.  (Sure, we'd sync the two drivers, but  
cannot see the reason to do so.)

Now that both INSTALL and GENERIC use pccons, I doubt anybody will  
use pccons instead of wscons.  And getting rid of old, unused code is  
a worthy goal I think :-)  (Less maintenance headaches, less obsolete  
code to look at.)

--

-- 
Julio M. Merino Vidal <jmmv84 <at> gmail.com>

Jason Thorpe | 11 Sep 17:46 2007

Re: Is pccons of any use in shark?


On Sep 11, 2007, at 8:43 AM, Julio M. Merino Vidal wrote:

> So, can we kill it?  I don't like the fact that the pccons code is  
> duplicated all over the tree.  E.g. I found a bug in shark's pccons  
> that had long been fixed in i386; I'm afraid there may be other  
> instances of similar problems.  (Sure, we'd sync the two drivers,  
> but cannot see the reason to do so.)

Nuke it from orbit.  It's the only way to be sure.

-- thorpej

Izumi Tsutsui | 11 Sep 17:58 2007
Picon

Re: Is pccons of any use in shark?

jmmv84 <at> gmail.com wrote:

> So, can we kill it?

No idea about pccons, but what about ofcons?

(I confirmed all of pccons, ofcons and wscons worked
 as console when I added wscons for shark ;-)
---
Izumi Tsutsui

Matt Thomas | 12 Sep 17:46 2007

VFP support?


I have a few ARMs with real VFP.  What is the state of VFP support in  
NetBSD?
Does it work?  Should it work?

Matt Thomas | 12 Sep 17:57 2007

L2 caches and cpufuncs.


The Freescale i.MX31 has a 128KB L2 cache controller.  It's not clear  
how it
should interact with the normal cpu functions.

Obviously, since the L2 looks like memory to the CPU, any icache ops  
don't
even need to know the L2 exists.

The question is should the dcache ops know about it?  There's only one
component that really needs to know it's there, bus_dma.  So maybe there
should be a separate interface for it to do L2 cache ops.

Comments?

Chris Gilbert | 13 Sep 01:05 2007
Picon

Re: L2 caches and cpufuncs.

Matt Thomas wrote:
> 
> The Freescale i.MX31 has a 128KB L2 cache controller.  It's not clear
> how it
> should interact with the normal cpu functions.
> 
> Obviously, since the L2 looks like memory to the CPU, any icache ops don't
> even need to know the L2 exists.
> 
> The question is should the dcache ops know about it?  There's only one
> component that really needs to know it's there, bus_dma.  So maybe there
> should be a separate interface for it to do L2 cache ops.

That would seem reasonable.  Although it would be nice if it was
compiled away on machines that don't need it, but then it would be nice
if other cpu_funcs eg cpwait did that as well.

> Comments?

Thanks,
Chris

Chris Gilbert | 13 Sep 01:19 2007
Picon

Re: VFP support?

Matt Thomas wrote:
> 
> I have a few ARMs with real VFP.  What is the state of VFP support in
> NetBSD?
> Does it work?  Should it work?

I don't think it's supported at the moment, I don't remember anyone
adding code to save the VFP regs on a context switch which is probably
the main bit of kernel work needed.

gcc appears to have vfp support as a vfp file does exist:
src/gnu/dist/gcc4/gcc/config/arm/vfp.md
possibly enabled by using:
-mfpu=vfp

Also I note that sys/arch/arm/include/float.h has some #ifndef __VFP_FP__

Is it a full vfp implementation, or is it like the original floating
point where the some instructions are in hardware, and some are emulated?

So I guess it's been thought about, but as your possibly the first
person with a VFP capable chip you get the fun of making it work :)

Thanks,
Chris

Matt Thomas | 13 Sep 04:37 2007

Re: VFP support?


On Sep 12, 2007, at 4:19 PM, Chris Gilbert wrote:

> Matt Thomas wrote:
>>
>> I have a few ARMs with real VFP.  What is the state of VFP support in
>> NetBSD?
>> Does it work?  Should it work?
>
> I don't think it's supported at the moment, I don't remember anyone
> adding code to save the VFP regs on a context switch which is probably
> the main bit of kernel work needed.
>
> gcc appears to have vfp support as a vfp file does exist:
> src/gnu/dist/gcc4/gcc/config/arm/vfp.md
> possibly enabled by using:
> -mfpu=vfp
>
> Also I note that sys/arch/arm/include/float.h has some #ifndef  
> __VFP_FP__
>
> Is it a full vfp implementation, or is it like the original floating
> point where the some instructions are in hardware, and some are  
> emulated?
>
> So I guess it's been thought about, but as your possibly the first
> person with a VFP capable chip you get the fun of making it work :)

It's a full implementation as far as I can tell.


Gmane