[uClinux-dev] Can I provide tty handle to lrzsz?
Hi, I am implementing ZMODEM protocol in my embedded device using lrzsz package. It looks from the source code that I don't have any control over the serial port handle that lrzsz opens. How do I transfer/receive files using lrzsz on serial ports that I can specify from other programs? In other words, for instance, if three serial ports are open on my embedded device, how do I specify the port that I want lrzsz to use? Hope this makes sense. Thanks! Details: Platform:BF533 OS: Blackfin uClinux (2.4.x) lrzsz Version: 0.12.20 Cheers, Amol ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] emulate fork
Quoth Niklas Molin: Problem is that the code is using fork and each child process is running simultaneously (plus the parent process needs to be in charge of handle all information each child processes are sending/receiving). If I understood vfork() right, it will halt the parent process until it _exit() or exec() (what is vfork() then used for?)? Is there some other way to run parallel processes in uClinux or should I try to change to a threaded system instead? If you vfork and exec in the child then both processes will run in parallel. The second process could be another copy of the same program (started with different parameters), or a standalone 'helper' program. This is essentially equivalent behaviour to fork(), it just requires additional setup (and more RAM, unless you're using XIP). They will share handles as normal for forked processes (so you can transfer data between them with pipes), but they won't share memory. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] emulate fork
Hi Gavin. Thanks for your reply. Since I'm using Nios, then I don't think they are supporting (yet) XIP or PIC. So I'll see if I can solve it by using the exec function. Regards, Niklas From: gav...@compacsort.com To: uclinux-dev@uclinux.org Subject: RE: [uClinux-dev] emulate fork Date: Wed, 10 Jun 2009 10:32:16 +1200 Quoth Niklas Molin: Problem is that the code is using fork and each child process is running simultaneously (plus the parent process needs to be in charge of handle all information each child processes are sending/receiving). If I understood vfork() right, it will halt the parent process until it _exit() or exec() (what is vfork() then used for?)? Is there some other way to run parallel processes in uClinux or should I try to change to a threaded system instead? If you vfork and exec in the child then both processes will run in parallel. The second process could be another copy of the same program (started with different parameters), or a standalone 'helper' program. This is essentially equivalent behaviour to fork(), it just requires additional setup (and more RAM, unless you're using XIP). They will share handles as normal for forked processes (so you can transfer data between them with pipes), but they won't share memory. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev _ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] new uClinux-dist patch
Hi Jeff, Jeff Bacon wrote: Quick question. If I want to apply the newest stable patch-set to the base 888 kernel tree, should I only stick with the patch set that is on Sourceforge, or are the ones on the uClinux.org site just as stable(i.e. the one you just uploaded)? They are the same. The sourceforge files are copied from uclinux.org. Jim Donelson takes the image I put on uclinux.org and copies them to sourceforge. I don't have any access to what goes onto sourceforge myself. I've noticed that the Sourceforge site does not have the last few patch-sets and I'm just wondering if there is a reason for that (or is it just that no one has gotten around to uploading the new patches to Sourceforge?). Basically yes, that is right. I pinged Jim to copy them over, but got no response. Regards Greg On Thu, May 21, 2009 at 2:53 AM, Greg Ungerer g...@snapgear.com wrote: Hi All, I have started an upload of a new uClinux-dist patch, at: http://www.uclinux.org/pub/uClinux/dist/patches/uClinux-dist-20080808-20090520.patch.gz It won't all be there for probably about 24 hours. So hold of downloading 'till tomorrow :-) It includes a linux-2.6.29 kernel, and other various fixes and source updates - nothing major. I think most targets work as well as the did with the 2.6.26 kernel in there. (Excepting ARMulator I think, I haven't had time to look at it yet). As usual please post any patches and fixes here. (I may be a little slow in responding for the next couple of weeks, I'll be away). I haven't released a linux-2.6.29-uc0 patch set as I normally would. Instead I have been pushing my changes into the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git And then promoting them from there. Means less work for me :-) But, are people attached to using the -uc patch series? Does anyone still want me to create them? So far in that git tree in the for-linus branch is a set of changes to clean up the various ColdFire reset/reboot code, it should work much better on all platforms now. There is some more merged include file cleanups in the includes branch. The biggest changes in that git tree and some interrupt controller improvements I am working on. There is now specific support code for each of the various types of interrupt controllers used in the various ColdFire parts. The support for the new parts with the larger more flexible interrupt controllers is clean and nice (so for 5208, 5235, 5271/5275, 5282, 5329 and their type). The code for the older parts (5206, 5249, 5307, 5407, etc) is better, but I am still working to improve it a little more. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] new uClinux-dist patch
Hi Alexander, Alexander Stein wrote: Am Donnerstag, 21. Mai 2009 08:53:33 schrieb Greg Ungerer: I have started an upload of a new uClinux-dist patch, at: http://www.uclinux.org/pub/uClinux/dist/patches/uClinux-dist-20080808-20090 520.patch.gz It won't all be there for probably about 24 hours. So hold of downloading 'till tomorrow :-) Is there a reopsitory for uClinux-dist? No, not as such. There is an old CVS lying around at cvs.uclinux.org. But it was only a mirror of the tar ball releases and updates, not used as a truly active repository. And it hasn't been updated for quite some time I tink. m68knommu is the kernel-2.6 only part. It is even less than that. It is only the m68knommu changes (and some generic uclinux changes). Is this the kernel tree distributed by uClinux-dist? No. I'm also interested in the changes and development oudside of that directory. Also integrating a ~100MB gzipped patchfile into a local (git) repository isn't much fun. The complete patch is really the only way to get at that at the moment. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 1/2] mtd/maps: uclinux: fix building when partition support is disabled
Mike Frysinger wrote:
From: Timofei Bondarenko t...@ipi.ac.ru
The uClinux map driver doesn't even use partitions, so we shouldn't require
it in order to work properly.
Signed-off-by: Timofei Bondarenko t...@ipi.ac.ru
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
CC: Greg Ungerer g...@uclinux.org
Acked-by: Greg Ungerer g...@uclinux.org
CC: uclinux-dev@uclinux.org
CC: linux-...@lists.infradead.org
---
drivers/mtd/maps/uclinux.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
index 81756e3..57699c2 100644
--- a/drivers/mtd/maps/uclinux.c
+++ b/drivers/mtd/maps/uclinux.c
@@ -87,7 +87,11 @@ static int __init uclinux_mtd_init(void)
mtd-priv = mapp;
uclinux_ram_mtdinfo = mtd;
+#ifdef CONFIG_MTD_PARTITIONS
add_mtd_partitions(mtd, uclinux_romfs, NUM_PARTITIONS);
+#else
+ add_mtd_device(mtd);
+#endif
return(0);
}
@@ -97,7 +101,11 @@ static int __init uclinux_mtd_init(void)
static void __exit uclinux_mtd_cleanup(void)
{
if (uclinux_ram_mtdinfo) {
+#ifdef CONFIG_MTD_PARTITIONS
del_mtd_partitions(uclinux_ram_mtdinfo);
+#else
+ del_mtd_device(uclinux_ram_mtdinfo);
+#endif
map_destroy(uclinux_ram_mtdinfo);
uclinux_ram_mtdinfo = NULL;
}
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH 2/3] mtd/maps: uclinux: mark local stuff static
Mike Frysinger wrote:
The uclinux_ram_mtdinfo, uclinux_romfs, and uclinux_point symbols do not
need to be visible outside of this module, so mark them static.
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: Greg Ungerer g...@uclinux.org
Acked-by: Greg Ungerer g...@uclinux.org
CC: uclinux-dev@uclinux.org
CC: linux-...@lists.infradead.org
---
drivers/mtd/maps/uclinux.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
index 61d4087..d4314fb 100644
--- a/drivers/mtd/maps/uclinux.c
+++ b/drivers/mtd/maps/uclinux.c
@@ -30,11 +30,11 @@ struct map_info uclinux_ram_map = {
.size = 0,
};
-struct mtd_info *uclinux_ram_mtdinfo;
+static struct mtd_info *uclinux_ram_mtdinfo;
//
-struct mtd_partition uclinux_romfs[] = {
+static struct mtd_partition uclinux_romfs[] = {
{ .name = ROMfs }
};
@@ -42,7 +42,7 @@ struct mtd_partition uclinux_romfs[] = {
//
-int uclinux_point(struct mtd_info *mtd, loff_t from, size_t len,
+static int uclinux_point(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, void **virt, resource_size_t *phys)
{
struct map_info *map = mtd-priv;
--
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] new uClinux-dist patch
Yes, and I am two patches behind, but I will catch up over the next few days (that how slow the download speeds are). On Tue, Jun 9, 2009 at 8:39 PM, Greg Ungerer g...@snapgear.com wrote: Hi Jeff, Jeff Bacon wrote: Quick question. If I want to apply the newest stable patch-set to the base 888 kernel tree, should I only stick with the patch set that is on Sourceforge, or are the ones on the uClinux.org site just as stable(i.e. the one you just uploaded)? They are the same. The sourceforge files are copied from uclinux.org. Jim Donelson takes the image I put on uclinux.org and copies them to sourceforge. I don't have any access to what goes onto sourceforge myself. I've noticed that the Sourceforge site does not have the last few patch-sets and I'm just wondering if there is a reason for that (or is it just that no one has gotten around to uploading the new patches to Sourceforge?). Basically yes, that is right. I pinged Jim to copy them over, but got no response. Regards Greg On Thu, May 21, 2009 at 2:53 AM, Greg Ungerer g...@snapgear.com wrote: Hi All, I have started an upload of a new uClinux-dist patch, at: http://www.uclinux.org/pub/uClinux/dist/patches/uClinux-dist-20080808-20090520.patch.gz It won't all be there for probably about 24 hours. So hold of downloading 'till tomorrow :-) It includes a linux-2.6.29 kernel, and other various fixes and source updates - nothing major. I think most targets work as well as the did with the 2.6.26 kernel in there. (Excepting ARMulator I think, I haven't had time to look at it yet). As usual please post any patches and fixes here. (I may be a little slow in responding for the next couple of weeks, I'll be away). I haven't released a linux-2.6.29-uc0 patch set as I normally would. Instead I have been pushing my changes into the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git And then promoting them from there. Means less work for me :-) But, are people attached to using the -uc patch series? Does anyone still want me to create them? So far in that git tree in the for-linus branch is a set of changes to clean up the various ColdFire reset/reboot code, it should work much better on all platforms now. There is some more merged include file cleanups in the includes branch. The biggest changes in that git tree and some interrupt controller improvements I am working on. There is now specific support code for each of the various types of interrupt controllers used in the various ColdFire parts. The support for the new parts with the larger more flexible interrupt controllers is clean and nice (so for 5208, 5235, 5271/5275, 5282, 5329 and their type). The code for the older parts (5206, 5249, 5307, 5407, etc) is better, but I am still working to improve it a little more. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 3/3] mtd/maps: uclinux: do not allow to be built as a module
Mike Frysinger wrote: There isn't any benefit to building the uClinux MTD map as a module as the rootfs it requires in order to actually be usable is appended to the kernel image, not the module. No known system builds it this way either, so change the option to bool. Signed-off-by: Mike Frysinger vap...@gentoo.org CC: Paul Mundt let...@linux-sh.org CC: Greg Ungerer g...@uclinux.org Acked-by: Greg Ungerer g...@uclinux.org CC: uclinux-dev@uclinux.org CC: linux-...@lists.infradead.org --- drivers/mtd/maps/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig index 82923bd..907873b 100644 --- a/drivers/mtd/maps/Kconfig +++ b/drivers/mtd/maps/Kconfig @@ -501,7 +501,7 @@ config MTD_BFIN_ASYNC If compiled as a module, it will be called bfin-async-flash. config MTD_UCLINUX - tristate Generic uClinux RAM/ROM filesystem support + bool Generic uClinux RAM/ROM filesystem support depends on MTD_PARTITIONS MTD_RAM !MMU help Map driver to support image based filesystems for uClinux. -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Unable to compile uclinux-dist, arm-linux-gcc: Command not found
Hi Peter, Peter Weichai wrote: I encounted very weird problem. I couldnt compile my uClinux-dist. From the terminal screen message, its due to arm-linux-gcc, command not found. However i already specified the arm-linux-gcc path. Below is what i got from echo $PATH /usr/local/arm/3.4.1/bin:/usr/local/arm/3.4.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games Was this a pre-built binary toolchain? Or one you generated yourself? I wouldn't normally expect you to have use such a specific path directory (ie /usr/local/arm/3.4.1/bin)... Regards Greg --Screen Message of uclinux-dist build make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/peter/uclinux/uClinux-dist/tools/ucfront' ln -sf /home/peter/uclinux/uClinux-dist/tools/ucfront/ucfront tools/ucfront-gcc ln -sf /home/peter/uclinux/uClinux-dist/tools/ucfront/ucfront tools/ucfront-g++ ln -sf /home/peter/uclinux/uClinux-dist/tools/ucfront/ucfront-ld tools/ucfront-ld chmod +x tools/romfs-inst.sh tools/modules-alias.sh . linux-2.6.x/.config; if [ $CONFIG_INITRAMFS_SOURCE != ]; then \ mkdir -p `dirname $CONFIG_INITRAMFS_SOURCE`; \ touch $CONFIG_INITRAMFS_SOURCE || exit 1; \ fi make ARCH=arm CROSS_COMPILE=arm-linux- -j1 -C linux-2.6.x || exit 1 make[1]: arm-linux-gcc: Command not found make[1]: Entering directory `/home/peter/uclinux/uClinux-dist/linux-2.6.x' CHK include/linux/version.h make[2]: `include/asm-arm/mach-types.h' is up to date. CHK include/linux/utsrelease.h CC arch/arm/kernel/asm-offsets.s /bin/sh: arm-linux-gcc: not found make[2]: *** [arch/arm/kernel/asm-offsets.s] Error 127 make[1]: *** [prepare0] Error 2 make[1]: Leaving directory `/home/peter/uclinux/uClinux-dist/linux-2.6.x' make: *** [linux] Error 1 - ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Moving to new kernel distro
Hi Roger,
Roger Thornblad wrote:
I'm still pursuing the 2.6.x issue on 5407.
So far I've traced it to some code in kmem_cache_create().
in_interrupt() is trigerring a call to BUG(), and that's the end.
I'll keep looking. If you or anybody else our there has any advice on
something to chase and/or try let me know.
I wouldn't expect any general problems in that part of the
kernel startup. I would more guess at real processor cache
setup/use problems that would lead to this type of problem.
Are you running with the 5407's cache enabled or disabled?
Regards
Greg
-Original Message-
From: uclinux-dev-boun...@uclinux.org [mailto:uclinux-dev-boun...@uclinux.org]
On Behalf Of Greg Ungerer
Sent: Thursday, May 21, 2009 12:29 AM
To: uClinux development list
Subject: Re: [uClinux-dev] Moving to new kernel distro
Hi All,
Below is a patch that gets the smc91c111 ethernet controller on the M5249 board
running. It is reasonably simple, but this code does rely on the ColdFire
interrupt changes I am working on as well to be applied first. So this is
really just for example purposes at the moment.
There is one additional change needed on this to properly acknowledge the
interrupts from the smc91c111. And I have some up-coming interrupt controller
changes that will actually clean this up properly - so I haven't included that
change here now.
Note: this patch was generated against linux-2.6.30-rc5.
Regards
Greg
--- git.linux-2.6.x.4/drivers/net/smc91x.h 2009-04-17 22:53:23.0
+1000
+++ linux-2.6.x/drivers/net/smc91x.h2009-05-20 14:59:45.0 +1000
@@ -371,6 +371,34 @@ static inline void LPD7_SMC_outsw (unsig
#include unit/smc9.h
+#elif defined(CONFIG_COLDFIRE)
+
+#define SMC_CAN_USE_8BIT 0
+#define SMC_CAN_USE_16BIT 1
+#define SMC_CAN_USE_32BIT 0
+#define SMC_NOWAIT 1
+
+static inline void mcf_insw(void *a, unsigned char *p, int l) {
+ u16 *wp = (u16 *) p;
+ while (l-- 0)
+ *wp++ = readw(a);
+}
+
+static inline void mcf_outsw(void *a, unsigned char *p, int l) {
+ u16 *wp = (u16 *) p;
+ while (l-- 0)
+ writew(*wp++, a);
+}
+
+#define SMC_inw(a, r) _swapw(readw((a) + (r)))
+#define SMC_outw(v, a, r) writew(_swapw(v), (a) + (r))
+#define SMC_insw(a, r, p, l) mcf_insw(a + r, p, l)
+#define SMC_outsw(a, r, p, l) mcf_outsw(a + r, p, l)
+
+#define SMC_IRQ_FLAGS (IRQF_DISABLED)
+
#else
/*
--- git.linux-2.6.x.4/arch/m68knommu/platform/5249/config.c 2009-05-19
11:45:50.0 +1000
+++ linux-2.6.x/arch/m68knommu/platform/5249/config.c 2009-05-21
14:11:00.0 +1000
@@ -42,8 +42,35 @@ static struct platform_device m5249_uart
.dev.platform_data = m5249_uart_platform,
};
+#ifdef CONFIG_M5249
+
+static struct resource m5249_smc91x_resources[] = {
+ {
+ .start = 0xe300,
+ .end= 0xe300 + 0x100,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = 166,
+ .end= 166,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device m5249_smc91x = {
+ .name = smc91x,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(m5249_smc91x_resources),
+ .resource = m5249_smc91x_resources,
+};
+
+#endif /* CONFIG_M5249 */
+
static struct platform_device *m5249_devices[] __initdata = {
m5249_uart,
+#ifdef CONFIG_M5249
+ m5249_smc91x,
+#endif
};
/***/
@@ -72,6 +99,24 @@ static void __init m5249_uarts_init(void
/***/
+#ifdef CONFIG_M5249
+
+static void __init m5249_smc91x_init(void) {
+ u32 gpio;
+
+ /* Set the GPIO line as interrupt source for smc91x device */
+ gpio = readl(MCF_MBAR2 + MCFSIM2_GPIOINTENABLE);
+ writel(gpio | 0x40, MCF_MBAR2 + MCFSIM2_GPIOINTENABLE);
+
+ gpio = readl(MCF_MBAR2 + MCFSIM2_INTLEVEL5);
+ writel(gpio | 0x0400, MCF_MBAR2 + MCFSIM2_INTLEVEL5); }
+
+#endif /* CONFIG_M5249 */
+
+/**
+*/
+
static void __init m5249_timers_init(void)
{
/* Timer1 is always used as system timer */ @@ -98,6 +143,9 @@ void
__init config_BSP(char *commandp, i
static int __init init_BSP(void)
{
m5249_uarts_init();
+#ifdef CONFIG_M5249
+ m5249_smc91x_init();
+#endif
platform_add_devices(m5249_devices, ARRAY_SIZE(m5249_devices));
return 0;
}
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
825 Stanley St,
