which is the best root File system in embed linux system?
Hi, MPC852T target board with 8MB flash, which kind foot file system is the best selection among of: 1. Cramfs 2. EXT2 3. JFFS2 4. RAMDISK Thanks advance! ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
jffs2 problem help!
During creating jffs2 ,I modified the file /drive/mtd/maps/rpxlite.c just like the file tqm8xxl.c,I refered the manual DULG.after loading and running the kernel,display some following message: init_rpxlite_mtd: chip probing count 0 request_module[cfi_cmdset_0002]: Root fs not mounted Support for command set 0002 not present cfi_probe: No supported Vendor Command Set found init_rpxlite_mtd: chip probing count 1 request_module[cfi_cmdset_0002]: Root fs not mounted Support for command set 0002 not present cfi_probe: No supported Vendor Command Set found init_rpxlite_mtd: chip probing count 2 request_module[cfi_cmdset_0002]: Root fs not mounted Support for command set 0002 not present cfi_probe: No supported Vendor Command Set found init_rpxlite_mtd: chip probing count 3 request_module[cfi_cmdset_0002]: Root fs not mounted Support for command set 0002 not present cfi_probe: No supported Vendor Command Set found RPXLITE: No support flash chips found! Where is wrong? and when I use the commmand xd ,show no command,why? thanks !! ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCMCIA problem help!
Hi, Our board was bought from a company. This company use TQM823L board files in PPCBoot 1.1.5 as a model and it made some changes accroding to their hardware connections(but these changes are trivial). And the pc card voltage is 3.3V. In message Sea1-DAV39b0zrAXBir0002037c at hotmail.com you wrote: When I use PC card on mpc823, there is some trouble, the card Which board is this? m8xx_pcmcia: Version 0.03, 14-Feb-2000, Magnus Damm m8xx_pcmcia: TQM8xxL using SLOT_B with IRQ 13. You configured for a TQM8xxL board, but from the messages I've seen it doesn't look like a TQM823L to me. Are you absolutely sure that this is a TQM823L? And do you use U-Boot for loading? What is the matter with it? I guess it's a misconfigured board. = = = = = = = = = = = = = = = = = = = = ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCMCIA problem help!
In message Sea1-DAV123WOXs8Nxn0001ba6d at hotmail.com you wrote: Our board was bought from a company. This company use TQM823L board files in PPCBoot 1.1.5 as a model and it made some changes accroding to their hardware connections(but these changes are trivial). And the pc card voltage is 3.3V. As I stated before: I guess your board is mis-configured. Even trivial changes of the hardware may need adaptions of the boot loader and/or kernel sources. You don't give enough information so it's impossible to say what might be wrong. 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 I used to think that the brain was the most wonderful organ in my body. Then I realized who was telling me this.- Emo Phillips ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
jffs2 problem help!
In message BAY13-F46HY44cnNRxG368d at hotmail.com you wrote: During creating jffs2 ,I modified the file /drive/mtd/maps/rpxlite.c just like the file tqm8xxl.c,I refered the manual DULG.after loading and running I understand that your board is neither a rpxlite nor a TQM8xxL - so which board are you using then? init_rpxlite_mtd: chip probing count 0 request_module[cfi_cmdset_0002]: Root fs not mounted Support for command set 0002 not present ... RPXLITE: No support flash chips found! Seems you misconfigured your MTD sub-system, like selection CFI support when you board in fact does not use CFI conformant flash chips. Or your board does not find the correct start address of the flash memory - which in case of the TQM8xxL gets passed in the bd_info structure by U-Boot. Where is wrong? and when I use the commmand xd ,show no command,why? Please explain where xd comes into play? 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 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PCMCIA problem help!
In message Sea1-DAV123WOXs8Nxn0001ba6d at hotmail.com you wrote: Our board was bought from a company. This company use TQM823L board files in PPCBoot 1.1.5 as a model and it made some changes accroding to their hardware connections(but these changes are trivial). And the pc card voltage is 3.3V. As I stated before: I guess your board is mis-configured. Even trivial changes of the hardware may need adaptions of the boot loader and/or kernel sources. You don't give enough information so it's impossible to say what might be wrong. Because I am not familiar with pc card, I do not know which information do you need to decide the error. Can you tell me about that, and then I will provide the information needed as elaborate as possible. Thank you! = = = = = = = = = = = = = = = = = = = = yhxing xyuhua_telecom at hotmail.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Question about process/kernel address space
Hi, in some elderly code for a VME-supporting 824x-board from our company I found the following line in ppc_md.setup_io_mappings(): io_block_mapping(0x8000, 0x8000, 0x1000, _PAGE_IO); This is obviously meant to map a window of VME IO memory into virtual address space. What puzzles me is that the mapping is located below PAGE_OFFSET (0xc000), which, from my general understanding, is bad :( But since apparently nobody had a problem with this for years, (and ranges above PAGE_OFFSET are tight) I'd like to know what the actual implications are. Ok, should a process ever access this range, it would fail (since the BATs go first and allow only supervisor access(?)), but a user process ever using such a high address seems highly unlikely. What I worry more is that it might introduce some security holes or stability problems, any thoughts? Thanks, -- Stefan Nickl Kontron Modular Computers ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Re: Re: which is the best root File system in embed linux system?
Because our board will be turned on and off frequently, so I think high stability is the important, and a R/W file system is prefer selection too! Another performances such as speed of booting is not the focus! Now our system can runs ok, I use EXT2 FS as the root file system build in a 32M DOC2000, but it seems it's unstable! In any time when the linux is starting, you turn off the power, maybe the root file system will crash! I have serval questions want to be confirmed: 1. Whether the DOC2000 is unstable? 2. Can I build a EXT2 FS in flash? 3. How to avoid the file system crash in embed linux system? Thanks! ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Question about process/kernel address space
Stefan Nickl wrote: Hi, in some elderly code for a VME-supporting 824x-board from our company I found the following line in ppc_md.setup_io_mappings(): io_block_mapping(0x8000, 0x8000, 0x1000, _PAGE_IO); This is obviously meant to map a window of VME IO memory into virtual address space. What puzzles me is that the mapping is located below PAGE_OFFSET (0xc000), which, from my general understanding, is bad :( But since apparently nobody had a problem with this for years, (and ranges above PAGE_OFFSET are tight) I'd like to know what the actual implications are. Ok, should a process ever access this range, it would fail (since the BATs go first and allow only supervisor access(?)), but a user process ever using such a high address seems highly unlikely. On my PPC kernel, TASK_SIZE is 0x8000, so that should be OK. ( linux 2.6.5 ) I think the area between TASK_SIZE and PAGE_OFFSET can also be used to map stuff as long as you take care not to map two things at the same place. IIRC, in ARM, the modules are loaded in that space, but I don't know for PPC. Sylvain Munaut ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Re: Re: which is the best root File system in embed linux system?
In message 20040422085859.C6134424CD at denx.de you wrote: Because our board will be turned on and off frequently, so I think high stability is the important, and a R/W file system is prefer selection too! Another performances such as speed of booting is not the focus! How about speed when accessing (especially reading) files? What about memory footprint? Now our system can runs ok, I use EXT2 FS as the root file system build in a 32M DOC2000, but it seems it's unstable! You asked adbout a filesystem for flash before - this is NOT the same as DOC or even CompacfFlash, as these devices use an internal controller which may perfom certain operations like wear levelling etc. So what do you want to know - filesystems for plain flash memory, or for DOC? The ext2 filesystem is extremley well tested and can be considered to be very stable. Howebver, it was not designed to be used like you attempt to do - i. e. just powering off the device. You must always unmount an ext2 filesystem (or at least remount it read-only_)_ before shutting doen the system. In any time when the linux is starting, you turn off the power, maybe the root file system will crash! Yes, this is the logical consequence of your mis-use. I have serval questions want to be confirmed: 1. Whether the DOC2000 is unstable? NO. It is working perfectly fine in many applications. 2. Can I build a EXT2 FS in flash? Yes, you can. Both in flash memory and on a DOC device. BUt you have to be aware of the restrictions (i. e. ext2 requires to be unmounted before shutdown, and it does not implement any wear levelling which may be useful on writable flash filesystems). 3. How to avoid the file system crash in embed linux system? Don't do things which are outside of the specifications of the software. 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 I like your game but we have to change the rules. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
which is the best root File system in embed linux system?
Just to add to Wolfgang's comments, turning off power without warning is not simply a file system problem. It is a hardware problem that NO file system, no matter how robust it is, can survive. The memory chips (flash, EEPROM, battery backed RAM) require a finite amount of time to actually perform the write operation. If you shut down power at the wrong time (and it WILL happen even if the probabilities appear to be vanishingly small), the memory chip will scribble on an unintended location. Voice of painful experience: the scribbling will be on an _UNINTENDED_ location at some point. You cannot count on the write being a partial write to the INTENDED location. It WILL overwrite something important at some point. The probability may be very small, but it is NOT ZERO. To prevent memory corruption, you need a power fail warning that gives you enough time to complete any write(s) in progress and get your software into a no write state. If you have a writable file system, you will want to unmount the file system, which will take more time than the typical power fail holdup time. Note that even battery backed RAM is vulnerable, and in some ways more vulnerable, even though (and because) they are so fast. The classic problem with BB-RAM is that the processor doesn't get a clean reset and randomly strobes the write line with random garbage on the address and data bus, causing memory corruption. The best solution is to have a software controlled power off switch: pushing the switch causes the processor to shut down in an orderly fashion including, as a last step, removing power. This is the power switch methodology used by most or all PCs today (holding the switch for 6 seconds typically causes a hardware power removal in case the software is AFU). The second-best solution is to have a power monitor on the raw power side plus enough energy stored in capacitors to give several milliseconds of operating time for the processor to tidy up things and go into an wait loop where it waits for the power monitor (you DO have a GOOD power monitor I hope) to reset it. Note that the wait loop typically needs to monitor the input power so that, if power is restored, it restarts rather than being stuck in the wait loop. gvb -Original Message- From: owner-linuxppc-embedded at lists.linuxppc.org [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Wolfgang Denk Sent: Thursday, April 22, 2004 5:40 AM To: jeffy Cc: linuxppc-embedded at lists.linuxppc Subject: Re: Re: Re: which is the best root File system in embed linux system? In message 20040422085859.C6134424CD at denx.de you wrote: Because our board will be turned on and off frequently, so I think high stability is the important, and a R/W file system is prefer selection too! Another performances such as speed of booting is not the focus! How about speed when accessing (especially reading) files? What about memory footprint? Now our system can runs ok, I use EXT2 FS as the root file system build in a 32M DOC2000, but it seems it's unstable! You asked adbout a filesystem for flash before - this is NOT the same as DOC or even CompacfFlash, as these devices use an internal controller which may perfom certain operations like wear levelling etc. So what do you want to know - filesystems for plain flash memory, or for DOC? The ext2 filesystem is extremley well tested and can be considered to be very stable. Howebver, it was not designed to be used like you attempt to do - i. e. just powering off the device. You must always unmount an ext2 filesystem (or at least remount it read-only_)_ before shutting doen the system. In any time when the linux is starting, you turn off the power, maybe the root file system will crash! Yes, this is the logical consequence of your mis-use. I have serval questions want to be confirmed: 1. Whether the DOC2000 is unstable? NO. It is working perfectly fine in many applications. 2. Can I build a EXT2 FS in flash? Yes, you can. Both in flash memory and on a DOC device. BUt you have to be aware of the restrictions (i. e. ext2 requires to be unmounted before shutdown, and it does not implement any wear levelling which may be useful on writable flash filesystems). 3. How to avoid the file system crash in embed linux system? Don't do things which are outside of the specifications of the software. 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 I like your game but we have to change the rules. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
anyone ever see swap_dup: Bad swap file entry?
I am using the linuxppc_2_4_devel tree from http://ppc.bkbits.net/ and a ramdisk which I downloaded from Wolfgang Denx's FTP site. The compile environment is the latest ELDK. I have this tree and ramdisk working just fine on an MPC8260 processor. I took that support and changed a few lines of code in arch/ppc/lib/string.S and arch/ppc/kernel/misc.S to get the kernel to boot on an MPC8248 processor. The kernel appears to boot and mount the ramdisk but then I get the following error. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1431k freed VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev Freeing unused kernel memory: 56k init swap_dup: Bad swap file entry 0e18d55c swap_dup: Bad swap file entry 0e18d55c swap_dup: Bad swap file entry 0e18d55c swap_dup: Bad swap file entry 0e18d55c swap_dup: Bad swap file entry 0e18d55c swap_dup: Bad swap file entry 0e18d55c swap_dup: Bad swap file entry 0e18d55c swap_dup: Bad swap file entry 0e18d55c This error is in mm/swapfile.c It happens when type = nr_swapfile in function swap_duplicate. The only time nr_swapfile gets changed is function sys_swapon. Using my BDI2000 I see that sys_swapon is never getting called. Does anyone know when or if sys_swapon should get called? Has anyone seen this before? Any advice is always appreciated. Steve Blakeslee ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
good learning experience for Linux
I sent a message earlier today about getting a swap_dup: Bad swap file entry 0e18d55c error. I found the problem and fixed it and wanted to share it with people who are still learning this stuff, like myself. After 2 days of pounding on my head I found the file Documentation/powerpc/cpu_features.txt It explained how the file arch/ppc/kernel/cputable.c has a list of the known powerPC PVRs(processor version register). The 8248 was not in there so it was using a default entry. That was the cause of my problems. I added a new entry for the 8248 and all is working. My lesson was a little research makes things much nicer. Lesson learned. Steve Blakeslee ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
good learning experience for Linux
Steven Blakeslee wrote: I sent a message earlier today about getting a swap_dup: Bad swap file entry 0e18d55c error. I found the problem and fixed it and wanted to share it with people who are still learning this stuff, like myself. After 2 days of pounding on my head I found the file Documentation/powerpc/cpu_features.txt It explained how the file arch/ppc/kernel/cputable.c has a list of the known powerPC PVRs(processor version register). The 8248 was not in there so it was using a default entry. That was the cause of my problems. I added a new entry for the 8248 and all is working. My lesson was a little research makes things much nicer. Lesson learned. So, is this already in the latest kernel sources? If not, have you considered sending in a patch? - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
good learning experience for Linux
I still have so more to do like verifying FEC and PCI. Also I did it on 2.4 which I believe is done or close to being. I can provide a patch when I am done. -Original Message- From: Dan Kegel [mailto:[EMAIL PROTECTED] Sent: Thursday, April 22, 2004 11:59 AM To: Steven Blakeslee Cc: 'linuxppc-embedded at lists.linuxppc.org'; 'etux at embeddedtux.org' Subject: Re: good learning experience for Linux Steven Blakeslee wrote: I sent a message earlier today about getting a swap_dup: Bad swap file entry 0e18d55c error. I found the problem and fixed it and wanted to share it with people who are still learning this stuff, like myself. After 2 days of pounding on my head I found the file Documentation/powerpc/cpu_features.txt It explained how the file arch/ppc/kernel/cputable.c has a list of the known powerPC PVRs(processor version register). The 8248 was not in there so it was using a default entry. That was the cause of my problems. I added a new entry for the 8248 and all is working. My lesson was a little research makes things much nicer. Lesson learned. So, is this already in the latest kernel sources? If not, have you considered sending in a patch? - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
