[RFC] Remove G2_LE core decl from CLASSIC_PPC part of arch/ppc/kernel/cputable.c
Hello Dan, Friday, August 27, 2004, 7:00:59 PM, you wrote: >> Since G2_LE is NOT a "classic" core ( in particular - true >> little-endian), > How is it not a classic core? It certainly isn't bookE, and it isn't > 8xx. > No one should care about little-endian anyway. I'm voting for the > first candidate that makes that illegal. :-) Agree. >> With that move we'll conserve some memory of kernel, > How does this single change save anything but a few bytes of > cpu table? Maybe ~2K of rubbish for somebody "few" - for me not :) (don't forget its embedded platform). >> but need some explanations which PPCs based on >> it, for modify Kconfig ( I know MPC52xx and MPC82xx based on it). > What other kernel changes would you make based on > this configuration? Only Kconfig, nothing more. -- Best regards, Andrey Volkov ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ushort fcc_fcce
On 27-08-2004 16:53, "Dan Malek" wrote: > > On Aug 27, 2004, at 5:31 AM, Jaap-Jan Boor wrote: > >> Why is >> include/asm-ppc/immap_8260.h: ushort fcc_fcce; > > Because in the original documentation I had under NDA > many years ago when this was written didn't describe > ATM nor HDLC. It listed this as a 16-bit field for Ethernet. > > I've made a note to change it. ok, thanks Jaap-Jan > > Thanks. > > -- Dan > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[RFC] Remove G2_LE core decl from CLASSIC_PPC part of arch/ppc/kernel/cputable.c
Hello Kumar,
Friday, August 27, 2004, 6:15:20 PM, you wrote:
> What purpose does this change really serve. Linux does not use the
> true little-endian feature of the G2_LE core, beyond that it is very
> much in the class of classic ppc.
> Is the memory savings really that much?
sizeof(*cpu_table) ~ 1300 bytes
+ code in cpu_setup_6xx.S ~ 1000 bytes
+ more simple to filter out some features in Kconfig (ex. SMP,
ALTIVEC...)
And optionally (?):
+ LE (if it will be needed sometime for somebody)
+ "An additional input interrupt signal, core_cint,
implements a critical interrupt function."
>>
>> Since G2_LE is NOT a "classic" core ( in particular - true
>> little-endian),
>> may be now is time to remove it from CLASSIC_PPC part of
>> arch/ppc/kernel/cputable.c, and move it to itself part.
>> I bear in mind next:
>>
>> from arch/ppc/kernel/cputable.c:
>>
>> #if CLASSIC_PPC
>> .
>> { /* All G2_LE (603e core, plus some) have the same pvr */
>> 0x7fff, 0x0082, "G2_LE",
>> CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB |
>> CPU_FTR_CAN_NAP | CPU_FTR_HAS_HIGH_BATS,
>> COMMON_PPC,
>> 32, 32,
>> __setup_cpu_603
>> },
>>
>> #endif /* CLASSIC_PPC */
>>
>> May be better like this:
>>
>> #if CONFIG_G2_LE
>> { /* All G2_LE (603e core, plus some) have the same pvr */
>> 0x7fff, 0x0082, "G2_LE",
>> CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB |
>> CPU_FTR_CAN_NAP | CPU_FTR_HAS_HIGH_BATS,
>> COMMON_PPC,
>> 32, 32,
>> __setup_cpu_603
>> },
>> #endif
>>
>> With that move we'll conserve some memory of kernel,
>> but need some explanations which PPCs based on
>> it, for modify Kconfig ( I know MPC52xx and MPC82xx based on it).
--
Best regards,
Andrey Volkov
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Kernel oops when initializing ethernet driver
Hi Patrick, Patrick Huesmann wrote: > Hi, > > >>>Interestingly, the kernel only crashes when accessing that one >> >>particular >> >>>register (at offset 0x0040). Every other register in that range can be >>>written to and read from w/o problems. >> >>So that sounds like a hardware problem, doesn't it. This is one of those >>things where the FPGA has a hard PPC core and a bunch of VHDL >>peripherals? > > > Yes, exactly. The peripherals are connected to the PPC core via the OPB > (on-chip peripheral bus) and now I must assume that the address decode / > "chip" select logic within that OPB is buggy or not configured right. > AFAIK Xilinx recommends to use PLB version of the ethernet controller. For performance reasons at least. > >>The good thing there is that the VHDL isn't much harder >>to fix than C code. That would be my wild guess - the VHDL is not >>decoding the address correctly. > > > I don't even know if we have the VHDL source - the peripherals are > ready-to-go logic units that are just inserted in the FPGA design. > Do you use EDK to build your design? > >>However, also check that you are not accidentally writing past 0x0040. >>For instance, if 0x0040 is a byte address and you write 16 bits you'll >>be writing to 0x0040 and 0x0041. > > > It is a 32-bit access at 0x0040. > > Thanks, > Patrick > In your kernel boot messages do you see a line similar to: eth0: Xilinx EMAC #0 at 0x6000 mapped to 0xC9015000, irq=30 Is the physical address in your log the one you expect? Best regards, Andrei ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ushort fcc_fcce
Jaap-Jan Boor wrote: > hi, > > Why is > include/asm-ppc/immap_8260.h: ushort fcc_fcce; > > and not uint fcc_fcce, as e.g. the fcc event register > in hdlc mode uses 32 bits. > > thanks, > > Jaap-Jan > > > > > Yep, this is correct. FYI in the fec_8xx it is accessed as 32bits anyway. Patch? Regards Pantelis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Cramfs Limitations
Wolfgang Denk wrote?? > Why not? Of course you can. You just cannot write to it. But I know little on application code's behavior. I cannot adjust it's write operation, I am afraid. It's another folk's job to code the application. > > choice but use JFFS2 for deployment, which performance couldn't > > compare with RAMDISK.It's a pity that RAMDISK cannot update some > > info permanently. EXT2 seems not a > > You can use any filesystem, including one on a RAMDISK. Good hints. I don't really want to give up RAMDISK for it has a better performance than JFFS2 and EXT2. > If the root filesystem happens to be read-only, you just need to > provide a writable filesystem for those things that need to get > written. In case of data that may Recently, I have been thinking about to build up a sector on FLASH for R/W operation, like JFFS2. Then my root fileystem still keeps as RAMDISK. So I can get a fastest boot process and write sector while running. In your opinion, this way should work. Right? > get lost at reboot you can use tmpfs, and for persistent storage you > can use JFFS2. tmfs is new to me but interesting. I will try it. Thanks for your further help a lot! Sam ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Does ext2 based on MTD acceptable for Embedded Development?
In message <412F2398.313.E2BE91 at localhost> you wrote: > > > We do, and it works perfect. You just want to make sure to mount it > > read-only. > Is there an advantage to use ext2 instead of cramfs for read only fs? Boot time, as you don't need to uncompress the stuff. 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 Windows95 = graphical user interface for a single-threaded interrupt handler (DOS) ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Kernel oops when initializing ethernet driver
Hi, > > I don't even know if we have the VHDL source - the peripherals are > > ready-to-go logic units that are just inserted in the FPGA design. > > > Do you use EDK to build your design? Yes. > Is the physical address in your log the one you expect? Yes. Apparently, the hardware guy disabled the ethernet controller's "S/W reset" option in the EDK. This explains why the PPC got no ACK from OPB when writing to the reset register, and threw the data check exception. I hope that this problem is solved, when we enable that option. Thanks again to all who replied, Patrick ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Kernel oops when initializing ethernet driver
> Hi Patrick, > > Patrick Huesmann wrote: > > Hi, > > > > > >>>Interestingly, the kernel only crashes when accessing that one > >> > >>particular > >> > >>>register (at offset 0x0040). Every other register in that range can be > >>>written to and read from w/o problems. > >> > >>So that sounds like a hardware problem, doesn't it. This is one of > those > >>things where the FPGA has a hard PPC core and a bunch of VHDL > >>peripherals? > > > > > > Yes, exactly. The peripherals are connected to the PPC core via the OPB > > (on-chip peripheral bus) and now I must assume that the address decode / > > "chip" select logic within that OPB is buggy or not configured right. > > > > AFAIK Xilinx recommends to use PLB version of the ethernet controller. > For performance reasons at least. > > > > >>The good thing there is that the VHDL isn't much harder > >>to fix than C code. That would be my wild guess - the VHDL is not > >>decoding the address correctly. > > > > > > I don't even know if we have the VHDL source - the peripherals are > > ready-to-go logic units that are just inserted in the FPGA design. > > > Do you use EDK to build your design? > > > >>However, also check that you are not accidentally writing past 0x0040. > >>For instance, if 0x0040 is a byte address and you write 16 bits you'll > >>be writing to 0x0040 and 0x0041. > > > > > > It is a 32-bit access at 0x0040. > > > > Thanks, > > Patrick > > > > In your kernel boot messages do you see a line similar to: > > eth0: Xilinx EMAC #0 at 0x6000 mapped to 0xC9015000, irq=30 > > Is the physical address in your log the one you expect? > > > Best regards, > Andrei > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[RFC] Remove G2_LE core decl from CLASSIC_PPC part of arch/ppc/kernel/cputable.c
Hello all,
Since G2_LE is NOT a "classic" core ( in particular - true little-endian),
may be now is time to remove it from CLASSIC_PPC part of
arch/ppc/kernel/cputable.c, and move it to itself part.
I bear in mind next:
from arch/ppc/kernel/cputable.c:
#if CLASSIC_PPC
.
{ /* All G2_LE (603e core, plus some) have the same pvr */
0x7fff, 0x0082, "G2_LE",
CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB |
CPU_FTR_CAN_NAP | CPU_FTR_HAS_HIGH_BATS,
COMMON_PPC,
32, 32,
__setup_cpu_603
},
#endif /* CLASSIC_PPC */
May be better like this:
#if CONFIG_G2_LE
{ /* All G2_LE (603e core, plus some) have the same pvr */
0x7fff, 0x0082, "G2_LE",
CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB |
CPU_FTR_CAN_NAP | CPU_FTR_HAS_HIGH_BATS,
COMMON_PPC,
32, 32,
__setup_cpu_603
},
#endif
With that move we'll conserve some memory of kernel,
but need some explanations which PPCs based on
it, for modify Kconfig ( I know MPC52xx and MPC82xx based on it).
--
Best regards,
Andrey Volkov
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Kernel oops when initializing ethernet driver
Hi, > > Interestingly, the kernel only crashes when accessing that one > particular > > register (at offset 0x0040). Every other register in that range can be > > written to and read from w/o problems. > > So that sounds like a hardware problem, doesn't it. This is one of those > things where the FPGA has a hard PPC core and a bunch of VHDL > peripherals? Yes, exactly. The peripherals are connected to the PPC core via the OPB (on-chip peripheral bus) and now I must assume that the address decode / "chip" select logic within that OPB is buggy or not configured right. > The good thing there is that the VHDL isn't much harder > to fix than C code. That would be my wild guess - the VHDL is not > decoding the address correctly. I don't even know if we have the VHDL source - the peripherals are ready-to-go logic units that are just inserted in the FPGA design. > However, also check that you are not accidentally writing past 0x0040. > For instance, if 0x0040 is a byte address and you write 16 bits you'll > be writing to 0x0040 and 0x0041. It is a 32-bit access at 0x0040. Thanks, Patrick ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Kernel oops when initializing ethernet driver
Hi, > Machine check means you generated an address that the hardware was > unable to complete - you wrote (or read) a non-existent address. It's > mapped in the MMU ok but doesn't exist on the board. Do you mean something like a "bus error"? > Memory mapped I/O tends to exist in tight little clusters, and if you get > your address off by 1 or something you get a machine check. So you > gotta find exactly what address it's writing to and why it's off - > probably > .h configuration kind of thing somewhere... Interestingly, the kernel only crashes when accessing that one particular register (at offset 0x0040). Every other register in that range can be written to and read from w/o problems. > Hope that's some kind of help :-) Thanks a lot, Patrick ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Kernel oops when initializing ethernet driver
Hi, I'm getting a kernel oops that's triggered by the device driver initialization code (Xilinx VirtexII-Pro on-chip ethernet). It crashes when executing the code XIIF_V123B_RESET(InstancePtr->BaseAddress); (line 554, function XEmac_Reset() in drivers/net/xilinx_enet/xemac.c) The oops message looks like this: > Instruction machine check in kernel mode. > Oops: machine check, sig: 7 > NIP: C00BBA78 XER: C05F LR: C00BBA6C SP: C1FEFF20 REGS: c1fefe70 TRAP: 0200Not tainted > MSR: 9030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 > TASK = c1fee000[1] 'swapper' Last syscall: 120 > last math last altivec > GPR00: 000A C1FEFF20 C1FEE000 0020 1030 0001 068D C015377F > GPR08: C300 0034 C1FEFE30 C016 3104 > GPR16: C430 C488 C420 C4A0 > GPR24: 0810 C0130A60 C1FD7560 C016 C1FD75E8 > Call backtrace: > C00BBA6C C00BB5E0 C0162890 C0162AA4 C015A618 C00024B0 C0006BD4 I don't know jack about kernel oopses, but I learned that this is probably a access violation (Address not mapped in MMU, or whatever). The address that the driver wants to access is 0xc340, which is the virtual address of some ethernet softcore register. The physical registers of the NIC begin at 0x8000, and IIRC they are mapped to 0xc300 by cfg->BaseAddress = (u32) ioremap(lp->save_BaseAddress, remap_size); in the module's probe() function in xilinx_enet/adapter.c where remap_size is well above 0x40 (it's 0x4000, AFAIK) Does anybody know what could be the problem? Do I have to do some I/O mapping by hand, before the driver's init routine is invoked? Do I have to configure the FPGA bitstream in some magic way, before the Linux drivers can be used? I'm using the linuxppc_2_4_devel tree from Montavista and a gcc-3.3.2 toolchain. I'm linking the ethernet driver straight into the kernel (not as loadable module). Thanks in advance, Patrick ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[RFC] Remove G2_LE core decl from CLASSIC_PPC part of arch/ppc/kernel/cputable.c
On Aug 27, 2004, at 11:16 AM, Andrey Volkov wrote: > Maybe ~2K of rubbish for somebody "few" - for me not :) (don't forget > its embedded platform). If you have a system of this magnitude where a couple of Kbytes is going to be the difference between success or failure, I'd suggest looking other places than adding an superfluous #ifdef around the cpu table. There are lots of places in the kernel where thorough analysis and careful configuration will save you lots more than this and probably make a difference. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
How to port ppc-linux to new custom boards? (virtexII)
Hi, > > Thank you very much. This is exactly the type of info I'm looking for. > > Did you manage to get a self-decompressing zImage, or is this ALWAYS the > > bootloader's job on ppc-linux? > I guess in my case (U-Boot) it is the job of the bootloader. > May be you have to add the decompressing code to your bootloader. > This seems to be not so complicated for the code is available. > Download the U-Boot sources and look for the function gunzip() within > common/cmd_bootm.c In the meantime, I managed to build a self-decompressing zImage. It is fairly easy, the board type has to be added to the arch/ppc/boot/simple Makefile and the zImage is then generated by using dd to strip the ELF headers off the zvmlinux file. (There are already examples for this in the Makefile). BTW: The zImage is *MANDATORY* if there is no standard bootloader used, because embed_config() sets up the board info structure and sets up some essential magic cache stuff. I spent a few days just messing around, wondering why I got strange errors and unreproducable behaviour. Eventually, I found out that the cache was b0rken because I didn't do the initial cache setup thing ;) Thanks again to all folks who replied to my thread, Patrick ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
440SP evaluation board?
I am trying to find out if and when some code might be available for the 440SP evaluation board? Gary McKenna ADIC Corporation ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Does ext2 based on MTD acceptable for Embedded Development?
From: Wolfgang Denk <[EMAIL PROTECTED]> > > I would not use ext2 on MTD. > > We do, and it works perfect. You just want to make sure to mount it > read-only. Is there an advantage to use ext2 instead of cramfs for read only fs? Regards, Oliver ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ushort fcc_fcce
hi, Why is include/asm-ppc/immap_8260.h: ushort fcc_fcce; and not uint fcc_fcce, as e.g. the fcc event register in hdlc mode uses 32 bits. thanks, Jaap-Jan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[RFC] Remove G2_LE core decl from CLASSIC_PPC part of arch/ppc/kernel/cputable.c
On Aug 27, 2004, at 7:34 AM, Andrey Volkov wrote: > Since G2_LE is NOT a "classic" core ( in particular - true > little-endian), How is it not a classic core? It certainly isn't bookE, and it isn't 8xx. No one should care about little-endian anyway. I'm voting for the first candidate that makes that illegal. :-) > With that move we'll conserve some memory of kernel, How does this single change save anything but a few bytes of cpu table? > but need some explanations which PPCs based on > it, for modify Kconfig ( I know MPC52xx and MPC82xx based on it). What other kernel changes would you make based on this configuration? -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ushort fcc_fcce
On Aug 27, 2004, at 5:31 AM, Jaap-Jan Boor wrote: > Why is > include/asm-ppc/immap_8260.h: ushort fcc_fcce; Because in the original documentation I had under NDA many years ago when this was written didn't describe ATM nor HDLC. It listed this as a 16-bit field for Ethernet. I've made a note to change it. Thanks. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Does ext2 based on MTD acceptable for Embedded Development?
In message <412EFA07.27872.405FEB at localhost> you wrote: > > > still want to consult with you such a question.Dose > > ext2 filesystem besed on MTD a acceptable option? > > I would not use ext2 on MTD. We do, and it works perfect. You just want to make sure to mount it read-only. > JFFS2 is much better for that purpose for in contrast to ext2, it is > power down reliable and performs wear leveling. These features are only interesting when you need a writable filesystem. 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 Program maintenance is an entropy-increasing process, and even its most skilfull execution only delays the subsidence of the system into unfixable obsolescence. - Fred Brooks, "The Mythical Man Month" ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Cramfs Limitations
In message <20040827013550.73877.qmail at web15605.mail.cnb.yahoo.com> you wrote: > > > Are you really surprised that opening a file for > > writing fails on a read-only filesystem??? > > So only for this reason, I cannot choose Cramfs for my > application deployment??? Then I have nearly no other Why not? Of course you can. You just cannot write to it. > choice but use JFFS2 for deployment, which performance > couldn't compare with RAMDISK.It's a pity that RAMDISK > cannot update some info permanently. EXT2 seems not a You can use any filesystem, including one on a RAMDISK. If the root filesystem happens to be read-only, you just need to provide a writable filesystem for those things that need to get written. In case of data that may get lost at reboot you can use tmpfs, and for persistent storage you can use JFFS2. If you are concerned about updating individual files in your read-only filesystem (instead of updating the whole image (*)) you can use an overlay filesystem. For example, you can use "mini_fo" which was specifically tailored for such purposes; please see http://atlas.denx.de/denx/e/news.php#MINI_FO (*) Updating the whole image is not a bad idea - this way you can guarantee that all files int he image are really compatible with each other; keeping the system in a consisten state is much more difficult when individual files can get replaced at random. 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 "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Cramfs Limitations
Wolfgang Denk wrote?? > > INIT: can't open(/etc/ioctl.save,O_WRONLY):Permission denied! > > > > What's on earth with it?Could 2_4_devel or 2.6 fix it? > > Are you really surprised that opening a file for writing fails on a > read-only filesystem??? So only for this reason, I cannot choose Cramfs for my application deployment??? Then I have nearly no other choice but use JFFS2 for deployment, which performance couldn't compare with RAMDISK.It's a pity that RAMDISK cannot update some info permanently. EXT2 seems not a good idea for FLASH. I really feel puzzled with my 30MB application code deployment. Thanks very much for your input! Sam ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[RFC] Remove G2_LE core decl from CLASSIC_PPC part of arch/ppc/kernel/cputable.c
What purpose does this change really serve. Linux does not use the
true little-endian feature of the G2_LE core, beyond that it is very
much in the class of classic ppc. Is the memory savings really that
much?
- kumar
On Aug 27, 2004, at 6:34 AM, Andrey Volkov wrote:
>
> Hello all,
>
> Since G2_LE is NOT a "classic" core ( in particular - true
> little-endian),
> may be now is time to remove it from CLASSIC_PPC part of
> arch/ppc/kernel/cputable.c, and move it to itself part.
> I bear in mind next:
>
> from arch/ppc/kernel/cputable.c:
>
> #if CLASSIC_PPC
> .
> { /* All G2_LE (603e core, plus some) have the same pvr */
> 0x7fff, 0x0082, "G2_LE",
> CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB |
> CPU_FTR_CAN_NAP | CPU_FTR_HAS_HIGH_BATS,
> COMMON_PPC,
> 32, 32,
> __setup_cpu_603
> },
>
> #endif /* CLASSIC_PPC */
>
> May be better like this:
>
> #if CONFIG_G2_LE
> { /* All G2_LE (603e core, plus some) have the same pvr */
> 0x7fff, 0x0082, "G2_LE",
> CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB |
> CPU_FTR_CAN_NAP | CPU_FTR_HAS_HIGH_BATS,
> COMMON_PPC,
> 32, 32,
> __setup_cpu_603
> },
> #endif
>
> With that move we'll conserve some memory of kernel,
> but need some explanations which PPCs based on
> it, for modify Kconfig ( I know MPC52xx and MPC82xx based on it).
>
> --
> Best regards,
> Andrey Volkov
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Does ext2 based on MTD acceptable for Embedded Development?
Hi, From: Song Sam <[EMAIL PROTECTED]> > still want to consult with you such a question.Dose > ext2 filesystem besed on MTD a acceptable option? I would not use ext2 on MTD. JFFS2 is much better for that purpose for in contrast to ext2, it is power down reliable and performs wear leveling. Regards, Oliver ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
