Jonathan Cline | 3 May 2003 00:45

s3c2xx0 typos

Hi,

Perhaps these are two non critical typos
(likely cut & paste errors) noticed in
current arm kernel.

1. double include, see below

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/s3c2xx0/s3c2800var.h?re
v=1.1&content-type=text/x-cvsweb-markup

#include <arm/s3c2xx0/s3c2xx0var.h>

#ifndef _ARM_S3C2800VAR_H_
#define _ARM_S3C2800VAR_H_

#include <arm/s3c2xx0/s3c2xx0var.h>

2. second FAIL("TIMER0") should likely say TIMER1

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/arm/s3c2xx0/s3c2800.c?rev=1
.2&content-type=text/x-cvsweb-markup

	if (bus_space_map(iot, S3C2800_TIMER0_BASE,
		S3C2800_TIMER_SIZE, 0, &sc->sc_tmr0_ioh))
		FAIL("TIMER0");

	if (bus_space_map(iot, S3C2800_TIMER1_BASE,
		S3C2800_TIMER_SIZE, 0, &sc->sc_tmr1_ioh))
		FAIL("TIMER0");
(Continue reading)

Hiroyuki Bessho | 3 May 2003 07:20
Picon

Re: s3c2xx0 typos

"Jonathan Cline" <jcline <at> d2tech.com> writes:

> Hi,
>
> Perhaps these are two non critical typos
> (likely cut & paste errors) noticed in
> current arm kernel.
>
>

Fixed. thank you for your report.

Reinoud Zandijk | 7 May 2003 01:18
Picon

Re: excuse the incorrect name

Dear Arthur,

On Tue, May 06, 2003 at 05:11:02PM -0500, Tara Lee Procter wrote:
> Hello, my name is Arthur (not Tara) :)  I was wondering where I may find
> more information on using NetBSDs ARM port to run it on the Cirrus Logic
> EP7312 or the CS89712(ethernet)?   It is the ARM 720T core with a bunch or
> peripherals on the chip..  I have been searching the internet for more
> information, how-to's, but now luck.  Would you be kind enough to point me
> in the right direction?  I would probably be cross compiling on a i386
> architecture to the ARM.

Hmm... i am not familiar with the EP or CD chips you mention but it being
an ARM 720T core gives hope! I've relayed it on the more general
port-arm <at> netbsd.org mailing list for the ARM ports are devided up into
Acorn32, Shark, hand held devices and expirimental boards.

The ARM7 core and esp. the ARM710 is fully supported so porting might be
easy since it mainly is writing your own startup-code (aka like
src/sys/arch/acorn32/acorn32/rpc_machdep.c) and provide device drivers for
the build in devices you want to use. They are propably allready supported
in one form or another and are either shared with the other ARM ports or
between other ports with chip/bus-drivers (src/dev/ic/, src/dev/pci). If
you have specific questions about porting and supported devices its also
good to also check the evbarm and hpcarm ports pages.

Googling gives me the EP7312 product page ... well it seems like we support
the processor allthough the Thumb instruction set extention is not used in
NetBSD but on the whole it looks very much like a bog standard ARM7. Is it 
part of a expirimental board? or some other (propriaty) device?

(Continue reading)

Maciuszonek Artur | 7 May 2003 06:54
Picon
Favicon

Re: excuse the incorrect name

Please be kind enough to update this e-mail address to
flying_wookie <at> shaw.ca as the response to the thread.

Thank You

Artur M.

---------------------------------------------

Dear Arthur,

On Tue, May 06, 2003 at 05:11:02PM -0500, Tara Lee Procter wrote:
> Hello, my name is Arthur (not Tara) :)  I was wondering where I may find
> more information on using NetBSDs ARM port to run it on the Cirrus Logic
> EP7312 or the CS89712(ethernet)?   It is the ARM 720T core with a bunch or
> peripherals on the chip..  I have been searching the internet for more
> information, how-to's, but now luck.  Would you be kind enough to point me
> in the right direction?  I would probably be cross compiling on a i386
> architecture to the ARM.

Hmm... i am not familiar with the EP or CD chips you mention but it being
an ARM 720T core gives hope! I've relayed it on the more general
port-arm <at> netbsd.org mailing list for the ARM ports are devided up into
Acorn32, Shark, hand held devices and expirimental boards.

The ARM7 core and esp. the ARM710 is fully supported so porting might be
easy since it mainly is writing your own startup-code (aka like
src/sys/arch/acorn32/acorn32/rpc_machdep.c) and provide device drivers for
the build in devices you want to use. They are propably allready supported
in one form or another and are either shared with the other ARM ports or
(Continue reading)

Ted Lemon | 16 May 2003 01:22

Shark looking for a good home.

I have a Shark that's been lying around that needs a good home.   It's 
your basic DNARD, with (I think) 64M of memory.   If anybody wants it, 
please let me know.   Preference to someone who's going to do something 
cool with it, of course.

BTW, I'm not on the port-arm mailing list, so please contact me 
privately.

Jonathan Cline | 16 May 2003 20:14
Picon

atomic write routine

Hello,

In developing the psionarm port, I've now run
into writing some mach dep assembly (ARM7).  
I'd appreciate feedback on the following routine 
as this is my first attempt at arm assembly.
The problem I am solving here is simple:
on this SoC, there is a peripheral control 
register which is shared by multiple devices
(UART has some bits, timer has some bits, etc).
Since there are FIQ's active which might create
races by writes to this register and the current
arm kernels don't have intrinsic atomic routines
for blocking FIQ, I've written the below to 
set and get the register (called syscon).
I believe this explaination is longer than the
code itself, so here goes.  Also note that
there are two defines elsewhere:

#define SK_REG_BANK      (0x80000000)
#define SK_SYSCON           (0x0100)

Question ahead of time: what regs are
available for use when calling asm from C?
I've guessed that args are passed in r0..rN
respectively.  In SetSYSCON below, I'm clobbering
r3, r4, r5.  What's the c-model to save them?

/*
 * void    SetSYSCON(u_int clear_mask, u_int set_mask);
(Continue reading)

Ben Harris | 17 May 2003 14:54
Picon

Re: atomic write routine

On Fri, 16 May 2003, Jonathan Cline wrote:

> Question ahead of time: what regs are
> available for use when calling asm from C?
> I've guessed that args are passed in r0..rN
> respectively.  In SetSYSCON below, I'm clobbering
> r3, r4, r5.  What's the c-model to save them?

NetBSD currently more-or-less follows the old ARM Procedure Call Standard
(APCS), in 32-bit mode (even on 26-bit CPUs) with no floating point and an
implicit stack limit.  When ARM finally complete their EABI (which was
called EABI-2001 until that started to be embarassing), we'll probably
follow that.  Anyway, the short answer to your question is:

R0-R3: argument passing/caller-saved
R4-R10: callee-saved
R12, R14: caller-saved
R11: frame pointer
R13: stack pointer

The usual idiom for creating a stack frame is:

	mov	ip, sp
	stmfd	sp!, {r4-r10, fp, ip, lr, pc}
	sub	fp, ip, #4

And to return:

	ldmdb	fp, {r4-r10, fp, sp, pc}

(Continue reading)

John Clark | 23 May 2003 16:34
Favicon

Problems with the SYM53C8XX driver on Arm NetBSD and IQ80321

I'm working on the port of NetBSD to the Intel XScale eval board titled 
IQ80321. This has
the Verde XScale chip on it. Apparently there is a problem with how the 
Verde produces byte
accesses  on the PCI, and how the Symbios/LSI 53C1010 responds.

I would like to know if there are any others working with the 
Symbios/LSI chip on a Verde
design.

Thanks
John Clark

Jason Thorpe | 23 May 2003 19:40

Re: Problems with the SYM53C8XX driver on Arm NetBSD and IQ80321


On Friday, May 23, 2003, at 07:34  AM, John Clark wrote:

> I would like to know if there are any others working with the 
> Symbios/LSI chip on a Verde
> design.

I haven't used Verde with a 53c1010, but I do know someone at Intel who 
has used a 53c895 with a Verde.

Have you tried setting the switches on the board to PCI-66 mode, rather 
than PCI-X?

         -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

John Clark | 23 May 2003 20:08
Favicon

Re: Problems with the SYM53C8XX driver on Arm NetBSD and IQ80321


Am Freitag, 23.05.03, um 10:40 Uhr (US/Pacific) schrieb Jason Thorpe:

>
> On Friday, May 23, 2003, at 07:34  AM, John Clark wrote:
>
>> I would like to know if there are any others working with the 
>> Symbios/LSI chip on a Verde
>> design.
>
> I haven't used Verde with a 53c1010, but I do know someone at Intel 
> who has used a 53c895 with a Verde.
>
> Have you tried setting the switches on the board to PCI-66 mode, 
> rather than PCI-X?

I will look into that. But shouldn't that sort of be 'automagic' if my 
card is PCI-66/33 only?
Or is there something subtile which when the PCI-66 is forced, changes 
things?

Thanks
John Clark


Gmane