linuxdc-dev — Developer discussion list

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

[Park, C. <Chr...@ba...>]

Is there any way for us in the states to order one (or two?)  $70US still
beats what they are going for on ebay.

Thanks,
CP

-----Original Message-----
From: John Wiggins [mailto:lin...@ho...]
Sent: Friday, November 30, 2001 9:21 AM
To: lin...@li...
Subject: Re: [linuxdc-dev]Fwd: Re: networking dreamcasts


Yeah, my bba is still on the pre-order list on ebworld.com lol
i'd love to get my hands on one none the less

--
John Wiggins
Loxly Norwych (DAoC)
Xortan Brax (EQ)
Gunther Dragon (UDIC)
lin...@ho...
jwi...@sp...
wig...@ya...



>From: "M. R. Brown" <mr...@0x...>
>To: lin...@li...
>Subject: [linuxdc-dev]Fwd: Re: networking dreamcasts
>Date: Thu, 29 Nov 2001 23:56:57 -0600
>
>Too bad I disassembled my black Dreamcast after I bought my white one
>(mainly because the BBA didn't match)!
>
>Just kidding...
>
>M. R.
>
>----- Forwarded message from Stone-sama <sto...@ho...> -----
>
>From: "Stone-sama" <sto...@ho...>
>Subject: Re: networking dreamcasts
>Date: Fri, 30 Nov 2001 00:49:20 -0500
>X-Mailer: Microsoft Outlook Express 6.00.2462.0000
>To: <por...@ne...>
>Precedence: list
>
> >From IGN
>
>"More On the Dreamcast Broadband Adapter
>The Dreamcast broadband adapter will go down as one of the most 
>talked-about
>products that was never fully used. And now, it may actually be re-released
>in a different color in order to appease some of the hardcorest of Sega
>fans.
>
>The story goes like this, apparently. Up till now, CSI has made available
>the broadband adapter in the Dreamcast's original white color.
>Unfortunately, there are a good number of black colored systems out there,
>and having a white device attached to the back of your black system is just
>plain unsightly. Thus, CSI is considering releasing a black colored version
>of the adapter.
>
>CSI will take reservations for the 8,800 yen device from 12/1 to 12/28 at
>its website. If 2000 orders are received, the concept will become a real
>product which will be shipped out in February or March."
>
>-Brian
>
>----- Original Message -----
>From: "Scott Hughes" <sh...@da...>
>To: <por...@ne...>
>Sent: Thursday, November 29, 2001 12:19 PM
>Subject: RE: networking dreamcasts
>
>
> >
> > > Now to me, a computer not connected to a network isn't very
> > > useful, and I'm not quite willing to shell out $100+ for the
> > > broadband adapter on Ebay when I bought the machine for $40.
> >
> > There's a Japanese company who might be releasing more BBAs.  Does 
>anyone
>on
> > this list read Japanese?
> >
> > http://www3.csi-msp.com/bbsite/
> >
> > The info I read said that they are taking reservations, and if more than
> > 2000 are reserved they'll do it.  Maybe someone can translate the page 
>for
> > us non-speakers.
> >
> > Scott
> >
> >
>
>----- End forwarded message -----
><< attach3 >>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


_______________________________________________
Linuxdc-dev mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxdc-dev

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

[John W. <lin...@ho...>]

Yeah, my bba is still on the pre-order list on ebworld.com lol
i'd love to get my hands on one none the less

--
John Wiggins
Loxly Norwych (DAoC)
Xortan Brax (EQ)
Gunther Dragon (UDIC)
lin...@ho...
jwi...@sp...
wig...@ya...



>From: "M. R. Brown" <mr...@0x...>
>To: lin...@li...
>Subject: [linuxdc-dev]Fwd: Re: networking dreamcasts
>Date: Thu, 29 Nov 2001 23:56:57 -0600
>
>Too bad I disassembled my black Dreamcast after I bought my white one
>(mainly because the BBA didn't match)!
>
>Just kidding...
>
>M. R.
>
>----- Forwarded message from Stone-sama <sto...@ho...> -----
>
>From: "Stone-sama" <sto...@ho...>
>Subject: Re: networking dreamcasts
>Date: Fri, 30 Nov 2001 00:49:20 -0500
>X-Mailer: Microsoft Outlook Express 6.00.2462.0000
>To: <por...@ne...>
>Precedence: list
>
> >From IGN
>
>"More On the Dreamcast Broadband Adapter
>The Dreamcast broadband adapter will go down as one of the most 
>talked-about
>products that was never fully used. And now, it may actually be re-released
>in a different color in order to appease some of the hardcorest of Sega
>fans.
>
>The story goes like this, apparently. Up till now, CSI has made available
>the broadband adapter in the Dreamcast's original white color.
>Unfortunately, there are a good number of black colored systems out there,
>and having a white device attached to the back of your black system is just
>plain unsightly. Thus, CSI is considering releasing a black colored version
>of the adapter.
>
>CSI will take reservations for the 8,800 yen device from 12/1 to 12/28 at
>its website. If 2000 orders are received, the concept will become a real
>product which will be shipped out in February or March."
>
>-Brian
>
>----- Original Message -----
>From: "Scott Hughes" <sh...@da...>
>To: <por...@ne...>
>Sent: Thursday, November 29, 2001 12:19 PM
>Subject: RE: networking dreamcasts
>
>
> >
> > > Now to me, a computer not connected to a network isn't very
> > > useful, and I'm not quite willing to shell out $100+ for the
> > > broadband adapter on Ebay when I bought the machine for $40.
> >
> > There's a Japanese company who might be releasing more BBAs.  Does 
>anyone
>on
> > this list read Japanese?
> >
> > http://www3.csi-msp.com/bbsite/
> >
> > The info I read said that they are taking reservations, and if more than
> > 2000 are reserved they'll do it.  Maybe someone can translate the page 
>for
> > us non-speakers.
> >
> > Scott
> >
> >
>
>----- End forwarded message -----
><< attach3 >>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[linuxdc-dev]Fwd: Re: networking dreamcasts

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

Too bad I disassembled my black Dreamcast after I bought my white one
(mainly because the BBA didn't match)!

Just kidding...

M. R.

----- Forwarded message from Stone-sama <sto...@ho...> -----

From: "Stone-sama" <sto...@ho...>
Subject: Re: networking dreamcasts
Date: Fri, 30 Nov 2001 00:49:20 -0500
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
To: <por...@ne...>
Precedence: list

>From IGN

"More On the Dreamcast Broadband Adapter
The Dreamcast broadband adapter will go down as one of the most talked-about
products that was never fully used. And now, it may actually be re-released
in a different color in order to appease some of the hardcorest of Sega
fans.

The story goes like this, apparently. Up till now, CSI has made available
the broadband adapter in the Dreamcast's original white color.
Unfortunately, there are a good number of black colored systems out there,
and having a white device attached to the back of your black system is just
plain unsightly. Thus, CSI is considering releasing a black colored version
of the adapter.

CSI will take reservations for the 8,800 yen device from 12/1 to 12/28 at
its website. If 2000 orders are received, the concept will become a real
product which will be shipped out in February or March."

-Brian

----- Original Message -----
From: "Scott Hughes" <sh...@da...>
To: <por...@ne...>
Sent: Thursday, November 29, 2001 12:19 PM
Subject: RE: networking dreamcasts


>
> > Now to me, a computer not connected to a network isn't very
> > useful, and I'm not quite willing to shell out $100+ for the
> > broadband adapter on Ebay when I bought the machine for $40.
>
> There's a Japanese company who might be releasing more BBAs.  Does anyone
on
> this list read Japanese?
>
> http://www3.csi-msp.com/bbsite/
>
> The info I read said that they are taking reservations, and if more than
> 2000 are reserved they'll do it.  Maybe someone can translate the page for
> us non-speakers.
>
> Scott
>
>

----- End forwarded message -----

[linuxdc-dev]the site

[Espen R. <es...@ii...>]

ok so I started (finallyyy yeah wowowowowow etc.) working on the site,
but:

where is the actual content to put in it :D (I could copy'n'paste
from old site (where?) and I'll ofcourse include the stuff allready in cvs

cvs, I might need some password so I can start checking in stuff?
(now I use anonymous)

ht2html didn't look that convinving to me (a bit untidy)? and boring? ;)

anyways, here is some logo and colorstuff, comments welcome, I'm thinking
of making the sections (tables basically) ready first in regular html then
include them in ht2html/whatever

check it: http://www.ii.uib.no/~espenr/linuxDC/index2.html

none of the links work ofcourse, and I'm thinking of making it viewable
primarily in mozilla/ie, and besides some css no fancy stuff (right now IE
is not optimal with the bgcolor etc.)

espen
-------------------------------------------------------------------
I don't need to test my programs. I have an error-correcting modem.

Re: [linuxdc-dev]Dreamcast sound

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

* Adrian McMenamin <ad...@mc...> on Sun, Nov 25, 2001:

>=20
> So: do you have such an app, or can you give me a fireproof way of gettin=
g=20
> PRBOOM to run?
>=20

$ cat /dev/urandom > /dev/dsp

Should produce static if it works.

M. R.

[linuxdc-dev]Dreamcast sound

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

My work on building a sound driver for LinuxDC continues ... but I have a 
problem which someone on the list might be able to help with.

Essentially, I need an application for the DC which will attempt to play some 
sound.

I have been trying use PRBOOM, but it seems to have difficulties with the 
framebuffer (?). I have had PRBOOM work before on the DC but more by hit an 
miss than design.

Currently PRBOOM opens the sound drivers but then promptly shuts down 
reporting that it cannot set the display to 320 x 200. All the right debug 
messages appear on screen indicating that the open and release methods on the 
driver are opened and closed in the right order and that all the 
memory_requests and memory_releases work, but nothing is around long enough 
to be seriously tested.

So: do you have such an app, or can you give me a fireproof way of getting 
PRBOOM to run?

Thanks

Adrian

[linuxdc-dev]Dreamcast memory

[<ga...@wi...>]

Has anyone sucessfully swapped out the 16MB memory chip that the
dreamcast comes with for a larger chip?


						Gareth

-- 
"Apparently if you play the Windows NT CD backwards you hear satanic messages"
"You think that's bad, if you play it forwards it installs Windows NT!"
------------------------------------------------------------------------------
Gareth J. Greenaway
ga...@wi...    

Re: [linuxdc-dev]Misbehaving driver code

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

On Friday 23 Nov 2001 5:13 am, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Thu, Nov 22, 2001:
> > The good news is that I am now pretty confident that this task (writing
> > the driver) is doable...
>
> Two things about directly accessing the AICA hardware:
>
> 1) Use io_request_region() to reserve AICA registers and RAM,
> 2) Use the in{b,w,l}() out{b,w,l}() macros when accessing registers.  This
>    lets us do things like wait for the G2 bus FIFO (0xa05f688c) and other
>    cool stuff, without the device driver ever needing to worry about it:
>
>    void outl(u32 val, void *addr)
>    {
>    	while ((u32 *)*(0xa05f688c) & 1) ;
> 	*reg = val;
>    }
>
> You only have to worry about AICA-specific stuff in your driver at this
> point, you don't have to get all funky like libdream or KOS.
>

Thanks for the tips. No need to worry about the driver getting "all funky" 
:-> At the moment the thing I am interested in is getting some noise to come 
out of the speakers!


> See, even the kernel can do sane abstraction ;).
>
> M. R.

Re: [linuxdc-dev]Misbehaving driver code

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

* Adrian McMenamin <ad...@mc...> on Thu, Nov 22, 2001:

>=20
> The good news is that I am now pretty confident that this task (writing t=
he=20
> driver) is doable...
>=20

Two things about directly accessing the AICA hardware:

1) Use io_request_region() to reserve AICA registers and RAM,
2) Use the in{b,w,l}() out{b,w,l}() macros when accessing registers.  This
   lets us do things like wait for the G2 bus FIFO (0xa05f688c) and other
   cool stuff, without the device driver ever needing to worry about it:

   void outl(u32 val, void *addr)
   {
   	while ((u32 *)*(0xa05f688c) & 1) ;
	*reg =3D val;
   }

You only have to worry about AICA-specific stuff in your driver at this poi=
nt,
you don't have to get all funky like libdream or KOS.

See, even the kernel can do sane abstraction ;).

M. R.

Re: [linuxdc-dev]Misbehaving driver code

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

On Thursday 22 Nov 2001 12:19 am, Paul Mundt wrote:
> On Wed, Nov 21, 2001 at 08:58:06PM +0000, Adrian McMenamin wrote:
> > But rmmod produces "Device busy" error message.
>
> This is to be expected.. as you're misusing MOD_{INC,DEC}_USE_COUNT.
>
> > Any ideas? Is it simply because this is not a properly registered driver
> > yet - or is there a coding problem?
> >
> > Any and all help etc....
>
> [snip]
>
> > static int __init init_aica (void)
> > {
> >      MOD_INC_USE_COUNT; //increment count
>
> [snip]
>
> This is not at all what you want to do. You're forcing its usage count up
> on an initialization even though nothing is actually using it. The proper
> way to do this would be to setup an aica_open() and stick your
> MOD_INC_USE_COUNT in there, and then decrement it on an aico_close(), then
> hand that off to a file operations structure when you register.
>


Errr... yes.  I should have paid more attention to the sample code I was 
looking at.

The good news is that I am now pretty confident that this task (writing the 
driver) is doable...

Re: [linuxdc-dev]Misbehaving driver code

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

On Wed, Nov 21, 2001 at 08:58:06PM +0000, Adrian McMenamin wrote:
> But rmmod produces "Device busy" error message.
>=20
This is to be expected.. as you're misusing MOD_{INC,DEC}_USE_COUNT.

> Any ideas? Is it simply because this is not a properly registered driver =
yet=20
> - or is there a coding problem?
>=20
> Any and all help etc....
>=20
[snip]

> static int __init init_aica (void)
> {
>      MOD_INC_USE_COUNT; //increment count
[snip]

This is not at all what you want to do. You're forcing its usage count up on
an initialization even though nothing is actually using it. The proper way =
to
do this would be to setup an aica_open() and stick your MOD_INC_USE_COUNT in
there, and then decrement it on an aico_close(), then hand that off to a fi=
le
operations structure when you register.

> }
>=20
> static void __exit exit_aica(void)
> {
>   /*set low bit of register to 1*/
>   printk("<1>AICA sound driver being unloaded...\n");
>   SET_AICA_REG(0x2c00) |=3D 1;
>   MOD_DEC_USE_COUNT;
>  =20
> }
>=20
Same deal here, MOD_DEC_USE_COUNT should only ever be used by a close call.
Think of the following scenario .. you bring up the device, and open()
/dev/dsp .. this should accordingly increment its usage count, as it's in u=
se
by the application that open()'ed it. Later on .. when you close() the file
descriptor, its usage count is decremented.

Checking /proc/modules will always report the current status of a module and
its usage count.. a module can't be unloaded if it's in use.

Regards,

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

[linuxdc-dev]Misbehaving driver code

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

Below is a code fragment from the sound driver i am working on - very basic 
as you can see.

I intend ploughing on - adding to the attach bit to plug into the OSS 
drivers, but even this simple code misbehaves at the moment.

I am sure it is something basic and silly, but I hope you will indulge me by 
telling me what...

What happens now...

insmod aica.o generates (correctly) - "Attaching AICA" and then "AICA sound 
driver has been initialised"

lsmod shows it then in situ.

But rmmod produces "Device busy" error message.

Any ideas? Is it simply because this is not a properly registered driver yet 
- or is there a coding problem?

Any and all help etc....






// Macros to make it easier
#define AICA_REG(x) ((int *)(0xa0700000 + (x)))
#define SET_AICA_REG(x) (*AICA_REG(x))

static int attach_aica(void)
{
  printk("<1>Attaching AICA\n");


  return 0;
}


static int __init init_aica (void)
{
     MOD_INC_USE_COUNT; //increment count
     
     //disable the ARM7
     SET_AICA_REG(0x2c00) |= 1;

     //empty sound memory
     memset((void*)0xa0800000, 0, 0x200000);

     

     /*Simply set low bit of AICA register 0x2c00 to zero
       this maps to 0xa0702c00 in the SH4 memory map*/
     
     SET_AICA_REG(0x2c00) &= ~1;
     attach_aica();
     printk("<1>AICA sound driver has been initialised\n");
     return 0;
}

static void __exit exit_aica(void)
{
  /*set low bit of register to 1*/
  printk("<1>AICA sound driver being unloaded...\n");
  SET_AICA_REG(0x2c00) |= 1;
  MOD_DEC_USE_COUNT;
  
}

module_init(init_aica);
module_exit(exit_aica);

Re: [linuxdc-dev]Memeory mapping

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

On Monday 19 Nov 2001 9:46 pm, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Mon, Nov 19, 2001:
> > At last I feel I am beginning to understand how to do this (write the
> > sound driver) but I have a question about memory mapping, or rather
> > wonder if soemone will confirm my understanding of the DC memory map - as
> > there are a plethora of memory maps out there saying different things....
>
> The best understanding comes from the SH7750 Hardware and Programming
> manuals.  The break down the SH4 memory space and MMU in *excrutiating*
> detail.
>
> > The memory map appears to repeat itself over and over again, but the
> > kernel is in the P1 area and (obviously) executes as privileged code with
> > the bottom of system RAM at 0x80000000?
>
> Nope, it's 0x8c000000.

Hmmm... I should learn to read. Many thanks for the rest of this too.

Re: [linuxdc-dev]Memeory mapping

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

* Adrian McMenamin <ad...@mc...> on Mon, Nov 19, 2001:

> At last I feel I am beginning to understand how to do this (write the sou=
nd=20
> driver) but I have a question about memory mapping, or rather wonder if=
=20
> soemone will confirm my understanding of the DC memory map - as there are=
 a=20
> plethora of memory maps out there saying different things....
>=20

The best understanding comes from the SH7750 Hardware and Programming
manuals.  The break down the SH4 memory space and MMU in *excrutiating*
detail.

> The memory map appears to repeat itself over and over again, but the kern=
el=20
> is in the P1 area and (obviously) executes as privileged code with the bo=
ttom=20
> of system RAM at 0x80000000?
>=20

Nope, it's 0x8c000000.

> Now, I assume that for a sound driver should also access the sound memory=
 in=20
> privileged mode so that's at 0x80800000 for the driver? (Can ill-behaved =
user=20
> programs then write all over that - or does the kernel memory management =
stop=20
> them?)
>=20

In order for you to understand this, you also need to realize that the
memory space doesn't simply "repeat" itself, each range signifies user
mode, whether or not the range can be remapped using the MMU, and if the
memory accesses are cached or not.  0x8xxxxxxx is cached.  0xaxxxxxxx
isn't.  You wouldn't ever want to access external RAM or memory-mapped
hardware registers using the cache, that would be very, very, catastrophic.

So you're actually talking about 0xa0800000 for the AICA memory.  It's
registers are located at 0xa0700000.  This is the SH4 view of the AICA's
address space, the AICA views it differently.  From the AICA, RAM starts at
0 and the registers are mapped to 0x00800000.

As far as accesses under Linux are concerned, the very nature of a
"protected" OS means that you'd want to explicitly map the AICA RAM before
the *kernel* could use it, userspace programs wouldn't have a chance.
Userspace programs can't access anything outside of their virtual memory
space.  This is also covered in the same section as the SH4 memory spaces.

Technically your kernel driver could write all over AICA RAM and reg space
without reserving it first, but this isn't good programming practice (even
though die-hard embedded programmers will argue about that) or The Right
Thing(tm) as far as Linux kernel programming is concerned.  Just use the
I/O resource reservation routines (request_region() mostly), and you should
be ok - this helps ensure that no other driver tries to access the mem space
that you're working with.

> Meanwhile the sound registers are only accessible in privileged mode - as=
=20
> they are mapped (for the SH4) into 0xa0700000 - 0xa07033ff - or can these=
 be=20
> reached at 0x80700000 - 0x808033ff too? Or even in user space at 0x007000=
0=20
> etc?

Again, because the 0x00 and 0x80 regions are cached, never use them to
access hardware registers.

You may also want to browse around for explanations on virtual memory
management, or read the relevant kernel sources.

M. R.

[linuxdc-dev]Memeory mapping

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

At last I feel I am beginning to understand how to do this (write the sound 
driver) but I have a question about memory mapping, or rather wonder if 
soemone will confirm my understanding of the DC memory map - as there are a 
plethora of memory maps out there saying different things....

The memory map appears to repeat itself over and over again, but the kernel 
is in the P1 area and (obviously) executes as privileged code with the bottom 
of system RAM at 0x80000000?

Now, I assume that for a sound driver should also access the sound memory in 
privileged mode so that's at 0x80800000 for the driver? (Can ill-behaved user 
programs then write all over that - or does the kernel memory management stop 
them?)

Meanwhile the sound registers are only accessible in privileged mode - as 
they are mapped (for the SH4) into 0xa0700000 - 0xa07033ff - or can these be 
reached at 0x80700000 - 0x808033ff too? Or even in user space at 0x0070000 
etc?

Adrian

Re: [linuxdc-dev]IRC

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

The IRC channels seems completely unreachable at the moment, so forgive this 
coming by email...

But for novelty value somebody out there might be interested to know that I 
have now successfully compiled and 'installed' (ie used insmod) the OSS core 
sound driver modules on the DC.

They don't actually do anything - so nobody should expect working sound just 
yet.

I have to comment out a lot of DMA stuff and alter one of the kernel files 
(as suggested in the linuxsh-dev list).

I *will* be trying to get some sound, but don't expect any results in a hurry.

But if anybody wants to know more or would like the files used etc, just drop 
me a line.

Adrian

Re: [linuxdc-dev]NFS Mounting problem

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

On Monday 05 Nov 2001 12:01 pm, Stuart Menefy wrote:
> Adrian
>
> One of the options which is passed to the kernel is whether to
> mount the root file system, r/w or read only. This is not passed
> on the command line, but as a separate parameter (the read only flag
> is at offset 0 to the parameter block, the command line offset 256 bytes).
>
> Its normal to write the root file system read only rather then read
> write so that fsck can check it first. Of course this doesn't make
> much sense for a network file system!
>
> I suspect the problem you're having is that full mount tries to maintain
> /etc/mtab, which at this point is on the read only file system. So just
> add the -n option to your mount.
>
> At the moment I'm using:
>   mount -n -o remount,rw /dev/root / -t root
> which appears to work fine.
>
> Stuart
>
>

Thanks for this, it did indeed solve the problem - and explained some of the 
behaviour of the box underbusy box.

Have to register my disappointment at the lacklustre performance of X on the 
Dc though - and there's not much to run either.

Has anybody tried to port vnc by any chance?

Re: [linuxdc-dev]NFS Mounting problem

[Stuart M. <Stu...@st...>]

Adrian

One of the options which is passed to the kernel is whether to
mount the root file system, r/w or read only. This is not passed
on the command line, but as a separate parameter (the read only flag
is at offset 0 to the parameter block, the command line offset 256 bytes).

Its normal to write the root file system read only rather then read
write so that fsck can check it first. Of course this doesn't make
much sense for a network file system!

I suspect the problem you're having is that full mount tries to maintain
/etc/mtab, which at this point is on the read only file system. So just
add the -n option to your mount.

At the moment I'm using:
  mount -n -o remount,rw /dev/root / -t root
which appears to work fine.

Stuart


On Nov 5, 12:20am, ad...@mc... wrote:
> Subject: [linuxdc-dev]NFS Mounting problem
> I have been NFS mounting my shell (busybox) successfully but I am now 
> attempting to mount the m17n GNU/Debian distro but I am having serious 
> difficulties...
> 
> I can mount the files, but only as read only.
> 
> All the commands to NFS are rw and I think it is the boot loader 
> (kernel-boot.S) that is forcing a read only mount.
> 
> I had exactly the same problem with busybox but simply fixed this by 
> remounting the NFS filesystem in rcS: mount -o remount,rw /. This won't work 
> here (it seems the mount supplied is not as flexible as the one in the 
> busybox shell?)
> 
> There were issues about the kernel mismatch (the m17n distro is built for 
> 2.4.5 and I am using 2.4.10-pre6) but this is secondary, as far as I can see, 
> to the issue of rw mounting the filesystem.
> 
> Has anybody else had this problem and, if so, how did they fix it?
> 
> Thanks
> 
> Adrian
> 
> _______________________________________________
> Linuxdc-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxdc-dev
> 
> 
>-- End of excerpt from ad...@mc...

[linuxdc-dev]NFS Mounting problem

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

I have been NFS mounting my shell (busybox) successfully but I am now 
attempting to mount the m17n GNU/Debian distro but I am having serious 
difficulties...

I can mount the files, but only as read only.

All the commands to NFS are rw and I think it is the boot loader 
(kernel-boot.S) that is forcing a read only mount.

I had exactly the same problem with busybox but simply fixed this by 
remounting the NFS filesystem in rcS: mount -o remount,rw /. This won't work 
here (it seems the mount supplied is not as flexible as the one in the 
busybox shell?)

There were issues about the kernel mismatch (the m17n distro is built for 
2.4.5 and I am using 2.4.10-pre6) but this is secondary, as far as I can see, 
to the issue of rw mounting the filesystem.

Has anybody else had this problem and, if so, how did they fix it?

Thanks

Adrian

[linuxdc-dev]IRC

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

The channel appears to have disappeared! Or has it just moved or changed name?

Re: [linuxdc-dev]A couple of questions

[The D. W. <do...@ge...>]

* Adrian McMenamin (ad...@mc...) [011025 19:17]:
> 2. I am now using devfs but this breaks QtE (which appears to want to use 
> /dev/fb0) and I can see no obvious way to alter QtE to fix it. Any thoughts 
> anyone?

In your initrd or boot scripts, create a link from /dev/fb to
/dev/fb0

Or you can have devfsd do it via the devfsd.conf file:
# Plain version
REGISTER ^fb/0$ CFUNCTION GLOBAL symlink $devname fb0
UNREGISTER ^fb/0$ CFUNCTION GLOBAL unlink fb0

# Fancier Version
REGISTER ^fb/([0-9])$ CFUNCTION GLOBAL symlink $devname fb\1
UNREGISTER ^fb/([0-9])$ CFUNCTION GLOBAL unlink fb\1

Note: I've not actually use the above, but I *think* it should work.
Test before wasting a CDR on it.

Ciao!

-- 
Famous Last Words: "Where did all the Indians come from?" -- Custer

The Doctor What: Da Man                          http://docwhat.gerf.org/
do...@ge...                                                   KF6VNC

[linuxdc-dev]A couple of questions

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

1. Has anybody any experience of using DMA in the kernel - when I compile it 
in the keyboard gets disabled - has nobody written a device driver that uses 
DMA, for instance?

2. I am now using devfs but this breaks QtE (which appears to want to use 
/dev/fb0) and I can see no obvious way to alter QtE to fix it. Any thoughts 
anyone?

Adrian

Re: [linuxdc-dev]A sound driver

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

On Monday 22 October 2001 12:21 am, M. R. Brown wrote:

>
> Since this sounds like more of a generic "full-scoping" kernel issue, you
> probably want to forward this to lkml.
>
> M. R.

My own stupidity, I'm afraid. The answer was pretty obvious when I looked at 
the source code - I needed to compile another file alongside it which 
included the body of the missing function. Doh!

Anyway, it's fixed now, it compiles and it loads. Of course, it doesn't 
actually do anything. It's just the place holder for the most basic of 
operations.

Re: [linuxdc-dev]A sound driver

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

* Adrian McMenamin <ad...@mc...> on Sun, Oct 21, 2001:

> As promised on IRC I am making a few faltering steps towards creating a s=
ound=20
> driver for the DC.
>=20
> I have started by compiling the sound_core.c written by Alan Cox.
>=20
> It compiles fine using sh4-linux-gcc but when I use modprobe to load it, =
I=20
> get "unresolved symbol mod_firmware_load". I can't find any explanation f=
or=20
> this function/macro in the Linux Device Drivers book and while I can find=
=20
> lots of examples of other people having this problem with their sound=20
> cards/linux kernels when I trawl through Google, I get no clear explanati=
on.
>=20
> Anyone here know what this is about?
>=20

Since this sounds like more of a generic "full-scoping" kernel issue, you
probably want to forward this to lkml.

M. R.

[linuxdc-dev]A sound driver

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

As promised on IRC I am making a few faltering steps towards creating a sound 
driver for the DC.

I have started by compiling the sound_core.c written by Alan Cox.

It compiles fine using sh4-linux-gcc but when I use modprobe to load it, I 
get "unresolved symbol mod_firmware_load". I can't find any explanation for 
this function/macro in the Linux Device Drivers book and while I can find 
lots of examples of other people having this problem with their sound 
cards/linux kernels when I trawl through Google, I get no clear explanation.

Anyone here know what this is about?