linuxdc-dev — Developer discussion list

Re: [linuxsh-dev] Re: [linuxdc-dev][PATCH] maple keyboard fix

[Robert L. <rm...@te...>]

On Thu, 2001-12-06 at 10:25, M. R. Brown wrote:

> > The attached patch fixes the problems.  There may be more.  _Please_
> > merge into CVS.
> 
> Applied to branch and head - thanks!

Thank you.  As SH users start using 2.4.15-pre7 and later kernels, they
may experience odd problems.  I wish I could give a formula for tracking
down if a specific issue is this memchr/memscan problem, but it can
manifest itself in a myriad of ways.

One thing to consider is that _all_ uses of memscan are either broken
now or where broken before the change.  I.e., they expected one of the
two behaviors at some point but got the other.  This means a global
audit of memscan use may be useful.

	Robert Love

Re: [linuxdc-dev][PATCH] maple keyboard fix

[M. R. B. <mr...@0x...>]

* Robert Love <rm...@te...> on Thu, Dec 06, 2001:

>=20
> The attached patch fixes the problems.  There may be more.  _Please_
> merge into CVS.

Applied to branch and head - thanks!

M. R.

> --- linux/drivers/char/maple_keyb.c.orig	Thu Dec  6 01:39:45 2001
> +++ linux/drivers/char/maple_keyb.c	Thu Dec  6 01:40:48 2001
> @@ -55,7 +55,7 @@
> =20
>  	for(i=3D2; i<8; i++) {
> =20
> -		if(kbd->old[i]>3&&memscan(kbd->new+2, kbd->old[i], 6)=3D=3DNULL) {
> +		if(kbd->old[i]>3&&memchr(kbd->new+2, kbd->old[i], 6)=3D=3DNULL) {
>  			if(dc_kbd_keycode[kbd->old[i]])
>  				input_report_key(dev,
>  						 dc_kbd_keycode[kbd->old[i]],
> @@ -65,7 +65,7 @@
>  				       kbd->old[i]);
>  		}
> =20
> -		if(kbd->new[i]>3&&memscan(kbd->old+2, kbd->new[i], 6)!=3DNULL) {
> +		if(kbd->new[i]>3&&memchr(kbd->old+2, kbd->new[i], 6)!=3DNULL) {
>  			if(dc_kbd_keycode[kbd->new[i]])
>  				input_report_key(dev,
>  						 dc_kbd_keycode[kbd->new[i]],

[linuxdc-dev][PATCH] maple keyboard fix

[Robert L. <rm...@te...>]

In 2.4.15-pre7, the following change to include/asm-sh/string.h were
merged:

-#define __HAVE_ARCH_MEMSCAN
-#define memscan memchr

This was a Good Thing, since the two function are not specified to have
the same behavior.  memchr returns NULL on no match, and memscan returns
addr+1 if a match is not found.

The problem lies in that there is SH arch code that depended on the
false behavior of memscan -- that is, even though they called memscan,
they assumed it returned NULL on no match (since it was defined as
memchr which does just that).

At least one problem area was found: maple_keyb.c, and this was causing
my previously reported keyboard problem on my Dreamcast.

The attached patch fixes the problems.  There may be more.  _Please_
merge into CVS.

	Robert Love

[linuxdc-dev]Re: [PATCH] Preemptible Kernel for SH (and thus dreamcast)

[Robert L. <rm...@te...>]

Users of gcc-3.x will need the attached patch for gcc to compile an SH
kernel patched with preempt-kernel.  This is _not_ our fault, it is a
gcc bug and is now merged into CVS and should be part of gcc-3.1.

gcc-2.9x compiles without problem.  It is only 3.x versions that suffer
the bug.

        Robert Love

Re: [linuxdc-dev]keyboard key press problem

[Robert L. <rm...@te...>]

On Wed, 2001-12-05 at 18:19, Adrian McMenamin wrote:
> Not this problem exactly (or even nearly?). But when I have compiled in the 
> DMA interface in the past, the keyboard is unresponsive. Possibly releated?

CONFIG_SH_DMA is unset ... any other ideas?

	Robert Love

Re: [linuxdc-dev]keyboard key press problem

[Adrian M. <ad...@mc...>]

On Wednesday 05 Dec 2001 11:06 pm, Robert Love wrote:
> I recently upgraded my Dreamcast's kernel from 2.4.14-pre to 2.4.16 (the
> previous and the current linux cvs module at sourceforge).
>
> 2.4.14-pre worked fine.  2.4.16 boots fine.  However, the keyboard is
> spastic, for lack of a better word.
>
> Pressing a single key causes it to repeat ad infinitum until I press a
> different key, in which case it then repeats.  Certain odd key
> combinations cause it to stop.  Enter works the first time I press it
> but not subsequent times.  Eventually I can't type anything at all.
>
> Obviously I can't even log in because I get something like
> rrrrrrrrrrooooooooooooooootttttttttttttt etc.
>
> I've tried to look through what changed from one kernel to the next,
> with no luck.  I have spent a bit of time hacking this out and can not
> find the problem.  Anyone experience or hear of this?  Anyone
> successfully running 2.4.16 or later on their Dreamcast?
>
> 	Robert Love
>
Not this problem exactly (or even nearly?). But when I have compiled in the 
DMA interface in the past, the keyboard is unresponsive. Possibly releated?

[linuxdc-dev]keyboard key press problem

[Robert L. <rm...@te...>]

I recently upgraded my Dreamcast's kernel from 2.4.14-pre to 2.4.16 (the
previous and the current linux cvs module at sourceforge).

2.4.14-pre worked fine.  2.4.16 boots fine.  However, the keyboard is
spastic, for lack of a better word.

Pressing a single key causes it to repeat ad infinitum until I press a
different key, in which case it then repeats.  Certain odd key
combinations cause it to stop.  Enter works the first time I press it
but not subsequent times.  Eventually I can't type anything at all.

Obviously I can't even log in because I get something like
rrrrrrrrrrooooooooooooooootttttttttttttt etc.

I've tried to look through what changed from one kernel to the next,
with no luck.  I have spent a bit of time hacking this out and can not
find the problem.  Anyone experience or hear of this?  Anyone
successfully running 2.4.16 or later on their Dreamcast?

	Robert Love

Re: [linuxdc-dev]Dreamcast sound and kernel memory

[Adrian M. <ad...@mc...>]

On Sunday 02 Dec 2001 11:49 pm, Adrian McMenamin wrote:
> Various fixes I have made still don't produce any sound.


I think I am finally going to admit defeat and write some ARM code. The 
hacked version of the assembler I used doesn't work - presumably because it 
simply locks the ARM in an endless loop.

The issue seems to be what the ARM processor is doing rather than any 
difficulty of writing to the ARM registers - if its stuck in an endless loop 
with interrupts off then I don't suppose it matters what values you poke its 
registers with :->

I can see how Dan Potter manges his IPC on the simple stuff and I'll simply 
copy that (or rather produce something similar to fit in with the OSS 
interface). It should produce a working driver of sorts in a day ot two.

It's not elegant - DP's code simply polls for any new commands, but as the 
ARM is not important in terms of executing anything in either user or kernel 
space, we can afford to be I think.

Assuming nobody leaps up to tell me I've got this all wrong I will start work 
tomorrow.

Will let you know how it goes.


Adrian

[linuxdc-dev]Re: [linuxsh-dev] [PATCH] gdrom compile fix

[Jeremy S. <js...@mv...>]

Robert Love wrote:

> Two problems prevent gdrom from compiling under kernel 2.4.16 (cvs
> module "linux" was recently updated to 2.4.16):
>
> - cdrom_fops global struct was removed in favor or per-driver structs
> declaring their block device functions. this patch adds a proper
> gdrom_bdops structure and uses it.
>
> - cdrom.c includes asm/segment.h.  arch-sh does not have the header.
> this patch adds a simple segment.h with no defines.  this is standard
> practice since segment.h is deprecated (see arch-ia64, for instance).
>
> Without this patch neither cdrom support in general or the gdrom driver
> in specific will compile on later kernels.  Can someone merge it into
> CVS?

Done for the linux-2_4-branch, will do head later.

[linuxdc-dev][PATCH] gdrom compile fix

[Robert L. <rm...@te...>]

Two problems prevent gdrom from compiling under kernel 2.4.16 (cvs
module "linux" was recently updated to 2.4.16):

- cdrom_fops global struct was removed in favor or per-driver structs
declaring their block device functions. this patch adds a proper
gdrom_bdops structure and uses it.

- cdrom.c includes asm/segment.h.  arch-sh does not have the header. 
this patch adds a simple segment.h with no defines.  this is standard
practice since segment.h is deprecated (see arch-ia64, for instance).

Without this patch neither cdrom support in general or the gdrom driver
in specific will compile on later kernels.  Can someone merge it into
CVS?

Thanks,

	Robert Love

Re: [linuxdc-dev][PATCH] Preemptible Kernel for SH (and thus dreamcast)

[Robert L. <rm...@te...>]

On Sun, 2001-12-02 at 21:32, Jason Keirstead wrote:

> I have the pre-empt patch installe don my base machine here, and have never 
> really noticed much of a difference in response time. Would this make more of 
> an effect in the dreamcast for some reason?

What results are perceived would depend on the work load.

That said, the slower the clock of the system the longer the resulting
latency from executing a given kernel operation.  Thus, a preemptible
kernel on the dreamcast can offer significant advantages.

I would wager you would see a nice benefit in interactive performance
under load on the dreamcast; but then again, I would think you would see
that on your normal machine, too.

	Robert Love

Re: [linuxdc-dev][PATCH] Preemptible Kernel for SH (and thus dreamcast)

[Jason K. <ja...@ke...>]

I have the pre-empt patch installe don my base machine here, and have never 
really noticed much of a difference in response time. Would this make more of 
an effect in the dreamcast for some reason?

On December 2, 2001 9:53 pm, Robert Love wrote:
> I also want to mention that we have a version of the preemptible kernel
> for the SH arch now, and it seems to run lovely on the Dreamcast.
>
> It is available at:
> 	http://www.kernel.org/pub/linux/kernel/people/rml/sh/preempt-kernel-sh-2.4
>.16-1.patch
>
> You will also need the base preempt-kernel patch at:
> 	http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/pree
>mpt-kernel-rml-2.4.16-1.patch
>
> And a recent SH tree. The "linux" module in CVS at
> http://sf.net/projects/linuxsh was recently updated to 2.4.16.
> Alternatively, here is a patch to bring 2.4.16 in sync with the SH tree:
> 	http://www.kernel.org/pub/linux/kernel/people/rml/sh/sh-update-rml-2.4.16-
>1.patch
>
> There is a bit of information about the preemptible kernel at
> http://tech9.net/rml/linux as well as LWN, slashdot, etc.  Basically,
> the current linux kernel does not allow processes to be preempted when
> operating inside the kernel.  I.e., kernel calls run until completion --
> this implies that even if task A needs to run, if task B is running and
> in the kernel, task A won't be scheduled until task A is done.  The
> degradation this causes to latency and system response is clear.
> Further, however, since with the preempt-kernel patch I/O-bound tasks
> are scheduled as-soon-as I/O is available, throughput tends to increase,
> too.  We are aiming at inclusion in 2.5.
>
> Its pretty neat.  If nothing else, tell your friends you have a fully
> preemptible Dreamcast.  Or something.
>
> Comments and feedback is welcome,
>
> 	Robert Love
>
>
> _______________________________________________
> Linuxdc-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxdc-dev

[linuxdc-dev][PATCH] Preemptible Kernel for SH (and thus dreamcast)

[Robert L. <rm...@te...>]

I also want to mention that we have a version of the preemptible kernel
for the SH arch now, and it seems to run lovely on the Dreamcast.

It is available at:
	http://www.kernel.org/pub/linux/kernel/people/rml/sh/preempt-kernel-sh-2.4.16-1.patch

You will also need the base preempt-kernel patch at:
	http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.16-1.patch

And a recent SH tree. The "linux" module in CVS at
http://sf.net/projects/linuxsh was recently updated to 2.4.16. 
Alternatively, here is a patch to bring 2.4.16 in sync with the SH tree:
	http://www.kernel.org/pub/linux/kernel/people/rml/sh/sh-update-rml-2.4.16-1.patch

There is a bit of information about the preemptible kernel at
http://tech9.net/rml/linux as well as LWN, slashdot, etc.  Basically,
the current linux kernel does not allow processes to be preempted when
operating inside the kernel.  I.e., kernel calls run until completion --
this implies that even if task A needs to run, if task B is running and
in the kernel, task A won't be scheduled until task A is done.  The
degradation this causes to latency and system response is clear. 
Further, however, since with the preempt-kernel patch I/O-bound tasks
are scheduled as-soon-as I/O is available, throughput tends to increase,
too.  We are aiming at inclusion in 2.5.

Its pretty neat.  If nothing else, tell your friends you have a fully
preemptible Dreamcast.  Or something.

Comments and feedback is welcome,

	Robert Love

[linuxdc-dev]Using your gdrom as the root device and no initrd

[Robert L. <rm...@te...>]

It seems the prevailing method of booting and using Linux on the
dreamcast involves loading the kernel image and an initrd off a CD-R (or
network), loading the kernel, and booting into an initrd.  The initrd
never returns -- instead it typically populates the ram disk with a
minimal filesystem and then mounts the gdrom elsewhere.  Symlinks or
other hackery link everything together.

I think this approach is nonsense.  A far better idea would be to boot
into the kernel with your root device being your GD-ROM (ie
root=/dev/gdrom on the command line) and use tmpfs for writable storage.

It's pretty easy:
Apply the attached patch to your kernel tree.  The patch adds the gdrom
to the root_dev_names array so it can be a root device.  Enable
CONFIG_TMPFS and disable all the initrd/ramdisk/loopback/ext2 cruft. 
Recompile.

Have your CD filesystem setup however you would want it, this may mean
merging it with your previous initrd filesystem.

Upon boot, have an early SysV init script mount /var as tmpfs.  Easiest
would be to do `mount -a' with this in your /etc/fstab:

tmpfs		/var	tmpfs	defaults,size=4m 0 0

You can then populate it via script.  An easy way would be to `cp -r
/etc/var /var' although I've found I just need to create 4 or 5
directories in there -- no specific files need to be there.

As for things in /etc that need to be writable, that is a design flaw
but oh well.  You can symlink /etc/mtab to /proc/mount.  The only other
thing I've come across that _has_ to be writable is /etc/resolv.conf so
your DHCP client can place your nameserver there.  In that case, just
symlink it into /var.

And that is it.  You will get a smaller and faster kernel and the beauty
of tmpfs (its fast, small, lives in the page cache, is dynamic, and does
limit checking).

If you are using boot-kernel or something else that wants an initrd.gz
to load, you can just have it load an empty file (or anything).  The
kernel won't notice it and the memory will be used for something else. 
I am working on a boot loader that doesn't load initrd.

Just thought I'd share...it seams a more ideal way.

	Robert Love

Re: [linuxdc-dev]Dreamcast sound and kernel memory

[Adrian M. <ad...@mc...>]

Various fixes I have made still don't produce any sound. 

I think we can be sure that it is possible to set the register values in SH4 
land - but the key issue seems to be finding some code for the ARM to run.

To tell the truth I had been working on the assumption that the ARM had some 
sort of firmware code that allowed it to do different things - but I know 
that is now not true.

I made this assumption because Dan Potter's code doesn't appear to do 
anything but poke the registers.

But KOS also appears to have a little bit of ARM7 assembler - crt0.s

My knowledge of ARM 7 assembler is zero - but this code seems to me to be the 
bit that resides at ARM address 0


It compiles to a 1.1k bit of code.

What do people think? Is this the holy grail (suitably modified, of course).



# Adapted from Marcus' AICA example among a few other sources =)

.text
.globl	arm_main
.globl	timer
.globl	jps

# Exception vectors
	b	start
	b	undef
	b	softint
	b	pref_abort
	b	data_abort
	b	rsrvd
	b	irq


# FIQ code adapted from the Marcus AICA example
fiq:
	# Save regs
	#stmdb	sp!, {r0-r14}

	# Grab interrupt type (store as parameter)
	ldr	r8,intreq
	ldr	r9,[r8]
	and	r9,r9,#7
	cmp	r9,#2
	bne	fiq_done

	# Type 2 is timer interrupt. Increment timer variable.
	adr	r8,timer
	ldr	r9,[r8]
	add	r9,r9,#1
	str	r9,[r8]

	# Request a new timer interrupt. We'll calculate the number
	# put in here based on the "jps" (jiffies per second).
	ldr	r8, timer_control
	mov	r9,#256-(44100/4410)
#	ldr	r9,jps
	str	r9,[r8,#0x10]
	mov	r9,#0x40
	str	r9,[r8,#0x24]
	b	fiq_done

	# Return from interrupt
fiq_done:

	# Clear interrupt
	ldr	r8,intclr
	mov	r9,#1
	str	r9,[r8]
	str	r9,[r8]
	str	r9,[r8]
	str	r9,[r8]

	# Restore regs and return
	#ldmdb	sp!, {r0-r14}
	subs	pc,r14,#4

intreq:
	.long	0x00802d00
intclr:
	.long	0x00802d04
timer_control:
	.long	0x00802880
timer:
	.long	0
jps:
	.long	256-(44100/1000)


start:
	# Setup a basic stack, disable IRQ, enable FIQ
	mov	sp,#0xb000
	mrs	r10,CPSR
	orr	r10,r10,#0x80
	bic	r10,r10,#0x40
	msr	CPSR_all,r10

	# Call the main for the SPU
	bl	arm_main

	# Loop infinitely if we get here
here:	b	here


# Handlers we don't bother to catch
undef:
softint:
	mov	pc,r14
pref_abort:
data_abort:
irq:
rsrvd:
	sub	pc,r14,#4

Re: [linuxdc-dev]Dreamcast sound and kernel memory

[M. R. B. <mr...@0x...>]

* Paul Mundt <pm...@mv...> on Sun, Dec 02, 2001:

>=20
> If the FIFO is slow in dealing with, there's likely a good reason for it..
> doing DMA directly without any kind of flow control might also cause you =
to
> kill the AICA.
>=20

I have to see how Dan Potter does AICA DMA in KOS and review the notes from
my reverse-engineering sessions.  I think it operates like any other DMA on
the DC's G2 bus .. let's hope so.

Whoops!  Just grabbed kos from CVS and yeah, it uses bitmaster's original
AICA DMA example, so it's normal G2 DMA, nothing special.

> The other thing to consider (as I've told you on IRC), the AICA is likely=
 not
> too responsive.. and expecting it to be will likely end up shooting you i=
n the
> foot. Perhaps something more along the lines of waiting for a brief durat=
ion
> of time after a read (mdelay(5) perhaps?), and doing the reads with inter=
rupts
> disabled might prove to yield more consistent data without the need to do=
 a
> nasty read-twice and compare hack.
>=20

Yeah, I think the tests that people have done on the AICA haven't been that
intensive ... if something broke that passed it off as broken instead of
exploring work arounds.  A couple of us need to sit down and really plug
the fscker :P.

M. R.

Re: [linuxdc-dev]Dreamcast sound and kernel memory

[Paul M. <pm...@mv...>]

On Sun, Dec 02, 2001 at 01:05:23PM -0600, M. R. Brown wrote:
> Damn, I need time :P.  Check out the latest KOS which (apparently) has AI=
CA
> DMA working.  You want to use DMA.  You have to use DMA.  It's DMA or die
> ... ok maybe that's too much.  But that's the only way you'll effectively
> get anything to AICA RAM without choking on the FIFO.
>=20
Er, side stepping the FIFO through DMA doesn't sound like that good of a
solution either. DMA is definately the optimal way to go for AICA access, b=
ut
it might still prove to be useful to have a non-DMA fallback that waits on =
the
FIFO for its reads (especially for debugging when things go horribly wrong).

If the FIFO is slow in dealing with, there's likely a good reason for it..
doing DMA directly without any kind of flow control might also cause you to
kill the AICA.

[snip]
> void aica_rtc_gettimeofday(struct timeval *tv) {
> 	unsigned long val1, val2;
>=20
> 	do {
> 		val1 =3D ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
> 			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
> 		val2 =3D ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
> 			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
> 	} while (val1 !=3D val2);
[snip]
> }
>=20
The other thing to consider (as I've told you on IRC), the AICA is likely n=
ot
too responsive.. and expecting it to be will likely end up shooting you in =
the
foot. Perhaps something more along the lines of waiting for a brief duration
of time after a read (mdelay(5) perhaps?), and doing the reads with interru=
pts
disabled might prove to yield more consistent data without the need to do a
nasty read-twice and compare hack.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [linuxdc-dev]Dreamcast sound and kernel memory

[Adrian M. <ad...@mc...>]

On Sunday 02 Dec 2001 7:05 pm, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Sun, Dec 02, 2001:
> > Now, is it right to just copy a lump of memory over from user space in
> > this way?
>
> Well even if it was ok (I don't know) semantically, you can't do it
> realistically for the AICA.  Remember the discussion on dcdev?  You can
> only copy so much data to AICA RAM at once - if you don't wait for the FIFO
> to be clear then you'll crash the AICA.
>

That may be the problem - as the memory allocation now apears to work (at 
least a read of the memory returns that it contains the same data that was 
written).


> > I haven't specifically allocated a buffer inside the sound RAM area -
> > just claimed it for the kernel when initiating the module and assumed
> > that it's there - the function doesn't fail in the sense that the -EFAULT
> > error is never reported, but does that mean it has actually worked?
> >
> > Should I be allocating a buffer first and copying the data from user
> > space into that?
>
> Damn, I need time :P.  Check out the latest KOS which (apparently) has AICA
> DMA working.  You want to use DMA.  You have to use DMA.  It's DMA or die
> ... ok maybe that's too much.  But that's the only way you'll effectively
> get anything to AICA RAM without choking on the FIFO.
>

I'd have to write my own DMA routines (I think) as the kernel supported ones 
crash the SH4 kernel or rather cause input to freeze up - far too big a job 
for me.


> I still have to sit down and write the register test to see if it's
> feasible to play with the AICA regs directly from the SH4.  Or you could
>
> :P.
> :
> > Perhaps I am just clutching at straws.
>
> What you need is a AICA test program.  It doesn't even have to be kernel
> related, and you can provide your own inX() outX() routines that treat the
> AICA registers as latches and checks *every* value you get back from the
> AICA.  I still believe you can play with AICA registers from the SH4, take
> a look at this:
>
> From arch/sh/kernel/rtc-aica.c:
>
> /* The AICA RTC is represented by a 32-bit seconds counter stored in 2
>  * 16-bit registers.*/
> #define AICA_RTC_SECS_H         0xa0710000
> #define AICA_RTC_SECS_L         0xa0710004
>
> /**
>  * aica_rtc_gettimeofday - Get the time from the AICA RTC
>  * @tv: pointer to resulting timeval
>  *
>  * Grabs the current RTC seconds counter and adjusts it to the Unix
>  * Epoch.
>  */
> void aica_rtc_gettimeofday(struct timeval *tv) {
> 	unsigned long val1, val2;
>
> 	do {
> 		val1 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
> 			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
> 		val2 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
> 			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
> 	} while (val1 != val2);
>
> 	tv->tv_sec = val1 - TWENTY_YEARS;
>
> 	/* Can't get microseconds with just a seconds counter. */
> 	tv->tv_usec = 0;
> }
>
>
> Now, you see how I'm grabbing those registers?

Yes, okay  but I am not exactly sure what the point you are making is. Simple 
test routines I've put in the SH4 code today show that the registers report 
that their contents after writing agree with the value that is meant to be 
written to them.

  In your test program (or
> your kernel driver), write a generic routine that does just that.  You may
> end up with valid values after all.
>
> The aica_rtc_settimeofday() is basically the same, except at the top of the
> while loop, there are ctrl_outl() statements that write the register value.
> You could even throw the FIFO check in there just to be on the safe side.
>
I need to know more about the FIFO I thin - is it in the CPU manual?


> Let's prove those dcdev'rs wrong :P.  Let me know what you come up with,
> and I'll try to work on something later.
>
> Hope this helps,
>
> M. R.

Re: [linuxdc-dev]Dreamcast sound and kernel memory

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Sun, Dec 02, 2001:

>=20
> Now, is it right to just copy a lump of memory over from user space in th=
is=20
> way?
>=20

Well even if it was ok (I don't know) semantically, you can't do it
realistically for the AICA.  Remember the discussion on dcdev?  You can
only copy so much data to AICA RAM at once - if you don't wait for the FIFO
to be clear then you'll crash the AICA.

> I haven't specifically allocated a buffer inside the sound RAM area - jus=
t=20
> claimed it for the kernel when initiating the module and assumed that it'=
s=20
> there - the function doesn't fail in the sense that the -EFAULT error is=
=20
> never reported, but does that mean it has actually worked?
>=20
> Should I be allocating a buffer first and copying the data from user spac=
e=20
> into that?
>=20

Damn, I need time :P.  Check out the latest KOS which (apparently) has AICA
DMA working.  You want to use DMA.  You have to use DMA.  It's DMA or die
=2E.. ok maybe that's too much.  But that's the only way you'll effectively
get anything to AICA RAM without choking on the FIFO.

I still have to sit down and write the register test to see if it's
feasible to play with the AICA regs directly from the SH4.  Or you could
:P.

> Perhaps I am just clutching at straws.
>=20

What you need is a AICA test program.  It doesn't even have to be kernel
related, and you can provide your own inX() outX() routines that treat the
AICA registers as latches and checks *every* value you get back from the
AICA.  I still believe you can play with AICA registers from the SH4, take
a look at this:

=46rom arch/sh/kernel/rtc-aica.c:

/* The AICA RTC is represented by a 32-bit seconds counter stored in 2
 * 16-bit registers.*/
#define AICA_RTC_SECS_H         0xa0710000
#define AICA_RTC_SECS_L         0xa0710004

/**
 * aica_rtc_gettimeofday - Get the time from the AICA RTC
 * @tv: pointer to resulting timeval
 *
 * Grabs the current RTC seconds counter and adjusts it to the Unix
 * Epoch.
 */
void aica_rtc_gettimeofday(struct timeval *tv) {
	unsigned long val1, val2;

	do {
		val1 =3D ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
		val2 =3D ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
	} while (val1 !=3D val2);

	tv->tv_sec =3D val1 - TWENTY_YEARS;

	/* Can't get microseconds with just a seconds counter. */
	tv->tv_usec =3D 0;
}


Now, you see how I'm grabbing those registers?  In your test program (or
your kernel driver), write a generic routine that does just that.  You may
end up with valid values after all.

The aica_rtc_settimeofday() is basically the same, except at the top of the
while loop, there are ctrl_outl() statements that write the register value.
You could even throw the FIFO check in there just to be on the safe side.

Let's prove those dcdev'rs wrong :P.  Let me know what you come up with,
and I'll try to work on something later.

Hope this helps,

M. R.

Re: [linuxdc-dev]Dreamcast sound and kernel memory

[Adrian M. <ad...@mc...>]

On Sunday 02 Dec 2001 4:18 pm, Adrian McMenamin wrote:
> Well, maybe I should be writing ARM code after all - but I'm still going to
> give the SH4 stuff one more try and I have a question which I wonder if
> someone might help me with.
>
> In the dsp write the code currently does this...
>
> static ssize_t aica_audio_do_write(struct file *file,
> 				   const char *buffer,
> 				   size_t count,
> 				   loff_t *ppos)
> {
>
>   aica_dev_t *devc=file->private_data;
>
>   //really want to write?
>   if (!(file->f_mode & FMODE_WRITE)) return -EINVAL;
>
>
>   //now output this to the selected channel
>
>   //fill a chunk of the sound memory with the contents of the buffer
>   aica_halt_channel(devc->channel); //halt anything playing there already
>   int offset = 0xf000;
>   if (copy_from_user((void*)(0xa0800000 + offset), (const void*) buffer,
> count))
>     {
>       DEBGM("Failed to copy memory bufferfrom user space\n");
>       return -EFAULT;
>     }
>
> .
> .
> .
> .
> ...........Lots of code..........
> .
>
>
>   return count;
>
> }
>
> Now, is it right to just copy a lump of memory over from user space in this
> way?
>
> I haven't specifically allocated a buffer inside the sound RAM area - just
> claimed it for the kernel when initiating the module and assumed that it's
> there - the function doesn't fail in the sense that the -EFAULT error is
> never reported, but does that mean it has actually worked?
>
> Should I be allocating a buffer first and copying the data from user space
> into that?
>
> Perhaps I am just clutching at straws.
>


My own tests suggest this to be the case :-<

[linuxdc-dev]Dreamcast sound and kernel memory

[Adrian M. <ad...@mc...>]

Well, maybe I should be writing ARM code after all - but I'm still going to 
give the SH4 stuff one more try and I have a question which I wonder if 
someone might help me with.

In the dsp write the code currently does this...

static ssize_t aica_audio_do_write(struct file *file,
				   const char *buffer,
				   size_t count,
				   loff_t *ppos)
{
  
  aica_dev_t *devc=file->private_data;

  //really want to write?
  if (!(file->f_mode & FMODE_WRITE)) return -EINVAL;
  

  //now output this to the selected channel

  //fill a chunk of the sound memory with the contents of the buffer
  aica_halt_channel(devc->channel); //halt anything playing there already
  int offset = 0xf000;
  if (copy_from_user((void*)(0xa0800000 + offset), (const void*) buffer, 
count))
    {
      DEBGM("Failed to copy memory bufferfrom user space\n");
      return -EFAULT;
    }

.
.
.
.
...........Lots of code..........
.

   
  return count;

}

Now, is it right to just copy a lump of memory over from user space in this 
way?

I haven't specifically allocated a buffer inside the sound RAM area - just 
claimed it for the kernel when initiating the module and assumed that it's 
there - the function doesn't fail in the sense that the -EFAULT error is 
never reported, but does that mean it has actually worked?

Should I be allocating a buffer first and copying the data from user space 
into that?

Perhaps I am just clutching at straws.

Re: [linuxdc-dev]Re: [linuxsh-dev] Toolset

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Fri, Nov 30, 2001:

>=20
> > * Michael Grig <mg...@ho...> on Fri, Nov 30, 2001:
> > > Hi,
> > >
> > > Thanks for your quick response to my last message. Indeed upgrading to
> > > 3.0.2 with the lastest patch solved my problem.
>=20
>=20
> If there are new set of, patched, tools, is it worth trying to build QtE =
or=20
> QPE or Konq/E again?
>=20

Not likely, those are the ones I've been using.  It would take dedicated SH
hackers to fix some of the messes (thanks to kaz and NIIBE for their
efforts thus far) in binutils and GCC.

M. R.

Re: [linuxdc-dev]Re: [linuxsh-dev] Toolset

[Adrian M. <ad...@mc...>]

> * Michael Grig <mg...@ho...> on Fri, Nov 30, 2001:
> > Hi,
> >
> > Thanks for your quick response to my last message. Indeed upgrading to
> > 3.0.2 with the lastest patch solved my problem.


If there are new set of, patched, tools, is it worth trying to build QtE or 
QPE or Konq/E again?


Adrian

[linuxdc-dev]Re: [linuxsh-dev] Logging in from a serial console

[M. R. B. <mr...@0x...>]

* Michael Grig <mg...@ho...> on Fri, Nov 30, 2001:

> Hi,
>=20
> Thanks for your quick response to my last message. Indeed upgrading to
> 3.0.2 with the lastest patch solved my problem.
> On a related note, why are you guys using the 3.0 series anyway?
> Wouldn't it be better to stick with something stable, like 2.95.3,
> instead of having to continuously track a moving target?
>=20

The SH backend in GCC 2.95.x isn't stable enough.  Check the linux-sh and
linuxsh-dev mailing list archives for more info.

> Anyway, I decided to give the debian dc distro a try. Unfortunatly, as
> I still lack a DC keyboard, I have to log in from the serial terminal.
> (which should be possible according to the distro README).
>=20
> First I tried connecting (using minicom) to an already running system,
> but as that did not work, I devised a new strategy: I connect to the
> bootloader during the boot, interupt it, and issue:
> mount
> load -v /boot/vmlinux
> load -v -r -b 0x8c400000 /boot/initrd.gz
> exec -c "mem=3D16M init=3D/busybox console=3DttySC1,115200 /etc/profile"
>=20
> and it happily redirects all boot messages to the serial console,
> however when it gets to the login, it still issues it on the tty0
> and not on the serial console!!
>=20
> What am I missing here?
>=20

Hit return in minicom and you should see a login prompt.  This will work
even if the system has already booted.  You can see how this works in
/etc/inittab.

M. R.

Re: [linuxdc-dev]Fwd: Re: networking dreamcasts

[Adrian M. <ad...@mc...>]

On Friday 30 Nov 2001 2:24 pm, Park, Christopher wrote:
> Is there any way for us in the states to order one (or two?)  $70US still
> beats what they are going for on ebay.
>

Lik Sang have announced today they have more stock.