Subject: Re: Debugging / SPL-levels / AT91RM9200 success
To: None <port-arm@netbsd.org>
From: Toru Nishimura <locore64@alkyltechnology.com>
List: port-arm
Date: 03/03/2007 17:40:00
Sami Kantoluoto wrote;

> I'm porting NetBSD to run our embedded hardware and it has Atmel's AT91RM9200
> CPU. So far I've following running:
> 
> NetBSD 4.0_BETA2 (MPCSA_GENERIC) #0: Wed Feb 28 04:05:03 EET 2007
> skanto@haapana:/tmp/nb4arm/obj/sys/arch/evbarm/compile/MPCSA_GENERIC
> total memory = 65536 KB
> avail memory = 61000 KB
> mainbus0 (root)
> cpu0 at mainbus0: ARM920T rev 0 (ARM9TDMI core)

_KooL_

> With current the system was quite unstable (paniced quite often under heavy
> load) so I tried netbsd-4 and it looked stable. 

NB-current has much trouble for many ports.  It'd be rather better to wait for
dusts get settled down.

> Anyway, under heavy CF I/O NetBSD may just hang or if I try to terminate
> e.g. 'dd if=/dev/w0c bs=64k', the shell just hangs or so. So I'm wondering
> if there's a good way to verify the SPL levels are working correctly etc.
> Or any other ideas to check?

It's necessary for you to disclose and explain how you implemented splFOO()
for your HW.  Just out of curiosity; I can see "pcmcia" device node in the dmesg.
Is it necessary after all?  I think it could be simpler to do the same.  I once had
a deal with MX1L NetBSD porting in which design CF card was interfaced via
custom CPLD in a simple form.  Since the slot is dedicated for CF, splbio() is
acceptable to guard critical sections.  On the other hands, any hot-plug-able bus,
like PCMCIA, USB (or SDIO) must be able to support any type of peripheral
devices, logics determining correct spl level must be dynamic and complicated.
I guess "cf" node can be made to arbitrate apb->cf->wdc logic path.  It can be
hot-swappable if you design your own kernel-thread to replace pcmcia node.

Toru Nishimura/ALKYL Technology