subject:"Re\: \[RFC PATCH 04\/19\] powerpc\: wii\: device tree"

Benjamin Herrenschmidt wrote:
 On Sun, 2009-11-22 at 23:01 +0100, Albert Herranz wrote:
 
 +/memreserve/ 0x0180 0xe80;  /* memory hole (includes I/O area) */
 +/memreserve/ 0x1000 0x0004000;  /* DSP RAM */
 
 Weird layout... nothing you can do about I suppose.
 
 Out of curiosity, what is that DSP RAM ? Some actual DSP core somewhere
 in the IO chip setup to use memory from up there ?
 

Yes, there's a DSP used normally for audio purposes.

 I'll skip on some things that I'm sure others will have commented
 about :-)
 

Ok :)

 +/*
 + * The Nintendo Wii has two discontiguous RAM memory areas called
 + * MEM1 and MEM2.
 + * MEM1 starts at 0x and contains 24MB of 1T-SRAM.
 + * MEM2 starts at 0x1000 and contains 64MB of DDR2 RAM.
 + * Between both memory address ranges there is an address space
 + * where memory-mapped I/O registers are found.
 + *
 + * Currently, Linux 32-bit PowerPC does not support RAM in
 + * discontiguous memory address spaces. Thus, in order to use
 + * both RAM areas, we declare as RAM the range from the start of
 + * MEM1 to the end of useable MEM2 and exclude the needed parts
 + * with /memreserve/ statements, at the expense of wasting a bit
 + * of memory.
 + */
 +memory {
 +device_type = memory;
 +/* MEM1 + memory hole + MEM2 - firmware/buffers area */
 +reg = 0x 0x133e;
 +};
 
 So we do have a nasty hole here in the middle. How bad it is if you try
 to just have two ranges in there (ie as if it was discontiguous) ? We
 shouldn't be far from being able to do discontig mem actually, should be
 easy enough to fix. Tho I don't have (yet) the HW :-) (I'm tempted...)
 

My plan is to just put the two ranges on the device tree (to reflect the actual 
hardware) and coalesce them in the fixup function of the bootwrapper.
Then add the needed reservations and hacks to make that work (mmu_mapin_ram / 
ioremap).

 Same comment as other discussions about the framebuffer here.
 

Ok.

 +cpus {
 +#cpus = 1;
 +#address-cells = 1;
 +#size-cells = 0;
 +
 +PowerPC,broad...@0 {
 +device_type = cpu;
 +reg = 0;
 +clock-frequency = 72900; /* 729MHz */
 +bus-frequency = 24300; /* 243MHz core-to-bus 3x */
 +timebase-frequency = 6075; /* 243MHz / 4 */
 +i-cache-line-size = 32;
 +d-cache-line-size = 32;
 +i-cache-size = 32768;
 +d-cache-size = 32768;
 +};
 +};
 +
 +/* devices contained in the hollywood chipset */
 +soc {
 
 Call it hollywood
 

I like that too. Simple and effective.

 +#address-cells = 1;
 +#size-cells = 1;
 +#interrupt-cells = 1;
 +model = hollywood;
 +compatible = nintendo,hollywood;
 +clock-frequency = 24300; /* 243MHz */
 +ranges = 0x0c00 0x0c00 0x0001
 +  0x0d00 0x0d00 0x0001
 +  0x0d04 0x0d04 0x0005
 +  0x0d80 0x0d80 0x1000
 +  0x133e 0x133e 0x00c2;
 +
 +vi...@0c002000 {
 +compatible = nintendo,hollywood-video;
 +reg = 0x0c002000 0x100;
 +interrupts = 8;
 +interrupt-parent = PIC0;
 +};
 +
 +PIC0: p...@0c003000 {
 +#interrupt-cells = 1;
 +compatible = nintendo,flipper-pic;
 +reg = 0x0c003000 0x8;
 +interrupt-controller;
 +};
 +
 +resetswi...@0c003000 {
 +compatible = nintendo,hollywood-resetswitch;
 +reg = 0x0c003000 0x4;
 +interrupts = 1;
 +interrupt-parent = PIC0;
 +};
 +
 +au...@0c005000 {
 +compatible = nintendo,hollywood-audio;
 +reg = 0x0c005000 0x200 /* DSP */
 +   0x0d006c00 0x20;/* AI */
 +interrupts = 6;
 +interrupt-parent = PIC0;
 +};
 +
 +/* Team Twiizers' 'mini' firmware IPC */
 
 Out of curiosity, what are these ? :-)
 

Those are the guys behind most Wii hacking efforts.

 +m...@0d00 {
 +#address-cells = 1;
 +#size-cells = 1;
 +#interrupt-cells = 1;
 +compatible = twiizers,starlet-mini-ipc;
 +reg = 0x0d00 0x40  /* IPC */
 +   0x13fc 0x4; /* mini header pointer */
 +};
 +
 +ser...@0d006400 {
 +

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Benjamin Herrenschmidt wrote:
 On Wed, 2009-11-25 at 18:49 +0100, Segher Boessenkool wrote:
 +/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
 Like others have said already, don't do this.  If you need
 a workaround, put it in the platform code.

 +/memreserve/ 0x1000 0x0004000; /* DSP RAM */
 This address is fixed in the DSP hardware, right?  If not,
 you shouldn't do a reserve here.

 +   chosen {
 +   /* root filesystem on 2nd partition of SD card */
 +   bootargs = nobats root=/dev/mmcblk0p2 rootwait udbg-immortal;
 Question: why do you need/want nobats?
 
 Good point. I can't even guarantee that the kernel will work reliably
 with nobats :-) At least you really want the kernel .text to be fully
 covered by an IBAT.
 

It works with nobats.
I must say that all the patches posted (and the device drivers, which haven't 
been posted yet) are tested and working code.

 What does this clock freq mean?  Hollywood has lots of
 clocks, many of them configurable.  Bus frequency is in
 the cpu node already.  The binding doesn't say what this
 is either, since you didn't write a binding :-)

 Just remove it?
 
 BTW. If we want to play with clocks, maybe you should look at
 my proposed binding for clocks and implementing the clk API :-)
 
 +   ranges = 0x0c00 0x0c00 0x0001
 + 0x0d00 0x0d00 0x0001
 + 0x0d04 0x0d04 0x0005
 + 0x0d80 0x0d80 0x1000
 All of 0cXX and 0dXX actually.

 + 0x133e 0x133e 0x00c2;
 This is just part of MEM2, don't treat it special here.

 +   vi...@0c002000 {
 +   compatible = nintendo,hollywood-video;
 +   reg = 0x0c002000 0x100;
 +   interrupts = 8;
 +   interrupt-parent = PIC0;
 If you say interrupt-parent = .. in the root node, you can
 leave it out in most of the rest of the tree.  Using the Flipper
 PIC for this sounds like a good plan.
 
 Well, for the rest of the tree except stuff whose interrupt parent
 is PIC1. With two PICs I prefer being explicit.
 

Let it be specific then :)

 +   PIC0: p...@0c003000 {
 +   #interrupt-cells = 1;
 +   compatible = nintendo,flipper-pic;
 +   reg = 0x0c003000 0x8;
 This register block is bigger actually.  It's not only PIC,
 but some other bus stuff as well, dunno what to do here.
 
 Add nodes for the other things ?
 
 +   interrupt-controller;
 +   };
 +
 +   resetswi...@0c003000 {
 +   compatible = nintendo,hollywood-resetswitch;
 +   reg = 0x0c003000 0x4;
 That's the same address.  Don't do that.

 Create a flipper-processor-interface node for the whole 3000
 block (size 100)?  You can hang the PIC as a subnode under it,
 without a reg.
 
 Yeah.
 

Agreed.

 +   /* Team Twiizers' 'mini' firmware IPC */
 +   m...@0d00 {
 Although mini is awesome, it isn't hardware, and doesn't
 belong in the device tree.
 
 So what is at d000 ?
 

There you can find the hardware interface that supports the IPC mechanism.
It is made up of a pair of registers to pass data between the processors and a 
pair of control/flags registers.
The hardware can interrupt the PowerPC side when there is data available for it.

 +   ser...@0d006400 {
 +   compatible = nintendo,hollywood-serial;
 You might want to pick a more descriptive name for this,
 serial is usually understaood to mean RS232.  Which
 this isn't.
 
 What is it then ? You definitely want some other name if it's not
 classic rs232 style serial.
 

It is what Nintendo calls the Serial Interface (SI) which is a proprietary 
serial hardware to drive the gamepads (and a custom keyboard too, once 
available for an RPG game).

 Cheers,
 Ben.
 

Thanks,
Albert

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Benjamin Herrenschmidt wrote:
 On Wed, 2009-11-25 at 19:34 +0100, Albert Herranz wrote:
 We need nobats (or a hack in the mmu_mapin_ram() code) because of the
 discontiguous ram problem.
 
 I would vote for a hack in mmu_mapin_ram() for now.
 

I'll cook that.

 Cheers,
 Ben.
 

Thanks,
Albert


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote:

  Are the above OHCI and EHCI special ? If not, there's an existing
  binding for that sort of thing, which btw requires properties to
  indicate the endianness of the registers and in-memory data structures
  etc...
  
 
 They are a bit special because registers are in reverse little endian format,
 must be written in 32-bit chunks, and (all things point to) they have 
 hardware bugs.

Well.. first what is reverse little endian ? :-) Big endian ?

The OHCI driver today has separate flags to control register endianness
and memory based data structures endianness.

I think we also only use 32-bit reads and writes no ? So that should be
covered :-)

As for HW bugs, well, as long as we know them we can define a quirk bit
and add the necessary workarounds to the driver :-)

Do you have a patch somewhere that adds the OCHI and EHCI support btw ?
 
Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree


  Good point. I can't even guarantee that the kernel will work reliably
  with nobats :-) At least you really want the kernel .text to be fully
  covered by an IBAT.
  
 
 It works with nobats.

But does it work -reliably- ? :-)

I haven't looked at that for years, but we used to have a subtle issue
if you happen to take a hash miss on the kernel text or data in the
wrong time, such as when SRR0/SRR1 are modified and before a subsequent
rfi. This is very very hard to trigger and maybe impossible without SMP
but to keep in mind.

Paulus added some code ages ago to close most of these by using the
MSR:RI bit so that the hash code could detect the situation and branch
to some recovery code, but from memory, while that dealt with missing
D-BATs, we still had a potential window of problem if the kernel text
itself wasn't entirely covered.

Any ways, not a big deal right now, as I said, we really want the BATs
for performances anyways, so we should probably just add some kind of
hack in mmu_mapin_ram() for the time being.

 I must say that all the patches posted (and the device drivers, which haven't
 been posted yet) are tested and working code.

That was my impression too, but in this case, I'm talking about a
potential very hard to hit problem that you may well have never managed
to actually trigger.

 There you can find the hardware interface that supports the IPC mechanism.
 It is made up of a pair of registers to pass data between the processors and a
 pair of control/flags registers.
 The hardware can interrupt the PowerPC side when there is data available for 
 it.

Ok. So the right way to do that would be to have a node purely
representing the HW IPC, unrelated to whatever is running on the
secondary processor.

However, it's ok to have -below- that node, a set of device nodes or a
node with properties or whatever representing the FW in there and the
function it exposes.

That can be discussed later tho. I'm not that keen on having those info
be in the .dts coming with the kernel since those functions essentially
depend on what FW is loaded on the aux. processor.

What might do however is to have a way for that FW itself to provide you
with the nodes and properties for the functions it provides :-) Then you
can have the boot wrapper or the kernel platform init code use some well
defined (and as stable as possible) IPC API to identify the FW there and
expose all that stuff.

Of course that wouldn't work with FW we don't have control on. Can Linux
run on the wii with the original N. FW on the aux. processor ? Can we
detect what is running there ? Do we care ?

 It is what Nintendo calls the Serial Interface (SI) which is a proprietary
 serial hardware to drive the gamepads (and a custom keyboard too, once 
 available
 for an RPG game).

So I would give it a different name than serial then. Make it gpsi
maybe ? (game pad serial interface ?) :-) Or invent something else...

Cheers,
Ben.

  Cheers,
  Ben.
  
 
 Thanks,
 Albert


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Benjamin Herrenschmidt wrote:
On Thu, 2009-11-26 at 16:09 +0100, Albert Herranz wrote:

Are the above OHCI and EHCI special ? If not, there's an existing
binding for that sort of thing, which btw requires properties to
indicate the endianness of the registers and in-memory data structures
etc...

They are a bit special because registers are in reverse little endian format,
must be written in 32-bit chunks, and (all things point to) they have
hardware bugs.

Well.. first what is reverse little endian ? :-) Big endian ?

It's the same case as the register access for the Freescale eSDHC controller,
which is already in the existing sdhci-of driver.

The OHCI driver today has separate flags to control register endianness
and memory based data structures endianness.

I think we also only use 32-bit reads and writes no ? So that should be
covered :-)

There are 8, 16 and 32 bit accesses. We need the same workarounds as present
for the Freescale eSDHC controller.

As for HW bugs, well, as long as we know them we can define a quirk bit
and add the necessary workarounds to the driver :-)

Yes, that's how it was done.
Although it it currently not integrated into sdhci-of. I think that the
specific eSDHC code should be moved to another file, and leave the sdhci-of
with the generic code and the sdhci_of_match table. Then adding a similar
driver would simply consist in adding another file with the sdhci_data
(containing ops and quirks) and adding an entry to the sdhci_of_match table in
sdhci-of.

Do you have a patch somewhere that adds the OCHI and EHCI support btw ?

Yes, too. Although it needs review and cleanup too.

I have a git tree with all the stuff, but it contains only the existing code
previous to the effort of mainlining it:

http://git.infradead.org/users/herraa1/gc-linux-2.6.git/shortlog/refs/heads/mini/gc-linux-2.6.31

Cheers,
Ben.

Thanks,
Albert

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Benjamin Herrenschmidt wrote:
 Good point. I can't even guarantee that the kernel will work reliably
 with nobats :-) At least you really want the kernel .text to be fully
 covered by an IBAT.

 It works with nobats.
 
 But does it work -reliably- ? :-)
 

It does AFAICT. My Wii is a 24x7 linux box although it is not stressed in any 
way usually.

 Any ways, not a big deal right now, as I said, we really want the BATs
 for performances anyways, so we should probably just add some kind of
 hack in mmu_mapin_ram() for the time being.
 

Yup. The idea is to map the first 16MB of MEM1 with a BAT.
Mapping the whole 24MB with BATs may not be possible because we want the 
framebuffer in MEM1 for performance reasons.

 I must say that all the patches posted (and the device drivers, which haven't
 been posted yet) are tested and working code.
 
 That was my impression too, but in this case, I'm talking about a
 potential very hard to hit problem that you may well have never managed
 to actually trigger.
 

I haven't actually, if that applies :)

 There you can find the hardware interface that supports the IPC mechanism.
 It is made up of a pair of registers to pass data between the processors and 
 a
 pair of control/flags registers.
 The hardware can interrupt the PowerPC side when there is data available for 
 it.
 
 Ok. So the right way to do that would be to have a node purely
 representing the HW IPC, unrelated to whatever is running on the
 secondary processor.
 

Totally agreed.

 However, it's ok to have -below- that node, a set of device nodes or a
 node with properties or whatever representing the FW in there and the
 function it exposes.
 
 That can be discussed later tho. I'm not that keen on having those info
 be in the .dts coming with the kernel since those functions essentially
 depend on what FW is loaded on the aux. processor.
 

I think we can leave this for later as you said.

 What might do however is to have a way for that FW itself to provide you
 with the nodes and properties for the functions it provides :-) Then you
 can have the boot wrapper or the kernel platform init code use some well
 defined (and as stable as possible) IPC API to identify the FW there and
 expose all that stuff.
 

Segher was playing with an OF implementation...

 Of course that wouldn't work with FW we don't have control on. Can Linux
 run on the wii with the original N. FW on the aux. processor ? Can we
 detect what is running there ? Do we care ?
 

Yes, it can. And it is done. But I think we don't care/need that in mainline.

 It is what Nintendo calls the Serial Interface (SI) which is a proprietary
 serial hardware to drive the gamepads (and a custom keyboard too, once 
 available
 for an RPG game).
 
 So I would give it a different name than serial then. Make it gpsi
 maybe ? (game pad serial interface ?) :-) Or invent something else...
 

I'd choose gcnsi with a compatible like nintendo,gamecube-si :)

(gcn is the official short abbreviation for the Nintendo GameCube)

 Cheers,
 Ben.
 

Thanks,
Albert

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

On Thu, 2009-11-26 at 22:38 +0100, Albert Herranz wrote:

 Yup. The idea is to map the first 16MB of MEM1 with a BAT.
 Mapping the whole 24MB with BATs may not be possible because we want the 
 framebuffer
 in MEM1 for performance reasons.

How big is the fb ? We have plenty of BATs on these things... so one 16M
for the low mem and one 64M for the high mem, that leaves something
like 6 to manage as much as possible up to the fb :-)

Let's keep 1 or 2 for debug and maybe even BAT map the fb itself, we
still are quite comfortable :-)

That reminds me we still need to re-introduce a clean version of
io_block_mapping (or ioremap flag that does the same) so the platform
code can establish a BAT mapping for a whole bunch of IOs and ioremap
transparenty picks addresses in there. We used to do it, dropped it
mostly because it was done badly (virtual address was hard coded which
caused all sorts of issues) but it shouldn't be hard to do it right and
it would improve perfs a little bit more.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

+/memreserve/ 0x0180 0xe80;	/* memory hole (includes I/O  
area) */

+/memreserve/ 0x1000 0x0004000; /* DSP RAM */


Weird layout... nothing you can do about I suppose.

Out of curiosity, what is that DSP RAM ? Some actual DSP core  
somewhere

in the IO chip setup to use memory from up there ?


It's an actual DSP yes, and it seems it uses that fixed address range
(at the start of the 64MB GDDR3 memory) always.  So we have to stay
away from that memory range.


+   memory {
+   device_type = memory;
+   /* MEM1 + memory hole + MEM2 - firmware/buffers area */
+   reg = 0x 0x133e;
+   };


So we do have a nasty hole here in the middle. How bad it is if you  
try

to just have two ranges in there (ie as if it was discontiguous) ?


Not bad at all.  There is no as if -- it _is_ discontiguous memory,
they are totally different memory technology even.


+   /* Team Twiizers' 'mini' firmware IPC */


Out of curiosity, what are these ? :-)


There is an embedded ARM9 in the Hollywood.  It is the boss of the
system, not the PowerPC.  mini is the name of the code we run on it.

There is a hardware IPC interface between the ARM and the PowerPC (just
a bunch of doorbells and general purpose regs).


Similar comment as before, could the above be dynamically probed ? If
you are not a hacker you may not need that at all to use some linux
based piece of SW on the wii right ?


Yeah.  Well, after any other drivers have been merged, anyway, heh :-)


+   oh...@0d06 {


Why the 1 ?


Right, call them both just ohci please.  Or usb even.


+   PIC1: p...@0d800030 {
+   #interrupt-cells = 1;
+   compatible = nintendo,hollywood-pic;
+   reg = 0x0d800030 0x8;
+   interrupt-controller;
+   interrupts = 14;
+   interrupt-parent = PIC0;
+   };


Ah, a cascaded PIC, fun fun fun


Well at least this cascaded PIC is sane, the root PIC is less so :-P


+   hollywood-ahbp...@0d800064 {
+   compatible = nintendo,hollywood-ahbprot;
+   reg = 0x0d800064 0x4;
+   };


What is this ?


Most of the devices new in Hollywood (AES engine, NAND engine, USB,
SD, etc.) sit on an AHB bus.  The AHBPROT register is used to configure
which of these can be accessed from the PowerPC.

Modern mini always gives us full control.  Also, there is no reason
to single out the AHBPROT reg in the device tree like this, anyway.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree


BTW. If we want to play with clocks, maybe you should look at
my proposed binding for clocks and implementing the clk API :-)


There are no clocks that are configurable from the PowerPC side
(well, maybe things like the USB clocks, but we do not know how).


+   /* Team Twiizers' 'mini' firmware IPC */
+   m...@0d00 {


Although mini is awesome, it isn't hardware, and doesn't
belong in the device tree.


So what is at d000 ?


0c00 is the flipper-compatible stuff
0d00 is the hollywood new devices
0d80 is the same as part of 0d00, but with some extra bits
sometimes.


+   ser...@0d006400 {
+   compatible = nintendo,hollywood-serial;


You might want to pick a more descriptive name for this,
serial is usually understaood to mean RS232.  Which
this isn't.


What is it then ? You definitely want some other name if it's not
classic rs232 style serial.


It's SPI I think, with some extra signals.  It's the gamepads mostly.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

Segher Boessenkool wrote:
 So what is at d000 ?
 
 0c00 is the flipper-compatible stuff
 0d00 is the hollywood new devices
 0d80 is the same as part of 0d00, but with some extra bits
 sometimes.
 

Also, when in Wii native mode, stuff like EXI, SI and AI (which is 
flipper-compatible stuff too) is available at 0d00 only.

 +ser...@0d006400 {
 +compatible = nintendo,hollywood-serial;

 You might want to pick a more descriptive name for this,
 serial is usually understaood to mean RS232.  Which
 this isn't.

 What is it then ? You definitely want some other name if it's not
 classic rs232 style serial.
 
 It's SPI I think, with some extra signals.  It's the gamepads mostly.
 

EXI is SPI.
But SI is a different thingy.

See http://www.int03.co.uk/crema/hardware/gamecube/gc-control.htm .

 
 Segher
 
 

Cheers,
Albert

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

They are a bit special because registers are in reverse little  
endian format,
must be written in 32-bit chunks, and (all things point to) they  
have hardware bugs.


Well.. first what is reverse little endian ? :-) Big endian ?


Nah.  Little-endian, with a 32-bit bus swizzle.  This is not the
same thing as big-endian when not all your registers are 32 bits.

Also, you can only write 32 bits, they don't use byte enables.

As for HW bugs, well, as long as we know them we can define a quirk  
bit

and add the necessary workarounds to the driver :-)


The question is if the device is close enough to OHCI to declare it
as that in the device tree.  I would say yes.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree

There you can find the hardware interface that supports the IPC  
mechanism.
It is made up of a pair of registers to pass data between the  
processors and a

pair of control/flags registers.
The hardware can interrupt the PowerPC side when there is data  
available for it.


Ok. So the right way to do that would be to have a node purely
representing the HW IPC, unrelated to whatever is running on the
secondary processor.


Or you can keep it implicit in the Hollywood control registers.
It is one 512-byte block with lots of things thrown together (and
then mixed up real good).


However, it's ok to have -below- that node, a set of device nodes or a
node with properties or whatever representing the FW in there and the
function it exposes.


That's not really useful though, it's easy to probe for.

What might do however is to have a way for that FW itself to  
provide you

with the nodes and properties for the functions it provides :-)


You get a pointer at the very last word of memory.  It point to an
info header that has everything you need to know (most importantly,
a version identifier).

Of course that wouldn't work with FW we don't have control on. Can  
Linux

run on the wii with the original N. FW on the aux. processor ?


It _can_, but there are no advantages to doing that, and lots and  
lots of

disadvantages, so the plan is to not add support for that in mainline.


Can we
detect what is running there ? Do we care ?


You can detect this for anything that uses a mini-compatible interface.
You shouldn't care for anything else ;-)


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree


Yup. The idea is to map the first 16MB of MEM1 with a BAT.
Mapping the whole 24MB with BATs may not be possible because we  
want the framebuffer

in MEM1 for performance reasons.


How big is the fb ?


A bit more than a megabyte, something like that.


We have plenty of BATs on these things... so one 16M
for the low mem and one 64M for the high mem, that leaves something
like 6 to manage as much as possible up to the fb :-)


The CXe in the gamecube has only four BATs though.

In all code I have done for the XFB, I map it like any other RAM and
dcbst it after writing to it.  Maybe that is slower though, WIMG=0100
might be better.  Dunno.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 04/19] powerpc: wii: device tree