linuxdc-dev

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]IRC

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

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

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

[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]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.

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]Some basic questions and Linux DC + NFS

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

On Sun, Oct 14, 2001 at 02:21:16AM -0400, Danny Rodriguez wrote:
> Do you guys, by any chance, have sample .config files for the DC? One
> that supports the BBA and NFS?
>=20
There's an old one in CVS, but nothing that's really useful. Due to the
straightforward nature of setting up a config for the DC, there's no real n=
eed
for this.. but at the same time I suppose sticking in a standard defconfig
probably couldn't hurt either.. Will see what NIIBE-san thinks about adding
arch/sh/configs (in accordance w/ PPC and MIPS guidelines) and go from ther=
e.

Regards,

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