linuxdc-dev — Developer discussion list

Re: [linuxdc-dev] aica driver speedup

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

ale...@at... wrote:
> ad...@mc... wrote:
> > 
> > I'm a bit puzzled, as I have played high sample rate and bit rate MP3s without seeing any real impact on system time etc. But I haven't been using very sophisticated tools to measure it (just looking at 'uptime' really).
> > 
> > But I've certainly been able to run this in the background without any noticeable impact on foreground applications.
> > 
> > Tell me more about your setup - what player are you using and what tool to measure system time etc.
> > 
> > In the meantime I'll remind myself what myy code looks like. Can you post a patch?
> > 
> > Adrian
> > 
> > 
>     I'm using mpg123 to play the mp3 and top to see what the system is up
> to.  I also noticed that previously I was not able to run "bb" w/o it
> dogging as soon as the audio started up.  With the changes it plays
> pretty smooth (maybe one audio skip).  I posted a patch with my original
> mail.  That was against r1.5 that's currently in CVS.  Looks like it got
> truncated in the archive... don't know if that's normal.  I'll try
> again.
> 	Alex


Apologies. I'm using an online mail reader, so missed the patch. Are you using the m17n disto then? Could you email me a copy of top?

What is bb? Is that a media demo app?
> 
> 

Re: [linuxdc-dev] aica driver speedup

[Alex W. <ale...@at...>]

ad...@mc... wrote:
> 
> I'm a bit puzzled, as I have played high sample rate and bit rate MP3s without seeing any real impact on system time etc. But I haven't been using very sophisticated tools to measure it (just looking at 'uptime' really).
> 
> But I've certainly been able to run this in the background without any noticeable impact on foreground applications.
> 
> Tell me more about your setup - what player are you using and what tool to measure system time etc.
> 
> In the meantime I'll remind myself what myy code looks like. Can you post a patch?
> 
> Adrian
> 
> 

    I'm using mpg123 to play the mp3 and top to see what the system is up
to.  I also noticed that previously I was not able to run "bb" w/o it
dogging as soon as the audio started up.  With the changes it plays
pretty smooth (maybe one audio skip).  I posted a patch with my original
mail.  That was against r1.5 that's currently in CVS.  Looks like it got
truncated in the archive... don't know if that's normal.  I'll try
again.

	Alex

Re: [linuxdc-dev] aica driver speedup

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

ale...@at... wrote:
> 
>     I was a little perturbed by how much system time was being consumed
> when playing mp3s on the dc, so I went looking around.  The main problem
> seems to be the busy wait in aica_audio_tidy_buffers() for "high freq"
> audio.  I changed the 23000 Hz to 48000, and the dc seems to keep up
> just fine.  For me this made playing a 44100 Hz mp3 go from ~85% system
> time to <5%.  While I was in there I did some other cleanups and rewrote
> the buffer allocation scheme.  I haven't done much more than play mp3s,
> so use at your own risk.  Let me know what you think.  I'm not on the
> mailing list, so please keep me in the CC.  Thanks,
> 	Alex
> 

I'm a bit puzzled, as I have played high sample rate and bit rate MP3s without seeing any real impact on system time etc. But I haven't been using very sophisticated tools to measure it (just looking at 'uptime' really).

But I've certainly been able to run this in the background without any noticeable impact on foreground applications.

Tell me more about your setup - what player are you using and what tool to measure system time etc.

In the meantime I'll remind myself what myy code looks like. Can you post a patch?

Adrian

Re: [linuxdc-dev] aica driver speedup

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

ale...@at... wrote:
> 
>     I was a little perturbed by how much system time was being consumed
> when playing mp3s on the dc, so I went looking around.  The main problem
> seems to be the busy wait in aica_audio_tidy_buffers() for "high freq"
> audio.  I changed the 23000 Hz to 48000, and the dc seems to keep up
> just fine.  For me this made playing a 44100 Hz mp3 go from ~85% system
> time to <5%.  While I was in there I did some other cleanups and rewrote
> the buffer allocation scheme.  I haven't done much more than play mp3s,
> so use at your own risk.  Let me know what you think.  I'm not on the
> mailing list, so please keep me in the CC.  Thanks,
> 	Alex
> 

I'm a bit puzzled, as I have played high sample rate and bit rate MP3s without seeing any real impact on system time etc. But I haven't been using very sophisticated tools to measure it (just looking at 'uptime' really).

But I've certainly been able to run this in the background without any noticeable impact on foreground applications.

Tell me more about your setup - what player are you using and what tool to measure system time etc.

In the meantime I'll remind myself what myy code looks like. Can you post a patch?

Adrian

[linuxdc-dev] aica driver speedup

[Alex W. <ale...@at...>]

    I was a little perturbed by how much system time was being consumed
when playing mp3s on the dc, so I went looking around.  The main problem
seems to be the busy wait in aica_audio_tidy_buffers() for "high freq"
audio.  I changed the 23000 Hz to 48000, and the dc seems to keep up
just fine.  For me this made playing a 44100 Hz mp3 go from ~85% system
time to <5%.  While I was in there I did some other cleanups and rewrote
the buffer allocation scheme.  I haven't done much more than play mp3s,
so use at your own risk.  Let me know what you think.  I'm not on the
mailing list, so please keep me in the CC.  Thanks,

	Alex

Re: [linuxdc-dev] Web page status ?

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

On Monday 02 Sep 2002 4:04 am, ePAc wrote:
> I have been a couple of time to the linuxdc.sf.net, and it has a nice page
> mentioning that it is being worked on..
>
> What would be the status of that page these days ?
> anyone is maintaining this ?
>
> I'd love to check some of the old "messages" from the old page, anyone got
> that around ?
>
> Thanks,
> Jok
> (finally with a BBA, and ready to show my dreamcast how to run ssh :o)
>

All the old stuff from the site of any interest is in the CVS: 
http://sourceforge.net/projects/linuxdc and follow the links.

[linuxdc-dev] Web page status ?

[ePAc <ep...@ko...>]

I have been a couple of time to the linuxdc.sf.net, and it has a nice page
mentioning that it is being worked on..

What would be the status of that page these days ?
anyone is maintaining this ?

I'd love to check some of the old "messages" from the old page, anyone got
that around ?

Thanks,
Jok
(finally with a BBA, and ready to show my dreamcast how to run ssh :o)



---
Nothing is foolproof to a sufficiently talented fool...
  oo
,(..)\
  ~~

[linuxdc-dev] VMU Flash driver

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

There is now a working/available for testing VMU driver in the linuxdc CVS. It 
supports reads and writes. (see /drivers/mtd/maps in the CVS).

To test it I suggest you compile the kernel with the char and ccahed block mtd 
devices.

Reads are cached and so are fast. Writes are very slow at present - as a full 
512 byte read is done for every byte written. I will fix that in due course.

The driver also outputs a lot of status messages at the moment - I would 
particularly welcome anybody with strange flash devices (the camera? Come on, 
somebody's got to have it!) and odd sizes telling me if they get anything 
different from devices with 1 partition, a write count of 4, a read count of 
1 and a block size of 512 bytes.

Please let me know of any problems you have asap. Otherwise, remember when you 
are writing that it is very easy to simply trash the existing data on your 
VMU. I have no idea if the DC will then fix that.

You use this under the terms of the GPL and that means no warranty! You have 
been warned.

Adrian

Re: [linuxdc-dev] Re: [linuxdc-cvs] CVS: linux-sh-dc/drivers/mtd/maps vmu-flash.c,1.6,1.7

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

On Saturday 31 Aug 2002 11:30 pm, M. R. Brown wrote:
> * Adrian McMenamin <zx8...@us...> on Sat, Aug 31, 2002:
> > Update of /cvsroot/linuxdc/linux-sh-dc/drivers/mtd/maps
> > In directory usw-pr-cvs1:/tmp/cvs-serv23778/drivers/mtd/maps
> >
> > Modified Files:
> > 	vmu-flash.c
> > Log Message:
> > VMU reads now verified as working
>
> You may want to consider wrapping all those printk's in a CONFIG_VMU_DEBUG
> or some other kind of option.  Unecessary printk's (esp. just status ones)
> are hazardous to your health.  printk() is an expensive operation, esp. in
> low-level drivers (ask Paul what he'd like to do to those who put printk's
> in net driver interrupt handlers :P).
>

Point taken. This is still  a work in progress and those messages are as much 
about debugging the code - and the devices - as anything else (he says hoping 
people with a few bizarre flash devices - anybody got one of those cameras? - 
have a go).

Everybody assumes all flash chips on the DC are the same (1 partition, 256 
blocks of 512 bytes) but there is no reason for them to be.

I think I'll removing them in 'production' code.


> M. R.

[linuxdc-dev] Re: [linuxdc-cvs] CVS: linux-sh-dc/drivers/mtd/maps vmu-flash.c,1.6,1.7

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

* Adrian McMenamin <zx8...@us...> on Sat, Aug 31, 2002:

> Update of /cvsroot/linuxdc/linux-sh-dc/drivers/mtd/maps
> In directory usw-pr-cvs1:/tmp/cvs-serv23778/drivers/mtd/maps
>=20
> Modified Files:
> 	vmu-flash.c=20
> Log Message:
> VMU reads now verified as working
>=20

You may want to consider wrapping all those printk's in a CONFIG_VMU_DEBUG
or some other kind of option.  Unecessary printk's (esp. just status ones)
are hazardous to your health.  printk() is an expensive operation, esp. in
low-level drivers (ask Paul what he'd like to do to those who put printk's
in net driver interrupt handlers :P).

M. R.

Re: [linuxdc-dev] Help! Please.

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

On Monday 26 Aug 2002 8:37 pm, Adrian McMenamin wrote:
> I am having lots of problems rebuilding my kernel source tree.
>
> The CVS in linuxdc says its against 2.4.18 in linux-sh, but AFAICS there is
> no 2.4.18 in linux-sh. Either way I have lots of dead symlinks after
> downloading a "2.4.18" branch from linux-sh.
>
> So what should I be building against and what have I done wrong?
>
Apologies. I think I can see what I was doing wrong now. Sorry.

[linuxdc-dev] Help! Please.

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

I am having lots of problems rebuilding my kernel source tree.

The CVS in linuxdc says its against 2.4.18 in linux-sh, but AFAICS there is no 
2.4.18 in linux-sh. Either way I have lots of dead symlinks after downloading 
a "2.4.18" branch from linux-sh.

So what should I be building against and what have I done wrong?

Adrian

Re: [linuxdc-dev] another round of BBAs?

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

On Monday 26 Aug 2002 6:45 pm, David Willmore wrote:
> Just caught up on reading and I found this:
> http://slashdot.org/article.pl?sid=02/08/25/0132227&mode=thread&tid=127
>
> Seems good.  Can anyone read this and tell us what the details are?
>
> Cheers,
> David
>
I think the central point is that unless you are in Japan or have a very good 
friend there then forget it. They are only shipping these things inside 
Japan.

Adrian

[linuxdc-dev] another round of BBAs?

[David W. <dav...@ia...>]

Just caught up on reading and I found this:
http://slashdot.org/article.pl?sid=02/08/25/0132227&mode=thread&tid=127

Seems good.  Can anyone read this and tell us what the details are?

Cheers,
David

Re: [linuxdc-dev] Cannot get my kernel to compile.

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

On Saturday 24 Aug 2002 11:21 pm, you wrote:
> probably because you compiled in DRI, and the kernel doesn't like that
> for some reason. i don't think there's any DRI for any sh4 devices
> anyway, so just take out the DRI/XFree stuff and try again, i guess.

As I didn't add any such things and as I cannot see any option to remove
 them, I don't think this is the problem. I am not getting very cheesed off
 with this, anybody else got any suggestions?

C'mon folks. I'm the only one (who seems to be) doing any kernel hacking on
the project right now and I'm stuck. Please, please, pretty please, help me!

:->

[linuxdc-dev] Cannot get my kernel to compile.

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

Can someone tell me why I am repeatedly having this problem?

Type....

make ARCH=sh CROSS_COMPILE=sh4-linux- clean dep zImage

get....

......................
......................

make[6]: Entering directory `/home/Adrian/linux/drivers/char/drm'
/home/Adrian/linux/scripts/mkdep -D__KERNEL__ -I/home/Adrian/linux/include 
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer 
-fno-strict-aliasing -fno-common -ml -m4 -mno-implicit-fp -pipe  -- 
ati_pcigart.h drm_agpsupport.h drm_auth.h drm_bufs.h drm_context.h drm_dma.h 
drm_drawable.h drm_drv.h drm_fops.h drm.h drm_init.h drm_ioctl.h drm_lists.h 
drm_lock.h drm_memory.h drmP.h drm_proc.h drm_scatter.h drm_stub.h drm_vm.h 
ffb_context.c ffb_drv.c ffb_drv.h ffb.h gamma_dma.c gamma_drv.c gamma_drv.h 
gamma.h i810_dma.c i810_drm.h i810_drv.c i810_drv.h i810.h mga_dma.c 
mga_drm.h mga_drv.c mga_drv.h mga.h mga_state.c mga_ucode.h mga_warp.c 
pvr2_drv.c pvr2.h r128_cce.c r128_drm.h r128_drv.c r128_drv.h r128.h 
r128_state.c radeon_cp.c radeon_drm.h radeon_drv.c radeon_drv.h radeon.h 
radeon_state.c sis_drm.h sis_drv.c sis_drv.h sis_ds.c sis_ds.h sis.h sis_mm.c 
tdfx_drv.c tdfx.h > .depend
make[6]: Leaving directory `/home/Adrian/linux/drivers/char/drm'
make -C drm-4.0 fastdep
make: Entering an unknown directory
make: *** drm-4.0: No such file or directory.  Stop.
make: Leaving an unknown directory
make[5]: *** [_sfdep_drm-4.0] Error 2
make[5]: Leaving directory `/home/Adrian/linux/drivers/char'
make[4]: *** [fastdep] Error 2
make[4]: Leaving directory `/home/Adrian/linux/drivers/char'
make[3]: *** [_sfdep_char] Error 2
make[3]: Leaving directory `/home/Adrian/linux/drivers'
make[2]: *** [fastdep] Error 2
make[2]: Leaving directory `/home/Adrian/linux/drivers'
make[1]: *** [_sfdep_drivers] Error 2
make[1]: Leaving directory `/home/Adrian/linux'
make: *** [dep-files] Error 2

[linuxdc-dev] New files in CVS

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

For those of you who don't subscribe to the CVS mailing list, this email is to 
inform you that a semi-working vmu-flash (map) driver has been added to the 
CVS, together with a purely experimental microphone driver.

The vmu-flash driver is a map driver - it can only communicate with the system 
through user level drivers (see http://www.linux-mtd.infradead.org for more 
info on what this means).

Adrian

[linuxdc-dev] VMU Driver - latest diff

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

This is getting quite close to working, I hope.


--- vmu-old.c	Fri Aug 16 00:05:22 2002
+++ vmu-flash.c	Wed Aug 21 23:16:18 2002
@@ -2,6 +2,10 @@
  * drivers/mtd/maps/vmu-flash.c
  * 
  * (C)opyright 2001 Paul Mundt <le...@ch...>
+ +
+ +
+ + Messed about with and fragments copyright 2002, Adrian McMenamin 
<ad...@mc...>
+ +
  * 
  * Flash mapping handler for the Sega Dreamcast VMU.
  *
@@ -26,12 +30,111 @@
 /* MTD Information */
 static struct mtd_info *vmu_flash_mtd = NULL;
 
+/* Persistent result */
+static struct mapleq *lastmq;
+static struct maple_driver dc_flashmap_driver;
+char *block_buffer = NULL;
+
+int waken_up = 1;
+
 /* VMU Block */
 typedef struct block_s {
 	unsigned int num;	/* Block Number */
 	unsigned int ofs;	/* Block Offset */
 } block_t;
 
+/*************************************/
+/**********Read and write routines*************/
+int maple_vmu_read_block(unsigned int num, u_char * buf)
+{
+
+	/* async maple call
+	   assemble maple call
+	   wait for return */
+
+
+	/* Sanity check */
+	if (!vmu_flash_mtd) {
+		printk(KERN_WARNING
+		       "VMU FLASH: Attempting to read data without having set up mtd.\n");
+		return -1;
+	}
+
+	struct maple_driver_data *mdd =
+	    (struct maple_driver_data *) (vmu_flash_mtd->priv);
+	struct mapleq *mqu = (struct mapleq *) &(mdd->mq);
+	mqu->command = 11;
+	mqu->length = 2;
+
+	((unsigned long *) (mqu->recvbuf))[0] =
+	    cpu_to_be32(MAPLE_FUNC_MEMCARD);
+
+	((unsigned long *) (mqu->recvbuf))[1] = num;
+	mqu->sendbuf = mqu->recvbuf;
+	if (maple_add_packet(mqu) != 0) {
+		printk(KERN_WARNING "VMU FLASH: Could not add packet\n");
+		return -1;
+	}
+
+	lastmq = NULL;
+	wait_queue_head_t wq_mq;
+	init_waitqueue_head(&wq_mq);
+	do {
+		interruptible_sleep_on_timeout(&wq_mq, 1);
+	} while (lastmq == NULL);
+
+	/* Now check if we've got a proper return */
+
+	if (block_buffer){;
+	   memcpy(block_buffer, buf,  512);
+	   kfree(block_buffer);
+	   block_buffer = NULL;
+	   return 0; 
+	}
+
+	printk(KERN_WARNING "VMU FLASH: Read has failed\n");
+
+	return -1;
+
+}
+
+int maple_vmu_write_block(unsigned int num, u_char * buf)
+{
+
+	/* This function does not have to sleep */
+
+	/* Sanity check */
+	if (!vmu_flash_mtd) {
+		printk(KERN_WARNING
+		       "VMU FLASH: Attempting to write data without having set up mtd.\n");
+		return -1;
+	}
+
+	struct maple_driver_data *mdd =
+	    (struct maple_driver_data *) (vmu_flash_mtd->priv);
+	struct mapleq *mqu = (struct mapleq *) &(mdd->mq);
+	mqu->command = 12;
+	mqu->length = 514;
+
+	((unsigned long *) (mqu->recvbuf))[0] =
+	    cpu_to_be32(MAPLE_FUNC_MEMCARD);
+
+	((unsigned long *) (mqu->recvbuf))[1] = num;
+	memcpy((mqu->recvbuf) + 8, buf, 512);
+
+	mqu->sendbuf = mqu->recvbuf;
+	if (maple_add_packet(mqu) != 0) {
+		printk(KERN_WARNING "VMU FLASH: Could not add packet\n");
+		return -1;
+	}
+
+	return 0;
+
+}
+
+/*************************************/
+
+
 /**
  * __ofs_to_block - Offset to Block Conversion
  * 
@@ -56,27 +159,29 @@
 
 	/* Zero the block */
 	memset(block, 0, sizeof(struct block_s));
-	
+
 	/* Make sure we don't overstep our boundaries */
 	if (src_ofs >= VMU_NUM_BLOCKS * VMU_BLOCK_SIZE) {
-		printk(KERN_WARNING "Source offset exceeds total offset\n");
+		printk(KERN_WARNING
+		       "Source offset exceeds total offset\n");
 		kfree(block);
 		return NULL;
 	}
 
 	/* Find the block number */
-	block->num = (unsigned int)(src_ofs / VMU_BLOCK_SIZE);
+	block->num = (unsigned int) (src_ofs / VMU_BLOCK_SIZE);
 
 	/* Validate we've got a valid block */
 	if (block->num > VMU_NUM_BLOCKS) {
-		printk(KERN_WARNING "Block number exceeds number of blocks\n");	
+		printk(KERN_WARNING
+		       "Block number exceeds number of blocks\n");
 		kfree(block);
 		return NULL;
 	}
-	
+
 	/* Calculate remaining offset in block */
-	block->ofs = (unsigned int)(src_ofs % VMU_BLOCK_SIZE);
-	
+	block->ofs = (unsigned int) (src_ofs % VMU_BLOCK_SIZE);
+
 	return block;
 }
 
@@ -90,11 +195,10 @@
  * Reads a byte from a VMU at the specified offset.
  *
  */
-static __

Re: [linuxdc-dev] Quick question

[Micah D. <mi...@na...>]

Yeah, I've read a lot of the KOS stuff. I even tried to port some of the TA demos to Linux in userspace by mmap()'ing /dev/mem.. but I never got the Store Queues working.

Still, right now it's something I'd like to work on, but I have more important things to do first.

On Mon, Aug 19, 2002 at 12:32:07PM -0400, ps...@wi... wrote:
> On Mon, 2002-08-19 at 05:39, Micah Dowty wrote:
> > I'm still interested in working on DRI support for the PowerVR chip, but I have no idea when I'll have time.
> 
> i would also be interested in such a project. i suggest you take a look
> at the latest OpenGL implementations from KallistiOS and company, as
> they can do quite magical things with video now.

-- 
Only you can prevent creeping featurism!

Re: [linuxdc-dev] Quick question

[Micah D. <mi...@na...>]

I'm still interested in working on DRI support for the PowerVR chip, but I have no idea when I'll have time.

On Sun, Aug 11, 2002 at 06:37:57AM -0500, M. R. Brown wrote:
> This being a developers list, and there being potentially more than 3
> developers out of the 102 people subscribed:
> 
> Is anyone still interested in developing Linux on the Dreamcast?
> 
> Just curious.
> 
> M. R.



-- 
Only you can prevent creeping featurism!

[linuxdc-dev] VMU driver latest

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

I am edging closer to producing a simple driver that will have a character 
based interface to the vmu flash memory (more sophisticated front ends can 
then be built on top of that).

Here is the latest diff of my work from Paul's core file in the CVS:


--- vmu-old.c	Fri Aug 16 00:05:22 2002
+++ vmu-flash.c	Mon Aug 19 00:12:39 2002
@@ -2,6 +2,10 @@
  * drivers/mtd/maps/vmu-flash.c
  * 
  * (C)opyright 2001 Paul Mundt <le...@ch...>
+ +
+ +
+ + Messed about with and fragments copyright 2002, Adrian McMenamin 
<ad...@mc...>
+ +
  * 
  * Flash mapping handler for the Sega Dreamcast VMU.
  *
@@ -26,12 +30,84 @@
 /* MTD Information */
 static struct mtd_info *vmu_flash_mtd = NULL;
 
+/* Persistent result */
+static struct mapleq lastmq;
+static struct maple_driver dc_flashmap_driver;
+
+int waken_up = 1;
+
 /* VMU Block */
 typedef struct block_s {
 	unsigned int num;	/* Block Number */
 	unsigned int ofs;	/* Block Offset */
 } block_t;
 
+/*************************************/
+/**********Read and write routines*************/
+int maple_vmu_read_block(unsigned int  num, u_char *buf){
+
+  /* async maple call
+  assemble maple call
+  wait for return */
+
+
+  /* Sanity check */
+  if (!vmu_flash_mtd){
+    printk(KERN_WARNING "VMU FLASH: Attempting to read data without having 
set up mtd.\n");
+    return -1;
+  }
+
+  struct maple_driver_data *mdd = (struct maple_driver_data 
*)(vmu_flash_mtd->priv);
+  struct mapleq *mqu = (struct mapleq *) &(mdd->mq);
+  mqu->command = 11;
+  mqu->length = 2;
+
+((unsigned long *) (mqu->recvbuf))[0] =
+	    cpu_to_be32(MAPLE_FUNC_MEMCARD);
+
+ ((unsigned long *) (mqu->recvbuf))[1] = num;
+ mqu->sendbuf = mqu->recvbuf;
+ if (maple_add_packet(mqu) != 0){
+		printk(KERN_WARNING "VMU FLASH: Could not add packet\n");
+		return -1;
+ }
+
+ return 0;
+
+}
+
+int maple_vmu_write_block(unsigned int  num, u_char *buf){
+  
+
+ /* Sanity check */
+  if (!vmu_flash_mtd){
+    printk(KERN_WARNING "VMU FLASH: Attempting to read data without having 
set up mtd.\n");
+    return -1;
+  }
+
+  struct maple_driver_data *mdd = (struct maple_driver_data 
*)(vmu_flash_mtd->priv);
+  struct mapleq *mqu = (struct mapleq *) &(mdd->mq);
+  mqu->command = 12;
+  mqu->length = 514;
+
+((unsigned long *) (mqu->recvbuf))[0] =
+	    cpu_to_be32(MAPLE_FUNC_MEMCARD);
+
+ ((unsigned long *) (mqu->recvbuf))[1] = num;
+ memcpy((mqu->recvbuf) + 8, buf, 512);
+
+ mqu->sendbuf = mqu->recvbuf;
+ if (maple_add_packet(mqu) != 0){
+		printk(KERN_WARNING "VMU FLASH: Could not add packet\n");
+		return -1;
+ }
+
+ return 0;
+
+}
+/*************************************/
+
+
 /**
  * __ofs_to_block - Offset to Block Conversion
  * 
@@ -90,7 +166,7 @@
  * Reads a byte from a VMU at the specified offset.
  *
  */
-static __u8 vmu_flash_read8(struct map_info *map, unsigned long ofs)
+static __u8 vmu_flash_read8(unsigned long ofs)
 {
 	block_t *block;
 	u_char *buf = NULL;
@@ -105,7 +181,7 @@
 	}
 
 	/* Read the block */
-	if (maple_vmu_read_block(vmu_flash_mdev, block->num, buf)) {
+	if (maple_vmu_read_block(block->num, buf)) {
 		printk(KERN_WARNING "Can't read block: %d\n", block->num);
 		kfree(block);
 		return 1;
@@ -129,7 +205,7 @@
  * Writes a byte to a VMU at the specified offset.
  *
  */
-static void vmu_flash_write8(struct map_info *map, __u8 d, unsigned long ofs)
+static void vmu_flash_write8( __u8 d, unsigned long ofs)
 {
 	block_t *block;
 	u_char *buf = NULL;
@@ -144,7 +220,7 @@
 	}
 
 	/* Read the block */
-	if (maple_vmu_read_block(vmu_flash_mdev, block->num, buf)) {
+	if (maple_vmu_read_block(block->num, buf)) {
 		printk(KERN_WARNING "Can't read block: %d\n", block->num);
 		kfree(block);
 		return;
@@ -154,7 +230,7 @@
 	(__u8)(*(buf + block->ofs)) = d;
 
 	/* Write the block */
-	if (maple_vmu_write_block(vmu_flash_mdev, block->num, buf)) {
+	if (maple_vmu_write_block(block->num, buf)) {
 		printk(KERN_WARNING "Can't write block: %d\n", block->num);
 		kfree(block);
 		return;
@@ -163,12 +239,35 @@
 	kfree(block);
 }
 
-static struct map_info vmu_flash_map = {
-	name:		"VMU Flash",
-	size:		VMU_NUM_BLOCKS * VMU_BLOCK_SIZE,
-	read8:		vmu_flash_read8,
-	write8:		vmu_flash_write8,
-};
+/***********************************************/
+/* Read and Write 

[linuxdc-dev] Fwd: "Phase" and VMU flash access

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

----------  Forwarded Message  ----------

Subject: "Phase" and VMU flash access
Date: Sun, 18 Aug 2002 18:27:00 +0100
From: Adrian McMenamin <ad...@mc...>
To: lin...@li...
Cc: dc...@ya...;

Apologies for the cross posting - this is a question about a linux driver I
 am attempting to write, but people on the dcdev list may have a better idea
 of the answer!

I am trying to build on the work of Paul Mundt (Lethal), who started a vmu
flash driver for linux. I am making some progress, but now have a question
about how the maple bus interfaces to the VMU.

On Marcus Comstedt's site, the great man has written this about the block
 read command (command number/name, format, expected return):

11 Block read       func, (pt<<24)|(phase<<16)|block            8


He then writes this about "phase":

phase
Sequence number for piecewise block access


What does this mean? Is it the number of the particular byte being acessed
inside the 512 byte vmu flash block, or something different?

Is it possible to access byte by byte, or does mplae bus just return the 512
byte block?

Anybody got any hints or existing working code I could look at?

Thanks

Adrian

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

Re: [linuxdc-dev] glibc not compiling

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

* ps...@wi... <ps...@wi...> on Fri, A=
ug 16, 2002:

> this is probably a frequent source of trouble, but i really need some
> help on this and you all seem to be the experts.
>=20
[...]
>=20
> First i downloaded the latest nightly cvs of binutils
> (binutils-020814.tar.bz2) and cross-compiled it for the SH4 architecture
> (no patches applied). then i downloaded the latest stable gcc release
> 3.2 (pretty recent) and finally got it to cross-compile. now i started
> trying to cross-compile glibc 2.2.5 (without patches, and maybe once
> with them), but it seemed to be giving me too much of a hard time, and
> because of my deadline i downloaded glibc 2.2.4 and the patch for it.

All 3.x versions of GCC can be cross-compiled without patches, but they
won't compile much correctly and binutils won't generate working shared
executables.  Just grab 3.0.4 + patches and you should be fine.  Make sure
your binutils and glibc are patched as well.  DO NOT USE STOCK TOOLS FOR
SUPERH -- EVER.  Even MIPS targets usually require an outside, patched
toolchain.

Thanks,

M. R.

Re: [linuxdc-dev] glibc not compiling

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

Others might be able to give you specific advice about your errors (I am not an expert). But you *do* need to use a patched compiler, toolchain and glibc to build your kernel.

The patches are available from ftp.m17n.org - in ftp://ftp.m17n.org/pub/super-h/testing/ IIRC - you will see what version they are patched against there.

You can always ask for advice on the irc channel too: #linuxdc at irc.openprojects.net.

Keep us informed of any progress.

A.

[linuxdc-dev] glibc not compiling

[<ps...@wi...>]

this is probably a frequent source of trouble, but i really need some
help on this and you all seem to be the experts.

i've been trying to build a dreamcast/sh4 toolchain and so far i'm stuck
on compiling glibc. i've been using several guides as references and
found bill gatliff's "An introduction to embedded linux" the best so
far. 

First i downloaded the latest nightly cvs of binutils
(binutils-020814.tar.bz2) and cross-compiled it for the SH4 architecture
(no patches applied). then i downloaded the latest stable gcc release
3.2 (pretty recent) and finally got it to cross-compile. now i started
trying to cross-compile glibc 2.2.5 (without patches, and maybe once
with them), but it seemed to be giving me too much of a hard time, and
because of my deadline i downloaded glibc 2.2.4 and the patch for it.
patch installed, i played around with the configure options, and had
errors each time i tried to make it. finally, i thought it would be
finished, but it seems to have had a strange error. here's the final
snippet of the compilation:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

sh-linux-gnu-gcc -ml -m4 ../sysdeps/generic/s_significand.c -c -O -Wall -Winline -Wstrict-prototypes -Wwrite-strings -m4 -ml   -fPIC   -Wno-uninitialized -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -DNO_LONG_DOUBLE -D_Mlong_double_=double -I../include -I. -I/home/dreamcast/gentoo/BUILD/base/glibc-sh-linux-gnu/math -I.. -I../libio  -I/home/dreamcast/gentoo/BUILD/base/glibc-sh-linux-gnu -I../sysdeps/sh/elf -I../sysdeps/unix/sysv/linux/sh -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/sh -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/sh -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic  -nostdinc -isystem /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include -isystem /home/dreamcast/gentoo/BUILD/base/include/  -include ../include/libc-symbols.h  -DPIC -DSHARED   -o /home/dreamcast/gentoo/BUILD/base/glibc-sh-linux-gnu/math/s_significand.os
sh-linux-gnu-gcc -ml -m4 ../sysdeps/ieee754/dbl-64/s_sin.c -c -O -Wall -Winline -Wstrict-prototypes -Wwrite-strings -m4 -ml   -fPIC   -Wno-uninitialized -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -DNO_LONG_DOUBLE -D_Mlong_double_=double -I../include -I. -I/home/dreamcast/gentoo/BUILD/base/glibc-sh-linux-gnu/math -I.. -I../libio  -I/home/dreamcast/gentoo/BUILD/base/glibc-sh-linux-gnu -I../sysdeps/sh/elf -I../sysdeps/unix/sysv/linux/sh -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/sh -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/sh -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic  -nostdinc -isystem /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include -isystem /home/dreamcast/gentoo/BUILD/base/include/  -include ../include/libc-symbols.h  -DPIC -DSHARED   -o /home/dreamcast/gentoo/BUILD/base/glibc-sh-linux-gnu/math/s_sin.os
../sysdeps/ieee754/dbl-64/s_sin.c:1125: warning: conflicting types for built-in function `sinl'
../sysdeps/ieee754/dbl-64/s_sin.c:1127: warning: conflicting types for built-in function `cosl'
sh-linux-gnu-gcc -ml -m4 ../sysdeps/ieee754/dbl-64/s_tan.c -c -O -Wall -Winline -Wstrict-prototypes -Wwrite-strings -m4 -ml   -fPIC   -Wno-uninitialized -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -DNO_LONG_DOUBLE -D_Mlong_double_=double -I../include -I. -I/home/dreamcast/gentoo/BUILD/base/glibc-sh-linux-gnu/math -I.. -I../libio  -I/home/dreamcast/gentoo/BUILD/base/glibc-sh-linux-gnu -I../sysdeps/sh/elf -I../sysdeps/unix/sysv/linux/sh -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/sh -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/sh -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic  -nostdinc -isystem /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include -isystem /home/dreamcast/gentoo/BUILD/base/include/  -include ../include/libc-symbols.h  -DPIC -DSHARED   -o /home/dreamcast/gentoo/BUILD/base/glibc-sh-linux-gnu/math/s_tan.os
../sysdeps/ieee754/dbl-64/s_tan.c: In function `tan':
../sysdeps/ieee754/dbl-64/s_tan.c:466: Internal compiler error in output_branch, at config/sh/sh.c:1050
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [/home/dreamcast/gentoo/BUILD/base/glibc-sh-linux-gnu/math/s_tan.os] Error 1
make[2]: Leaving directory `/home/dreamcast/gentoo/BUILD/base/glibc-build/glibc-2.2.4/math'
make[1]: *** [math/others] Error 2
make[1]: Leaving directory `/home/dreamcast/gentoo/BUILD/base/glibc-build/glibc-2.2.4'
make: *** [all] Error 2

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

the other bugs i believe were include-dependent, and i think i finally
got my includes sorted out, so this bug i don't think i could handle (it
told me to make a bug report, which is never good). has anyone seen this
before? should i start trying an earlier version of glibc? keep in mind
i'd really like to use the most up-to-date utilities as possible, since
this will eventually be a port of Gentoo Linux to the dreamcast. oh, and
if anyone would like to comment on what kind of work the patching
involves specifically, i'd love to learn how to fix source for the sh4
arch myself.