MPC82xx enet on SCC3
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/
Quoted 2 lines · Oliver Fuchs
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.
Quoted 3 lines
It seems to be necessary to modify
arch/ppc/8260_io/enet.cAm 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/
From: Dan Malek <[email protected]> Subject: Re: MPC82xx enet on SCC3
Quoted 6 lines
Quoted 2 lines
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/
Quoted 2 lines · In message <4120DA20.2984.1BD2DC2@localhost> you wrote:
I would contribute this, if anyone wants to use it.
Please do.
Quoted 2 lines
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.
Quoted 1 line
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: [email protected] There's no future in time travel.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 3 lines · Wolfgang Denk
Quoted 1 line
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/
From: Wolfgang Denk <[email protected]>
Quoted 4 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 1 line
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
In reply to Wolfgang DenkHi,
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/
Re: Cramfs Limitations
Quoted 2 lines · In message <[email protected]> you wrote:
Error in Step 7: Cannot load shared resource!
Use grep to find out who is printing this.
Quoted 4 lines
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: [email protected] I program, therefore I am.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Re: Cramfs Limitations
Wolfgang Denk <[email protected]> wrote��
Quoted 6 lines
Quoted 3 lines
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: Cramfs Limitations
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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.
Quoted 3 lines
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: [email protected] "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: Cramfs Limitations
Wolfgang Denk <[email protected]> wrote��
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 3 lines
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?
Quoted 2 lines
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 reply to Wolfgang DenkHi,
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]
[email protected]:/# eraseall /dev/mtd3 [email protected]:/# mkfs.ext2 /dev/mtdblock3 [email protected]:/# ls test/tmp/ bin dev etc home lib lost+found mnt opt proc root sbin tmp usr var
[email protected]:/# (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
[email protected]:/# 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: Does ext2 based on MTD acceptable for Embedded Development?
Hi,
From: Song Sam <[email protected]>
Quoted 2 lines
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: Does ext2 based on MTD acceptable for Embedded Development?
Quoted 5 lines · In message <412EFA07.27872.405FEB@localhost> you wrote:
Quoted 3 lines
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.
Quoted 2 lines
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: [email protected] 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: Does ext2 based on MTD acceptable for Embedded Development?
From: Wolfgang Denk <[email protected]>
Quoted 4 lines
Quoted 1 line
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?
Quoted 4 lines · In message <412F2398.313.E2BE91@localhost> you wrote:
Quoted 3 lines
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: [email protected] Windows95 = graphical user interface for a single-threaded interrupt handler (DOS)
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 1 line · Oliver Fuchs
Ok, it was a little bit more, but I have it.
Apologies, I had FCC on the brain.
Quoted 2 lines
I have modified
arch/ppc/config.inandarch/ppc/8260_io/enet.cso 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).
Quoted 1 line
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/
From: Dan Malek <[email protected]>
Quoted 3 lines
Apologies, I had FCC on the brain.
never mind
Quoted 2 lines
Quoted 2 lines
I have modified
arch/ppc/config.inandarch/ppc/8260_io/enet.cso 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
Quoted 2 lines
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
arch/ppc/8260_io/Config.in +5 -4
@@ -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
arch/ppc/8260_io/enet.c +101 -18
171 lines not on this page · raw message