cache init problems - (non multi-mimed mail )
Hi.. I have a problem for porting PPC-BOOT to STT755EMC. Here is my BD spec. CPU: MPC750 ( main core ) + MPC8260 ( companion only ) L2 cache: 1M SDRAM on 60x bus: 64M SDRAM on Local bus: 32M FLASH: 8MB 10/100 Base T port on FFC2 Dual RS232 port residing SMC1 SMC2. The problem is cache. Whenever boot process reach at cache init code, all system is stoped!. No more progress! But if the cache init code is commented out from boot codes, Everything's fine except perfomence. I don't know why the code doesn't work. please help.. Here is the code i used. /* icache_enable */ mfspr r3, HID0 li r5, HID0_ICFI|HID0_ILOCK andcr3, r3, r5 ori r3, r3, HID0_ICE ori r5, r3, HID0_ICFI mtspr HID0, r5 mtspr HID0, r3 isync /* dcache_enable */ mfspr r3,HID0 ori r3,r3,HID0_DCE | HID0_DCFI sync mtspr HID0,r3 Thanks ps ) sorry for my previous Multi-mimed mail. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
initrd problems
Hello, I am unable to boot up my linux with my ramdisk image. Board: MPC8260 ADS Kernel: 2.4.1 PPC Boot: 2.0.0 When I boot up the kernel without ramdisk, the same kernel image is booting up fine. But when I use a ramdisk ## Booting image at 0010 ... Image Name: Embedix for MPC8260ADS Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:531861 Bytes = 519.4 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0020 ... Image Name: Simple ramdisk Image Image Type: PowerPC Linux RAMDisk Image (uncompressed) Data Size:4194304 Bytes = 4 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 00b5e000, end 00f5e000 ... OK I dont get any console output after this. I am not sure that it hangs, because I see the ethernet link led's getting reset (same behaviour in normal bootup) and the SCC controller leds getting enabled. (same behaviour in normal boot up). The command line passing into the kernel is: root=/dev/ram0 init=/linuxrc rw I believe PPC boot will pass the ramdisk start and end address along with the above command line. I have verified this also by checking the log_buff after I had reset the board. 00145664: 3c343e72 343a2030 30623565 3030300a4r4: 00b5e000. 00145674: 3c343e54 6f74616c 206d656d 6f7279204Total memory 00145684: 3d203136 4d423b20 7573696e 67203634= 16MB; using 64 00145694: 6b422066 6f722068 61736820 7461626ckB for hash tabl 001456a4: 65202861 74206330 31383030 3030290ae (at c018). 001456b4: 3c343e4c 696e7578 20766572 73696f6e4Linux version 001456c4: 20322e34 2e312028 726f6f74 40656d62 2.4.1 (root at emb 001456d4: 65646978 29202867 63632076 65727369edix) (gcc versi 001456e4: 6f6e2032 2e39352e 33203230 30313033on 2.95.3 200103 001456f4: 31352028 72656c65 61736529 2920233815 (release)) #8 00145704: 30205765 64204170 72203233 2031353a0 Wed Apr 23 15: 00145714: 35393a32 37205554 43203230 30330a3c59:27 UTC 2003. 00145724: 343e4f6e 206e6f64 65203020 746f74614On node 0 tota 00145734: 6c706167 65733a20 34303936 0a3c343elpages: 4096.4 00145744: 7a6f6e65 2830293a 20343039 36207061zone(0): 4096 pa 00145754: 6765732e 0a3c343e 7a6f6e65 2831293ages..4zone(1): 00145764: 20302070 61676573 2e0a3c34 3e7a6f6e 0 pages..4zon 00145774: 65283229 3a203020 70616765 732e0a3ce(2): 0 pages.. 00145784: 343e4b65 726e656c 20636f6d 6d616e644Kernel command 00145794: 206c696e 653a202f 6465762f line: /dev/ 001457a4: 001457b4: 001457c4: 001457d4: The r4 register which points to the ramdisk start is also correct. So PPC boot is passing the ramdisk parameter properly. I unable to get any more output from the log_buff. Also when I tried using a compressed image of the ramdisk, PPC boot failed to uncompress it. Can I provide a compressed image of the ramdisk to PPCBoot.? Is there anything wrong that I am doing in setting up the ramdisk environment ? Any pointers or suggestions would be very useful. Thank you. Regards, Sriram N ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cache init problems - (non multi-mimed mail )
In message 200304240452.h3O4qrq04070 at www.cnetia.com you wrote: I have a problem for porting PPC-BOOT to STT755EMC. Do not spend effort for PPCBoot. PPCBoot is a dead project, development has been discontiuned half a year ago. Please use the successort project U-Boot instead. You better post U-Boot related questions on the u-boot-users mailing list. Chances for helpful replies are better then. Here is the code i used. /* icache_enable */ mfspr r3, HID0 li r5, HID0_ICFI|HID0_ILOCK andcr3, r3, r5 ori r3, r3, HID0_ICE ori r5, r3, HID0_ICFI mtspr HID0, r5 mtspr HID0, r3 isync /* dcache_enable */ mfspr r3,HID0 ori r3,r3,HID0_DCE | HID0_DCFI sync mtspr HID0,r3 Why don't you use the existing code which works fine on a couple of systems? The dcache_enable code you present here is different from the code present in PPCboot and in U-Boot. It seems you tried to optimize it, but without understanding it. Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de If the facts don't fit the theory, change the facts. -- Albert Einstein ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
initrd problems
In message 3EA776EC.3090805 at tataelxsi.co.in you wrote: ## Booting image at 0010 ... Image Name: Embedix for MPC8260ADS Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:531861 Bytes = 519.4 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0020 ... Image Name: Simple ramdisk Image Image Type: PowerPC Linux RAMDisk Image (uncompressed) Data Size:4194304 Bytes = 4 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 00b5e000, end 00f5e000 ... OK Try using higher load addresses, i.e. load the kernel at 0x0020 and the ramdisk at 0x0040. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de A mouse is an elephant built by the Japanese. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Library size
Hi all, I am working on custome design board based on IBM power PC 405. We have seen the libraries like : ld-2.2.3.so libcrypt-2.2.3.so ld.so.1 libpthread-0.9.so libSegFault.so libc-2.2.3.so in the filesystem, lib folder. libc-2.2.3.so is taking arounr 1.5MB space. Is there any way to reduce the size of this file and whats the use of this file. Thanks Regards, Rakesh Jagota ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Library size
Hi Look at www.uclibc.org cedric -Original Message- From: owner-linuxppc-embedded at lists.linuxppc.org [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Rakesh Jagota Sent: Thursday, April 24, 2003 10:20 AM To: linuxppc-embedded at lists.linuxppc.org Subject: Library size Hi all, I am working on custome design board based on IBM power PC 405. We have seen the libraries like : ld-2.2.3.so libcrypt-2.2.3.so ld.so.1 libpthread-0.9.so libSegFault.so libc-2.2.3.so in the filesystem, lib folder. libc-2.2.3.so is taking arounr 1.5MB space. Is there any way to reduce the size of this file and whats the use of this file. Thanks Regards, Rakesh Jagota ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I2C having issues
- Original Message - From: Pagnotta, Chris [EMAIL PROTECTED] To: linuxppc-embedded at lists.linuxppc.org Sent: Tuesday, April 22, 2003 8:48 PM Subject: I2C having issues I tried a couple of things to to get the i2c device up and working and I am stil having some problems. The I2C registers are mappped to internal memory at address 0xEF60500. I cannot write to this address and read back the same values. Here is the output from just the ep405 bootloader. Chris, there was a bug in 2.4.17 which we are using, where a typo in #if caused the I2C to be in power-save mode. This gave the symptoms of the I2C module not responding at all. This is the diff: Index: ppc4xx_setup.c === RCS file: /P2/Hawkeye557/CVS_Repository/Hawkeye557/Linux-405GP/Talon-MVL/linux-2.4.17_ mvl21-talonbsp/arch/ppc/kernel/ppc4xx_setup.c,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.3 diff -c -r1.1.1.2 -r1.1.1.3 *** ppc4xx_setup.c 3 Jan 2003 17:42:34 - 1.1.1.2 --- ppc4xx_setup.c 4 Apr 2003 14:23:01 - 1.1.1.3 *** *** 104,111 value |= CPM_GPIO0; #endif ! #if !defined(CONFIG_PPC405_I2C_ADAP) ! value |= CPM_IIC0; value |= CPM_IIC1; #endif --- 104,111 value |= CPM_GPIO0; #endif ! #if !defined(CONFIG_I2C_PPC405_ADAP) !value |= CPM_IIC0; value |= CPM_IIC1; #endif -- Mark Powell, Senior Software Engineer, Primagraphics Limited New Cambridge House, Litlington, nr.Royston, Herts, SG8 0SS, UK Tel. +44 1763 85, Fax. 853324, http://www.primagraphics.co.uk ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Library size
Search the list archives for Library Optimization. There a ways to reduce the size of a glibc C library, or you should us an alternative C library such as uClibc. --Mark Rakesh Jagota wrote: Hi all, I am working on custome design board based on IBM power PC 405. We have seen the libraries like : ld-2.2.3.so libcrypt-2.2.3.so ld.so.1 libpthread-0.9.so libSegFault.so libc-2.2.3.so in the filesystem, lib folder. libc-2.2.3.so is taking arounr 1.5MB space. Is there any way to reduce the size of this file and whats the use of this file. Thanks Regards, Rakesh Jagota ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux DMA transfer (applied to 8245)
Hi , I am implementing DMA transfers initiated by the processor for the MPC8245. Since the standard pci_alloc_consistent take only a pci_dev structure but no addresses, I added a configuration function to set the target address (PCI) and the other parameters. I can see that the DMA transfer is started, and finished (an interrupt is generated) but I don't see the data copied on the target device ( DSP with a 4 MB memory window on PCI bus.) My question is : What type of addreess must I give to configure the DMA controller. Are there also caching issues that may prevent good read/write operation s? I suppose that the flushing og the cache done in pci_alloc_consistent is enough. Thanks -- Benoit Callebaut Software Development Engineer Barco | Control Rooms Noordlaan 5, 8520 Kuurne, Belgium Tel +32(0)56 36 84 28 Fax +32(0)56 36 86 05 mailto:benoit.callebaut at barco.com http://www.barcocontrolrooms.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
booting MGT5100?
Thanks for the info! I'm also using an icecube board. I'll grab the code from mv when you post it there. Do you use a bootloader or do you just use dbug to run a zImage? -Chris H. On Wed, Apr 23, 2003 at 09:55:42PM +, Chris Heintzelman wrote: I noticed that a few months ago someone mentioned booting Linux on one of these boards (MGT5100). There didn't seem to be much discussion though; I have one of these boards and would also like to boot linux on it, I'm wondering if anyone can point me to a good starting point on this? Any help is appreciated. I've got a toolchain and kernel built but am having no luck with it. Thanks, Chris H. I've been working with Kent Borg to bring up linux on the mgt5100. As Peter said, they're running it on an icecube, while I have a glacier system. The serial driver seems reasonably solid. I've been working on an ethernet driver and started testing it today. It has sent and received a few packets but lots of cleanup remains. I plan to put up a bk repository on source.mvista.com in a couple of weeks. I could send you a tarball if you'd rather not wait. -Dale Farnsworth ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
booting MGT5100?
On Thu, Apr 24, 2003 at 03:31:42PM +, Chris Heintzelman wrote: Thanks for the info! I'm also using an icecube board. I'll grab the code from mv when you post it there. Do you use a bootloader or do you just use dbug to run a zImage? -Chris H. I'm using the boot_simple boot wrapper code. -Dale ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
The boot loader thingie in arch/ppc/boot/simple is nifty. So why isn't there a provision for putting it on ROM? (Or is there and I missed it?) Because boot/simple decompresses to RAM at 0x0, it seems obvious that it might be decompressing from ROM. What is the right way to do this? (Or, pointers on how to make it ROMable would be appreciated.) Thanks, -kb, the Kent who got as far as Linux booting most of the way but not finding initrd because he has it messed up. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
Kent Borg wrote: The boot loader thingie in arch/ppc/boot/simple is nifty. So why isn't there a provision for putting it on ROM? Well, you normally place it in ROM along with the kernel that is attached. The purpose of all of these bootloaders is to convert a rom calling sequence into a standard (yes, there is one) Linux start up call. They also perform any hardware specific fixups that may be necessary prior to calling Linux. Another feature is it isolates boot rom changes from Linux changes. The old PPCBoot, and probably the new U-boot, kind of perform some of these functions. The reason I'm not a fan of doing this is if we make a change to the Linux calling sequence (which happens rarely) you also have to update the boot rom to match. Not a good thing, IMHO. The other really nice thing about these bootloaders, compressed kernels, and attached initrd, is you can boot the identical image from all devices. For example, during development you can tftp load the image, get everything working, then place the exact same bits into a flash rom. Simply jump to the first location of the image and it will boot from flash. It's relatively easy to adapt these loaders to any custom product requirements. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
On Thu, Apr 24, 2003 at 01:13:35PM -0400, Dan Malek wrote: The other really nice thing about these bootloaders, compressed kernels, and attached initrd, is you can boot the identical image from all devices. For example, during development you can tftp load the image, get everything working, then place the exact same bits into a flash rom. Simply jump to the first location of the image and it will boot from flash. Yes, but disappointingly the ppc/boot/simple I am using (from 2.4 devel) won't run from ROM. Is there a better boot loader I should be using? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
The simple boot loaders are loaders, they are NOT bootroms. They expect the board to have a firmware/bootrom/monitor that does the necessary very low level very hardware specific initialization (things like setting up memory maps, initializing the SDRAM controller, etc.). The simple boot loaders do the added steps necessary for starting linux, so they are necessary but NOT sufficient. gvb At 01:32 PM 4/24/2003 -0400, kentborg at borg.org wrote: On Thu, Apr 24, 2003 at 01:13:35PM -0400, Dan Malek wrote: The other really nice thing about these bootloaders, compressed kernels, and attached initrd, is you can boot the identical image from all devices. For example, during development you can tftp load the image, get everything working, then place the exact same bits into a flash rom. Simply jump to the first location of the image and it will boot from flash. Yes, but disappointingly the ppc/boot/simple I am using (from 2.4 devel) won't run from ROM. Is there a better boot loader I should be using? Thanks, -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
Kent Borg wrote: On Thu, Apr 24, 2003 at 01:13:35PM -0400, Dan Malek wrote: The other really nice thing about these bootloaders, compressed kernels, and attached initrd, is you can boot the identical image from all devices. For example, during development you can tftp load the image, get everything working, then place the exact same bits into a flash rom. Simply jump to the first location of the image and it will boot from flash. Yes, but disappointingly the ppc/boot/simple I am using (from 2.4 devel) won't run from ROM. Is there a better boot loader I should be using? You're a little sparse on info here but try lopping off the first 64KB of your zImage (or jump 0x1 into the zImage that you have). Mark ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
Jerry Van Baren wrote: The simple boot loaders are loaders, they are NOT bootroms. They expect the board to have a firmware/bootrom/monitor that does the necessary very low level very hardware specific initialization (things like setting up memory maps, initializing the SDRAM controller, etc.). The simple boot loaders do the added steps necessary for starting linux, so they are necessary but NOT sufficient. In general this is true. However, it is possible to put enough hw init in the simple boot loader (bootwrapper as I and others now call it) to run linux. This has been done in the past. Mark ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
I based mine off boot/simple. It runs fine from ROM. Suppose for example I have 32MB SDRAM from 0x to 0x01ff, and 16MB flash from 0xff00 to 0x. The key is that arch/ppc/boot/ld.script, and arch/ppc/boot/simple/Makefile with -Ttext (say) 0x0040, make zImage.initrd an ELF file which should go at 0x0040. I build zImage.initrd and store it in flash at 0xff00, not at 0x0040. There is firmware on the board which initializes the memory controller, etc. This firmware then jumps into the image in flash -- jumps directly to 0xff01, with the extra 0x0001 to get around the ELF header -- and zImage.initrd does start executing there. It immediately checks its PC and sees that it's not at 0x0040 where it belongs, so it copies itself there (to RAM) and keeps running from there. Then its BSS, data and stack are in RAM as they should be. You can see that zImage.initrd copies itself from *anywhere* to where it should belong. This is why, as Dan pointed out, you can use a single zImage.initrd. If I am developing, I TFTP it to the board, say to 0x0100. Then I jump to 0x0101. If I am happy with it, I store it in flash at 0xff00. Then I jump to 0xff01. Wherever I put it, it will copy itself to where it belongs. -Original Message- From: Kent Borg [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2003 10:39 AM To: Kerl, John Subject: Re: boot/simple in ROM? On Thu, Apr 24, 2003 at 10:35:21AM -0700, Kerl, John wrote: Why won't it run from ROM? It puts the stack and bss in ROM. Am I doing something wrong or using a bad version?? -kb ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Basic Config file
Hello all, I recently downloaded and installed the ELDK under RedHat 8 targeting a 74xx. Everything went pretty smooth (Thanks Wolfgang!). I am utterly inexperienced at building the kernel. This is the first one. I have everything compiling, but getting various linker unresolves. Can someone point me to or send a simple config file as an example? As few components as possible would be great. Thank you Kevin ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
Dan Malek wrote: The old PPCBoot, and probably the new U-boot, kind of perform some of these functions. The reason I'm not a fan of doing this is if we make a change to the Linux calling sequence (which happens rarely) you also have to update the boot rom to match. Not a good thing, IMHO. That's a very small price to pay for all the luxury of having a smarter boot-monitor. And, how many times was the linux calling sequence changed in the last two years ? cheers ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
Mark A. Greer wrote: You're a little sparse on info here but try lopping off the first 64KB of your zImage (or jump 0x1 into the zImage that you have). Oh yeah...good point. It's just a reflex for me to check this, so I seldom think of it anymore. I think some board builds automatically chop this in the makefile with a 'dd' command (or, they used to) :-) -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot/simple in ROM?
On Thu, Apr 24, 2003 at 11:06:32AM -0700, Kerl, John wrote: I based mine off boot/simple. It runs fine from ROM. Suppose for example I have 32MB SDRAM from 0x to 0x01ff, and 16MB flash from 0xff00 to 0x. The key is that arch/ppc/boot/ld.script, and ...suddenly I GET it! I was being too clever and trying to link for my ROM address, and of course that will put the stack and bss in ROM. Duh. When I simply burn my 0x80 RAM image at 0xfec0 the bss and stack are still down in 0x80-range, and it works great. Thanks to all for having such patience, -kb, the Kent who is glad he didn't ask such a question on, say, the qmail list. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bdigdb flash
Hi, is there someone who has a config file (for bdigdb) for a AMD flash (AM29DL323G)? thanks greggiraud at netcourrier.com grego ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Basic Config file
Read the ELDK manual, however, did not see anything on the kernel configuration and building it. Went to kernelnewbies for that...anywhere else I can go for kernel configuration. Unresolveds are: va_to_pte and get_IMMR in traps.c the get_IMMR seems to be 8xx specific. va_to_pte is in several headers for asm code, but grep of the source tree does not show any implementations in *.[Sch] Thanks Kevin emanuel stiebler wrote: Kevin A. Sapp wrote: Hello all, I recently downloaded and installed the ELDK under RedHat 8 targeting a 74xx. Everything went pretty smooth (Thanks Wolfgang!). I am utterly inexperienced at building the kernel. This is the first one. I have everything compiling, but getting various linker unresolves. Can you tell us more what unresolves you get ? Can someone point me to or send a simple config file as an example? As few components as possible would be great. Try the defaults first. I assume you read the documentation, right ? ;-) cheers ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Basic Config file
In message 3EA84246.9050101 at catapult.com you wrote: Read the ELDK manual, however, did not see anything on the kernel configuration and building it. Went to kernelnewbies for that...anywhere else I can go for kernel configuration. There is also http://www.denx.de/re/DPLG.html (but this does not answer the details of kernel configuration - it only describes how to use existing default configs). In all other cases you just have to know what you are doing. Unresolveds are: va_to_pte and get_IMMR in traps.c the get_IMMR seems to be 8xx specific. va_to_pte is in several headers for asm code, but grep of the source tree does not show any implementations in *.[Sch] It's a bug. Both EXPORT_SYMBOL()s are 8xx specific. Fixed in our current CVS. Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de A dog always bit deepest on the veterinary hand. - Terry Pratchett, _Wyrd Sisters_ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
pcmcia terminology
Hi, I have another PCMCIA/CF question to ask of this list. I have a PPC405gp-based device (similar to the Walnut) that has a CF slot on the front that we'd like to get working. I did some looking around in the archives and came across this: http://lists.linuxppc.org/linuxppc-embedded/200207/msg00124.html I guess I too am tripping up a bit over the terminology. The hardware spec for my device says the following: The intended mode for the device is Common Memory Mode. The motherboard does not provide signals to the CF to operate in I/O or True IDE mode. There are two memory regions in the device's memory map for accessing the card's attribute and common memory. Any idea if this is going to present a problem? Or is this how they normally work (i.e. is this what Linux expects)? I've read the SanDisk documentation and I think I understand that fairly well. I've written a quick and dirty driver that can check the DCR and GPIO registers to see if a card is inserted and dump out the contents of some of the attribute memory. I'm just not sure how it all fits together on the Linux side. How does PCMCIA fit together with CF and how does that fit together with IDE? (or is it ATA?). Does MTD play any part? And what ever happened to filesystems? Should I be looking at pccf_4xx.c? My understanding is that this might be what I'm looking for... a common memory mode -only to I/O mode translator?? Help with any of the above would be very much appreciated. Trevor ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
