headers
Shoichi Miyake | 1 Aug 2003 09:07
Picon
Picon

ZAO425 pci supported ?

Hello,

I've accidently got a ZAO425 evaluation board, and just started to
play with NetBSD/evbarm.

I see PCI/mPCI devices are supported on NetBSD/evbarm page, but those
codes seems not commited in repositry, right ?

If that's bucause already written but just not commited, I hope if I
could get and use them (I think maybe those are Fukuhara-san's
code...).

Any help would be appreciated,

Best Regards,
Shoichi Miyake
Permalink | Reply | 2 comments |
headers
Ichiro FUKUHARA | 1 Aug 2003 09:20

Re: ZAO425 pci supported ?

Hi Miyake-san,

I have not completed writing a perfect PCI/mPCI code yet,
however Im going to commit later for a while.
Pls give me cooperation about the review of a that code. 

From: Shoichi Miyake <smi <at> sm.sony.co.jp>
Subject: ZAO425 pci supported ?
Date: Fri, 01 Aug 2003 16:07:27 +0900 (JST)
Message-ID: <20030801.160727.62136302.smi <at> sm.sony.co.jp>

smi> Hello,
smi> 
smi> I've accidently got a ZAO425 evaluation board, and just started to
smi> play with NetBSD/evbarm.
smi> 
smi> I see PCI/mPCI devices are supported on NetBSD/evbarm page, but those
smi> codes seems not commited in repositry, right ?
smi> 
smi> If that's bucause already written but just not commited, I hope if I
smi> could get and use them (I think maybe those are Fukuhara-san's
smi> code...).
Permalink | Reply | 1 comment |
headers
Shoichi Miyake | 1 Aug 2003 11:44
Picon
Picon

Re: ZAO425 pci supported ?

> Hi Miyake-san,

Hi, Fukuhara-san, thank you for your prompt reply!

> I have not completed writing a perfect PCI/mPCI code yet,
> however Im going to commit later for a while.
> Pls give me cooperation about the review of a that code. 

Oh, that's good news to me.
Yes, I don't know if I can commit, I'll do my best.

Best Regards,
Shoichi Miyake
Permalink | Reply | 0 comments |
headers
Valeriy E. Ushakov | 2 Aug 2003 23:21
Picon

Re: can't profile on Shark

On Thu, Jun 26, 2003 at 15:59:14 +0100, Richard Earnshaw wrote:

> rearnsha <at> arm.com said:
> > I don't know why the gmon module needs to do FP arithmetic, I though
> > it  just wrote out the raw tables. 
> 
> Hmm, this is from libc/gmon/gmon.c:
> 
> #ifndef notdef
>                 s_scale = ((float)p->kcountsize / o ) * SCALE_1_TO_1;
> #else /* avoid floating point */
>                 u_long quot = o / p->kcountsize;
>                 
>                 if (quot >= 0x10000)
>                         s_scale = 1;
>                 else if (quot >= 0x100)
>                         s_scale = 0x10000 / quot;
>                 else if (o >= 0x800000)
>                         s_scale = 0x1000000 / (o / (p->kcountsize >> 8));
>                 else
>                         s_scale = 0x1000000 / ((o << 8) / p->kcountsize);
> #endif
> 
> Anyone know why that is "#ifndef notdef" rather than "#ifdef notdef"?  
> Seems backwards to me...

On Thu, Jun 26, 2003 at 18:53:08 -0700, Jason Thorpe wrote:

> On Thursday, June 26, 2003, at 07:59  AM, Richard Earnshaw wrote:
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ignatios Souvatzis | 3 Aug 2003 10:08
Picon

Re: can't profile on Shark

On Fri, Jun 27, 2003 at 10:18:46AM +0200, Ignatios Souvatzis wrote:
> On Thu, Jun 26, 2003 at 06:53:08PM -0700, Jason Thorpe wrote:
> > 
> > On Thursday, June 26, 2003, at 07:59  AM, Richard Earnshaw wrote:
> > 
> > >Anyone know why that is "#ifndef notdef" rather than "#ifdef notdef"?
> > >Seems backwards to me...
> > 
> > Eek, yes, it's certainly a mistake.
> 
> So I should reverse that to #ifdef , rebuild my libs and be able to
> find out why my program is horribly slow on the Sharks, compared to
> M68060 and PII/400?
> 
> I'll try that.

Sorry, I was distracted by RL. I'll try that really soon know.

	-is
Permalink | Reply | 0 comments |
headers
Ignatios Souvatzis | 3 Aug 2003 10:53
Picon

Re: can't profile on Shark

Hi,

On Sun, Aug 03, 2003 at 01:21:44AM +0400, Valeriy E. Ushakov wrote:

> And that ifndef in gmon.c is still not fixed.  Changing
> s/ifndef/ifdef/ makes the program link and produce the gmon.out.

Same for Shark/NetBSD-1.6.1.

> I'd like to commit that change.

You should ask on tech-foo for some value of foo... the libc change is not
sh3/arm specific, but will affect all architectures.

	-is

--

-- 
seal your e-mail: http://www.gnupg.org/
Permalink | Reply | 0 comments |
headers
Shoichi Miyake | 9 Aug 2003 11:11
Picon
Picon

/bin/sh (?) problem on md-root on ZAO425

Hi, I'm sorry if you see this message again and again, but my message
seems to be stucking in somewhere...

Hi,

On ZAO425 board,
have anyone experienced symptom like this about /bin/sh ?

What I did are,
- cross-built on NetBSD-1.6U/i386 (around August 3 or 4 source)
- first off, used build.sh release
- created big-endian sysinst ramdisk for armeb
- built ZAO425_MD kernel
- mdsetimage'ed this kernel and ramdisk
- used Redboot to boot this kernel
- made .profile nearly empty, to make it simple...
[/.profile]
set -x
PATH=/sbin:/bin:/usr/bin:/usr/sbin:/
export PATH
TERM=vt100
export TERM
HOME=/
export HOME

umask 022

ROOTDEV=/dev/md0a
[end of .profile]
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Laight | 9 Aug 2003 11:38
Picon

Re: /bin/sh (?) problem on md-root on ZAO425

> + PATH=/sbin:/bin:/usr/bin:/usr/sbin:/
> + export PATH
> + T1TER=vt0
> + export 1 TE
> + HOME=/
> + exAex HOME
> + umask 022
> + ROV=ROevDEd0/dd0a

This can only be caused by using misaligned memory transfers.
(and I expect there are nested ones later, causing complete gibberish).

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 1 comment |
headers
Shoichi Miyake | 11 Aug 2003 06:14
Picon
Picon

Re: /bin/sh (?) problem on md-root on ZAO425

Hello David,

> > + PATH=/sbin:/bin:/usr/bin:/usr/sbin:/
> > + export PATH
> > + T1TER=vt0
> > + export 1 TE
> > + HOME=/
> > + exAex HOME
> > + umask 022
> > + ROV=ROevDEd0/dd0a
> 
> This can only be caused by using misaligned memory transfers.
> (and I expect there are nested ones later, causing complete gibberish).

Hmm..., does it mean libc has some issue ?
I'll try more investigation...

Anyway, thank you very much for your follow up!

Best Regards,
Shoichi Miyake
Permalink | Reply | 0 comments |
headers
Richard Earnshaw | 11 Aug 2003 10:58
Favicon

EVBARM - layout of BootConfig structure


The current BootConfig structure in evbarm/include/bootconfig.h has

#define DRAM_BLOCKS     1

typedef struct _BootConfig {
        PhysMem dram[DRAM_BLOCKS];
        u_int dramblocks;
} BootConfig;

This is somewhat back-to-front, in that if I increase DRAM_BLOCKS (as I 
wish to do) that will move the offset of the dramblocks field.  I'd like 
to rearrange this structure to:

typedef struct _BootConfig {
        u_int dramblocks;
        PhysMem dram[DRAM_BLOCKS];
} BootConfig;

so that it is possible in future to bump the size of DRAM_BLOCKS without 
breaking a binary interface that is notionally shared between 
netbsd/evbarm and its "bios" (having netbsd able to access a larger array 
won't hurt, since the size only matters if NetBSD allocates one of these 
statically, and if it doesn't then it will never access beyond 
dramblocks-1 entries).  However, doing so will break things if any 
existing builds are already using a "bios" to probe memory.

So before I go ahead and do this, is anybody already relying on this 
structure externally?
(Continue reading)

Permalink | Reply | 4 comments |

Gmane