This list is closed, nobody may subscribe to it.
2004 |
Jan
(103) |
Feb
(56) |
Mar
(25) |
Apr
(38) |
May
(24) |
Jun
(20) |
Jul
(22) |
Aug
(23) |
Sep
(1) |
Oct
(24) |
Nov
(8) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(14) |
Feb
(23) |
Mar
(7) |
Apr
(23) |
May
(11) |
Jun
(1) |
Jul
(29) |
Aug
(7) |
Sep
|
Oct
|
Nov
(8) |
Dec
(11) |
2006 |
Jan
|
Feb
(24) |
Mar
(22) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(2) |
Dec
(4) |
2007 |
Jan
(1) |
Feb
(4) |
Mar
(5) |
Apr
(10) |
May
|
Jun
(5) |
Jul
(3) |
Aug
(3) |
Sep
(6) |
Oct
(11) |
Nov
(3) |
Dec
(4) |
2008 |
Jan
(8) |
Feb
(19) |
Mar
(43) |
Apr
(27) |
May
(15) |
Jun
(10) |
Jul
(39) |
Aug
(9) |
Sep
(12) |
Oct
(15) |
Nov
(14) |
Dec
(4) |
2009 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(15) |
2010 |
Jan
(2) |
Feb
(7) |
Mar
|
Apr
(16) |
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
|
Oct
(9) |
Nov
(2) |
Dec
|
2011 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(4) |
May
(2) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(5) |
Dec
(3) |
2012 |
Jan
(12) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2017 |
Jan
(1) |
Feb
(2) |
Mar
(7) |
Apr
(2) |
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Maarten t. H. <ma...@tr...> - 2008-03-15 13:13:45
|
Hi, Attached are the modifications I had to make to get my PS/2 to GC keyboard adapter working properly. The adapter from "May Flash" and on the box it is called "GC Keyboard & PS Controller Adapter 2in1" (it can convert PSX joypads as well). There are two parts to the modifications: - getting the key codes from the raw data - a few changes in the key mapping The raw data was located in different nibbles as in the original code. I don't know if my adapter is different from the other keyboards/adapters, whether the data format is different in Wii mode compared to GC mode or whether the old code was simply broken. The old code for the third key does look broken: key[2] = (raw[0] << 4) & 0xFF; key[2] |= (raw[1] << 28) & 0xFF; The second statement has no effect, but if you replace "<<" by ">>", it starts making sense. Since this only makes a difference if 3 keys are pressed simultaneously, it's likely nobody noticed it, so the rest of it might still be correct. If you look at the diff, the key mapping looks totally different, but that is because I had to realign the columns; in fact there are only a few changes: 0A: scroll Lock 36: PrtSc and numpad-slash 37: numpad-star 39: semicolon 3A: apostrophe 3F: backslash 53: caps Lock cursors: 36 and listed I'm using a US/International PS/2 PC keyboard, so differences are probably not due to a PC keyboard layout difference. I am looking for someone with a different keyboard/adapter to test whether this new code works with it. And if it doesn't, if there is some way to auto-detect the keyboard type (maybe using other parts of the raw data). Bye, Maarten |
From: Daniel T. <da...@re...> - 2008-01-03 08:00:11
|
On Wed, 2008-01-02 at 23:21 +0000, Albert Herranz wrote: > I can't see any advantage over the current solution in using a fourcc for= the > visual. It would help if applications were written to expect a fourcc cod= e, but > they aren't so you end up even in a worst situation. It's not a great step forward. I just don't really like breaking the applications that support GC (i.e. so they don't run on normal PPC). If I get really precious about it I'm sure I could identify a 'cube from files in /proc. > On the other hand, one thing that I have in mind and could make linux > applications directly useable using the cube's framebuffer is building a = virtual > rgb framebuffer at the kernel level using the "recently" merged deferred = io > framework. Creating a virtual RGB frame buffer was my preferred solution for the 'problem' but it seemed easier to be efficient within userspace since damage tracking is easier. I had not come across Documentation/fb/deferred_io.txt before. I'll have a good read of this, having a 'real' framebuffer implementation is quite desirable to save a lot of userspace conversions. It would be a great step on the way to good X with the Xvideo extension (for efficient YUV access for decoders) which has long been my ambition. I suspect I will never actually find the time to write the Xvideo stuff though. Sigh. --=20 Daniel Thompson <da...@re...> |
From: Albert H. <alb...@ya...> - 2008-01-02 23:22:14
|
Daniel Thompson writes: > I've been fiddling again looking at porting a few more frame buffer code > to operate with the 'cube not-RGB frame buffer. It struck me that > instead of lying about the visual reporting it with a fourcc code would > be quite useful for detecting and adapting to strange pixel formats (and > the resulting code could be ported to other weird hardware without > conditional compilation). > > The attached patch shows what I have in mind. > Hi Daniel, I can't see any advantage over the current solution in using a fourcc for the visual. It would help if applications were written to expect a fourcc code, but they aren't so you end up even in a worst situation. Maybe if the standard Linux kernel starts using a fourcc to specify a visual then we could use it in a useful way. On the other hand, one thing that I have in mind and could make linux applications directly useable using the cube's framebuffer is building a virtual rgb framebuffer at the kernel level using the "recently" merged deferred io framework. Cheers, Albert |
From: Daniel T. <da...@re...> - 2007-12-23 11:58:12
|
Hi Folks I've been fiddling again looking at porting a few more frame buffer code to operate with the 'cube not-RGB frame buffer. It struck me that instead of lying about the visual reporting it with a fourcc code would be quite useful for detecting and adapting to strange pixel formats (and the resulting code could be ported to other weird hardware without conditional compilation). The attached patch shows what I have in mind. -- Daniel Thompson <da...@re...> |
From: James W. <jk...@ho...> - 2007-10-16 00:10:47
|
I have the Gecko and it can be used for just a couple of things.=20 Homebrew Games for Gamecube can be run from it using SDLoad in = combination with an Action Replay and a crazy long code. I've done this. = Animal Crossing 2? for the Japanese market offered the ability to = take screen shots and save them directly to the SD card so they could be = viewed and shared through your computer. I have not done this.=20 My understanding of why standard game saves don't work is SD cards = and the gamecube memory card while electrically are very similar they = use a different "Command Set" for reading and writing to their memory. = At a really basic level (abstraction leaks) it's like IDE and SCSI both = are harddrives that read and write data but they are not interchangable = because their command set is different (and their wiring, I know). Some homebrew games can read and write on SD cards because they are = using their own programming calls to access the memory cards. |
From: Groepaz <gr...@gm...> - 2007-09-22 16:24:49
|
On Samstag 22 September 2007, Joe Mason wrote: > On 9/22/07, TD <top...@go...> wrote: > > So I tried this, but it wouldn't let me do it. The SD card appears as > > unavailable. Everything I can find on the subject tells me that the SD > > adaptor (Gecko) /can't/ be used for game saves. So, how do I get the > > saves onto the SD card? SDLoad? Modchip? Something else? Were you > > wrong - can this even be done? :P > > Really? What else would it be *for*? the sd-gecko was used by one japanese game for letting users trade items (was it animal-crossing? mmmh forgot). it's completely unsupported from anything else. -- http://www.hitmen-console.org http://www.gc-linux.org/docs/yagcd.html http://www.pokefinder.org http://ftp.pokefinder.org For most girls, talk DXPP, DYPP, Plasma, FLI, and rasterbars - its a real winner. |
From: Joe M. <jo...@no...> - 2007-09-22 16:20:12
|
On 9/22/07, TD <top...@go...> wrote: > So I tried this, but it wouldn't let me do it. The SD card appears as > unavailable. Everything I can find on the subject tells me that the SD > adaptor (Gecko) /can't/ be used for game saves. So, how do I get the > saves onto the SD card? SDLoad? Modchip? Something else? Were you > wrong - can this even be done? :P Really? What else would it be *for*? Well, I was just assuming - I've never used one myself. Sorry if I steered you wrong. Joe |
From: Joe M. <jo...@no...> - 2007-09-13 14:36:46
|
On 9/12/07, TD <top...@go...> wrote: > I recently swapped my PAL games for NTSC(USA) to take advantage of the > progressive scan output. What I didn't know is that the NTSC games > don't read my PAL save data. Obviously most people would give up / swap > back, but surely this is the perfect reason for me to try Linux on my > Gamecube. :D I would /imagine/ that there is some game-specific ID > somewhere, that the game checks for, and if it's not found, it creates a > new file. For example, I have both PAL and NTSC Mario Kart saves on the > same card. If I could change the ID, I'd be laughing (possibly). You might be better off getting a Memory Card/SD adaptor (no idea how much they cost), sticking it in slot B, and copying your saves to a standard SD card. Then you should, in theory, be able to read and edit them in any computer with an SD reader. Joe |
From: Anders M. <amm...@cc...> - 2007-08-24 04:07:14
|
Hello, IBM has contributed "official" paired singles support in the form of the PPC750CL CPU, so there's probably little reason to maintain the separate repository any longer. See the thread starting at <http://sourceware.org/ml/binutils/2007-08/msg00330.html>. IBM are also in the process of contributing paired singles support for GCC, but the patch hasn't been approved yet. The most recent version is posted at <http://gcc.gnu.org/ml/gcc-patches/2007-08/ msg01531.html>. Regards, Anders Montonen |
From: PeterPan <pet...@ko...> - 2007-07-05 08:34:18
|
How about the bandwidth? -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: gc-...@li... [mailto:gc-...@li...] =B4=FA=B1=ED = Groepaz =B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA7=D4=C25=C8=D5 15:18 =CA=D5=BC=FE=C8=CB: gc-...@li... =D6=F7=CC=E2: Re: [Gc-linux-devel] Create a network adapter through the = slot? On Thursday 05 July 2007 08:19, PeterPan wrote: > Hi! > > > > I wonder if it's possible to create a network adapter (hardware) which = is > plug in one slot of GameCube. Because Wii in GC-mode not have a = network > adapter you know. Maybe we can make a usb adapter to connect to a = wireless > network? > > > > Is it possible?? sounds possible, why not .... you'd "only" have to design the hardware, = and=20 write a driver :=3DP --=20 http://www.hitmen-console.org http://www.gc-linux.org/docs/yagcd.html http://www.pokefinder.org http://ftp.pokefinder.org Eine wirklich gute Idee erkennt man daran, dass ihre Verwirklichung von vorne=20 herein ausgeschlossen erscheint.=20 <Albert Einstein> -------------------------------------------------------------------------= This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Gc-linux-devel mailing list Gc-...@li... https://lists.sourceforge.net/lists/listinfo/gc-linux-devel |
From: Groepaz <gr...@gm...> - 2007-07-05 07:17:38
|
On Thursday 05 July 2007 08:19, PeterPan wrote: > Hi! > > > > I wonder if it's possible to create a network adapter (hardware) which is > plug in one slot of GameCube. Because Wii in GC-mode not have a network > adapter you know. Maybe we can make a usb adapter to connect to a wireless > network? > > > > Is it possible?? sounds possible, why not .... you'd "only" have to design the hardware, and write a driver :=P -- http://www.hitmen-console.org http://www.gc-linux.org/docs/yagcd.html http://www.pokefinder.org http://ftp.pokefinder.org Eine wirklich gute Idee erkennt man daran, dass ihre Verwirklichung von vorne herein ausgeschlossen erscheint. <Albert Einstein> |
From: PeterPan <pet...@ko...> - 2007-07-05 06:30:40
|
Hi! I wonder if it's possible to create a network adapter (hardware) which is plug in one slot of GameCube. Because Wii in GC-mode not have a network adapter you know. Maybe we can make a usb adapter to connect to a wireless network? Is it possible?? Xuesong Guo. |
From: Groepaz <gr...@gm...> - 2007-06-18 15:04:27
|
On Monday 18 June 2007 16:56, abderezak amara wrote: > there is some problems at this time: > - no support of the wii remote ( there is a linux driver for it) this can not be fixed at this point. the existing linux driver will not help either - since gc-linux runs in the gamecube sandbox, which has not been cracked yet, the additional peripherials like bluetooth are not accessable > - many error on the boot dialog ( slow the boot ) strange, what kind of errors are these? i haven't seen anything unexpected (using a non modified MFE disk). > - change the resolution for showing subtitles on some divx the gamecube/wii only supports one fixed resolution. > i dont ask anyone to do this but i need > gc-linux sources and mfe sources , those are on the gc-linux cvs -- http://www.hitmen-console.org http://www.gc-linux.org/docs/yagcd.html http://www.pokefinder.org http://ftp.pokefinder.org When you take stuff from one writer, it's plagiarism; but when you take it from many writers, it's research. <Wilson Mizner> |
From: abderezak a. <abd...@ho...> - 2007-06-18 14:57:04
|
i run the mfe distro on wii there is some problems at this time: - no support of the wii remote ( there is a linux driver for it) - many error on the boot dialog ( slow the boot ) - change the resolution for showing subtitles on some divx i dont ask anyone to do this but i need gc-linux sources and mfe sources , some indication for what must be cahnged to avoir linux boot error messages _________________________________________________________________ Windows Live Spaces : créez votre blog à votre image ! http://www.windowslive.fr/spaces |
From: Groepaz <gr...@gm...> - 2007-04-29 22:56:29
|
On Monday 30 April 2007 00:52, Rob Reilink wrote: > Regarding the port name confusion: I had a look at the wrong cover :- > S. That's what happens when your 'cube is disassembed. Actually, the > high speed port might be very interesting as well. The pin > description from YAGCD resembles that of standard SDRAM IC's. It > might be possible to expand the GC ARAM. However, I haven't got a > clue on how to use this in software, or what size of SDRAM is > supported. Is there perhaps extra RAM in the GB Player? its just memory mapped... look at the "external interfaces" patent, and also check some N64 docs - the n64 ram expansion uses exactly the same interface. -- http://www.hitmen-console.org http://www.gc-linux.org/docs/yagcd.html http://www.pokefinder.org http://ftp.pokefinder.org Hard work has a future payoff. Laziness pays off now. |
From: Rob R. <ro...@re...> - 2007-04-29 22:52:55
|
It would be great if indeed this appears to be true. In that case, three different devices (Ethernet, SD card, USB) can be connected to all three EXI busses, so the system performance would be maximized. I'll design a version of my ethernet controller to fit onto the Serial Port 2. It will be soldered onto the mainboard, so it should be usable on GC's without this connector as well (I think they just removed the connector, the pinout should still be on the mainboard). Meanwhile, if someone has a GameCube running Linux with access to the mainboard, it should be able to confirm that it is on the EXI2 bus by measuring the CS pin voltage and poking 0x0 and 0x380 to 0xCC006828 to enable/disable all CS pins on the EXI2 channel. Regarding the port name confusion: I had a look at the wrong cover :- S. That's what happens when your 'cube is disassembed. Actually, the high speed port might be very interesting as well. The pin description from YAGCD resembles that of standard SDRAM IC's. It might be possible to expand the GC ARAM. However, I haven't got a clue on how to use this in software, or what size of SDRAM is supported. Is there perhaps extra RAM in the GB Player? Cheers, Rob Op 30-apr-2007, om 4:32 heeft Albert Herranz het volgende geschreven: > Albert Herranz <albert_herranz <at> yahoo.es> writes: >> 1514 is the "Serial Port 2" connector. >> So that text is claiming that "Serial Port 2" is related to the >> EXI0 bus, where >> the Boot ROM is located. > > Uhmm.. I think I've messed it up. > > 1514 is the "Serial Port 1" connector. > 1520 is the "Serial Port 2" connector. > So "Serial Port 1" should be EXI0 (as we know from the BBA). And > "Serial Port 2" > should be EXI2 from the drawings (FIG 26 and FIG 15C). > > Cheers, > Albert > > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gc-linux-devel mailing list > Gc-...@li... > https://lists.sourceforge.net/lists/listinfo/gc-linux-devel |
From: Albert H. <alb...@ya...> - 2007-04-29 18:32:56
|
Albert Herranz <albert_herranz <at> yahoo.es> writes: > 1514 is the "Serial Port 2" connector. > So that text is claiming that "Serial Port 2" is related to the EXI0 bus, where > the Boot ROM is located. Uhmm.. I think I've messed it up. 1514 is the "Serial Port 1" connector. 1520 is the "Serial Port 2" connector. So "Serial Port 1" should be EXI0 (as we know from the BBA). And "Serial Port 2" should be EXI2 from the drawings (FIG 26 and FIG 15C). Cheers, Albert |
From: Albert H. <alb...@ya...> - 2007-04-29 17:55:52
|
Groepaz <groepaz <at> gmx.net> writes: > > I can't tell if it is related to EXI or not. (But my guess is that it is > > not). > > mmmh, maybe that one is related to the mysterious "UART" reference? (its even > in yagcd, god knows where i got that one from =P) In US patent 6,609,977 (now 7,134,960) there is a reference which could confirm your theory: "A multi-pin modem connector 1514 is used to connect the graphics and audio processor 114 to an external or internal modem. The boot ROM/real time clock 134 is coupled to the modem connector 1514 and shares its bus for communication with the graphics and audio processor 114." 1514 is the "Serial Port 2" connector. So that text is claiming that "Serial Port 2" is related to the EXI0 bus, where the Boot ROM is located. Cheers, Albert |
From: Groepaz <gr...@gm...> - 2007-04-28 22:43:47
|
On Sunday 29 April 2007 00:32, Albert Herranz wrote: > No, I think he's talking about "Serial Port 2", the connector that was > removed on recent hardware revisions of the console. oh...yes ofcourse :) > I can't tell if it is related to EXI or not. (But my guess is that it is > not). mmmh, maybe that one is related to the mysterious "UART" reference? (its even in yagcd, god knows where i got that one from =P) -- http://www.hitmen-console.org http://www.gc-linux.org/docs/yagcd.html http://www.pokefinder.org http://ftp.pokefinder.org I can make it crash! |
From: Albert H. <alb...@ya...> - 2007-04-28 22:32:50
|
Groepaz <groepaz <at> gmx.net> writes: > you are talking about the "high speed port" right? if i recall correctly thats > not an exi device, it is memory mapped. there should be some vague info in > yagcd somewhere, but it was never investigated further since nothing besides > the gba player used it. No, I think he's talking about "Serial Port 2", the connector that was removed on recent hardware revisions of the console. I can't tell if it is related to EXI or not. (But my guess is that it is not). Cheers, Albert |
From: Groepaz <gr...@gm...> - 2007-04-28 13:24:35
|
On Saturday 28 April 2007 07:46, Rob Reilink wrote: > Hi, > > Yet another question, this time regarding the EXI hardware. My GC has > got a 'serial port 2', I believe this is P8 as described in 2.4.1.2 > of YAGCD. For my hardware, I'd like to use ports on different EXI > channels, so each device can use its channel for 100%. Now, I'm > wondering to which EXI channel/device this P8 is connected. It's not > in the EXI device listing in 10.2, and I can't seem to find it > enywhere else. > > Unfortunately, I haven't got Linux running on my 'cube yet because > I'm still waiting for some hardware to build my own 'modchip' (I > haven't got my BBA or PSO here in Australia where I'm staying for a > few moths). Therefore, I'm not able to just measure CS and poke > around in the EXI registers. Does anyone have more info? you are talking about the "high speed port" right? if i recall correctly th= ats=20 not an exi device, it is memory mapped. there should be some vague info in= =20 yagcd somewhere, but it was never investigated further since nothing beside= s=20 the gba player used it. =2D-=20 http://www.hitmen-console.org http://www.gc-linux.org/docs/yagcd.html http://www.pokefinder.org http://ftp.pokefinder.org Wer sp=E4ter bremst f=E4hrt l=E4nger schnell |
From: Rob R. <ro...@re...> - 2007-04-28 05:47:18
|
Hi, Yet another question, this time regarding the EXI hardware. My GC has got a 'serial port 2', I believe this is P8 as described in 2.4.1.2 of YAGCD. For my hardware, I'd like to use ports on different EXI channels, so each device can use its channel for 100%. Now, I'm wondering to which EXI channel/device this P8 is connected. It's not in the EXI device listing in 10.2, and I can't seem to find it enywhere else. Unfortunately, I haven't got Linux running on my 'cube yet because I'm still waiting for some hardware to build my own 'modchip' (I haven't got my BBA or PSO here in Australia where I'm staying for a few moths). Therefore, I'm not able to just measure CS and poke around in the EXI registers. Does anyone have more info? Cheers, Rob |
From: Albert H. <alb...@ya...> - 2007-04-25 18:28:44
|
Rob Reilink <rob <at> reilink.net> writes: > I've picked up this excellent idea, and designed a schematic and PCB > for this USB host interface. [...] Nice to hear from you again, Rob. > Now the problem is, with both the MAX3421 and the ENC28J60, 0x0000 > means just 'read register 0', which could be anything (might be 0x00 > after reset?). Also, both these parts do not have a 'Request ID' > command, so there's no straight-forward way to probe them. So how do > we identify these parts? Or could there be an easy way for the user > to set the exi channel/device manually? Module parameters? What about > the ethernet controller that might be used to mount the root fs? The current EXI driver is able to handle both "normal" EXI devices (which can answer to an exi_get_id() command) and "custom" EXI devices, like MMC/SD cards, the future USB adapter and your new SPI-based ethernet interface. "Custom" EXI devices have to be registered with an EXI identifier of EXI_ID_NONE. They will be initially matched against channel/device only. The driver probe function is responsible for checking if the device is really a matching device, and in that case it returns 0. Look at the MMC/SD card driver for example. It probes if a MMC/SD card is available by trying the card initialization sequence. If it fails, it assumes no card is there and the driver forgets about the device. This could lead to problems in the future if a driver probe sequence for one device can destroy another one. But, for now I think we can go ahead with what we have. Cheers, Albert |
From: Rob R. <ro...@re...> - 2007-04-25 11:32:20
|
I've picked up this excellent idea, and designed a schematic and PCB for this USB host interface. Links to the schematic and PCB are on the wiki: http://www.gc-linux.org/wiki/EXI:USBHostAdapter . I just have to wait for the company where I'm doing my internship at the moment to do their next PCB panel, then I can stick some of my PCB's on for free. Also, I'm currently working on a ethernet controller to replace the hard-to-get BBA. It will use Microchip's ENC28J60 SPI ethernet controller. I'm starting with the Linux driver modules, but I'm not sure how to do the probing/detection. The current EXI driver does (if I understand the source correctly): -select device -output 0x0000 (request ID) -read 16 bit ID -deselect device -if the read ID is 0 (which happens with MMC/SD cards apparently), and the device is on one of the memory cards, EXI_ID_NONE (or something) is returned, and all exi-device drivers claiming to support that ID are then probed. Now the problem is, with both the MAX3421 and the ENC28J60, 0x0000 means just 'read register 0', which could be anything (might be 0x00 after reset?). Also, both these parts do not have a 'Request ID' command, so there's no straight-forward way to probe them. So how do we identify these parts? Or could there be an easy way for the user to set the exi channel/device manually? Module parameters? What about the ethernet controller that might be used to mount the root fs? I guess there are more experienced driver programmers on this list who could tell me the way to go. Regards, Rob Reilink Op 20-mrt-2007, om 3:26 heeft Albert Herranz het volgende geschreven: > PATx box <patx_boite <at> hotmail.com> writes: >> I read a bit this morning before ordering parts and the MAX3421 >> will be >> needed instead of the MAX3420 witch is for peripheral devices >> only ... > > Yes, I noticed that too. > >> I ve ordered parts and i will make a shematic based on figure 21 >> (datasheet) >> and the memcard pinout... > > Remember to wire up the irq line too. We'll need that. > > My biggest concern is that the controller doesn't support a 32MHz > clock > (according to the data sheet it supports a maximum of 26MHz), so > we'll have to > run the SPI bus at 16MHz, unless someone figures out how to program > the EXI > interface to a intermediate clock speed. > > I think it would be a good idea to keep all the details of this > mini-project on > the project's wiki. I've started a page specially for that: > > http://www.gc-linux.org/wiki/EXI:USBHostAdapter > > Cheers, > Albert > > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Gc-linux-devel mailing list > Gc-...@li... > https://lists.sourceforge.net/lists/listinfo/gc-linux-devel |
From: Albert H. <alb...@ya...> - 2007-03-19 17:28:27
|
PATx box <patx_boite <at> hotmail.com> writes: > I read a bit this morning before ordering parts and the MAX3421 will be > needed instead of the MAX3420 witch is for peripheral devices only ... Yes, I noticed that too. > I ve ordered parts and i will make a shematic based on figure 21 (datasheet) > and the memcard pinout... Remember to wire up the irq line too. We'll need that. My biggest concern is that the controller doesn't support a 32MHz clock (according to the data sheet it supports a maximum of 26MHz), so we'll have to run the SPI bus at 16MHz, unless someone figures out how to program the EXI interface to a intermediate clock speed. I think it would be a good idea to keep all the details of this mini-project on the project's wiki. I've started a page specially for that: http://www.gc-linux.org/wiki/EXI:USBHostAdapter Cheers, Albert |