headers
J. Blanco | 2 Nov 2008 04:21
Picon
Favicon

Re: EP9307?


Hi,

Could you tell how to upoad a new linux image (arm linux, not the official
encore image) to this ENCORE device.

Thanks.
Jaime

Martin Guy wrote:
> 
>> Is there any support for Cirrus Logic EP9037 (ARM 920T)?
>>  http://www.cirrus.com/en/products/pro/detail/P1061.html
> 
> DUnno about that board, but yes, ep93xx is a supported NetBSD chip,
> with support for the Armadillo board and others.
> 
>>  It's useless for its intended purpose as a thin-client (too slow for
>> words), but for $150 it might make a nice plaything.
> I use one as an X terminal (albeit running Linux sue to its more
> stable frame buffer driver) and with its 64MB RAM it is perfectly fast
> enough.
> 
>     M
> 
> 

--

-- 
View this message in context: http://www.nabble.com/EP9307--tp19507986p20286789.html
Sent from the port-arm mailing list archive at Nabble.com.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikko Rapeli | 3 Nov 2008 10:19

Re: Status of current on ARM?

Thanks, all, for your input. Since some ARM platforms work with current, I'm
presuming only OMAP is broken.

On Fri, Oct 31, 2008 at 09:19:44AM -0700, Matt Thomas wrote:
> On Oct 31, 2008, at 5:52 AM, Mikko Rapeli wrote:
> 
> >What is the general status of netbsd-current on ARM?
> >
> >evbarm on OMAP 2420 has been broken since August 6th. Imre Deak  
> >brought
> >up the issues on port-arm, and later a pr was failed
> >http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=39791 .
> >An obvious workaround on OMAP 2420 is to undo a few changes, attached
> >patches, but I'm willing to test if anyone has better fixes around.
> 
> It works for me.  I booted a 2420 less than a week ago.

Not for me. Which 2420 are you working with? We are using TI's OMAP 2420
SDP evaluation boards. And which kernel config? I'm using the standard
TISDP2420 with changes to static IP addresses, root NFS paths and rootfs
location (sm0, type nfs) and serial port set to 115k bauds.

> >I would like to test and the post some thumb mode fixes to the kernel
> >which are working with OMAP 2420 on a branch from current, taken  
> >August
> >5th. But the failing kernel from current is blocking that work.
> 
> I see no reason since -current is working.  Are you sure your source  
> tree
> is clean?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Thomas | 3 Nov 2008 19:08

Re: Status of current on ARM?


On Nov 3, 2008, at 1:19 AM, Mikko Rapeli wrote:

> Thanks, all, for your input. Since some ARM platforms work with  
> current, I'm
> presuming only OMAP is broken.
>
> On Fri, Oct 31, 2008 at 09:19:44AM -0700, Matt Thomas wrote:
>>
>> It works for me.  I booted a 2420 less than a week ago.
>
> Not for me. Which 2420 are you working with? We are using TI's OMAP  
> 2420
> SDP evaluation boards. And which kernel config? I'm using the standard
> TISDP2420 with changes to static IP addresses, root NFS paths and  
> rootfs
> location (sm0, type nfs) and serial port set to 115k bauds.

TI 2420 SDP H4.  The TISDP2420 from evbarm.

>> I see no reason since -current is working.  Are you sure your source
>> tree
>> is clean?
>
> We use git for managing the netbsd sources, and the current cvs  
> tree gets
> updated to the git tree daily. There have not been any known issues  
> with this
> interworking. But to be sure I checked out sources from cvs on Friday,
> updated them to latest again this morning, and compiled both kernel
(Continue reading)

Permalink | Reply | 0 comments |
headers
der Mouse | 4 Nov 2008 07:04

audio can't set params??

I have a program which, among other things, plays audio.  Works fine on
i386 (both 3.1 and my old 1.4T).  But when I tried to run it on my
shark (also 3.1), I had trouble.

First time I run it after boot, it starts up fine.  But if I exit and
then restart, it fails when trying to open /dev/sound; the open call
shows EINVAL.  Adding debugging printfs to the kernel, I find that the
call to hw->set_params inside autiosetinfo() is failing.  Resetting the
audio playback state with "sh -c '< /dev/audio'" (/dev/audio being the
reset-on-open device) brings it back into a state where it can open
/dev/sound.

It seems to me there's surely something broken if it can set a
particular state with AUDIO_SETINFO while the device is open, but it
can't set the same state on open.

In case it matters, here's a diff between audioctl -a output in the
before ("working") and after ("broken") states.

8,9c8,9
< blocksize=800
< hiwat=81
---
> blocksize=8816
> hiwat=7
13,16c13,16
< play.rate=8000
< play.channels=1
< play.precision=8
< play.encoding=mulaw
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikko Rapeli | 4 Nov 2008 07:58

Re: Status of current on ARM?

[I think we can continue debugging this on port-arm]

On Mon, Nov 03, 2008 at 10:08:25AM -0800, Matt Thomas wrote:
> On Nov 3, 2008, at 1:19 AM, Mikko Rapeli wrote:
> >Not for me. Which 2420 are you working with? We are using TI's OMAP  
> >2420
> >SDP evaluation boards. And which kernel config? I'm using the standard
> >TISDP2420 with changes to static IP addresses, root NFS paths and  
> >rootfs
> >location (sm0, type nfs) and serial port set to 115k bauds.
> 
> TI 2420 SDP H4.  The TISDP2420 from evbarm.

So we have the same boards. Mine should be H4 too, but can't see it on
the stickers. SDP 2420-V5.0 is on it.

> >The result is a kernel panic in the pmap code, as described in pr  
> >#39791
> >and to which workaround are the two revert patches in my previous
> >mail. Boot log and backtrace can be found below.
> >
> >If I were managing a tree, I would revert patches that have issues on
> >some hardware, and would work to get those issues fixed. I'm  
> >willing to test
> >any alternatives there are, but at the moment current on OMAP 2420 is
> >broken, and workaround patches have been proposed.
> 
> Any reason why you haven't populated /dev on the server?  I don't  
> understand
> why your kernel is trying to write /dev/mem or /dev/kmem.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Matt Thomas | 4 Nov 2008 08:40

Re: Status of current on ARM?


On Nov 3, 2008, at 10:58 PM, Mikko Rapeli wrote:

> The userspace is a destdir.evbarm after build.sh build and  
> distribution
> targets. I thought the boot scripts created enough /dev nodes for  
> single
> user boot to succeed. Below is a log from an older kernel booting the
> same userspace from yesterdays current.

This is due a bug in userspace provoking a bug in pmap.c.  Which has now
been fixed.  If you cvs update, it should work now.
Permalink | Reply | 16 comments |
headers
Mikko Rapeli | 4 Nov 2008 10:51

Re: Status of current on ARM?

On Mon, Nov 03, 2008 at 11:40:07PM -0800, Matt Thomas wrote:
> On Nov 3, 2008, at 10:58 PM, Mikko Rapeli wrote:
> >The userspace is a destdir.evbarm after build.sh build and  
> >distribution
> >targets. I thought the boot scripts created enough /dev nodes for  
> >single
> >user boot to succeed. Below is a log from an older kernel booting the
> >same userspace from yesterdays current.
> 
> This is due a bug in userspace provoking a bug in pmap.c.  Which has now
> been fixed.  If you cvs update, it should work now.

Indeed, your patches work, thanks. Boot log follows down below.

The current kernel is not very well tuned for OMAP 2420 since it takes 
2 minutes and 44 seconds to boot it to the "Enter pathname of shell..."
point. In comparison our kernel branch takes 19 seconds. Userspace was the 
same yesterdays current on both.

Hopefully we can post our changes soon, since the biggest road
block is now fixed. If anyone has suggestions how to improve patch
flow from interested parties like us towards NetBSD, we'd very much like
to hear them.

Thanks again, Matt.

-Mikko

U-Boot 1.1.3 (Sep 10 2007 - 11:20:13)
(Continue reading)

Permalink | Reply | 15 comments |
headers
Chris Gilbert | 4 Nov 2008 14:06
Picon

Re: Status of current on ARM?

Mikko Rapeli wrote:
> On Mon, Nov 03, 2008 at 11:40:07PM -0800, Matt Thomas wrote:
>> On Nov 3, 2008, at 10:58 PM, Mikko Rapeli wrote:
>>> The userspace is a destdir.evbarm after build.sh build and  
>>> distribution
>>> targets. I thought the boot scripts created enough /dev nodes for  
>>> single
>>> user boot to succeed. Below is a log from an older kernel booting the
>>> same userspace from yesterdays current.
>> This is due a bug in userspace provoking a bug in pmap.c.  Which has now
>> been fixed.  If you cvs update, it should work now.
> 
> Indeed, your patches work, thanks. Boot log follows down below.
> 
> The current kernel is not very well tuned for OMAP 2420 since it takes 
> 2 minutes and 44 seconds to boot it to the "Enter pathname of shell..."
> point. In comparison our kernel branch takes 19 seconds. Userspace was the 
> same yesterdays current on both.

That's quite a scary difference.

> Hopefully we can post our changes soon, since the biggest road
> block is now fixed. If anyone has suggestions how to improve patch
> flow from interested parties like us towards NetBSD, we'd very much like
> to hear them.

Options are (and may depend on your corporate policies):
* supply patches to mailing lists
* add them to the PR database (at least they're tracked and not lost)
* get the hardware and patches into the hands of someone with commit
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christos Zoulas | 4 Nov 2008 22:58

Re: Status of current on ARM?

In article <491048E9.8090606 <at> dokein.co.uk>,
Chris Gilbert  <chris <at> dokein.co.uk> wrote:
>Mikko Rapeli wrote:
>> On Mon, Nov 03, 2008 at 11:40:07PM -0800, Matt Thomas wrote:
>>> On Nov 3, 2008, at 10:58 PM, Mikko Rapeli wrote:
>>>> The userspace is a destdir.evbarm after build.sh build and  
>>>> distribution
>>>> targets. I thought the boot scripts created enough /dev nodes for  
>>>> single
>>>> user boot to succeed. Below is a log from an older kernel booting the
>>>> same userspace from yesterdays current.
>>> This is due a bug in userspace provoking a bug in pmap.c.  Which has now
>>> been fixed.  If you cvs update, it should work now.
>> 
>> Indeed, your patches work, thanks. Boot log follows down below.
>> 
>> The current kernel is not very well tuned for OMAP 2420 since it takes 
>> 2 minutes and 44 seconds to boot it to the "Enter pathname of shell..."
>> point. In comparison our kernel branch takes 19 seconds. Userspace was the 
>> same yesterdays current on both.
>
>That's quite a scary difference.
>
>> Hopefully we can post our changes soon, since the biggest road
>> block is now fixed. If anyone has suggestions how to improve patch
>> flow from interested parties like us towards NetBSD, we'd very much like
>> to hear them.
>
>Options are (and may depend on your corporate policies):
>* supply patches to mailing lists
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael | 5 Nov 2008 01:04
Picon

Xorg on shark

Hello,

we now have native Xorg support for both rev. 4 and rev. 5 sharks in - 
current. Rev. 5 is still unaccelerated but writing an accelerated  
driver isn't very difficult, maybe I'll get around to do it.

have fun
Michael
Permalink | Reply | 0 comments |

Gmane