MPC82xx enet on SCC3

MPC82xx enet on SCC3

[Oliver Fuchs]

Hi all,

as far as I understand, my kernel (2.4.24 from ELDK3.0) is not
prepared for Ethernet on SCC3 of the MPC82xx.
It seems to be necessary to modify arch/ppc/8260_io/enet.c
Am I right?
Is there anyone who has done this already?

Thanks in advance,
Oliver

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC82xx enet on SCC3

[Dan Malek]

On Aug 12, 2004, at 10:29 AM, Oliver Fuchs wrote:

> as far as I understand, my kernel (2.4.24 from ELDK3.0) is not
> prepared for Ethernet on SCC3 of the MPC82xx.

It depends completely on how you chose the multiplex
the IO pins.  There are quite a few combinations, the
well known ones (for currently supported configurations)
are already part of the file.

> It seems to be necessary to modify arch/ppc/8260_io/enet.c
> Am I right?
> Is there anyone who has done this already?

An #ifdef and two lines of #defines should be all you need,
unless you have some special BSCR or other set up needed.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC82xx enet on SCC3

[Oliver Fuchs]

From:           	Dan Malek <dan@embeddededge.com>
Subject:        	Re: MPC82xx enet on SCC3

> > as far as I understand, my kernel (2.4.24 from ELDK3.0) is not
> > prepared for Ethernet on SCC3 of the MPC82xx.
>
> An #ifdef and two lines of #defines should be all you need,
> unless you have some special BSCR or other set up needed.
>
Ok, it was a little bit more, but I have it.
I have modified arch/ppc/config.in and arch/ppc/8260_io/enet.c so
that it fits to SCC1-4 w/o further modifications there.

I would contribute this, if anyone wants to use it.
But as Wolfgang has mentioned frequently, it only makes sense to
contribute a patch that aplies to the latest CVS version.
Is there any chance to get the latest CVS version by HTTP or FTP?

Oliver

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC82xx enet on SCC3

[Wolfgang Denk]

In message <4120DA20.2984.1BD2DC2@localhost> you wrote:
>
> I would contribute this, if anyone wants to use it.

Please do.

> But as Wolfgang has mentioned frequently, it only makes sense to
> contribute a patch that aplies to the latest CVS version.

Ummm... no. The "official" trees use BK, not CVS.

It's only us who still use stone-age tools like CVS.

> Is there any chance to get the latest CVS version by HTTP or FTP?

Not from our (denx.de) CVS server.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
There's no future in time travel.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC82xx enet on SCC3

[Ralph Siemsen]

Wolfgang Denk wrote:

>>Is there any chance to get the latest CVS version by HTTP or FTP?
>
> Not from our (denx.de) CVS server.

There is a BK to CVS export done frequently, and you can rsync that CVS
tree directly from rsync.kernel.org/pub/scm/linux/kernel/bkcvs/linux-2.5

Next best thing for those of us still living in the CVS "stone age"

-Ralph

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC82xx enet on SCC3

[Dan Malek]

On Aug 16, 2004, at 10:00 AM, Oliver Fuchs wrote:


> Ok, it was a little bit more, but I have it.

Apologies, I had FCC on the brain.

> I have modified arch/ppc/config.in and arch/ppc/8260_io/enet.c so
> that it fits to SCC1-4 w/o further modifications there.

Has anyone ever taken the patch I posted for multiple SCC Enet
support and brought it up to date?  That would have solved this
problem as well.  I've given to several people, all promising to
update it and send it back (because they actually had hardware
to test it and I don't any longer).

> I would contribute this, if anyone wants to use it.

Just send it to me and I'll get it into some source base :-)

	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MPC82xx enet on SCC3

[Oliver Fuchs]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 1282 bytes --]

From:           	Dan Malek <dan@embeddededge.com>
>
> Apologies, I had FCC on the brain.
>
never mind

> > I have modified arch/ppc/config.in and arch/ppc/8260_io/enet.c so
> > that it fits to SCC1-4 w/o further modifications there.
The idea is to have some board specific defines within
arch/ppc/platforms/<board>.h

like this:
--snip--
/* defines for arch/ppc/8260_io/enet.c */

#define PB_ENET_RXD      ((uint)0x00020000)
#define PD_ENET_RXD      ((uint)0x00000000)

#define PB_ENET_TXD	     ((uint)0x00000000)
#define PD_ENET_TXD      ((uint)0x00000080)

#define PC_ENET_CLSN     ((uint)0x00100000)

#define PC_ENET_TXCLK    ((uint)0x00000020)
#define PC_ENET_RXCLK    ((uint)0x00000010)

#define PB_ENET_LBK      ((uint)0x00400000)


#define CMXSCR_RS3CS_CLK5  0x00002000	/* SCC3 Rx Clock Source CLK5 */
#define CMXSCR_TS3CS_CLK6  0x00000500	/* SCC3 Tx Clock Source CLK6 */

#define CMX_CLK_ROUTE	((uint)(CMXSCR_RS3CS_CLK5 | CMXSCR_TS3CS_CLK6))

/* #define SCC_ENET_PIN_ENABLE */
--snap--

mind the defines for RxD and TxD for both ports B and D
it's needed to decide which port is used
SCC_ENET_PIN_ENABLE could be used to setup LBK, FDE or DSQ

> Just send it to me and I'll get it into some source base :-)
>
here you are
It's tested for SCC3.


Best regards,
Oliver Fuchs


[-- Attachment #2: Text from file 'sccenet.patch' --]
[-- Type: text/plain, Size: 6561 bytes --]

diff -purN linux-2.4.24/arch/ppc/8260_io/Config.in linux-2.4.24.scc/arch/ppc/8260_io/Config.in
--- linux-2.4.24/arch/ppc/8260_io/Config.in	2003-10-30 01:32:09.000000000 +0100
+++ linux-2.4.24.scc/arch/ppc/8260_io/Config.in	2004-08-16 16:55:45.000000000 +0200
@@ -7,10 +7,11 @@ bool 'Enable SCC Console' CONFIG_SCC_CON
 if [ "$CONFIG_NET_ETHERNET" = "y" ]; then
   bool 'CPM SCC Ethernet' CONFIG_SCC_ENET
   if [ "$CONFIG_SCC_ENET" = "y" ]; then
-  bool 'Ethernet on SCC1' CONFIG_SCC1_ENET
-    if [ "$CONFIG_SCC1_ENET" != "y" ]; then
-      bool 'Ethernet on SCC2' CONFIG_SCC2_ENET
-    fi
+  choice 'SCC Ethernet' \
+         "SCC1 CONFIG_SCC1_ENET \
+          SCC2 CONFIG_SCC2_ENET \
+          SCC3 CONFIG_SCC3_ENET \
+          SCC4 CONFIG_SCC4_ENET" SCC1
   fi
 #
 #  CONFIG_FEC_ENET is only used to get netdevices to call our init
diff -purN linux-2.4.24/arch/ppc/8260_io/enet.c linux-2.4.24.scc/arch/ppc/8260_io/enet.c
--- linux-2.4.24/arch/ppc/8260_io/enet.c	2003-10-30 01:32:09.000000000 +0100
+++ linux-2.4.24.scc/arch/ppc/8260_io/enet.c	2004-08-16 15:54:23.000000000 +0200
@@ -129,29 +129,95 @@ static void set_multicast_list(struct ne

 /* These will be configurable for the SCC choice.
 */
+#if defined(CONFIG_SCC1_ENET)
 #define CPM_ENET_BLOCK	CPM_CR_SCC1_SBLOCK
 #define CPM_ENET_PAGE	CPM_CR_SCC1_PAGE
 #define PROFF_ENET	PROFF_SCC1
 #define SCC_ENET	0
 #define SIU_INT_ENET	SIU_INT_SCC1
-
-/* These are both board and SCC dependent....
-*/
-#define PD_ENET_RXD	((uint)0x00000001)
-#define PD_ENET_TXD	((uint)0x00000002)
 #define PD_ENET_TENA	((uint)0x00000004)
 #define PC_ENET_RENA	((uint)0x00020000)
-#define PC_ENET_CLSN	((uint)0x00000004)
-#define PC_ENET_TXCLK	((uint)0x00000800)
-#define PC_ENET_RXCLK	((uint)0x00000400)
-#define CMX_CLK_ROUTE	((uint)0x25000000)
 #define CMX_CLK_MASK	((uint)0xff000000)

+#elif defined(CONFIG_SCC2_ENET)
+#define CPM_ENET_BLOCK	CPM_CR_SCC2_SBLOCK
+#define CPM_ENET_PAGE	CPM_CR_SCC2_PAGE
+#define PROFF_ENET	PROFF_SCC2
+#define SCC_ENET	1
+#define SIU_INT_ENET	SIU_INT_SCC2
+#define PD_ENET_TENA	((uint)0x00000020)
+#define PC_ENET_RENA	((uint)0x00080000)
+#define CMX_CLK_MASK	((uint)0x00ff0000)
+
+#elif defined(CONFIG_SCC3_ENET)
+#define CPM_ENET_BLOCK	CPM_CR_SCC3_SBLOCK
+#define CPM_ENET_PAGE	CPM_CR_SCC3_PAGE
+#define PROFF_ENET	PROFF_SCC3
+#define SCC_ENET	2
+#define SIU_INT_ENET	SIU_INT_SCC3
+#define PD_ENET_TENA	((uint)0x00000100)
+#define PC_ENET_RENA	((uint)0x00200000)
+#define CMX_CLK_MASK	((uint)0x0000ff00)
+
+#elif defined(CONFIG_SCC4_ENET)
+#define CPM_ENET_BLOCK	CPM_CR_SCC4_SBLOCK
+#define CPM_ENET_PAGE	CPM_CR_SCC4_PAGE
+#define PROFF_ENET	PROFF_SCC4
+#define SCC_ENET	3
+#define SIU_INT_ENET	SIU_INT_SCC4
+#define PD_ENET_TENA	((uint)0x00000800)
+#define PC_ENET_RENA	((uint)0x00800000)
+#define CMX_CLK_MASK	((uint)0x000000ff)
+
+#else
+  #error no SCC defined
+#endif
+/*
+  These are both board and SCC dependent....
+  RxD and TxD can be on port B or D
+  TENA is always on port D
+  RENA and CLSN are always on port C
+*/
+#ifndef PD_ENET_RXD
+  #define PD_ENET_RXD	((uint)0x00000001)
+#endif
+
+#ifndef PB_ENET_RXD
+  #define PB_ENET_RXD	((uint)0x00000000)
+#endif
+
+#ifndef PD_ENET_TXD
+  #define PD_ENET_TXD	((uint)0x00000002)
+#endif
+
+#ifndef PB_ENET_TXD
+  #define PB_ENET_TXD	((uint)0x00000000)
+#endif
+
+#ifndef PC_ENET_CLSN
+  #define PC_ENET_CLSN	((uint)0x00000004)
+#endif
+
+#ifndef PC_ENET_TXCLK
+  #define PC_ENET_TXCLK	((uint)0x00000800)
+#endif
+
+#ifndef PC_ENET_RXCLK
+  #define PC_ENET_RXCLK	((uint)0x00000400)
+#endif
+
+#ifndef CMX_CLK_ROUTE
+  #define CMX_CLK_ROUTE	((uint)0x25000000)
+#endif
+
+
 /* Specific to a board.
 */
+#ifdef CONFIG_EST8260
 #define PC_EST8260_ENET_LOOPBACK	((uint)0x80000000)
 #define PC_EST8260_ENET_SQE		((uint)0x40000000)
 #define PC_EST8260_ENET_NOTFD		((uint)0x20000000)
+#endif

 static int
 scc_enet_open(struct net_device *dev)
@@ -650,7 +716,7 @@ int __init scc_enet_init(void)
 	*/
 	sccp->scc_gsmrl &= ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);

-	/* Configure port C and D pins for SCC Ethernet.  This
+    /* Configure port C and D pins for SCC Ethernet.  This
 	 * won't work for all SCC possibilities....it will be
 	 * board/port specific.
 	 */
@@ -659,16 +725,26 @@ int __init scc_enet_init(void)
 	io->iop_pdirc &=
 		~(PC_ENET_RENA | PC_ENET_CLSN | PC_ENET_TXCLK | PC_ENET_RXCLK);
 	io->iop_psorc &=
-		~(PC_ENET_RENA | PC_ENET_TXCLK | PC_ENET_RXCLK);
-	io->iop_psorc |= PC_ENET_CLSN;
+		~(PC_ENET_RENA | PC_ENET_TXCLK | PC_ENET_RXCLK | (PC_ENET_CLSN & 0x00550000));
+	io->iop_psorc |= (PC_ENET_CLSN & 0x1080000c);

 	io->iop_ppard |= (PD_ENET_RXD | PD_ENET_TXD | PD_ENET_TENA);
 	io->iop_pdird |= (PD_ENET_TXD | PD_ENET_TENA);
 	io->iop_pdird &= ~PD_ENET_RXD;
-	io->iop_psord |= PD_ENET_TXD;
-	io->iop_psord &= ~(PD_ENET_RXD | PD_ENET_TENA);
+	io->iop_psord |= (PD_ENET_TXD & 0x00000002);
+	io->iop_psord &= ~(PD_ENET_TENA | ((PD_ENET_RXD | PD_ENET_TXD) & 0x000006fd));
+
+    /* if RxD or TxD are connected to port B, configure it */
+    if(PB_ENET_RXD | PB_ENET_TXD)
+    {
+      io->iop_pparb |= (PB_ENET_RXD | PB_ENET_TXD);
+      io->iop_pdirb |= (PB_ENET_TXD);
+      io->iop_pdirb &= ~(PB_ENET_RXD);
+      io->iop_psorb |= PB_ENET_TXD;
+      io->iop_psorb &= ~(PB_ENET_RXD);
+    }

-	/* Configure Serial Interface clock routing.
+    /* Configure Serial Interface clock routing.
 	 * First, clear all SCC bits to zero, then set the ones we want.
 	 */
 	immap->im_cpmux.cmx_scr &= ~CMX_CLK_MASK;
@@ -819,10 +895,11 @@ int __init scc_enet_init(void)
 	 */
 	sccp->scc_pmsr = (SCC_PSMR_ENCRC | SCC_PSMR_NIB22);

-	/* It is now OK to enable the Ethernet transmitter.
+    /* It is now OK to enable the Ethernet transmitter.
 	 * Unfortunately, there are board implementation differences here.
 	 */
-	io->iop_pparc &= ~(PC_EST8260_ENET_LOOPBACK |
+	#ifdef CONFIG_EST8260
+    io->iop_pparc &= ~(PC_EST8260_ENET_LOOPBACK |
 				PC_EST8260_ENET_SQE | PC_EST8260_ENET_NOTFD);
 	io->iop_psorc &= ~(PC_EST8260_ENET_LOOPBACK |
 				PC_EST8260_ENET_SQE | PC_EST8260_ENET_NOTFD);
@@ -830,8 +907,14 @@ int __init scc_enet_init(void)
 				PC_EST8260_ENET_SQE | PC_EST8260_ENET_NOTFD);
 	io->iop_pdatc &= ~(PC_EST8260_ENET_LOOPBACK | PC_EST8260_ENET_SQE);
 	io->iop_pdatc |= PC_EST8260_ENET_NOTFD;
+    #endif
+
+    #ifdef SCC_ENET_PIN_ENABLE
+      /* SCC_ENET_PIN_ENABLE must be a valid C statement !!! */
+      SCC_ENET_PIN_ENABLE;
+    #endif

-	dev->base_addr = (unsigned long)ep;
+    dev->base_addr = (unsigned long)ep;
 	dev->priv = cep;

 	/* The CPM Ethernet specific entries in the device structure. */

Re: MPC82xx enet on SCC3

[Oliver Fuchs]

From:           	Wolfgang Denk <wd@denx.de>
> > But as Wolfgang has mentioned frequently, it only makes sense to
> > contribute a patch that aplies to the latest CVS version.
>
> Ummm... no. The "official" trees use BK, not CVS.
Probably, I have mixed it up with postings in the U-Boot list.

> > Is there any chance to get the latest CVS version by HTTP or FTP?
>
> Not from our (denx.de) CVS server.
>
What a pity. I have only access to the net via firewall.

Best regards,
Oliver Fuchs


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Cramfs Limitations

[Song Sam]

Hi,

When creating CRAMFS filesystems on my custom 8xx
board based on MTD,application stopped with the
following message:

Error in Step 7: Cannot load shared resource!

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?

Thanks in advance!

Sam

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Does ext2 based on MTD acceptable for Embedded Development?

[Song Sam]

Hi,

Although I made ext2 on RPXlite DW board and worked,I
still want to consult with you such a question.Dose
ext2 filesystem besed on MTD a acceptable option?
Compared with JFFS2 and Cramfs,it's really hard to
create on FLASH.I mean the case of 30MB filesystem.I
just did succeed once but the performance was
unacceptable at all.Boot time could last
3'39"00,longer than 2-3 times than other
filesystem.Where did I go wrong,in method itself or
some detailes?

[Target]
root@172.16.115.12:/# eraseall /dev/mtd3
root@172.16.115.12:/# mkfs.ext2 /dev/mtdblock3
root@172.16.115.12:/# ls test/tmp/
bin  dev  etc  home  lib  lost+found  mnt  opt  proc
root  sbin  tmp  usr  var

root@172.16.115.12:/# (cd /test/tmp; tar cf - .) | (cd
/mnt; tar xf -)
tar: ./usr/local/lib/minigui/res/bmp/title.gif: time
stamp 2005-06-25 15:48:36 is 26989356 s in the future
tar: ./home/622/mginit/res/hotkey/help.gif: time stamp
2005-06-24 14:20:34 is 26897657 s in the future
tar: ./home/622/mginit/res/hotkey/advert.gif: time
stamp 2005-06-24 14:19:12 is 26897575 s in the future
tar: ./home/622/mginit/res/hotkey/city.gif: time stamp
2005-06-24 14:16:02 is 26897385 s in the future
tar: ./home/622/mginit/res/hotkey/email.gif: time
stamp 2005-06-24 14:15:38 is 26897361 s in the future
tar: ./home/622/mginit/res/hotkey/phone.gif: time
stamp 2005-06-24 14:14:20 is 26897283 s in the future
tar: ./home/622/mginit/res/hotkey/surf.gif: time stamp
2005-06-24 14:15:12 is 26897335 s in the future
tar: ./home/622/mginit/res/hotkey/ch-en.gif: time
stamp 2005-06-24 14:20:06 is 26897629 s in the future
tar: ./home/622/mginit/res/hotkey/accept.gif: time
stamp 2005-07-15 14:50:24 is 28713847 s in the future

or

root@172.16.115.12:/# cp -a /test/tmp /mnt

Often after that system would hang when using
'reboot'.A hard reset could see kernel crashed by 'no
init' message.

Thanks in advance!

Sam

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Cramfs Limitations

[Wolfgang Denk]

In message <20040826100827.78542.qmail@web15603.mail.cnb.yahoo.com> you wrote:
>
> Error in Step 7: Cannot load shared resource!

Use grep to find out who is printing this.

> 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???

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I program, therefore I am.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Cramfs Limitations

[Song Sam]

Wolfgang Denk <wd@denx.de> 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/

Re: Does ext2 based on MTD acceptable for Embedded Development?

[Oliver Fuchs]

Hi,

From:           	Song Sam <samlinuxppc@yahoo.com.cn>

> 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/

Re: Cramfs Limitations

[Wolfgang Denk]

In message <20040827013550.73877.qmail@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@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/

Re: Does ext2 based on MTD acceptable for Embedded Development?

[Wolfgang Denk]

In message <412EFA07.27872.405FEB@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@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/

Re: Cramfs Limitations

[Song Sam]

Wolfgang Denk <wd@denx.de> 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/

Re: Does ext2 based on MTD acceptable for Embedded Development?

[Oliver Fuchs]

From:           	Wolfgang Denk <wd@denx.de>

> > 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/

Re: Does ext2 based on MTD acceptable for Embedded Development?

[Wolfgang Denk]

In message <412F2398.313.E2BE91@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@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/