From: Victor M. <Vic...@no...> - 2005-01-17 18:33:54
|
Another way is to use a couple of GPIOs set as inputs and configured with jumpers. One startup, Linux reads these GPIOs to determine if a device is present. Owner must take care to to configure only one though. | GPIO X, | GPIO Y ------+----------+----------- nodev | none | none CF | jumper | none MMF | none | jumper -Vic -----Original Message----- From: Victor Mulyk [mailto:Vic...@no...] Sent: Friday, January 14, 2005 5:18 PM To: 'gum...@li...' Subject: RE: [Gumstix-users] SVN updates Altthough the hardware cannot be queried to determine its type, CF or MMC/SD, you could have some command that writes info to a well defined area in NVM indicating that on subsequent boots, the device type is either CF or MMC. On next boot, the kernel has to configure the GPIOs according to what it reads in NVM. If 0xFFFF (empty), then do nothing. It's not really fool proof, but it might be a start. -Vic -----Original Message----- From: Craig Hughes [mailto:cr...@gu...] Sent: Friday, January 14, 2005 4:21 PM To: gum...@li... Subject: [Gumstix-users] SVN updates I just checked in some audio patches to SVN, and with those, I'm getting pretty close to cutting a new "official" release to post on sf.net. A couple questions though, which people out there may have some thoughts on: 1. The ucb1400 chip seems to reset itself from time to time, losing the values which had been programmed into its registers, such as mixer volumes, which builtin filters are turned on or off, and the thing which switches on support for audio at bitrates other than 48000. It's quite annoying, because there doesn't appear to be any signal sent to the PXA's AC97 unit, so I don't know that I need to reprogram the registers when they get nuked. I'm actually not entirely sure that the PXA isn't signalling the rest dy dropping nACRESET to the chip -- but I can't see anything in the docs for either the UCB1400 or the PXA which says that this will be happening. It doesn't seem to be a power saving mode on the ucb1400 kicking in or anything, because it happens sometimes in the middle of playing something. Anyone have any thoughts about what might be going on here? I'll get Gordon to take a look at the hardware and verify there isn't noise plopping on the nACRESET line... 2. Hardware detection. Right now, the various kernel modules which provide drivers for bits of hardware don't detect whether that hardware is really there or not, they just go ahead and load themselves, re-programming GPIO alternate function modes and such as required if that hardware were in fact there. That's been fine so far, because no 2 pieces of hardware conflict with each other. However, Compact Flash uses the same GPIOs as the onboard MMC card on the -F gumstix, so with the current system, I can't have one software image which will work for both MMC and Compact Flash gumstix, because loading one module will break the other module. Any thoughts on how best to handle this? Uh, I think it's just those two for now. C ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |