Re: [uClinux-dev] how to read the voltag of gpio?
Hi,
goon863 wrote:
hi,
I want to read the gpio4 voltag of Micrel KS8695.When use
"IO_ADDRESS",it return "Segmentation fault". Any idea will be thanks.
#include
#include
#include
#define KS8695_GPIO_MODE0xE600
#define KS8695_GPIO_CTRL0xE604
#define KS8695_GPIO_DATA0xE608
#define KS8695_VA_IO_BASE IO_ADDRESS(KS8695_IO_BASE)
#define KS8695_WRITE(offset, v) __raw_writel((v), KS8695_VA_IO_BASE
+ (offset))
#define KS8695_READ(offset) __raw_readl(KS8695_VA_IO_BASE +
(offset))
int main(void)
{
u32 uReg;
printf("haha");
uReg = KS8695_READ(KS8695_GPIO_DATA);
return 0;
}
The KS8695 register addresses are not mapped into user space.
You cannot access them (using __raw_readl(), etc) in a user
space program.
Regards
Greg
--------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing CorporationPHONE: +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] Re: xcopilot no longer supported?
I do development for several different targets and
OSes, and you can't assuming you can install things with names
like m68k-elf-gcc in /usr/local/bin without conflicts. So the
uclinux tools are installed in /opt/uclinux instead of
/usr/local.
But, I can't figure out where that bogus path is being set. The
most portable thing to do would be to do something like the
following (in bash syntax):
$(dirname $(${CROSS_COMPILE}-gcc --print-libgcc-file))/include
Anyhow, I'll add a symlink from /usr/local/lib/gcc/m68k-uclinux
and try again...
Regards
Greg
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing CorporationPHONE: +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] Re: xcopilot no longer supported?
Hi Grant, Grant Edwards wrote: On 2008-09-17, Grant Edwards <[EMAIL PROTECTED]> wrote: I was unable to figure out where that path was coming from so as temporary work-around, I set up a symbolic link from /usr/local/lib/gcc/m68k-uclinux to the proper directory. After that I did get a successful build for the SnapGear Lite. It turns out that the SnapGear units I've got sitting around are Pros and not Lites, so I'll try building for the Pro... And... that fails: ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DCONFIG_SECUREEDGE -DEMBED -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -I../include -I/home/grante/uclinux/uClinux-dist/include -DRESOLVE_HOSTNAMES -DNO_DL -c -o iplink_vlan.o iplink_vlan.c ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -Os -g -fomit-frame-pointer -pipe -fno-common -fno-builtin -Wall -DCONFIG_SECUREEDGE -DEMBED -msep-data -Dlinux -D__linux__ -Dunix -D__uClinux__ -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -I../include -I/home/grante/uclinux/uClinux-dist/include -DRESOLVE_HOSTNAMES -DNO_DL -c -o link_veth.o link_veth.c ucfront-gcc m68k-uclinux-gcc -m5307 -DCONFIG_COLDFIRE -Wl,-elf2flt -Wl,-move-rodata -msep-data -Wl,-elf2flt -Wl,-move-rodata -msep-data -o ip ip.o ipaddress.o iproute.o iprule.o rtm_map.o iptunnel.o tunnel.o ipneigh.o ipntable.o iplink.o ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o iplink_vlan.o link_veth.o ../lib/libnetlink.a ../lib/libip2util.a -L../lib -lnetlink -lip2util -lresolv -ldl /opt/uclinux/bin/../lib/gcc/m68k-uclinux/4.1.1/../../../../m68k-uclinux/bin/ld.real: cannot find -ldl collect2: ld returned 1 exit status make[4]: *** [ip] Error 1 make[4]: Leaving directory `/home/grante/uclinux/uClinux-dist/user/iproute2/ip' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/grante/uclinux/uClinux-dist/user/iproute2' make[2]: *** [iproute2] Error 2 make[2]: Leaving directory `/home/grante/uclinux/uClinux-dist/user' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/grante/uclinux/uClinux-dist/user' make: *** [subdirs] Error 1 This latest version of the iproute2 package is broken for all non-MMU targets. Disable the iproute2 apps and try again. I guess the lesson is that the odds are pretty close to zero for anything not on your list of tested targets. One might wonder why the other targets are even listed as choices. Because they once worked. And in many cases can be gotten to work again with a little effort. Patches to fix most welcome. Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] Re: Trouble flashing a Snapgear Pro
Hi Grant, Grant Edwards wrote: On 2008-09-19, Grant Edwards <[EMAIL PROTECTED]> wrote: On 2008-09-19, Grant Edwards <[EMAIL PROTECTED]> wrote: If I do download a broken image into the device, is there a some sort of bootloader that can be used to fix the unit, it is it a brick at that point? In a manual for SG3xx/SG5xx firewalls, I've found a procedure for recovering some newwer snapgear models that requires a set of two firmware files (an .sgr file and an .sgu file). However, I can only find an .sgu file for the PRO. Further research indicates that for the PRO, you don't use separate .sgr and .sgu files and everything is bundled up inside a Windows executable (a somewhat nasty method to distribute updates for Linux machines). Of course you have to remember that most people using these devices are not Linux aware at all. These are "consumer" level devices. Anyway, the windows exectuable is not neccessary at all in this process. It is for those non-Linux aware users. I would have preferred to use my existing bootp/tftp setup, but I suppose I can set up a Windows machine should the need arise. :/ No need. The underlying process is just dhcp/tftp. Nothing special required. Hold in the button when you plug in the power and the unit will start up the bootloader dhcp/tftp load process recover process. I don't recall if the PRO had this in its bootloader or not (I think it does). Easy way to check. Hook up a serial port, the boot loader will output some messages when you hold the reset button in on power up if it has this support. One note about sgu and sgr images. They are the same format, sgr images are simply much smaller (thus better suited to being RAM/network loaded). sgr's don't normally contained the advanced networking (ipsec, etc) to make them smaller. On many units (those with more RAM) you can network load and run the sgu the same as the sgr. Try it, you can probably get away with directly dhcp/tftp loading your imagez.bin. (Sometimes and easier and quicker way to develop on these things. Oh, and also, to override the simple hardware checks that you tripped over initially just supply the "-H" option to netflash. Tells it to ignore the hardware type encoded in the trailer of the sgu/imagez.bin files. Regards Greg ---- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company 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] Re: Trouble flashing a Snapgear Pro
Hi Grant, Grant Edwards wrote: On 2008-09-19, Greg Ungerer <[EMAIL PROTECTED]> wrote: Further research indicates that for the PRO, you don't use separate .sgr and .sgu files and everything is bundled up inside a Windows executable (a somewhat nasty method to distribute updates for Linux machines). Of course you have to remember that most people using these devices are not Linux aware at all. These are "consumer" level devices. You're right. A windows machine is the one thing that everbody can be counted on to have. I would have preferred to use my existing bootp/tftp setup, but I suppose I can set up a Windows machine should the need arise. :/ No need. The underlying process is just dhcp/tftp. Nothing special required. Hold in the button when you plug in the power and the unit will start up the bootloader dhcp/tftp load process recover process. Great! That's what I was hoping for. I don't recall if the PRO had this in its bootloader or not (I think it does). Easy way to check. Hook up a serial port, the boot loader will output some messages when you hold the reset button in on power up if it has this support. Thanks. I'll give it a try. One note about sgu and sgr images. They are the same format, sgr images are simply much smaller (thus better suited to being RAM/network loaded). sgr's don't normally contained the advanced networking (ipsec, etc) to make them smaller. On many units (those with more RAM) you can network load and run the sgu the same as the sgr. OK, that's good to know. Try it, you can probably get away with directly dhcp/tftp loading your imagez.bin. (Sometimes and easier and quicker way to develop on these things. Definitely. Just to clarify two points... * Is the file that's being loaded via dhcp/tftp being loaded into RAM and run from RAM, or does it get burned into flash by the bootloader and then booted from flash? It is only load and run into RAM. The flash is not touched (that is without you doing something like a "netflash"). * Is anything used directly from flash (e.g. execute-in-place .text sections or read-only romfs)? Or is everything loaded into RAM at boot time? If configured and compiled to run from flash then that is supported. (Really that is XIP is supported - that may be running from flash or RAM depending on where the filesystem is actually located). Oh, and also, to override the simple hardware checks that you tripped over initially just supply the "-H" option to netflash. Tells it to ignore the hardware type encoded in the trailer of the sgu/imagez.bin files. Yup, I figured that out from the help output by netflash, but I didn't want to try it until I had a clear idea of how the recovery procedure was going to work. The odds of me ending up with a bad image in flash at some point are virtually 100%. Oh yes, easy to do when developing on these platforms. The dhcp/tftp boot is very useful feature :-) Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company 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] Fwd: [uclinux-help] patch for smtpclient , -P port bug
Hi Mike,
Mike Frysinger wrote:
forward from the Blackfin forums ... the --smtp-port option is
documented/used everywhere as 'P', but the actual getopt long opts
declares 'p'.
-mike
Submitted By: Andrea Federico Grisotto (andrea)
smtpclient in trunk and in 2008R1 branch doesn't accept "-P port" option,
I added a patch.
Andrea.
Looks good. Applied.
Regards
Greg
diff -uN smtpclient-orig/smtpclient_main.c smtpclient/smtpclient_main.c
--- smtpclient-orig/smtpclient_main.c 2008-03-11 12:05:46.0 +0100
+++ smtpclient/smtpclient_main.c2008-09-15 16:43:03.0 +0200
@@ -292,7 +292,7 @@
{ "errors-to",1, NULL, 'e' },
{ "carbon-copy", 1, NULL, 'c' },
{ "smtp-host",1, NULL, 'S' },
-{ "smtp-port",1, NULL, 'p' },
+{ "smtp-port",1, NULL, 'P' },
{ "src-host", 1, NULL, 'H' },
{ "mime-encode", 0, NULL, 'M' },
{ "use-syslog", 0, NULL, 'L' },
___
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 -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company 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] ping fails the 2nd time
Hi Matt, Matt Waddel wrote: I've encountered an interesting problem with ping (both busybox and the regular ping) on the Coldfire platforms. After typing to end ping the 1st time, running ping the 2nd time only lets one packet get through. Ping seems to hang after the first packet. So the following sequence: # ping 192.168.1.100 PING 192.168.1.100 (192.168.1.100): 56 data bytes 64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=10.0 ms 64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.0 ms 64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.0 ms 64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=0.0 ms 64 bytes from 192.168.1.100: icmp_seq=4 ttl=64 time=0.0 ms 64 bytes from 192.168.1.100: icmp_seq=5 ttl=64 time=0.0 ms 64 bytes from 192.168.1.100: icmp_seq=6 ttl=64 time=0.0 ms ^C --- 192.168.1.100 ping statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip min/avg/max = 0.0/1.4/10.0 ms # ping 192.168.1.100 PING 192.168.1.100 (192.168.1.100): 56 data bytes 64 bytes from 192.168.1.100: icmp_seq=0 ttl=64 time=0.0 ms <<<<< wait a long time where nothing happens >>>>> ^C --- 192.168.1.100 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms - If you set a limit to the number of ping packets using the command: ping -c 5 everything works fine - every time. (As long as you don't type .) Obviously the is leaving the ping/icmp system in a bad state somewhere. I'm using the 2.6.26 kernel, but I also saw the problem on the 2.6.23 kernel. Do any other platforms have this problem? Any ideas where to start looking? Very odd. As another data point I just tried this with a 2.6.26(-uc0) and it seemed to work fine. That was on a M5208EVB (with a pretty much stock build of image from the uClinux-dist-20080808). Regards Greg ---- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] pthreads, vfork and signals
Hi Allon, Allon Stern wrote: On Sep 20, 2008, at 12:20 PM, Jamie Lokier wrote: Allon Stern wrote: Never mind NPTL - I just want Linux Threads, which don't seem to be working for my on my NOMMU M5282 target, using 888. I'm using uClibc 20060608 Anybody have it working? A simple example causes an illegal instruction. I get an illegal instruction when using Linux Threads on ARM-nommu with arm-uclinux-elf-tools-base-gcc3.4.3-20050221.sh, The illegal instruction happens before main(), and GDB cannot debug it. If I use that compiler but with options to link to a uClibc from an older toolchain distribution, it works. (That's what I'm doing now.) So it's possible your problem isn't lack of support, but a toolchain that's broken somehow. Have you tried using a different one? To be clear, I'm using the 8-8-8 uClinux, using the latest released toolchain on uclinux.org Maybe it's time for an updated toolchain? Also, my illegal instruction happens after running a short time. My simple example prints in a loop, and starts a thread that prints in a loop. I see the child thread loop about a dozen times before the illegal instruction. Have you tried the Code Sourcery ColdFire tool chains? I seem to recal some time back mails on this list saying that threads (and c++) worked with those. Regards Greg ---- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] Application compilation woes
Hi Frederic, Frédéric DUBOIS wrote: Helllo, I am upgrading our uClinux distribution from 2.4.22 to 2.4.34, using the latest releases (or I think so: uClinux-dist-20080808.tar.gz and m68k-uclinux-tools-20061214.sh), for our 5272-based custom board. The kernel compilation finally went fine after I included the different bits related to our board (specific drivers, minor hacks, and userland utilities). We also have a quite large C++ application (circa half a meg, binary size) which is compiled apart from the uClinux tree, plus a smaller one (22k). The smaller one compiles and runs fine. It uses the same compilation switches as the bigger one. The bigger one either won't pass the compilation step or won't run: * if I append the -msep-data flag, the program can be built. However when I run it, I get "BINFMT_FLAT: reloc outside program" errors, followed by a SIGSEGV * if I don't use that switch, the compiler issues a " text=0x85c20 overlaps data=0x0" error. Help has been requested here a few times for both issues: * adding the -msep-data switch is wrong, for I use m68k and gcc 4.1.1 * The runtime relocation error is often the consequence of libraries built with -msep-data. So I leave the -msep-data switch out, and focus on the compile-time error. The only external lib I use is uClibc. Someone advised here to edit config.arch in our vendors directory, in order to disable XIP and shared libraries. I have un-commented these lines: DISABLE_XIP = 1 DISABLE_MOVE_RODATA = 1 (for this one I tried both to enable and disable) DISABLE_SHARED_LIB = 1 For each test, I do a "make clean" and rebuild. Same for my program. The most puzzling thing is that the m68k-uclinux-objdump output shows correct figures, AFAICT (see below) I ran out of clues. Any help appreciated. For problems with c++ apps I would suggest trying the compilation using the Code Sourcery ColdFire tools. I have heard reports that it works better for c++. Regards Greg * compilation: * (parts) m68k-uclinux-g++ -m5307 obj.cpp -c -NDEBUG -I/home/my/uClinux-dist/include -Wall ->overloaded-virtual -o obj.o * (final m68k-uclinux-g++ -m5307 -L/home/my/uClinux-dist/uClibc/ -lc -lgcc -lstdc++ -Wl,-elf2flt lots.o of.o obj.o files.o -o myprog ERROR: text=0x85c20 overlaps data=0x0 collect2: ld returned 1 exit status * objdump: m68k-uclinux-objdump -h myprog.elf ( main sections) Idx NameSizeVMA LMA File offAlgn 303 .text 00085c20 09cac 2**2 607 .data d7a000085c2000085c20 000887f02**2 608 .bss1380000933c0000333c0 00095f902**0 609 .stack 0008000800095f90 2**0 m68k-uclinx-objdump -h myprog.gdb (gives other figures) Idx NameSizeVMA LMA File offAlgn 0 .text 000877000002000 2**2 1 .data de300008770000087700 000897002**2 2 .bss13800009553000095530 000975302**2 3 .stack 00097530 2**0 ___ 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 -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] Re: How to enable serial console on SnapGear PRO?
Hi Grant, Grant Edwards wrote: On 2008-09-22, Grant Edwards <[EMAIL PROTECTED]> wrote: On 2008-09-21, Grant Edwards <[EMAIL PROTECTED]> wrote: On 2008-09-21, Grant Edwards <[EMAIL PROTECTED]> wrote: Now I'm trying to figure out how to get a serial console enabled (for both the kernel and a shell once things are started up)... I'm a bit stumped. I've done everything I can think of, including adding a line to config_BSP() like this: strncpy(commandp, " console=/dev/ttyS0,115200 ", size); Doh! I added the above line in the wrong place. It was being clobbered by a later memset(commandp, 0, size); After moving my strncpy() to the bottom of config_BSP(), I now get nice kernel startup messages and a sash prompt on ttyS0. Various userland application stuff is still broken, but I don't really care about that at this point. After looking at config_BSP() it's obvious that one can set CONFIG_BOOTPARAM and CONFIG_BOOTPARAM_STRING to acheive the same result. Modifying the kernel settings for those parameters after choosing the target in "make menuconfig" works. What I can't quite figure out is how to make ttyS0 the default. Setting CONFIG_BOOTPARAM and CONFIG_BOOTPARAM_STRING in vendors/SnapGear/PRO/config.linux-2.4.x appears to have no effect on the default values when a new configuration is created from scratch. Maybe I am mis-understanding. But those are the first time defaults - used when you first configure. So changing them in a tree configured to build for some particular target won't update the real linux-2.6.x/.config and config/.config files unless you explicitly choose to do so in "make config", or have done something like a "make distclean". Most of the Snapgear boards have a saved command line in flash at a fixed offset (I think it was offset 0xc020 into flash on the PRO's). So they don't default to a hard configured command line. Ofcourse no problem setting one in your own builds. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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: Build busybox in uClinux-dist-20080808 use GCC 4.2.1 will lead "Unhandled fault"
Hi Haitao, Haitao Zhang wrote: I'm trying to run busybox comes from uClinux-dist-20080808 and kernel 2.6.22 on a Philips LPC2200 board, the LPC2200 itself is a ARM7TDMI CPU, no MMU. After building whole userland of uClinux-dist-20080808 use the following toolchain (GCC 4.2.1): http://ftp.snapgear.org/pub/snapgear/tools/arm-linux/arm-linux-tools-20070808.tar.gz i see a lot of "Unhandled fault: vector exception (0x000) at 0x" when execute apps in busybox. seems none of busybox apps will work and some app will even cause a kerenl panic /> ps *debugging msg*Busybox starting from busybox/libbb/appletlib.c:main *debugging msg*BB_MMU=0 *debugging Restarting system. Kernel panic - not syncing: Watchdog timer reset failed! But after i rollback to use your old toolchian (GCC 3.4.4): http://ftp.snapgear.org/pub/snapgear/tools/arm-linux/arm-linux-tools-20061213.tar.gz i build busybox and others userland apps with just the same configuration, busybox, init and sash are all running very stable, without generating SIGSEGV. so could you give me some direction about this issue? is there anything i need to take care of after switch to use new toolchian? or i just encounter a toolchain defect? I only build fairly simple userland setups to run on the ARMulator (not even real non-MMU hardware). Maybe the toolchain is buggy. Stick with the gcc-3.4.4 toolchain if it works for you. Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] pthreads, vfork and signals
i Peter, Peter Griffin wrote: Also, my illegal instruction happens after running a short time. My simple example prints in a loop, and starts a thread that prints in a loop. I see the child thread loop about a dozen times before the illegal instruction. - allon I had a very similar bug when getting pthreads working on a uClinux port I was doing. The problem turned out to be incorrect cache flushing on the signal trampoline (arch/kernel/signal.c -- setup_frame()). The pthread library uses lots of signals to wake up and manage threads etc. If the signal trampoline is not properly flushed, you can get a cache hit rather than executing the trap instruction which is written into the user tasks stack frame to return from the signal handler. If this happens you end up executing your stack :-( A simple way to check if this is the problem is to turn the cache off completely and see if your pthread apps run ok (albeit slowly). For the m68knommu arch at least that was fixed earlier this year in a patch by Wilson Callan. I pushed that to main line (certainly in 2.6.26, maybe even 2.6.25 - I would have to double check that). Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company 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] pthreads, vfork and signals
Hi Michael, Michael Schnell wrote: The problem turned out to be incorrect cache flushing on the signal trampoline (arch/kernel/signal.c -- setup_frame()). Why should the cache need to be flushed ? Is the due to the silly "MMU after Cache" hardware glitch of the ARM architecture ? The original code (and how it is still done in m68k, maybe other arches too) put code _in_ the stack to deal with the signal return cleanup. That will hit the data cache, and depending on cache type some time sooner or later RAM. But the code cache could be now be stale relative to those addresses. Regards Greg ---- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company 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] pthreads, vfork and signals
Hi Peter, Peter Griffin wrote: > For the m68knommu arch at least that was fixed earlier this > year in a patch by Wilson Callan. I pushed that to main line > (certainly in 2.6.26, maybe even 2.6.25 - I would have to double > check that). > > Regards > Greg Ah ok, I ran into this whilst porting uClinux to a new arch (having used m68k as a basis, but before the patch), the reason being that I hadn't implemented ANY cache flushing macros ;-) Surprisingly running pthread applications was the first time that this caused a problem. Yeah, I hadn't struck it before either (then I have never used any apps with threads on m68knommu before either :-) Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company 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] mp3play doesn't play certain mp3 files
Hi Robin,
Robin Getz wrote:
On Mon 4 Aug 2008 13:26, Robin Getz pondered:
I needed to make this change to make mp3play play some mp3 files which I
had encoded with lame/modified the mp3tags with various Linux apps.
--- user/mp3play/mpegdec_lib/mp3onlydec.c (revision 6904)
+++ user/mp3play/mpegdec_lib/mp3onlydec.c (working copy)
@@ -189,7 +189,7 @@
value |= BSTR_read_byte( bs );
}
else { // first sync not valid -> try to use previous byte (#5
tolerance !)
- int loops = 16384; // #17
+ int loops = 1638400; // #17
if( check ) return MPEGDEC_ERR_BADFRAME; // Not an MPEG Stream !
value >>= 8;
value |= old_first << 24; // use previous byte
Does someone:
- know what this should actually be (I doubt that making it really big
is the correct answer)
Nope :-)
Can't say I have ever found any mp3 files that didn't work
with this "as is". And we have thrown quite a few at it
over the years.
- have any idea where the upstream for the mpegdec_lib is? I looked
around a little bit - but was unsuccessful.
Nope, again :-)
When I first wrote mp3play.c I got the library package from
Rob Scott directly (not a public web site as such). I don't
know where he picked it up originally. I know he got permission
from the original author to release it under the GPL.
As Ben Stein said: Bueller?... Bueller?... Bueller?
"Oh yeah" :-)
Regards
Greg
--------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company 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: build philosophy
Hi Robin, Robin Getz wrote: I'm just wondering - what is the expectation/common use... When I'm building up images, I use "make image" all the time. It's fast, and great when I'm just making some minor changes in the romfs/ directory. When I'm testing things out, I just edit scripts (like /etc/rc) in the romfs/ directory directly, and then just "make image". Works like a charm. Yep, I often do that to. For quick and dirty testing. However, a problem occurs if I need to do a 'make' in the dist (to rebuild some missing app), since my vendors/*/*/Makefile includes a: $(ROMFSINST) /etc/rc (like 150 other Makefiles) and romfs-inst.sh clobbers overtop of my local changes in romfs/etc/rc with the one from vendors/*/*/rc I could just stop making changes in the romfs/ directory (and do everything in ./vendors/*/* - which I don't do today - since I don't want to check anything into cvs/svn by mistake - and builds would take longer), or I could add a new flag to romfs-inst.sh (which would not copy the file if it already existed) - which would cause problems for people who expect today's behaviour Is ./romfs suppost to be the output of everything? (and people shouldn't be editing things there?) Well, yes. The "make romfs" step is supposed to construct a "final" filesystem layout that is exactly what will end up in the target root filesystem. The "make image" step is supposed to be the step that rolls everything together into a form to load into the target. In practice though sometimes romfs modifcation steps are done in the "image" phase - somethimes it is very difficult to avoid. If I am manually modifying the romfs/etc/rc for example I generally copy into and out of /tmp as well - so I can put it back for debug testing (and not lose it). Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company 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] pthreads, vfork and signals
Michael Schnell wrote: With a decently constructed MMU (cache after MMU viewed from the CPU, as done with all X86 CPUS, AFAIK), only DMA and SMP issues should make cache flush necessary, I have no idea, how the 68 K MMU and cache are constructed. It has nothing to do with m68k or "decently" constructed MMU's. If you have a harvard style cache (which is by far the most common arrangement these days). Then if you are copying or manipulating instructions in memory (eg copying them), they are passing through the data cache - as data, and then you need to flush the data cache before you try and execute in that region. (Obviously a write-thru data cache, or coherency logic between the instruction and data cache would obviate the need to flush). Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company 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] watchdogd: touchup and handle SIGHUP
Hi Mike,
Mike Frysinger wrote:
When the reboot program runs, it sends SIGHUP right after SIGTERM, so we
need to handle it as well.
Also fix a few spelling errors.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
Looks good, applied.
Thanks
Greg
user/watchdogd/watchdogd.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/user/watchdogd/watchdogd.c b/user/watchdogd/watchdogd.c
index d25aa1e..4b0ed2a 100644
--- a/user/watchdogd/watchdogd.c
+++ b/user/watchdogd/watchdogd.c
@@ -98,7 +98,7 @@ static void usage(char *argv[])
{
printf(
"%s [-f] [-w ] [-k ] [-s] [-h|--help]\n"
- "A simple watchdog deamon that send WDIOC_KEEPALIVE ioctl every
some\n"
+ "A simple watchdog daemon that send WDIOC_KEEPALIVE ioctl every
some\n"
"\"heartbeat of keepalives\" seconds.\n"
"Options:\n"
"\t-fstart in foreground (background is default)\n"
@@ -148,6 +148,7 @@ int main(int argc, char *argv[])
} else if (strcmp(*av, "-s") == 0) {
printf("-s switch: safe exit (CTRL-C and kill).\n");
sa.sa_handler = safe_exit;
+ sigaction(SIGHUP, &sa, NULL);
sigaction(SIGINT, &sa, NULL);
sigaction(SIGTERM, &sa, NULL);
} else if (strcmp(*av, FOREGROUND_FLAG) == 0) {
@@ -164,7 +165,7 @@ int main(int argc, char *argv[])
}
if (background) {
- printf("Start in deamon mode.\n");
+ printf("Start in daemon mode.\n");
vfork_daemon_rexec(1, 0, argc, argv, FOREGROUND_FLAG);
}
--
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company 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] kconfig: dynamic support for system libs
Hi Mike,
Mike Frysinger wrote:
These are a few fixes from upstream kconfig to get ncurses/gettext support
rolling on non-Linux systems (like Darwin or uClibc w/out locale).
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
Applied.
Thanks
Greg
config/kconfig/Makefile |4 +++-
config/kconfig/check.sh | 14 ++
config/kconfig/lxdialog/check-lxdialog.sh | 24 +---
3 files changed, 26 insertions(+), 16 deletions(-)
create mode 100755 config/kconfig/check.sh
diff --git a/config/kconfig/Makefile b/config/kconfig/Makefile
index e2d1c21..4ffb09e 100644
--- a/config/kconfig/Makefile
+++ b/config/kconfig/Makefile
@@ -4,11 +4,13 @@
CC = cc
-# lxdialog peices needed locally
+# lxdialog pieces needed locally
check-lxdialog := lxdialog/check-lxdialog.sh
CFLAGS += $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags)
LDLIBS += $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags $(CC))
+CPPFLAGS += $(shell $(CONFIG_SHELL) ./check.sh $(CC) $(CFLAGS) $(LDLIBS))
+
conf-objs := conf.o zconf.tab.o
mconf-objs := mconf.o zconf.tab.o
gconf-objs := gconf.o kconfig_load.o zconf.tab.o
diff --git a/config/kconfig/check.sh b/config/kconfig/check.sh
new file mode 100755
index 000..fa59cbf
--- /dev/null
+++ b/config/kconfig/check.sh
@@ -0,0 +1,14 @@
+#!/bin/sh
+# Needed for systems without gettext
+$* -xc -o /dev/null - > /dev/null 2>&1 << EOF
+#include
+int main()
+{
+ gettext("");
+ return 0;
+}
+EOF
+if [ ! "$?" -eq "0" ]; then
+ echo -DKBUILD_NO_NLS;
+fi
+
diff --git a/config/kconfig/lxdialog/check-lxdialog.sh
b/config/kconfig/lxdialog/check-lxdialog.sh
index 120d624..cdca738 100644
--- a/config/kconfig/lxdialog/check-lxdialog.sh
+++ b/config/kconfig/lxdialog/check-lxdialog.sh
@@ -4,21 +4,15 @@
# What library to link
ldflags()
{
- $cc -print-file-name=libncursesw.so | grep -q /
- if [ $? -eq 0 ]; then
- echo '-lncursesw'
- exit
- fi
- $cc -print-file-name=libncurses.so | grep -q /
- if [ $? -eq 0 ]; then
- echo '-lncurses'
- exit
- fi
- $cc -print-file-name=libcurses.so | grep -q /
- if [ $? -eq 0 ]; then
- echo '-lcurses'
- exit
- fi
+ for ext in so a dylib ; do
+ for lib in ncursesw ncurses curses ; do
+ $cc -print-file-name=lib${lib}.${ext} | grep -q /
+ if [ $? -eq 0 ]; then
+ echo "-l${lib}"
+ exit
+ fi
+ done
+ done
exit 1
}
--
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company 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] romfs-inst.sh: dont corrupt files when using -a and missing new line
Hi Mike,
Mike Frysinger wrote:
If you try to use -a on a file that happens to be missing a new line at the
end of file, the appended text will end up being appended to the last line
instead of being a line all by itself.
The code in question is a little wonky, but it was chosen due to its
portability across crappy non-GNU systems like Darwin.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
Applied.
Thanks
Greg
tools/romfs-inst.sh |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/tools/romfs-inst.sh b/tools/romfs-inst.sh
index 6dfa96b..2090545 100755
--- a/tools/romfs-inst.sh
+++ b/tools/romfs-inst.sh
@@ -123,6 +123,12 @@ file_append()
[ "$v" ] && echo "File pattern already installed."
else
[ "$v" ] && echo "Installing entry into ${ROMFSDIR}${dst}."
+ if [ -s ${ROMFSDIR}${dst} ] ; then
+ # if file lacks a trailing new line, add it before
appending the text
+ if [ $(tail -n1 ${ROMFSDIR}${dst} | tr -d '\n' | wc -c)
= $(tail -n1 ${ROMFSDIR}${dst} | wc -c) ] ; then
+ echo "" >> ${ROMFSDIR}${dst} || return 1
+ fi
+ fi
echo "${src}" >> ${ROMFSDIR}${dst} || return 1
fi
setperm ${ROMFSDIR}${dst}
--
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company 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 for default devices nodes when CONFIG_SERIAL_MCF is defined
Hi David, David Wu wrote: This simple patch(against uClinux-dist-20080808 + 20080811 patch) will add a few more device nodes if CONFIG_SERIAL_MCF is defined. Looks good, applied. Thanks Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company 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 for uCdimm modules' linker scripts in uClinux-dist-20080808
Hi David, David Wu wrote: This patch added a few sections in the linker script for uCdimm modules and allows for newer compilers to work. Applied. Thanks Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company 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 to avoid redefinition of struct _memnode in uClinux-dist-20080808 for uCTI5471-xE8D50
Hi David, David Wu wrote: Please find attached patch for uCTI5471-xE8D50 to avoid the redefinition of struct _memnode in uClinux-dist-20080808. Applied. Thanks Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a Secure Computing Company 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] M5272C3 No PHY device found. SOLVED.
Hi John, Adamson, John wrote: This message has two purposes: 1) to check and see if uclinux-dev is up and accepting messages and 2) summarizing the resolution to a problem with the hope that it helps someone else. My apologies if the logjam suddenly clears and my previous messages make it through...my mail client assures me that it has given up on them completely. I'm in the process of bringing up the latest uClinux-dist-20080808 and 2.6 kernel on my hardware and was having networking problems. The hardware is a near duplicate to the M5272C3, so I configure uClinux as such. A critical piece, however, is the absence of Freescale's dBug bootloader on my hardware. I'm using a custom bootloader. I modified fec.c (temporarily) so that it gets the MAC address from fec.c rather than reading a location in the dBug flash. At that point, the board was coming up, but printing a "No phy device found" message. Skipping to the solution, it turns out that the M5272C3 config of uClinux does not set the GPIO pins for the FEC, apparently relying on the bootloader to do this. I'm not sure where general opinion lies regarding how 'standalone' the configured uClinux image should be, and I suppose it could also be argued that I'm not really running on a M5272C3 if, by definition, the M5272C3 includes dBug. If the intent is to make the image as independent of the bootloader as possible, then I've included a proposed change to the 5272 config.c file below. There are probably better CONFIG switches to use, perhaps a combination of CONFIG_5272 and whatever gets set when the Coldfire FEC is enabled? I'm afraid I'm still trying to sort out the config routines. John (not Adam ) --- uClinux-dist/linux-2.6.x/arch/m68knommu/platform/5272/config.c 2008-06-19 21:22:23.0 -0400 +++ uClinux-changes/linux-2.6.x/arch/m68knommu/platform/5272/config.c 2008-08-27 14:21:53.0 -0400 @@ -143,6 +143,13 @@ void __init config_BSP(char *commandp, i /* Copy command line from FLASH to local buffer... */ memcpy(commandp, (char *) 0xf001, size); commandp[size-1] = 0; +#elif defined(CONFIG_M5272C3) + u32 v; + + /* Enable the lines for the FEC */ + v = readl(MCF_MBAR + MCFSIM_PBCNT); + v = (v & ~0x) | 0x; + writel(v, MCF_MBAR + MCFSIM_PBCNT); #endif mcf_timervector = 69; For most other board types this is currently handled in fec.c itself. To be consistent with those I would put the above code in CONFIG_M5272 specific fec_request_intrs() function. So I have gone ahead and put it there. Ultimately I plan on moving this type of board specific setup into the separate config.c files. (I have already done this for the serial port support - just haven't gotten around to the ethernet ports yet). Ofcourse if you feel brave you code code this up now, using the serial port setup code in arch/m68knommu/platform/5272/config.c as an example :-) Regards Greg ---- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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 to fix thttpd in uClinux-dist-20080808
Hi David, David Wu wrote: Hi Greg and all, Here is a patch for thttpd against uClinux-dist-200808011(uClinux-dist-20080808 + 20080811 patch) This patch fixes CGI calls for uClinux(vfork). Here is an example to test: /bin/thttpd -p 80 -d /home/httpd -c **.cgi -u root There is one issue: I got "Bad file descriptor" error in fdwatch() called in thttpd.c I haven't analysed the reason. Maybe someone can fix that. What is the purpose of the change to thttpd.c? Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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 for can4linux test program in uClinux-dist-200808008
Hi David, David Wu wrote: This patch applys to user/can4linux in uClinux-dist-200808008. can_send.c -- added set_mask() to setup MASK for RX frame ID -- modified test3 to test more byte patterns and make sure each pattern is unique receive.c -- added option to change baud rate -- added option to set mask -- option "t" for continuous test transmitter will send 6 group of data continuously receiver will check each 6 group of data with the first 6 group of data. receiver will exit on mismatch. example: run "receive -t -b 500" on receiver and then run "can_send -m -b 500 -D can0 -t3 -s10" on trasmitter I am not at all familiar with this code :-) I would like to hear comments from anyone else that uses it, or is familiar with it. Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] patches for MCF QSPI in uClinux-dist-20080808 for 2.4 kenel
Hi David, David Wu wrote: I have attached two patches. 1 linux-2.4.x_qspi.patch: the purpose for this patch is to make user/qspitest build for both 2.4 and 2.6 kernel -- created linux-2.4.x/include/asm-m68knommu/mcf_qspi.h -- removed linux-2.4.x/drivers/char/mcf_qspi.h and linux-2.4.x/include/asm-m68knommu/mcfqspi.h -- and added their contents into linux-2.4.x/include/asm-m68knommu/mcf_qspi.h 2 user_qspitest.patch: -- requires above changes -- using MCF_BUSCLK instead of MCF_CLK Yep, looks ok to me. Applied. In the linux-2.6.x sources there appears to be both: linux-2.6.x/include/asm-m68knommu/mcf_qspi.h linux-2.6.x/include/asm-m68knommu/mcfqspi.h Does that need to be cleaned up like the 2.4.x includes? Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] patches for MCF QSPI in uClinux-dist-20080808 for 2.4 kenel
Hi Peter, Peter Turczak wrote: maybe the patch I posted some time ago for making spi_coldfire work in Kernel 2.6 could serve as an inspiration, the file is attached again. In a project of mine this patch to the code beaves quite well (working stable without a problem) with two slaves, one using mtd_dataflash and an spidev on an MCF5208 processor. Actually those changes look like they can go in now. These are pretty strait forward fixups, so I applied this (removing the "//" comments though). Thanks Greg On Oct 2, 2008, at 4:20 PM, David Wu wrote: On Thu, 02 Oct 2008 03:17:44 -0400, Greg Ungerer <[EMAIL PROTECTED]> wrote: Hi David, David Wu wrote: I have attached two patches. 1 linux-2.4.x_qspi.patch: the purpose for this patch is to make user/qspitest build for both 2.4 and 2.6 kernel -- created linux-2.4.x/include/asm-m68knommu/mcf_qspi.h -- removed linux-2.4.x/drivers/char/mcf_qspi.h and linux-2.4.x/include/asm-m68knommu/mcfqspi.h -- and added their contents into linux-2.4.x/include/asm-m68knommu/mcf_qspi.h 2 user_qspitest.patch: -- requires above changes -- using MCF_BUSCLK instead of MCF_CLK Yep, looks ok to me. Applied. In the linux-2.6.x sources there appears to be both: linux-2.6.x/include/asm-m68knommu/mcf_qspi.h linux-2.6.x/include/asm-m68knommu/mcfqspi.h Does that need to be cleaned up like the 2.4.x includes? This file (mcfqspi.h) I believe is for the new SPI driver in drivers/spi/mcf_qspi.c and mcf_qspi.h is used for drivers/char/mcf_qspi.c. I will create a patch to remove linux-2.6.x/drivers/char/mcf_qspi.h and move its contents in linux-2.6.x/include/asm-m68knommu/mcf_qspi.h Right now I am working on 2.6.x patch. More patches will follow. But It seems we have a lot changes to the uClinux-dist-20080808 release for 2.6.x kernel. Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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 -- David Wu ___ 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 -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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 for uC68VZ328 LCD module in uClinux-dist-20080808 release
Hi David, David Wu wrote: This patch, originally comes from Phil Wilshire, supports uC68VZ328 LCD module properly. It seems the driver "mc68328digi.c" is only used for uCdimm. So this patch wouldn't affect others.(hope not) Please apply if it's OK. Applied. Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] Porting to a new ARM926EJ-S board
Hi Avtar, Avtar Singh wrote: We have a custom board running Freescale's i.MX21 (ARM926EJ-S) processor and Linux 2.6.22 with our board-specific patches. 2.6.22 is a little old now. Can you used something newer? 2.6.26-uc0 is the latest. 1. I wish to run a patched version of 2.6.22 ucLinux on the board without the MMU. Is it possible to patch ucLinux to run on ARM926EJ core without MMU? I am sure it would be. 2. I downloaded linux-2.6.22-uc0-big.patch from uclinux.org and applied it to plain vanilla kernel 2.6.22. Before applying any changes specific to our board, I want to just compile the linux patched with the uclinux patch for any ARM board. I tried setting .config using existing defconfigs in arch/arm/configs directory but compilation gives following error. Is there any ARM "config" that I can use so that I am able to compile just out of the box? You will find more useful default configs for non-MMU setups in the uClinux-dist (check http://www.uclinux.org/pub/uClinux/dist/). Specifically I usually build and test the GDB/ARMulator target. That may be a good reference. Regards Greg (.config that I used is attached) arch/arm/mm/consistent.c: In function `__dma_alloc': arch/arm/mm/consistent.c:223: error: `PTRS_PER_PTE' undeclared (first use in this function) arch/arm/mm/consistent.c:223: error: (Each undeclared identifier is reported only once arch/arm/mm/consistent.c:223: error: for each function it appears in.) arch/arm/mm/consistent.c:236: warning: implicit declaration of function `pte_none' arch/arm/mm/consistent.c:242: warning: implicit declaration of function `set_pte_ext' arch/arm/mm/consistent.c:242: warning: implicit declaration of function `mk_pte' arch/arm/mm/consistent.c: In function `dma_free_coherent': arch/arm/mm/consistent.c:389: error: `PTRS_PER_PTE' undeclared (first use in this function) arch/arm/mm/consistent.c:393: warning: implicit declaration of function `ptep_get_and_clear' arch/arm/mm/consistent.c:404: warning: implicit declaration of function `pte_present' arch/arm/mm/consistent.c:405: warning: implicit declaration of function `pte_pfn' arch/arm/mm/consistent.c:424: warning: implicit declaration of function `flush_tlb_kernel_range' arch/arm/mm/consistent.c: In function `consistent_init': arch/arm/mm/consistent.c:453: warning: implicit declaration of function `pgd_offset' arch/arm/mm/consistent.c:453: warning: assignment makes pointer from integer without a cast arch/arm/mm/consistent.c:460: warning: implicit declaration of function `pmd_none' arch/arm/mm/consistent.c:462: warning: implicit declaration of function `pmd_present' arch/arm/mm/consistent.c:462: warning: implicit declaration of function `pte_offset_kernel' arch/arm/mm/consistent.c:462: warning: pointer/integer type mismatch in conditional expression Thanks, AS ___ 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 -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] woo with building gcc-3.4.4
Hi Jun, Jun Sun wrote: I figured out the problem. Apparently there is a bug in glibc that causes libc.so file generated wrongly for LE libraries. This bug is fixed later in glibc 2.3.6. See the attachment of the fix. That is good to know. I have been pretty happy with the gcc-4.2 toolchains, I haven't had any problems with them. (Most recently I have been trailing a gcc-4.2.4 based toolchain without problems). Regards Greg On Mon, Oct 06, 2008 at 11:00:42AM -0700, Jun Sun wrote: Hi, Greg, I have been sucessful in following your instruction to build gcc 4.2 toolchain for ARM. However, the toolchain itself is not very successful. :) Now I have been trying to follow your instruction on building gcc 3.4, which is largely the same. However, I got the following error while building stage2 gcc: checking sys/machine.h presence... no checking for sys/machine.h... no checking for sys/types.h... (cached) yes checking fp.h usability... no checking fp.h presence... no checking for fp.h... no checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking for endian.h... (cached) yes checking for inttypes.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for float.h... (cached) yes checking for stdint.h... (cached) yes checking for main in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make: *** [configure-target-libstdc++-v3] Error 1 I checked with gcc 4.2 build and it worked fine there. It appears GCC_NO_EXECUTABLES is not set there. Do you have any clue as to what is wrong here? Certainly I am sure you have done this successfully. :) I am building it on fedora core 3, as you suggested earlier. TIA. Jun ___ 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 -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] uClinux kernel version 2.6
Hi Loren, Loren A. Linden Levy wrote: I cannot find the 2.6 kernel version in CVS: http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/ can someone point me to it? Thanks. There isn't one for 2.6 kernels. I have only been issuing patches against each 2.6 kernel release. (And then trying hard to push patches to mainline each merge window to keep it up to date). Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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 file for the "e2fsprogs" app of uClinux-dist-20080808.tar.bz2
Hi Michael, Michael Schnell wrote: it doesn't matter whether you are ELF/flat/fdpic Why is flat used for _some_ architectures and not for others ? What are the advantages of flat over ELF and vice versa ? (In fact I don't know exactly what "flat" means ;) ) FLAT format was the first native executable file format for non-MMU linux platforms (ie uCLinux). It is a very simple file layout containing the text and data sections of an application, a very small header, and optionally a relocation table. fdpic is a variation of the ELF format to support PIC code better for non-MMU platforms. (It can and is also used for VM linux). It hasn't been around as long as FLAT. Shared library support is easier with fdpic. Some non-MMU capable architectures support both. It really just comes down to someone putting in the effort. Regards Greg ---- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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 file for the "e2fsprogs" app of uClinux-dist-20080808.tar.bz2
Hi Arthur, Arthur Wong wrote: Thanks for the wonderful discussion. I know little about Blackfin before that, so my understanding is: * with Blackfin, both FLAT and FDPIC ELF were supported; * with ARM (no-mmu), still only support FLAT Is it right ? That is certainly correct at the moment. Regards Greg 2008/10/22 Michael Schnell <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> Thanks a lot ! I should take a look at the great blackfin docs more often ! -Michael ___ uClinux-dev mailing list uClinux-dev@uclinux.org <mailto:uClinux-dev@uclinux.org> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org <mailto: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 -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] subversion folders in uClinux/dist/patches
Hi Bernd, Bernd Büttner wrote: The uClinux-dist-20080808-xxx patch-files contain files under a subversion management folder. These folders start with ".svn" and all reside under user/clamav and subfolders. I'm working with uClinux in a subversion working-copy. Fortunately I did a dry-run with the patch-file, otherwise my working copy would be corrupted now. Will I have to edit the patch-file by myself (no fun with a 46MB file) or will there be a new, corrected one soon? I have fixed the package and patch building to remove those now. So the next patch won't have them. It will generate tonight (my time). But I might not get it onto uclinux.org for a few days. But within a week or so I should have a new patch with them up for download. There are some other files and directories starting with a '.', for example ".gitignore". I cannot say if they are correct or not. I think it best to remove those too. Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] ping fails the 2nd time - revisited
Hi Matt, Matt Waddel wrote: About a month ago I posted a question to the list about ping being broken the second time you ran it. The problem seemed to be related to the shell I was using (msh). I was finally able to get back to this problem and find a fix. Earlier this year a message was posted to the busybox mailing list that solved the problem: http://www.busybox.net/lists/busybox/2008-February/030260.html After integrating this patch, I have been able to run ping without any failures. Attached is a reformatted patch. Best regards, Matt ps. - I noticed this patch hasn't been accepted into the busybox base, but saving the signal state does seem like a good idea. I don't see any reason not to push this into the uClinux-dist busybox right now. So I have done that. Regards Greg ___ 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 -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] uClinux kernel version 2.6
Hi Alex, Loren A. Linden Levy wrote: There isn't one for 2.6 kernels. I have only been issuing patches against each 2.6 kernel release. (And then trying hard to push patches to mainline each merge window to keep it up to date). Sorry to be obtuse but where on the uClinux home page are these patches? Do you keep the patches in CVS somewhere. I am interested in trying out 2.6 to see if i have the same NFS issue that we are trying to debug in 2.4. The linux-2.6.x patches are kept at: http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/ Or if you prefer patch updates for the entire uClinux-dist then: http://www.uclinux.org/pub/uClinux/dist/patches/ Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] subversion folders in uClinux/dist/patches
Mike Frysinger wrote: On Friday 24 October 2008, Greg Ungerer wrote: Bernd Büttner wrote: There are some other files and directories starting with a '.', for example ".gitignore". I cannot say if they are correct or not. I think it best to remove those too. i would imagine a significant number of people import uclinux-dist into some SCM system. if things like .cvsignore and .gitignore were left behind, that'd keep people from having to recreate it themselves ... besides, it isnt like these files are terribly large in the first place and since they're plain text, i imagine compress fine enouh ... Oh yes, size is not really the problem. It is only a problem if they "iunterfere" with importing into a local SCM system. I think your right though, the *ignore files are probably safe, and are probably useful to leave in place. Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] kmalloc fails
Hi Dave, Dave Meador wrote: kmalloc is returning 0 when I try to allocate 24335 bytes inside a FEC driver that I am porting to coldfire uclinux 547x. I have enabled the kernel feature "[*] Allow allocating large blocks (> 1MB) of memory" to see if this fixes my problem, but no joy. Does anyone have an idea of what I can do to get past this? Can you show the code? Regards Greg Here is a snippet of my kernel output when loading: ... ColdFire internal UART serial driver ttyS0 at MMIO 0x10008600 (irq = 99) is a ColdFire UART ttyS1 at MMIO 0x10008700 (irq = 100) is a ColdFire UART ttyS2 at MMIO 0x10008800 (irq = 101) is a ColdFire UART RAMDISK driver initialized: 1 RAM disks of 2048K size 1024 blocksize loop: loaded (max 8 devices) ColdFire internal FEC driver version 0.11a FEC init - kmalloc request size 24335 bytes FEC init - kmalloc result 0x0 ... ___ 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 -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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 to fix user/fileutils/ls.c
Hi David, David Wu wrote: Hi Greg, Attached patch fixes user/fileutils/ls.c in uClinux-dist-20080808 for the following problems: Looks good, applied. Regards Greg [1] show the links without the patch "ls -la /bin" output: # ls -l /bin lrwxrwxrwx 1 root 0 7 Jan 1 1970 [ -rwxr--r-- 1 root 0 51860 Jan 1 1970 agetty after applied the patch: # ls -la /bin lrwxrwxrwx 1 root 0 7 Jan 1 1970 [ -> busybox -rwxr--r-- 1 root 0 51828 Jan 1 1970 agetty -rwxr--r-- 1 root 0 61528 Jan 1 1970 arp [2] show major:minor number correctly without the patch # ls -l /dev/ crw-r--r-- 1 root 0 0, 91 Jan 1 1970 can crw-r--r-- 1 root 0 0, 91 Jan 1 1970 can0 crw-r--r-- 1 root 0 0, 5 Nov 30 00:00 console crw-r--r-- 1 root 0 0, 5 Jan 1 1970 cua0 crw-r--r-- 1 root 0 0, 5 Jan 1 1970 cua1 crw-r--r-- 1 root 0 0, 29 Jan 1 1970 fb0 crw-r--r-- 1 root 0 0, 29 Jan 1 1970 fb1 with the patch # ls -l /dev/ crw-r--r-- 1 root 0 91, 0 Jan 1 1970 can crw-r--r-- 1 root 0 91, 0 Jan 1 1970 can0 crw-r--r-- 1 root 0 5, 1 Nov 30 00:00 console crw-r--r-- 1 root 0 5, 64 Jan 1 1970 cua0 crw-r--r-- 1 root 0 5, 65 Jan 1 1970 cua1 crw-r--r-- 1 root 0 29, 0 Jan 1 1970 fb0 crw-r--r-- 1 root 0 29, 32 Jan 1 1970 fb1 crw-r--r-- 1 root 0 28, 0 Jan 1 1970 hifn0 crw-r--r-- 1 root 0 89, 0 Jan 1 1970 i2c-0 [3] remove extra line for "ls -dl" without the patch # ls -dl /dev/ /bin drwxr-xr-x 1 root 02036 Jan 1 1970 /dev/ drwxr-xr-x 1 root 01064 Jan 1 1970 /bin # with the patch # ls -dl /dev/ /bin drwxr-xr-x 1 root 02004 Jan 1 1970 /dev/ drwxr-xr-x 1 root 01124 Jan 1 1970 /bin # ___ 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 -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] problems with quagga
Hi Mohsen, Mohsen wrote: I've tried to make uclinux with quagga but making the kernel ended with this error: make[2]: Entering directory `/apps/router/ADI/user/quagga' make[2]: *** No rule to make target `romfs'. Stop. make[2]: Leaving directory `/apps/router/ADI/user/quagga' make[1]: *** [romfs] Error 2 make[1]: Leaving directory `/apps/router/ADI/user' make: *** [romfs.subdirs] Error 1 Where did you get the source from? What version is it? Regards Greg ---- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] short-load-bytes
Hi Raj, pushparaj muthu wrote: I have installed the arm tool chain -3.4.2 When I try to cross compile kernel 2.6 What version? Patched of Linus original? Getting error message "invalid option `short-load-bytes' What changes have to make in the make file ? arch/arm/Makefile should contain a line something like: KBUILD_CFLAGS +=$(CFLAGS_ABI) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm That chooses whether to use whether to use short-load-bytes or alignment-traps based on what the compiler can do... Regards Greg ---- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +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] MCF528x interrupts
Allon Stern wrote: got it. My original driver used SA_INTERRUPT in the flags for the register_IRQ. That flag was not defined for the coldfire, and somewhere I read that it was the default. Turns out I really wanted to define IRQF_DISABLED. How did the original driver compile on 2.6.26? SA_INTERRUPT is not defined in 2.6.26 sources at all, it was deprecated and removed before that... Regards Greg Upshot: my IRQ was being called with interrupts enabled. - allon ___ 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: [EMAIL PROTECTED] SnapGear, a McAfee Company 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] coldfire - migrating a driver to a 2.6.x kernel
Hi Daniele,
Daniele Ziglioli wrote:
I need to port some 2.4 drivers to a 2.6.x uclinux kernel and I wish to
understand
the right way to do this.
Just as a reference I'm talking, for example, about cypress sl811
usb-host driver .
In particular I need to introduce some board-specific irqs and memory
address access managements.
The previous 2.4 driver (hc_sl811.c) was full of board-specific
conditional statement like for example:
#if defined(CONFIG_SIGNAL_MCP751)
/* Acknowledge interrupt */
{
volatile unsigned long *icrp;
icrp = (volatile unsigned long *) (MCF_MBAR + MCFSIM_ICR4);
*icrp = (*icrp & 0x777) | 0x0800; // INT5
}
#endif
I suppose this is not acceptable anymore in the new kernel drivers.
Which is the right way in the 2.6.x kernel to do this sort of things,
and in general to do specific board initialization or configurations ?
I suppose that some effort has been done in the new kernels to introduce
a clean separation between board-specific issues and the generic part of
the driver, but due to my lack of experience in 2.6.x kernel is not
clear for me how to operate.
I've had a look at LDD book, LKH docs, and some other readings, but I've
not found useful information about treating board-specific driver
codings techniques.
Could someone point me to some good examples or documents regarding
board-specific driver codings techniques,
Generally now in 2.6 based code you want to put the platform
hardware specifics in the platform code. In this case for the
ColdFire that would be files like:
arch/m68knommu/platform/520x/config.c
(The 520x is just an example, use the appropriate ColdFire type).
The serial port setups in many of those config.c files should
be a good example of what is needed.
Regards
Greg
--------
Greg Ungerer -- Principal EngineerEMAIL: [EMAIL PROTECTED]
SnapGear, a McAfee Company 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] coldfire - migrating a driver to a 2.6.x kernel
Hi Daniele,
Daniele Ziglioli wrote:
Greg Ungerer ha scritto:
Hi Daniele,
Daniele Ziglioli wrote:
I need to port some 2.4 drivers to a 2.6.x uclinux kernel and I wish
to understand
the right way to do this.
Just as a reference I'm talking, for example, about cypress sl811
usb-host driver .
In particular I need to introduce some board-specific irqs and memory
address access managements.
The previous 2.4 driver (hc_sl811.c) was full of board-specific
conditional statement like for example:
#if defined(CONFIG_SIGNAL_MCP751)
/* Acknowledge interrupt */
{
volatile unsigned long *icrp;
icrp = (volatile unsigned long *) (MCF_MBAR + MCFSIM_ICR4);
*icrp = (*icrp & 0x777) | 0x0800; // INT5
}
#endif
I suppose this is not acceptable anymore in the new kernel drivers.
Which is the right way in the 2.6.x kernel to do this sort of things,
and in general to do specific board initialization or configurations ?
I suppose that some effort has been done in the new kernels to
introduce a clean separation between board-specific issues and the
generic part of the driver, but due to my lack of experience in 2.6.x
kernel is not clear for me how to operate.
I've had a look at LDD book, LKH docs, and some other readings, but
I've not found useful information about treating board-specific
driver codings techniques.
Could someone point me to some good examples or documents regarding
board-specific driver codings techniques,
Generally now in 2.6 based code you want to put the platform
hardware specifics in the platform code. In this case for the
ColdFire that would be files like:
arch/m68knommu/platform/520x/config.c
(The 520x is just an example, use the appropriate ColdFire type).
The serial port setups in many of those config.c files should
be a good example of what is needed.
Regards
Greg
ok, thanks almost everthing is clear for me now, just a question more ...
on my board the device is connected via an external IRQ line , so on
coldfire cpu I need to acknowledge irq with something like:
void sl811_hcd_irq_ack(struct device *dev)
{
/* Acknowledge interrupt */
{
volatile unsigned long *icrp;
icrp = (volatile unsigned long *) (MCF_MBAR + MCFSIM_ICR4);
*icrp = (*icrp & 0x777) | 0x0800; // INT5
}
}
To obtain this I've modified the sl811-hcd.c and sl811.h adding a
specific callback: irq_ack ...
struct sl811_platform_data {
+++void(*irq_ack)(struct device *dev);
};
static irqreturn_t sl811h_irq(struct usb_hcd *hcd)
{
struct sl811*sl811 = hcd_to_sl811(hcd);
u8irqstat;
irqreturn_tret = IRQ_NONE;
unsignedretries = 5;
+++ if (sl811->board) {
+++ if (sl811->board->irq_ack) {
+++ sl811->board->irq_ack(hcd->self.controller);
+++ }
+++ }
spin_lock(&sl811->lock);
In this way I need to add a similar callback for every external device
that I need to manage.
My question is is this the right way or exist a platform dependent way
to generically ack any irq's ?
Setting an entry/exit platform callback when I made the request_irq(...)
, for example.
Currently there is no platform dependant way to handle this.
Been on my todo list for a while to clean this up.
Regards
Greg
--------
Greg Ungerer -- Principal EngineerEMAIL: [EMAIL PROTECTED]
SnapGear, a McAfee Company 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] Compiler library "libgcc.a" for uClinux
Hi KJ, Lin KJ wrote: I wonder whether the "arm-linux-" toolchains recommend by the uClinux website can be used for ARM uClinux world. They can, I use them to create running systems. (I always test the GDB/ARMultaor uClinux target with those arm-linux toolchains). The compiler library "libgcc.a" will be an issue. Since XIP code is must for uClinux, the "libgcc.a" must be produced by the XIP compiling flags. No, that is not the case. uClinux binaries do not necessarily have to be XIP. For the FLAT format using targets elf2flt can create binaries that do full relocation at load/run time. And this is the case I normally use. For the XIP cases you won't have the right libgcc.a from those toolchains. You would need to generate a toolchain from source and multilib it for the XIP case you want. For ARM, it will be "-fpic -msingle-pic-base". By objdump inspecting, I found the libgcc.a of the "arm-linux" toolchains on the uClinux website is not compilied by the options. Thats right... When the program calls the functions of libgcc.a, it will be broken in some cases. The easy way to test is to do the "long long" variable division. However, i seldom heard people complain about their toolchains. Why? Or my understanding is wrong? The arm-linux toolchain is really a standard VM linux tool chain. It also happens to work for the non-XIP uClinux case, which is why I use it. (One toolchain for all the arm-linux work I do). Doesn't other architecture have the same issue? It all depends on the toolchain in this case. Unfortunately there is a lot of different binary packages out there (different versions, different patches applied, etc). Some won't compile older uClinux-dist, some won't compile newer, it is a trick to find a combination that works the way you want it to (at least if you don't want to build the toolchain yourself). Regards Greg Greg Ungerer -- Principal EngineerEMAIL: [EMAIL PROTECTED] SnapGear, a McAfee Company 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] Compiler library "libgcc.a" for uClinux
Hi Jamie, Jamie Lokier wrote: Gavin Lambert wrote: dist/vendors/config/armnommu/config.arch" file? Usually in your board-specific config.arch file (not the generic armnommu one -- the one that you selected in the toplevel Makefile) there are three lines like this: # DISABLE_XIP := 1 # XIP works fine # DISABLE_MOVE_RODATA := 1 # move-rodata is fine # DISABLE_SHARED_LIBS := 1 # shared libs are fine Uncomment all three of these to disable XIP. You will also need to do a complete rebuild (make clean), otherwise you can have mixed object files, which cause problems. So we conclude that the tool on uclinux.org does incorrectly compiles the generic ARM-nommu architecture support from uclinux.org? If you go to the uClinux-dist download page and get the latest dist, and then get the arm-linux toolchain linked there, and then target and compile the GDB/ARMulator you get a working image. That is about as generic a ARM-nommu setup you can get... I've been collecting posts related to toolchains from uclinux-dev for a while, so that I have a clue next time I need to find a working toolchain. There are quite a few toolchain branches, and seemingly no reliable authority for compiled toolchains that work for every target variation. Nor even a place where you can be sure all the patches get to "eventually". Back in ye olde days we posted GCC patches to the GCC developers and they appeared in GCC releases :-) Yep, no one seems to do this. Shame on them :-) The toolchain links on uclinux.org are a bit hit-and-miss, depending on what you're building for. Between the lines (it could be more clear) is "Try this toolchain - it works very well for us - but it's work in progress and you'll need a toolchain from somewhere else (find it yourself) for some configurations different to ours". There is a few independant operators working in the toolchain space for non-mmu. Most don't seem to hang out on this list. I'm wondering if uclinux's toolchain page could be a bit more informative about the locations of toolchains that people ought to try, instead of offering a single one and no hint that it's not for everyone? Please send patches for changes. They can be updated just as easily as the code base. Regards Greg ---- Greg Ungerer -- Principal EngineerEMAIL: [EMAIL PROTECTED] SnapGear, a McAfee Company 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] Compiler library "libgcc.a" for uClinux
Hi KJ, Lin KJ wrote: Thanks for your detailed information. But i am still puzzled. You mentioned that the uClinux binaries do not necessarily have to be XIP and can be run on non-XIP mode. How do i switch to run non-XIP uClinux? Bypass the "-fpic -msingle-pic-base" CFLAGS and use some specific elf2flt options? No magic from elf2flt required. Just omit those cflags. If uClinux could be non-XIP, why the "-fpic -msingle-pic-base" cflags were added to the "uClinux-dist/vendors/config/armnommu/config.arch" file? When using the older arm-elf toolchain this was the default. Now you will find that these are overriden in specific target config.arch files. Actually, i am using the "arm-linux-tools-20070808.tar.gz" toolchain downloaded from SnapGear. Yeah, that is what I use. Regards Greg - 原始信件 寄件者： Greg Ungerer <[EMAIL PROTECTED]> 收件者： uClinux development list 寄件日期： 2008/12/4(星期四) 上午7:47:03 主 旨： Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux Hi KJ, Lin KJ wrote: I wonder whether the "arm-linux-" toolchains recommend by the uClinux website can be used for ARM uClinux world. They can, I use them to create running systems. (I always test the GDB/ARMultaor uClinux target with those arm-linux toolchains). The compiler library "libgcc.a" will be an issue. Since XIP code is must for uClinux, the "libgcc.a" must be produced by the XIP compiling flags. No, that is not the case. uClinux binaries do not necessarily have to be XIP. For the FLAT format using targets elf2flt can create binaries that do full relocation at load/run time. And this is the case I normally use. For the XIP cases you won't have the right libgcc.a from those toolchains. You would need to generate a toolchain from source and multilib it for the XIP case you want. For ARM, it will be "-fpic -msingle-pic-base". By objdump inspecting, I found the libgcc.a of the "arm-linux" toolchains on the uClinux website is not compilied by the options. Thats right... When the program calls the functions of libgcc.a, it will be broken in some cases. The easy way to test is to do the "long long" variable division. However, i seldom heard people complain about their toolchains. Why? Or my understanding is wrong? The arm-linux toolchain is really a standard VM linux tool chain. It also happens to work for the non-XIP uClinux case, which is why I use it. (One toolchain for all the arm-linux work I do). Doesn't other architecture have the same issue? It all depends on the toolchain in this case. Unfortunately there is a lot of different binary packages out there (different versions, different patches applied, etc). Some won't compile older uClinux-dist, some won't compile newer, it is a trick to find a combination that works the way you want it to (at least if you don't want to build the toolchain yourself). Regards Greg Greg Ungerer -- Principal EngineerEMAIL:[EMAIL PROTECTED] SnapGear, a McAfee Company PHONE: +61 7 3435 2888 825 Stanley St,FAX:+61 7 3891 3630 Woolloongabba, QLD, 4102, AustraliaWEB: 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 __ 付費才容量無上限？Yahoo!奇摩電子信箱2.0免費給你，信件永遠不必刪！ http://tw.mg0.mail.yahoo.com/dc/landing -- Greg Ungerer -- Principal EngineerEMAIL: [EMAIL PROTECTED] SnapGear, a McAfee Company 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] Compiler library "libgcc.a" for uClinux
Hi KJ, Lin KJ wrote: Thanks for your help again. It seems that there are some tricks on non-XIP uClinux. To run the non-XIP uClinux, I omitted the "-fpic -msingle-pic-base" XIP flags, and specified the "DISABLE_XIP := 1", "DISABLE_MOVE_RODATA := 1" and "DISABLE_SHARED_LIBS := 1" in the board-specific config.arch (someone suggested in the mailing list). You should only need to do this. That will not use the "-fpic -msingle-pic-base" flags after that. After make clean and make, however, it is failed on the elf2flt stage. I got the following repeated error messages. "ERROR: reloc type R_ARM_PC24 unsupported in this context" "ERROR: reloc type R_ARM_PLT32 unsupported in this context" Can you give the exact link line and exact error output? Take a look to the elf2flt source code. I found the "-a" FLTFLAGS was passed to elf2flt by wrapper linker(/usr/local/arm-linux/bin/ld), and elf2flt did the job by "use_resolved" mode. For ARM, under that mode, the relocation type "R_ARM_PC24" and "R_ARM_PLT32" can NOT be recognized. By further checking, it is due to the piece code of wrapper linker. -> if [ "yes" = "yes" ] then $LINKER $EMUL $SDIRS -T $LDSCRIPT -q -o "$OFILE.gdb" $ARG1 ||exit $? RFILE="$OFILE.gdb" -> FLTFLAGS="$FLTFLAGS -a" else if [ "yes" = "no" ] then $LINKER $EMUL $SDIRS -T $LDSCRIPT -Ur -d -o "$OFILE.elf" $ARG1 ||exit $? $LINKER $EMUL $SDIRS -T $LDSCRIPT -o "$OFILE.gdb" $ARG1 ||exit $? else $LINKER $EMUL -r -d -o "$OFILE.elf2flt" $ARG1 ||exit $? $LINKER $EMUL $SDIRS -T $LDSCRIPT -Ur -o "$OFILE.elf" "$OFILE.elf2flt" ||exit $? $LINKER $EMUL $SDIRS -T $LDSCRIPT -o "$OFILE.gdb" "$OFILE.elf2flt" ||exit $? rm -f "$OFILE.elf2flt" fi The wrapper linker always passes the "-a" option to the elf2flt and cause the bad resolved relocation messages for R_ARM_PC24 and R_ARM_PLT32. If i want to run the non-XIP uClinux, should i change the wrapper linker code? If yes, i should modify it to ["yes" = "no"] mode? or else mode? I dunno, I wouldn't have expected that you needed to do any more. Regards Greg - 原始信件 寄件者： Greg Ungerer <[EMAIL PROTECTED]> 收件者： Lin KJ <[EMAIL PROTECTED]> 副 本： uClinux development list 寄件日期： 2008/12/4(星期四) 下午8:00:18 主 旨： Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux Hi KJ, Lin KJ wrote: Thanks for your detailed information. But i am still puzzled. You mentioned that the uClinux binaries do not necessarily have to be XIP and can be run on non-XIP mode. How do i switch to run non-XIP uClinux? Bypass the "-fpic -msingle-pic-base" CFLAGS and use some specific elf2flt options? No magic from elf2flt required. Just omit those cflags. If uClinux could be non-XIP, why the "-fpic -msingle-pic-base" cflags were added to the "uClinux-dist/vendors/config/armnommu/config.arch" file? When using the older arm-elf toolchain this was the default. Now you will find that these are overriden in specific target config.arch files. Actually, i am using the "arm-linux-tools-20070808.tar.gz" toolchain downloaded from SnapGear. Yeah, that is what I use. Regards Greg - 原始信件 寄件者： Greg Ungerer <[EMAIL PROTECTED]> 收件者： uClinux development list 寄件日期： 2008/12/4(星期四) 上午7:47:03 主 旨： Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux Hi KJ, Lin KJ wrote: I wonder whether the "arm-linux-" toolchains recommend by the uClinux website can be used for ARM uClinux world. They can, I use them to create running systems. (I always test the GDB/ARMultaor uClinux target with those arm-linux toolchains). The compiler library "libgcc.a" will be an issue. Since XIP code is must for uClinux, the "libgcc.a" must be produced by the XIP compiling flags. No, that is not the case. uClinux binaries do not necessarily have to be XIP. For the FLAT format using targets elf2flt can create binaries that do full relocation at load/run time. And this is the case I normally use. For the XIP cases you won't have the right libgcc.a from those toolchains. You would need to generate a toolchain from source and multilib it for the XIP case you want. For ARM, it will be "-fpic -msingle-pic-base". By objdump inspecting, I found the libgcc.a of the "arm-linux" toolchains on the uClinux website is not compili
Re: [uClinux-dev] uncompressed kernel and rootfs
Hi Guo, Guo Tang wrote: In uclinux, both kernel and initramfs are compressed. I am wondering whether there is a configuration option to use uncompressed kernel and initramfs? Or could someone point to me where to change in order to enable this? Generally the final packaging (of kernel and filesystem) in uClinux-dist is handled by the vendor/board specific Makefile. You find these in ~/vendors///Makefile It is normally done in whatever form is the most common for the boot loader of that particular board. And this varies alot across the different boot loaders and architectures. I prefer uncompressed kernel and initramfs because in our design, the move of kernel and initramfs from flash to ram is fast (with hardware DMA), but our CPU is slow. And boot time is more important than saving flash size. Look around those Makefiles under ~/vendors/... for various ways it is done. Compressed or not is no problem really. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: [EMAIL PROTECTED] SnapGear, a McAfee Company 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: Fw: [uClinux-dev] Compiler library "libgcc.a" for uClinux
Hi KJ,
Lin KJ wrote:
I tried to compile the uClinux-dist(20080808)/user/flthdr as my testing.
And i got the following error messages.
# make user_only
make[3]: Entering directory `/home/kjlin/tmp/new/uClinux-dist/user/flthdr'
ucfront-gcc arm-linux-gcc -Os -g -fomit-frame-pointer
-pipe -msoft-float -fno-common -fno-builtin -Wall -DEMBED -Dlinux -D__linux__
-Dunix -D__uClinux__ -c -o flthdr.o flthdr.c
flthdr.c:44: warning: short_format defined but not used
ucfront-gcc arm-linux-gcc -Wl,-elf2flt -msoft-float -Wl,-elf2flt -msoft-float
-o flthdr flthdr.o
ERROR: reloc type R_ARM_PC24 unsupported in this context
ERROR: reloc type R_ARM_PC24 unsupported in this context
...
...
ERROR: reloc type R_ARM_PLT32 unsupported in this context
ERROR: reloc type R_ARM_PLT32 unsupported in this context
ERROR: reloc type R_ARM_PLT32 unsupported in this context
ERROR: reloc type R_ARM_PC24 unsupported in this context
...
...
ERROR: reloc type R_ARM_PC24 unsupported in this context
470 bad relocs
collect2: ld returned 1 exit status
Once i modified the wrapper linker code to bypass the elf2flt "-a" flag
mentioned last discussion,
the building process was fine.
I wonder if the default wrapper linker of "arm-linux" toolchain can be used for
non-XIP uClinux.
By the way, have you ever tested the "long long" variable division under
non-XIP mode?
No, not that I recall...
Regards
Greg
I tried the following code:
#include
void main(void)
{
long long a,b;
a=100;b=3;
printf("res: %d\n",a/b);
}
It will cause the "Illegal instruction" error while executing.
Listed its symbols by "arm-linux-nm test.gdb" and found that the
"_GLOBAL_OFFSET_TABLE_" was one of the symbols.
It should NOT be there and I think it is the reason that "Illegal instruction"
happened.
However, when i change the "long long" to "long" variable everything is fine.
Nor more "_GLOBAL_OFFSET_TABLE_" is in the symbols list and executed correctly.
Regards,
KJ
- 原始信件
寄件者： Greg Ungerer <[EMAIL PROTECTED]>
收件者： Lin KJ <[EMAIL PROTECTED]>
副 本： uclinux-dev@uclinux.org
寄件日期： 2008/12/5(星期五) 下午1:24:03
主 旨： Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux
After make clean and make, however, it is failed on the elf2flt stage.
I got the following repeated error messages.
"ERROR: reloc type R_ARM_PC24 unsupported in this context"
"ERROR: reloc type R_ARM_PLT32 unsupported in this context"
Can you give the exact link line and exact error output?
Take a look to the elf2flt source code.
I found the "-a" FLTFLAGS was passed to elf2flt by wrapper
linker(/usr/local/arm-linux/bin/ld),
and elf2flt did the job by "use_resolved" mode.
For ARM, under that mode, the relocation type "R_ARM_PC24" and "R_ARM_PLT32"
can NOT be recognized.
By further checking, it is due to the piece code of wrapper linker.
->if [ "yes" = "yes" ]
then
$LINKER $EMUL $SDIRS -T $LDSCRIPT -q -o "$OFILE.gdb" $ARG1
||exit $?
RFILE="$OFILE.gdb"
-> FLTFLAGS="$FLTFLAGS -a"
else
if [ "yes" = "no" ]
then
$LINKER $EMUL $SDIRS -T $LDSCRIPT -Ur -d -o "$OFILE.elf"
$ARG1||exit $?
$LINKER $EMUL $SDIRS -T $LDSCRIPT -o "$OFILE.gdb" $ARG1
||exit $?
else
$LINKER $EMUL -r -d -o "$OFILE.elf2flt" $ARG1
||exit $?
$LINKER $EMUL $SDIRS -T $LDSCRIPT -Ur -o "$OFILE.elf"
"$OFILE.elf2flt" ||exit $?
$LINKER $EMUL $SDIRS -T $LDSCRIPT -o "$OFILE.gdb"
"$OFILE.elf2flt"||exit $?
rm -f "$OFILE.elf2flt"
fi
The wrapper linker always passes the "-a" option to the elf2flt and cause the
bad resolved relocation messages for R_ARM_PC24 and R_ARM_PLT32.
If i want to run the non-XIP uClinux, should i change the wrapper linker code?
If yes, i should modify it to ["yes" = "no"] mode? or else mode?
I dunno, I wouldn't have expected that you needed to do any
more.
Regards
Greg
- 原始信件
寄件者： Greg Ungerer <[EMAIL PROTECTED]>
收件者： Lin KJ <[EMAIL PROTECTED]>
副 本： uClinux development list
寄件日期： 2008/12/4(星期四) 下午8:00:18
主 旨： Re: [uClinux-dev] Compiler library "libgcc.a" for uClinux
Hi KJ,
Lin KJ wrote:
Thanks for your detailed information.
But i am still puzzled.
You mentioned that the uClinux binaries do not necessarily have to be XIP and
can be run on non-XIP mode.
How do i switch to run non-XIP uClinux? Byp
Re: [uClinux-dev] Re: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm
Allon Stern wrote: On Dec 9, 2008, at 12:39 PM, Geert Uytterhoeven wrote: Sure, but that one is nicely protected by "#if defined (__mcfisaaplus__) || defined (__mcfisac__)", right? Well, that was the patch we had to apply. It wasn't in the baseline kernel.org kernel. What kernel.org version? Its has been in for a little while. In 2.6.28-rc8: grep mcfisaaplus arch/m68knommu/include/asm/* arch/m68knommu/include/asm/bitops.h:#if defined (__mcfisaaplus__) || defined (__mcfisac__) arch/m68knommu/include/asm/byteorder.h:#if defined (__mcfisaaplus__) || defined (__mcfisac__) Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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: Merge headerfiles for m68k and m68knommu to arch/m68k/include/asm
Geert Uytterhoeven wrote:
On Tue, 9 Dec 2008, Sam Ravnborg wrote:
On Tue, Dec 09, 2008 at 12:26:05AM +0100, Arnd Bergmann wrote:
On Tuesday 09 December 2008, Geert Uytterhoeven wrote:
I have used the following include guard:
#ifdef __uClinux__
#include "atomic_no.h"
#else
#include "atomic_mm.h"
#endif
gcc -E -dM for the two compilers revealed that this was the
only symbol that differed.
I think you can share a toolchain for m68k and m68knommu, at least for the
kernel (I used my plain m68k toolchain when experimenting with m68knommu for
Amiga).
With the above construct we do the "right thing" also for
headers exported to userspace.
But actually none of the headers using the above are
subject for export at the moment so we could use a
CONFIG_ symbol for the same.
So I prefer to just check CONFIG_MMU.
Some of them are, by means of include/asm-generic/Kbuild.asm, e.g.
unistd.h!
I was fooled by make headers_check showing no errros.
But it turns out that headers_check does not recognize
includes made with "".
So I will update the patch to include revevant *_{no,mm}.h files
in Kbuild.
I'm not sure if it's entirely correct, but I think you can use
#ifdef __KERNEL__
# ifdef CONFIG_MMU
# include "atomic_mm.h
# else
# include "atomic_no.h
# endif
#else
# ifndef __uClinux__
# include "atomic_mm.h
# else
# include "atomic_no.h
# endif
#endif
Can someone with a shared (m68k/m68knommu) please check if
__uClinux__ is only set in the m68knommu case.
Use:
touch foo.h; gcc -E -dM
to see what is defined by the compiler.
You will also need to specify if this is for m68k or m68knommu.
Any comments from the m68knommu toolchain people?
>
None of my m68k-linux compilers set __uClinux__, as expected.
A m68k-uclinux- gcc will. From a gcc-4.2.4
m68k-uclinux-gcc -E -dM /tmp/foo.h | grep -i linux
#define __linux 1
#define __linux__ 1
#define __uClinux__ 1
#define __gnu_linux__ 1
#define linux 1
(I think that is one of the very few differences of m68k-linux
over m68k-uclinux...)
I would rather just have a m68k-linux myself, and not have a
separate m68k-uclinux toolchain.
Regards
Greg
----
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company 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] Intermittent behavior with the netflash command
Hi, b2112 wrote: I'm using the uClinux 2.4 kernel in my application and I'm trying to use the netflash command to program flash remotely. I'm noticing inconsistent results with the netflash command across several boards of the same board type and revision. With some boards it works on the first try, others it either takes a couple of times or it doesn't work at all. I've tried using the command two ways thru a telnet session to the remote device, netflash –bCknr /dev/rom# and netflash –bknr /dev/rom# . In some cases the –C displays the verified data to the screen, other times it doesn't. Any ideas as to what could be wrong? Does the netflash command have any known issues? None specific that I know of. And I use it a _lot_. Not sure what version/variant of it you are using. It is has been continuously enhanced and added to for the last 10 odd years... Is there any chance that the underlying flash segments may be locked? If so then you may want to supply the "-u" switch. Are you sure that the underlying blkmem/mtd driver for your flash is bug free? Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] serial console as default console
Hi Andrei, Andrei Martynov wrote: I'm porting Sigma EM85XX patches from 2.4.17 to 2.6.24 kernel. The kernel is configured as # # Input device support # # CONFIG_INPUT is not set # # Character devices # # CONFIG_VT is not set # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # # CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=4 CONFIG_SERIAL_JASPER=y CONFIG_SERIAL_JASPER_CONSOLE=y CONFIG_SERIAL_JASPER_SERIAL_BAUDRATE=38400 and uses serial console during boot (console=ttyS0). I can see all boot messages until the warning "unable to open an initial console", but then only errors are displayed. My init script in the intiramfs looks like: mount -t proc proc /proc mount -t sysfs sysfs /sys busybox --install -s mknod /dev/null c 1 3 mknod /dev/console c 5 1 mdev -s exec sh and etc/inittab has a line ::respawn:getty -L ttyS0 38400 ^ Do you have a /dev/ttyS0 device in your root fs? Regards Greg I've added debug output to exec() and can see that the commands are executed exec: (/init) /init | exec code: 0 exec: (/bin/sh) mount -t proc proc /proc | exec code: 0 exec: (/bin/sh) mount -t sysfs sysfs /sys | exec code: 0 exec: (busybox) busybox --install -s | exec failed code -2 exec: (/bin/busybox) busybox --install -s | exec code: 0 exec: (/bin/sh) mknod /dev/null c 1 3 | exec code: 0 exec: (/bin/sh) mknod /dev/console c 5 1 | exec code: 0 exec: (/bin/sh) mdev -s | exec code: 0 exec: (/bin/sh) sh | exec code: 0 but it results in Kernel panic - not syncing: Attempted to kill init! Any ideas what I did wrong? -- -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] DQ5 Checks in mtd drivers
Hi Glen, Glenn Henshaw wrote: On 6-Jan-09, at 2:17 AM, Peter Turczak wrote: do you use CFI to detect your SST-Flash? I stumbled on this problem half a year ago on 2.6.x, I found out that SST has quite an interesting interpretation of the CFI-Standard. Their devices have both sectors and eraseblocks, and their CFI-Struct lists both, so the sum of all sector sizes appears to be the double of what the devices reports as its capacity and the kernel rejects it. Please find attached my patch for this, it is for 2.6.x but it will show the idea. It will partially disable CFI for the device and override the number of eraseblock sizes, then the detections works. Thanks, The 2.4 code I inherited, only uses one of the erase block sizes, so detection is not an issue. The problems I am seeing are related to the new checks for DQ5 being high after an erase / write cycle. This is not supported on the SST part, and I have removed them. Further, the 39VF640x parts have a slightly different command set. From the perspective of pushing the code back upstream, what is the best way to handle the differences in parts? Or does anyone care? The best place to ask would be on the MTD mailing list. I am sure someone cares :-) Regards Greg ... Glenn Greetings Peter On Jan 5, 2009, at 11:42 PM, Glenn Henshaw wrote: I have just managed to update a system from an older 2.4 kernel to the most recent 2.4.34.5-uc0 version. It looks like there were some checks added to the AMD FLASH drivers that totally break SST FLASH devices. 1) Where is the best place to complain? Was the old functionality hidden somewhere? 2) Where is the best place to submit the patch to support SST 39VF320x and 39VF640x devices? ... Glenn -- Glenn Henshaw Logical Outcome Ltd. e: li...@logicaloutcome.ca w: www.logicaloutcome.ca ___ 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, a McAfee Company 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] Latest good version of Snapgear
Hi Dave, Dave Rensberger wrote: Sorry if this has already been covered, but what should be considered the latest stable snapgear release? The web page says it's the 3.5.0 release, but the ftp site contains a newer one called "snapgear-20080711". The 20080711 package is a code snapshot. It is much newer than 3.5.0. (And IIRC it contains a newer samba package). Try it, it should be very close to the uClinux-dist-20080808 release. Though I suspect that the samba in there doesn't work on non-MMU systems. Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] uClinux 2.6.25-uc0 performance problem on MCF 5274/5275
Hi Alexander, Alexander Eremeenkov wrote: I have performance problems with applications on this kernel(uClinux 2.6.25-uc0). First of all, I have custom made board with this features: ColdFire 5274 @ 150 MHz External Bus Frequency 75 MHz uClinux 2.6.25 boot up and work perfectly stable, but very slow. For this board i have also 2.4.x kernel compiled, and it works more faster ( ~ 2-20 times faster, if different test application). After reading maillist, i find, that some people have equals problems, and their reason were - disabled cache. But in my case, cache enabled in start process normally. Calibration delay calculate good value: Calibrating delay loop... 98.71 BogoMIPS (lpj=493568) Also, if i disabled cache in /include/asm-m68knommu/mcfcache.h, i got looks-like normal, with disabled cache, value: Calibrating delay loop... 5.82 BogoMIPS So, I have drawn a conclusion, that cache enables good. Now, about performance. I test it with some applications. 1. Dhrystone test. With it, i have 4065 dhrystones/second, that critically small for this CPU. But i curious, that, when a disabled cache, the result same.. As though like cache at just flushed or worked incorrect. 2. Simple forever cycle with 1 value in memory incremented. This test, also show near ~5 real MISP performance. When i try to watch assess to external memory by CPU, i saw, that, it work with external RAM(where this application contain) everytime - but i think that, simple application with 5 command + 1 value memory must being in cache, and CPU must work with cache only. 3. Some real/work application. They do massive processing/moving data, working with peripheral, etc. I also have quite bad performance. Those applications runs at 2.4.x kernel at ~4 times faster. So, conclusion with it. 1) I think, that i can't have problems with hardware - because, 2.4.x kernel work fast. 2) I have enabled cache at start process - 98 BogoMIPS good value for my CPU, also 2.4 kernel calculate same result. Now i have question, maybe somebody have same problems at this kernel? Maybe 2.6.xx so slow, and ways to speed up it use old kernel or modern/faster CPU?Maybe some bugs in poring it to ColdFire family?Etc? There is no reason that application code performance (independant of use of kernel system calls) should give noticably different results on a 2.6 kernel vs a 2.4 kernel. Maybe it problem with cache at working process? Some drivers, for example, can flush cache..anyone have equal problem? About it, i will check it with kernel build for 5275EVB, but i think, that result will be same, because, a removed all i can drivers/modules form kernel, that almost "empty" kernel starts, and after it i run Dhrystone test, and get same result. Maybe it's a toolchain problem? I use m68k-uclinux-tools-20061214.sh, they have some minor problems, maybe reason with they? But, my second test with simple application excludes this variant. If someone had those problems I will be glad for any help. I recall a problem a little while back where the cache flush code was changing the cache configuration and not just flushing. (I think it was the 5282 cache support code that was broken). In this scenario the initial cache setup was good (so everything was fast), and after the first cache flush the setup was wrong. Now that would make something like the bogomips calculation look good, but later performance bad Looking at the 2 places this is done: linux-2.6.x/include/asm-m68knommu/mcfcache.h linux-2.6.x/include/asm-m68knommu/cacheflush.h I suspect this may have broken the cache support for the 527x series (so the 5270/5271 and 5274/5275). To verify if this is what you are seeing, can you change the cache flush code for CONFIG_M527x in cacheflush.h from: "movel #0x81000200, %%d0\n\t" to "movel #0x81400100, %%d0\n\t" This is just to prove this is the problem. A real fix would need the 528x and 527x cache flushing code separated out. Regards Greg And my kernel messages at result: /> cat /proc/kmsg <5>Linux version 2.6.25-uc0 (wa...@arch) (gcc version 4.1.1) #36 Mon Jan 5 13:05:16 PST 9 <6> <4> <4>uClinux/COLDFIRE(m5274/5275) <6>COLDFIRE port done by Greg Ungerer, g...@snapgear.com <6>Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne <7>On node 0 totalpages: 8192 <7> DMA zone: 0 pages used for memmap <7> Normal zone: 64 pages used fo
Re: [uClinux-dev] Problem with romfs
Hi Stephane, Stephane Lambert wrote: Thanks for your answer. Does the CONFIG_BLKMEM available for kernel 2.6? blkmem.c exists for kernel 2.4 but I haven't found it in kernel 2.6. No, there is no blkmem driver for 2.6. In its place use the mtd/maps/uclinux.c driver. Regards Greg Jate Sujjavanich a écrit : Is CONFIG_BLKMEM enabled? ___ 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, a McAfee Company 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] Problem with romfs
Hi Andrei, Andrei Martynov wrote: isn't it at the end the same as standard map_rom / map_ram drivers? Yes, it uses those. uclinux.c map driver gives you the dynamic setup of your attached ROMfs if you tacked it onto the end of your load image (that is it sits in RAM at _ebss). Regards Greg Monday, January 12, 2009, 11:51:32 AM, you wrote: No, there is no blkmem driver for 2.6. In its place use the mtd/maps/uclinux.c driver. -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] Memory allocators
Hi Andrei, Andrei Martynov wrote: is SLAB the only working allocator on NOMMU? There was a discussion some time ago and Greg mentioned that others are broken. I haven't looked at this for a while now. It would be good to see if anything has improved in more modern kernels... Regards Greg -- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] uClinux 2.6.25-uc0 performance problem on MCF 5274/5275
Hi Alex, Alex Eremeenkov wrote: Thanks a lot. Problem were with cache flushing, how you say. But i have one more question. It is able to add support of split D-cache&I-cache by enbling it in mcfcache.h and writing additional functions for flushing each cache region (add support for functions __flush_icache_all and __flush_dcache_all)? Or for enable D-cache it need some serious patch to kernel? Its possible to do. It has been on my todo list for a while. A long time back it broke things like te FEC ethernet driver (which needs proper fixing). Regards Greg 2008/10/5 Greg Ungerer mailto:g...@snapgear.com>> Hi Alexander, Alexander Eremeenkov wrote: I have performance problems with applications on this kernel(uClinux 2.6.25-uc0). First of all, I have custom made board with this features: ColdFire 5274 @ 150 MHz External Bus Frequency 75 MHz uClinux 2.6.25 boot up and work perfectly stable, but very slow. For this board i have also 2.4.x kernel compiled, and it works more faster ( ~ 2-20 times faster, if different test application). After reading maillist, i find, that some people have equals problems, and their reason were - disabled cache. But in my case, cache enabled in start process normally. Calibration delay calculate good value: Calibrating delay loop... 98.71 BogoMIPS (lpj=493568) Also, if i disabled cache in /include/asm-m68knommu/mcfcache.h, i got looks-like normal, with disabled cache, value: Calibrating delay loop... 5.82 BogoMIPS So, I have drawn a conclusion, that cache enables good. Now, about performance. I test it with some applications. 1. Dhrystone test. With it, i have 4065 dhrystones/second, that critically small for this CPU. But i curious, that, when a disabled cache, the result same.. As though like cache at just flushed or worked incorrect. 2. Simple forever cycle with 1 value in memory incremented. This test, also show near ~5 real MISP performance. When i try to watch assess to external memory by CPU, i saw, that, it work with external RAM(where this application contain) everytime - but i think that, simple application with 5 command + 1 value memory must being in cache, and CPU must work with cache only. 3. Some real/work application. They do massive processing/moving data, working with peripheral, etc. I also have quite bad performance. Those applications runs at 2.4.x kernel at ~4 times faster. So, conclusion with it. 1) I think, that i can't have problems with hardware - because, 2.4.x kernel work fast. 2) I have enabled cache at start process - 98 BogoMIPS good value for my CPU, also 2.4 kernel calculate same result. Now i have question, maybe somebody have same problems at this kernel? Maybe 2.6.xx so slow, and ways to speed up it use old kernel or modern/faster CPU?Maybe some bugs in poring it to ColdFire family?Etc? There is no reason that application code performance (independant of use of kernel system calls) should give noticably different results on a 2.6 kernel vs a 2.4 kernel. Maybe it problem with cache at working process? Some drivers, for example, can flush cache..anyone have equal problem? About it, i will check it with kernel build for 5275EVB, but i think, that result will be same, because, a removed all i can drivers/modules form kernel, that almost "empty" kernel starts, and after it i run Dhrystone test, and get same result. Maybe it's a toolchain problem? I use m68k-uclinux-tools-20061214.sh, they have some minor problems, maybe reason with they? But, my second test with simple application excludes this variant. If someone had those problems I will be glad for any help. I recall a problem a little while back where the cache flush code was changing the cache configuration and not just flushing. (I think it was the 5282 cache support code that was broken). In this scenario the initial cache setup was good (so everything was fast), and after the first cache flush the setup was wrong. Now that would make something like the bogomips calculation look good, but later performance bad Looking at the 2 places this is done: linux-2.6.x/include/asm-m68knommu/mcfcache.h linux-2.6.x/include/asm-m68knommu/cacheflush.h I suspect this may have broken the cache support for the 527x series (so the 5270/5271 and 5274/5275). To verify if this is what you are seeing, can you change the cache flush code for CONFIG_M527x in cacheflush.h from: "movel #0x81000200, %%d0\n\t" to "movel
Re: [uClinux-dev] Memory allocators
Greg Ungerer wrote: Hi Andrei, Andrei Martynov wrote: is SLAB the only working allocator on NOMMU? There was a discussion some time ago and Greg mentioned that others are broken. I haven't looked at this for a while now. It would be good to see if anything has improved in more modern kernels... I should have look at my recent kernel configs before I wrote that :-) I have quite a few using SLUB, and that seems to work well. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] uClinux 2.6.25-uc0 performance problem on MCF 5274/5275
Hi Alex,
Alex Eremeenkov wrote:
It is any possible to get earliest sources which implements D&I cache
enabled?It was be on 2.4.x kernel?
That was years ago I tried that, I no longer have the changes.
Regards
Greg
I try to do minor patch for adding split cache support, but kernel don't
start.
Change in mcfcache.h:
"movel #0x80400100, %%d0\n\t"
to
"movel #0x8100, %%d0\n\t" /* Split cache enable */
Change in cacheflush.h:
"movel #0x81400100, %%d0\n\t"
to
"movel #0x81000100, %%d0\n\t" /* Invalidate D&I cache */
Also add support to flush_icache_range & flush_dcache_range that
invalidates needed parts of cache.
I think that kernel don't want to start during incomplete implementation
of flush_* functions. Or it's a additional place where need to patch?
Or i do something wrong?
2009/1/12 Greg Ungerer mailto:g...@snapgear.com>>
Hi Alex,
Alex Eremeenkov wrote:
Thanks a lot. Problem were with cache flushing, how you say.
But i have one more question. It is able to add support of split
D-cache&I-cache by enbling it in mcfcache.h and writing
additional functions for flushing each cache region (add support
for functions __flush_icache_all and __flush_dcache_all)? Or for
enable D-cache it need some serious patch to kernel?
Its possible to do. It has been on my todo list for a while.
A long time back it broke things like te FEC ethernet driver
(which needs proper fixing).
Regards
Greg
2008/10/5 Greg Ungerer mailto:g...@snapgear.com> <mailto:g...@snapgear.com
<mailto:g...@snapgear.com>>>
Hi Alexander,
Alexander Eremeenkov wrote:
I have performance problems with applications on this
kernel(uClinux 2.6.25-uc0).
First of all, I have custom made board with this features:
ColdFire 5274 @ 150 MHz
External Bus Frequency 75 MHz
uClinux 2.6.25 boot up and work perfectly stable, but
very slow.
For this board i have also 2.4.x kernel compiled, and it
works
more faster ( ~ 2-20 times faster, if different test
application).
After reading maillist, i find, that some people have equals
problems, and their reason were - disabled cache. But in my
case, cache enabled in start process normally.
Calibration delay calculate good value:
Calibrating delay loop... 98.71 BogoMIPS (lpj=493568)
Also, if i disabled cache in
/include/asm-m68knommu/mcfcache.h,
i got looks-like normal, with disabled cache, value:
Calibrating delay loop... 5.82 BogoMIPS
So, I have drawn a conclusion, that cache enables good.
Now, about performance. I test it with some applications.
1. Dhrystone test. With it, i have 4065
dhrystones/second, that
critically small for this CPU. But i curious, that, when a
disabled cache, the result same.. As though like cache at
just
flushed or worked incorrect.
2. Simple forever cycle with 1 value in memory
incremented. This
test, also show near ~5 real MISP performance.
When i try to watch assess to external memory by CPU, i saw,
that, it work with external RAM(where this application
contain)
everytime - but i think that, simple application with 5
command
+ 1 value memory must being in cache, and CPU must work with
cache only.
3. Some real/work application. They do massive
processing/moving
data, working with peripheral, etc. I also have quite bad
performance. Those applications runs at 2.4.x kernel at
~4 times
faster.
So, conclusion with it.
1) I think, that i can't have problems with hardware -
because,
2.4.x kernel work fast.
2) I have enabled cache at start process - 98 BogoMIPS good
value for my CPU, also 2.4 kernel calculate same result.
Now i have question, maybe somebody have same problems at
this
kernel?
Maybe 2.6.xx so slow, and ways to speed up it use old
kernel or
modern/faster CPU?Maybe some bugs in poring it to ColdFire
family?Etc?
There is no reason that application code performance
(independant of
use of kernel system calls) should give noticably different
results
on a 2.6 kernel vs a 2.4 kernel.
Maybe it problem with cache at w
Re: [uClinux-dev] Re: Latest good version of Snapgear
Hi Dave, Dave Rensberger wrote: The 20080711 package is a code snapshot. It is much newer than 3.5.0. (And IIRC it contains a newer samba package). Try it, it should be very close to the uClinux-dist-20080808 release. Though I suspect that the samba in there doesn't work on non-MMU systems. Greg, Thanks for your reply. To be clear, I'm not actually trying to run samba on a non-MMU system (right now it's an x86 system). The reason I'm using Snapgear, is because I'd like my system to remain small, and I'd like to have the option to do a relatively painless port to ARM at some point. Ok. Do you have any pointers to Samba patches that will allow it to work on a uClibc based system with an MMU? Surely there must be people out there doing this for small/cheap NAS boxes. The samba soure in the uClinux-dist-20080808 is patched to work (with uClibc) and runs on MMU systems. (The snapgear package releases are the same as the uClinux-dist packages). Alternately, are there any plans to re-introduce glibc into snapgear? I could deal with the increase in image footprint that would come with snapgear+glibc, but I'm not really ready to accept the footprint increase that would come with using some of the larger glibc based Linux distros (DENX, Debian, etc.). Well, actually, there is... Upcoming patch sets for the uClinux-dist will have support for building glibc again (via a download when wanted machanism - instead of glibc source in the package). I don't know exactly when the next patch for that will do up. But I am hoping for sometime in the next couple of weeks. Regards Gerg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] Memory allocators
Hi Andrei, Andrei Martynov wrote: what kernel version with what patches can be used for ARM NOMMU target? I'm using 2.6.24, SLUB is broken there. I am using SLUB on ColdFire(m68knommu) targets with 2.6.26-uc0. I haven't tried SLUB on ARM nommu yet. Regards Greg Monday, January 12, 2009, 2:30:31 PM, you wrote: Greg Ungerer wrote: Hi Andrei, Andrei Martynov wrote: is SLAB the only working allocator on NOMMU? There was a discussion some time ago and Greg mentioned that others are broken. I haven't looked at this for a while now. It would be good to see if anything has improved in more modern kernels... I should have look at my recent kernel configs before I wrote that :-) I have quite a few using SLUB, and that seems to work well. Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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 -- -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] m68k: wire up sys_restart_syscall (fwd)
Hi Geert,
Geert Uytterhoeven wrote:
FYI...
Thanks for the pointer. I have tested and queued up a similar
change for m68knommu.
Regards
Greg
-- Forwarded message --
Date: Mon, 29 Dec 2008 19:34:57 +0100
From: Andreas Schwab
To: linux-m...@vger.kernel.org
Subject: [PATCH] m68k: wire up sys_restart_syscall
Make restart blocks working, required for proper syscall restarting.
Signed-off-by: Andreas Schwab
---
arch/m68k/kernel/entry.S |2 +-
arch/m68k/kernel/signal.c | 15 +++
include/asm-m68k/unistd.h |4 +---
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
index f28404d..5b78082 100644
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -424,7 +424,7 @@ resume:
.data
ALIGN
sys_call_table:
- .long sys_ni_syscall/* 0 - old "setup()" system call*/
+ .long sys_restart_syscall /* 0 - old "setup()" system call, used
for restarting */
.long sys_exit
.long sys_fork
.long sys_read
diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
index d1e9220..842bfd9 100644
--- a/arch/m68k/kernel/signal.c
+++ b/arch/m68k/kernel/signal.c
@@ -348,6 +348,9 @@ restore_sigcontext(struct pt_regs *regs, struct sigcontext
__user *usc, void __u
struct sigcontext context;
int err;
+ /* Always make any pending restarted system calls return -EINTR */
+ current_thread_info()->restart_block.fn = do_no_restart_syscall;
+
/* get previous context */
if (copy_from_user(&context, usc, sizeof(context)))
goto badframe;
@@ -433,6 +436,9 @@ rt_restore_ucontext(struct pt_regs *regs, struct
switch_stack *sw,
unsigned long usp;
int err;
+ /* Always make any pending restarted system calls return -EINTR */
+ current_thread_info()->restart_block.fn = do_no_restart_syscall;
+
err = __get_user(temp, &uc->uc_mcontext.version);
if (temp != MCONTEXT_VERSION)
goto badframe;
@@ -959,6 +965,15 @@ handle_restart(struct pt_regs *regs, struct k_sigaction
*ka, int has_handler)
regs->d0 = -EINTR;
break;
+ case -ERESTART_RESTARTBLOCK:
+ if (!has_handler) {
+ regs->d0 = __NR_restart_syscall;
+ regs->pc -= 2;
+ break;
+ }
+ regs->d0 = -EINTR;
+ break;
+
case -ERESTARTSYS:
if (has_handler && !(ka->sa.sa_flags & SA_RESTART)) {
regs->d0 = -EINTR;
diff --git a/include/asm-m68k/unistd.h b/include/asm-m68k/unistd.h
index 965abb8..3c19027 100644
--- a/include/asm-m68k/unistd.h
+++ b/include/asm-m68k/unistd.h
@@ -5,6 +5,7 @@
* This file contains the system call numbers.
*/
+#define __NR_restart_syscall 0
#define __NR_exit1
#define __NR_fork2
#define __NR_read3
@@ -359,9 +360,6 @@
#define __ARCH_WANT_SYS_SIGPROCMASK
#define __ARCH_WANT_SYS_RT_SIGACTION
-/* whitelist for checksyscalls */
-#define __IGNORE_restart_syscall
-
/*
* "Conditional" syscalls
*
--
----
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company 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] linux-2.6.26-uc0 M5329EVB patch 1/6
Hi Matt, Sam, Matt Waddel wrote: Hi Sam, Sam Ravnborg wrote: On Sat, Dec 20, 2008 at 07:16:31AM -0700, Matt Waddel wrote: This patch fixes a build error with the latest (4.3.2-45) toolchain. .text.unlikely is required in the linker script. Is this a general thing or specific to uclinux? For now I've only encountered it in the latest uClinux toolchain released from CodeSourcery. If it is general it belongs to: include/asm-generic/vmlinux.lds.h It might belong in the generic vmlinux.lds.h, but I'm reluctant to make this change global until I'm sure it doesn't break other system. This is already in the generic vmlinux.lds.h (came in with commit 6948385cbd83201fb933125c1a578b29b456605d back in July). Its in the TEXT_TEXT macro. So this local change for m68knommu should not be required for newer kernels. Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] linux-2.6.26-uc0 M5329EVB patch 2/6
Hi Matt, Matt Waddel wrote: This patch removes a lot of the unused code in the 532x config.c file. The only real change is to disable all the interrupts on start up. Looks good. I would like to commit it has 2 changes though. One to fix the incorrect adding of MCF_MBAR, and the other the clean up. Do you want to send it to me as 2 changes, or do you want me to go ahead and do it? I'll add your "Signed-off-by" to if thats ok? Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] linux-2.6.26-uc0 M5329EVB patch 3/6
Hi Matt, Matt Waddel wrote: This patch fixes the M5329 timer interrupt assignment. > --- linux-2.6.x.orig/arch/m68knommu/platform/coldfire/timers.c 2008-07-13 15:51:29.0 -0600 +++ linux-2.6.x/arch/m68knommu/platform/coldfire/timers.c 2008-12-18 21:31:52.0 -0700 @@ -35,8 +35,13 @@ * CPU's and some boards may want different. Their sub-architecture * startup code (in config.c) can change these if they want. */ +#if defined(CONFIG_M532x) +unsigned int mcf_timervector = 64+32; +unsigned int mcf_profilevector = 64+33; +#else unsigned int mcf_timervector = 29; unsigned int mcf_profilevector = 31; +#endif unsigned int mcf_timerlevel = 5; /* The code to do this was in .../532x/config.c, but you removed those lines in your previous patch. The idea is to keep CPU specific #ifdefs out of this common timer code, and only have to set it in the CPU specific config.c Or did I miss something here? Regards Greg ---- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] linux-2.6.26-uc0 M5329EVB patch 6/6
Hi Matt, Matt Waddel wrote: This patch adds the CONFIG_MTD_UCLINUX and CONFIG_MTD_UCLINUX_EBSS options to the mtd menu. > --- linux-2.6.x.orig/drivers/mtd/maps/Kconfig 2008-07-13 15:51:29.0 -0600 +++ linux-2.6.x/drivers/mtd/maps/Kconfig2008-12-16 15:03:18.0 -0700 @@ -523,6 +523,31 @@ help Map driver to support image based filesystems for uClinux. +config MTD_UCLINUX_EBSS + bool "uClinux RAM/ROM filesystem is located at ebss" + depends on MTD_UCLINUX + default y + help + The filesystem is located directly after the kernel in memory. + +config MTD_UCLINUX_ADDRESS + hex "uClinux RAM/ROM filesystem address" + default 0x140 + depends on MTD_UCLINUX && !MTD_UCLINUX_EBSS + help + The filesystem is located at the given address. + +choice + prompt "uClinux RAM/ROM is located in ROM/RAM" + default MTD_UCLINUX_RAM + depends on MTD_UCLINUX && !MTD_UCLINUX_EBSS + +config MTD_UCLINUX_RAM + bool "RAM" +config MTD_UCLINUX_ROM + bool "ROM" +endchoice + config MTD_WRSBC8260 tristate "Map driver for WindRiver PowerQUICC II MPC82xx board" depends on (SBC82xx || SBC8560) I do have that code in my source tree. The patch for it was in-advertantly dropped out of the linux-2.6.26-uc0 patch file. Regards Greg ---- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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][m68knommu] nommu bad allocation
Hi Jate,
Jate Sujjavanich wrote:
I am proposing the following patch in mmnommu/mmap.c in 2.4:
ret = -ENOMEM;
result = kmalloc(len, GFP_KERNEL);
if (!result) {
- printk("Allocation of length %lu from process %d
failed\n",
- len, current->pid);
+ printk("Allocation of length %lu from process %d (%s)
failed\n",
+ len, current->pid, current->comm);
show_free_areas();
goto error;
}
This patch adds the name of the process to the bad allocation error
message.
This could also be applied to mm/nommu.c in the 2.6 kernel.
Seems like a reasonable change, I have committed it.
Regards
Greg
----
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company 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] subversion folders in uClinux/dist/patches
Hi Bernd, Bernd Büttner wrote: sorry for the delay, had some other things to do. I tested the 20081030 patch. There are still some '.svn' entries in the user/clamav tree. I extracted them with awk (as Erwin told me to do) and then it works for I think I finally have them all removed now. Check with the latest uClinux-dist-20080808-20090112.patch if you want. Regards Greg Greg Ungerer schrieb: Hi Bernd, Bernd Büttner wrote: The uClinux-dist-20080808-xxx patch-files contain files under a subversion management folder. These folders start with ".svn" and all reside under user/clamav and subfolders. I'm working with uClinux in a subversion working-copy. Fortunately I did a dry-run with the patch-file, otherwise my working copy would be corrupted now. Will I have to edit the patch-file by myself (no fun with a 46MB file) or will there be a new, corrected one soon? I have fixed the package and patch building to remove those now. So the next patch won't have them. It will generate tonight (my time). But I might not get it onto uclinux.org for a few days. But within a week or so I should have a new patch with them up for download. There are some other files and directories starting with a '.', for example ".gitignore". I cannot say if they are correct or not. I think it best to remove those too. Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: g...@snapgear.com Secure Computing CorporationPHONE: +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, a McAfee Company 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] Possible bug? proc-arm6,7.S and AT91FR40162
Hi Marcello, Marcelo Salazar wrote: I'm working with AT91FR40162 (AT91R40008 core), uClinux-dist-20080808, kernel 2.4 and toolchain arm-linux-20061213. After downloading uClinux from the web, configuring and downloading to SD card, the kernel doesn't work (It freezes after bootloader). I changed the file: "linux-2.4.x/arch/armnommu/Makefile" ifeq ($(CONFIG_ARCH_ATMEL),y) TEXTADDR= 0x02208000 MACHINE = atmel endif The setting as it is is probably for a different board type, with a different boot loader that loads to a different default start address. We would need a config option to separate out the board types, and use different link addresses to support both. Regards Greg So, now the system.map generated match with my configuration. In addition, the original "linux-2.4.x/arch/armnommu/mm/proc-arm6,7.S" shows: __at91_proc_info: .long 0x1440 ... I changed it to: __at91_proc_info: .long 0x4440 ... And the kernel starts OK! In AT91R40008's datasheet I can see chip ID: 0x44000840 The questions: Is it necessary to edit the files Makefile(above) and proc-arm6,7.S to change those values? Are there other ways to do this? It's a bug? Regards Marcelo ___ 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, a McAfee Company 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] Possible bug? proc-arm6,7.S and AT91FR40162
Hi Marcelo, Erwin, Erwin Authried wrote: Am Donnerstag, den 13.11.2008, 07:43 +0100 schrieb Marcelo Salazar: Hello everybody: I'm working with AT91FR40162 (AT91R40008 core), uClinux-dist-20080808, kernel 2.4 and toolchain arm-linux-20061213. After downloading uClinux from the web, configuring and downloading to SD card, the kernel doesn't work (It freezes after bootloader). I changed the file: "linux-2.4.x/arch/armnommu/Makefile" ifeq ($(CONFIG_ARCH_ATMEL),y) TEXTADDR= 0x02208000 MACHINE = atmel endif So, now the system.map generated match with my configuration. In addition, the original "linux-2.4.x/arch/armnommu/mm/proc-arm6,7.S" shows: __at91_proc_info: .long 0x1440 ... I changed it to: __at91_proc_info: .long 0x4440 ... And the kernel starts OK! In AT91R40008's datasheet I can see chip ID: 0x44000840 Hi, it would probably be better to change the following mask value so that both 14.. and 44.. is accepted: __at91_proc_info: .long 0x1440 .long 0xbff000e0 Yes, changing the mask is the better fix. I have commited that change to the older 2.4.x code. Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] what is the difference setup_irq() and request_irq()
Hi Xin,
Xin Xie wrote:
Inside the uClinux 888’s 2.6.25’s Coldfire timer
setup(linux-2.6.25/arch/m68knommu/platform/coldfire/timers.c), the
interrupt handler is registered by calling setup_irq():
void coldfire_profile_init(void)
{
printk(KERN_INFO "PROFILE: lodging TIMER2 @ %dHz as profile timer\n",
PROFILEHZ);
setup_irq(mcf_profilevector, &coldfire_profile_irq);
/* Set up TIMER 2 as high speed profile clock */
__raw_writew(MCFTIMER_TMR_DISABLE, PA(MCFTIMER_TMR));
__raw_writetrr(((MCF_BUSCLK / 16) / PROFILEHZ), PA(MCFTIMER_TRR));
__raw_writew(MCFTIMER_TMR_ENORI | MCFTIMER_TMR_CLK16 |
MCFTIMER_TMR_RESTART | MCFTIMER_TMR_ENABLE, PA(MCFTIMER_TMR));
mcf_settimericr(2, 7);
}
Can anyone enlighten me why we cannot use the request_irq() here
anymore? Does this means all other interrupts registering routine need
use the setup_irq() in the Coldfire uClinux kernel?
IIRC it is because timers are setup very early, before the
request_irq() infrastructure has been initialized. (Before the switch
to generic irqs m68knommu code could still call it safely).
General drivers should always use request_irq().
Regards
Greg
--------
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company 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] How to alloc cache inhibited buffer on a Coldfire 547X?
Hi Dave,
Dave Meador wrote:
I am porting a FEC driver from linux 2.6.10 to uclinux which requires
the usage of DMA transfers to function.
In the FEC driver, I need to allocate a DMA buffer using a call like
"kmalloc(sz, GFP_DMA)". In the stock uclinux kernel, this call fails
because apparently the ZONE_DMA is not defined.
In order for me to get this FEC driver working, what I need to do (I
think) is the following:
1) define a ZONE_DMA area of 1MB
2) mark the ZONE_DMA region as cache-inhibited
I cannot figure out how to mod the uclinux kernel to make step #1 work
as all my calls to "kmalloc(sz,GFP_DMA)" return NULL. Can someone give
me ideas on how to setup a ZONE_DMA for a coldfire arch? Is there an
alternate way to alloc a buffer which is cache inhibited?
Have you looked at linux-2.6.x/Documentation/DMA-API.txt?
You probably should be using those functions I suspect...
Regards
Greg
Any help would be appreciated,
Thanks,
Dave Meador
Here is my attempt to mod arch/m68knommu/mm/init.c to enable a ZONE_DMA
zone:
{
unsigned long zones_size[MAX_NR_ZONES] = {0, };
unsigned int dma_reserve = (1*1024*1024); // reserve 1MB for DMA
set_dma_reserve(dma_reserve >> PAGE_SHIFT);
end_mem &= PAGE_MASK;
zones_size[ZONE_DMA] = dma_reserve >> PAGE_SHIFT;
zones_size[ZONE_NORMAL] = ((end_mem - PAGE_OFFSET ) >> PAGE_SHIFT) -
zones_size[ZONE_DMA];
#ifdef CONFIG_HIGHMEM
zones_size[ZONE_HIGHMEM] = 0;
#endif
free_area_init(zones_size);
}
___
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, a McAfee Company 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] uclinux 2.6 and 5272C3 eval board help
Hi Mark, See comments below. Mark Giacobbe wrote: I'm trying to build uclinux 2.6 kernel w/uclib for the 5272C3 eval board. The board has 4M dram on it. I have dbug and u-boot running. I downloaded the latest distro from uclinux.org <http://uclinux.org>. I configured the board in "make menuconfig" for 0x0040 of available memory, memory starts at 0x0, and kernel start address as 0x2. I then "dn 2 image.bin" from debug and then "g 2" Here is what I get: dBUG> g 2 Linux version 2.6.25-uc0 (pcm...@localhost.localdomain) (gcc version 4.1.1) #4 Wed Jan 14 14:38:03 EST 2009 uClinux/COLDFIRE(m5272) COLDFIRE port done by Greg Ungerer, g...@snapgear.com <mailto:g...@snapgear.com> Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne Built 1 zonelists in Zone order, mobility grouping off. Total pages: 1016 Kernel command line: PID hash table entries: 16 (order: 4, 64 bytes) Dentry cache hash table entries: 1024 (order: 0, 4096 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Memory available: 1572k/4096k RAM, (1108k kernel code, 151k data) Mount-cache hash table entries: 512 net_namespace: 152 bytes NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 512 (order: 0, 4096 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 512 bind 1024) TCP reno registered io scheduler noop registered io scheduler cfq registered (default) ColdFire internal UART serial driver ttyS0 at MMIO 0x1100 (irq = 73) is a ColdFire UART console [ttyS0] enabled ttyS1 at MMIO 0x1140 (irq = 74) is a ColdFire UART brd: module loaded FEC ENET Version 0.2 fec: PHY @ 0x0, ID 0x001378e2 -- LXT971 eth0: ethernet 00:cf:52:72:c3:01 PPP generic driver version 2.4.2 uclinux[mtd]: RAM probe address=0x15b000 size=0x10e000 Creating 1 MTD partitions on "RAM": 0x-0x0010e000 : "ROMfs" uclinux[mtd]: set ROMfs to be root filesystem TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 VFS: Mounted root (romfs filesystem) readonly. Freeing unused kernel memory: 48k freed (0x14300�sh invoked oom-killer: ^^ Out of memory killer task... gfp_mask=0x1201d2, order=0, oomkilladj=0 Stack from 00375ba4: 00375000 00045006 0012af53 0035bb92 001201d2 0035b9b0 001354fc 0003afe8 0013bb10 00045340 0035b9b0 001201d2 0012aec7 001201d2 0010 0013bb0c 0035b9b0 0011ac5a 0001 33480abe 00047650 0013bb0c 001201d2 000a 0006 0011 0008 0004 0006 002741a0 0036c6d0 0006 0009f740 0036c6cc 001201d2 00375008 Call Trace with CONFIG_FRAME_POINTER disabled: [00045006] [0012af53] [001201d2] [0003afe8] [00045340] [001201d2] [0012aec7] [001201d2] [0011ac5a] [00047650] [001201d2] [0009f740] [001201d2] [00049298] [001201d2] [00042001] [0004965e] [000420a6] [00049712] [00043320] [00052970] [000502dc] [0004e606] [0011b41e] [0007aed2] [0005605e] [00055e0a] [000572dc] [00020806] [00020838] [00020806] [00022f54] Mem-info: Normal per-cpu: CPU0: hi:0, btch: 1 usd: 0 Active:4 inactive:1 dirty:0 writeback:0 unstable:0 free:70 slab:287 mapped:0 pagetables:0 bounce:0 Normal free:280kB min:252kB low:312kB high:376kB active:16kB inactive:4kB present:4064kB pages_scanned:63 all_unreclaimable? yes lowmem_reserve[]: 0 0 0 Normal: 4*4kB 7*8kB 3*16kB 1*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 280kB You are basically out of usable memory. Running a configured 2.6 kernel, with a largish root filesystem and on a system with 4MB you are running our of RAM. Regards Greg 5 total pagecache pages 1024 pages of RAM 70 free pages 619 reserved pages 5 pages shared 0 pages swap cached Out of memory: kill process 12 (sh) score 0 or a child Killed process 12 (sh) Hard Reset SDRAM Size: 4M Copyright 1995-2001 Motorola, Inc. All Rights Reserved. ColdFire MCF5272 EVS Firmware v2e.1a.1c (Build 10 on Mar 9 2001 12:05:18) Enter 'help' for help. dBUG> So can anyone help me with what's going on? What else do I need to change? Thanks Mark ___ 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 Ungere
Re: [uClinux-dev] linux-2.6.26-uc0 M5329EVB patch 2/6
Hi Matt, Matt Waddel wrote: Greg Ungerer wrote: Hi Matt, Matt Waddel wrote: This patch removes a lot of the unused code in the 532x config.c file. The only real change is to disable all the interrupts on start up. Looks good. I would like to commit it has 2 changes though. One to fix the incorrect adding of MCF_MBAR, and the other the clean up. Do you want to send it to me as 2 changes, or do you want me to go ahead and do it? Either way is OK with me. (If you've already made the changes - thanks, if you want me to do it let me know.) I'll go ahead and split it. Regards Greg Best regards, Matt I'll add your "Signed-off-by" to if thats ok? Regards Greg ---- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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, a McAfee Company 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] linux-2.6.26-uc0 M5329EVB patch 3/6
Hi Matt, Matt Waddel wrote: Greg Ungerer wrote: Matt Waddel wrote: This patch fixes the M5329 timer interrupt assignment. > --- linux-2.6.x.orig/arch/m68knommu/platform/coldfire/timers.c 2008-07-13 15:51:29.0 -0600 +++ linux-2.6.x/arch/m68knommu/platform/coldfire/timers.c 2008-12-18 21:31:52.0 -0700 @@ -35,8 +35,13 @@ *CPU's and some boards may want different. Their sub-architecture *startup code (in config.c) can change these if they want. */ +#if defined(CONFIG_M532x) +unsigned intmcf_timervector = 64+32; +unsigned intmcf_profilevector = 64+33; +#else unsigned intmcf_timervector = 29; unsigned intmcf_profilevector = 31; +#endif unsigned intmcf_timerlevel = 5; /* The code to do this was in .../532x/config.c, but you removed those lines in your previous patch. The idea is to keep CPU specific #ifdefs out of this common timer code, and only have to set it in the CPU specific config.c > > Or did I miss something here? Maybe I'm the one missing something, but the way I saw this was the generic settings for mcf_timervector and mcf_profilevector in timers.c would override any values set in board specific config.c file. The values set in timers.c are the most common (or at least where in the past :-), and so I used them as the defaults. For platforms that didn't use these you set them to the correct values in the platform/config.c. Arguably it would be cleaner to have no default, and the per platform config must always set the appropriate values to use. So probably what should happen is these lines should be removed from timer.c: unsigned intmcf_timervector = 29; unsigned intmcf_profilevector = 31; and then external variables should be set for each platform in it's board config.c file. I wouldn't remove the base variable definition from timers.c, I think it logically belongs there. I would be happy if there was no "catch-all" default values. Currently config.c for platforms that need something not default do set these. If that's correct, would you like me to make those changes for all the Coldfire platforms? I think forcing every config.c to set the correct values is probably a good thing. I would take that change. Regards Greg ---- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] DMA Coldfire fix - uClinux-2.6.26-uc0
Hi Matt,
Matt Waddel wrote:
The attached patch fixes the required zones_size
definitions for Coldfire platforms. Kernel
memory allocations fail without this addition.
>
diff -ruN linux-2.6.x.orig/arch/m68knommu/mm/init.c
linux-2.6.x/arch/m68knommu/mm/init.c
--- linux-2.6.x.orig/arch/m68knommu/mm/init.c 2008-07-13 15:51:29.0
-0600
+++ linux-2.6.x/arch/m68knommu/mm/init.c2008-12-21 08:03:03.0
-0700
@@ -138,8 +138,14 @@
{
unsigned long zones_size[MAX_NR_ZONES] = {0, };
+#ifndef CONFIG_COLDFIRE
zones_size[ZONE_DMA] = 0 >> PAGE_SHIFT;
zones_size[ZONE_NORMAL] = (end_mem - PAGE_OFFSET) >> PAGE_SHIFT;
+#else
+ /* move all pages into the DMAable zone */
+ zones_size[ZONE_NORMAL] = 0;
+ zones_size[ZONE_DMA] = (end_mem - PAGE_OFFSET) >> PAGE_SHIFT;
+#endif
#ifdef CONFIG_HIGHMEM
zones_size[ZONE_HIGHMEM] = 0;
#endif
I can't see any reason why we shouldn't just make everything
ZONE_DMA for all m68k/nommu varients. The pure m68k arch does.
I think we can clean this up, at least a little bit too.
I propose something like this:
--- init.c 23 Oct 2007 01:19:23 - 1.19
+++ init.c 15 Jan 2009 04:41:53 -
@@ -136,13 +136,10 @@ void __init paging_init(void)
#endif
{
- unsigned long zones_size[MAX_NR_ZONES] = {0, };
+ unsigned long zones_size[MAX_NR_ZONES];
- zones_size[ZONE_DMA] = 0 >> PAGE_SHIFT;
- zones_size[ZONE_NORMAL] = (end_mem - PAGE_OFFSET) >> PAGE_SHIFT;
-#ifdef CONFIG_HIGHMEM
- zones_size[ZONE_HIGHMEM] = 0;
-#endif
+ memset(zones_size, 0, sizeof(zones_size));
+ zones_size[ZONE_DMA] = (end_mem - PAGE_OFFSET) >> PAGE_SHIFT;
free_area_init(zones_size);
}
}
Regards
Greg
----
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company 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] wildfire 5282 - cannot use mii-tool or ethtool
Hi Rob, Rob Brown wrote: I have a wildfire 5282 / coldfire MCF5282 running uClinux-dist-intec-wildfire-2.6.19 distribution. All is up and running and working fine. I now have a need to force the ethernet to 10 baseT, and have setup the toolchain to include the mii-tool or ethtool to do this both of these are failing to do this, even though ifconfig can return its ethernet info here are the outputs. # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:14:15:01:01:31 inet addr:10.1.1.196 Bcast:10.1.1.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:752 errors:0 dropped:0 overruns:0 frame:0 TX packets:19 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:113399 (110.7 KiB) TX bytes:7813 (7.6 KiB) Base address:0x1000 # ethtool eth0 Settings for eth0: No data available # mii-tool eth0 SIOCGMIIPHY on 'eth0' failed: Operation not supported # any ideas how I can get either of the tools to force eth0 to 10baseT half duplex? Looks like the fec.c driver doesn't support any of the mii-tool ioctls (the SIOCGMII family) of the ethtool ops. If you look at the other net drivers in drivers/net/*.c you will find plenty of examples of what is needed. For the mii-tool case look at the 2.4.x fec.c driver from the linux-2.4.x-uc trees. It has SIOCG ioctl support. May not be too difficult to port that across. Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] subversion folders in uClinux/dist/patches
Hi Bernd, Bernd Büttner wrote: I'm so sorry but there are still some in the directories: user/clamav/shared user/clamav/.split In the meantime I created an awk-file that removes them, so don't worry. Maybe it is just the patch that doesn't remove them. The master tree (that I make the patch from) doesn't have them anymore. Regards Greg Greg Ungerer schrieb: Hi Bernd, Bernd Büttner wrote: sorry for the delay, had some other things to do. I tested the 20081030 patch. There are still some '.svn' entries in the user/clamav tree. I extracted them with awk (as Erwin told me to do) and then it works for I think I finally have them all removed now. Check with the latest uClinux-dist-20080808-20090112.patch if you want. Regards Greg Greg Ungerer schrieb: Hi Bernd, Bernd Büttner wrote: The uClinux-dist-20080808-xxx patch-files contain files under a subversion management folder. These folders start with ".svn" and all reside under user/clamav and subfolders. I'm working with uClinux in a subversion working-copy. Fortunately I did a dry-run with the patch-file, otherwise my working copy would be corrupted now. Will I have to edit the patch-file by myself (no fun with a 46MB file) or will there be a new, corrected one soon? I have fixed the package and patch building to remove those now. So the next patch won't have them. It will generate tonight (my time). But I might not get it onto uclinux.org for a few days. But within a week or so I should have a new patch with them up for download. There are some other files and directories starting with a '.', for example ".gitignore". I cannot say if they are correct or not. I think it best to remove those too. Regards Greg -------- Greg Ungerer -- Chief Software Dude EMAIL: g...@snapgear.com Secure Computing CorporationPHONE: +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 ___ 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, a McAfee Company 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] m68k,m68knommu: merge header files
Hi Geert,
Geert Uytterhoeven wrote:
On Fri, 16 Jan 2009, Greg Ungerer wrote:
Sam Ravnborg wrote:
From 5a8b9717a399679c4753e596ea864b02a1197025 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg
Date: Sat, 13 Dec 2008 21:23:08 +0100
Subject: [PATCH] m68k,m68knommu: merge header files
Merge header files for m68k and m68knommu to the single location:
arch/m68k/include/asm
The majority of this patch was the result of the
script that is included in the changelog below.
The script was originally written by Arnd Bergman and
exten by me to cover a few more files.
When the header files differed the script uses the following:
The original m68k file is named _mm.h [mm for memory manager]
The m68knommu file is named _no.h [no for no memory manager]
The files uses the following include guard:
This include gaurd works as the m68knommu toolchain set
the __uClinux__ symbol - so this should work in userspace too.
Merging the header files for m68k and m68knommu exposes the
(unexpected?) ABI differences thus it is easier to actually
identify these and thus to fix them.
The commit has been build tested with both a m68k and
a m68knommu toolchain - with success.
The commit has also been tested with "make headers_check"
and this patch fixes make headers_check for m68knommu.
The script used:
TARGET=arch/m68k/include/asm
SOURCE=arch/m68knommu/include/asm
INCLUDE="cachectl.h errno.h fcntl.h hwtest.h ioctls.h ipcbuf.h \
linkage.h math-emu.h md.h mman.h movs.h msgbuf.h openprom.h \
oplib.h poll.h posix_types.h resource.h rtc.h sembuf.h shmbuf.h \
shm.h shmparam.h socket.h sockios.h spinlock.h statfs.h stat.h \
termbits.h termios.h tlb.h types.h user.h"
EQUAL="auxvec.h cputime.h device.h emergency-restart.h futex.h \
ioctl.h irq_regs.h kdebug.h local.h mutex.h percpu.h \
sections.h topology.h"
NOMUUFILES="anchor.h bootstd.h coldfire.h commproc.h dbg.h \
elia.h flat.h m5206sim.h m520xsim.h m523xsim.h m5249sim.h \
m5272sim.h m527xsim.h m528xsim.h m5307sim.h m532xsim.h \
m5407sim.h m68360_enet.h m68360.h m68360_pram.h m68360_quicc.h \
m68360_regs.h MC68328.h MC68332.h MC68EZ328.h MC68VZ328.h \
mcfcache.h mcfdma.h mcfmbus.h mcfne.h mcfpci.h mcfpit.h \
mcfsim.h mcfsmc.h mcftimer.h mcfuart.h mcfwdebug.h \
nettel.h quicc_simple.h smp.h"
FILES="atomic.h bitops.h bootinfo.h bug.h bugs.h byteorder.h cache.h \
cacheflush.h checksum.h current.h delay.h div64.h \
dma-mapping.h dma.h elf.h entry.h fb.h fpu.h hardirq.h hw_irq.h io.h \
irq.h kmap_types.h machdep.h mc146818rtc.h mmu.h mmu_context.h \
module.h page.h page_offset.h param.h pci.h pgalloc.h \
pgtable.h processor.h ptrace.h scatterlist.h segment.h \
setup.h sigcontext.h siginfo.h signal.h string.h system.h \
thread_info.h timex.h tlbflush.h traps.h uaccess.h ucontext.h \
unaligned.h unistd.h"
mergefile() {
BASE=${1%.h}
git mv ${SOURCE}/$1 ${TARGET}/${BASE}_no.h
git mv ${TARGET}/$1 ${TARGET}/${BASE}_mm.h
cat << EOF > ${TARGET}/$1
EOF
git add ${TARGET}/$1
}
set -e
mkdir -p ${TARGET}
git mv include/asm-m68k/* ${TARGET}
rmdir include/asm-m68k
git rm ${SOURCE}/Kbuild
for F in $INCLUDE $EQUAL; do
git rm ${SOURCE}/$F
done
for F in $NOMUUFILES; do
git mv ${SOURCE}/$F ${TARGET}/$F
done
for F in $FILES ; do
mergefile $F
done
rmdir arch/m68knommu/include/asm
rmdir arch/m68knommu/include
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Greg Ungerer
Signed-off-by: Sam Ravnborg
So I took this, applied, and have been running some tests
on m68knommu.
I had to make 2 small changes to make it work on 2.6.29-rc1.
I had to add swab.h into the list of FILES, and move the seting
of hdr-arch for m68knommu in the top level Makefile to after the
global hdr-arch setting (so all of about 3 lines later).
Otherwise it builds and runs fine for m68knommu in all
cases I have tested so far.
Thanks!
I have this applied as the only change at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
m68k-merge-includes
Huh, is this git repository really ca. 200 MiB?
Hmm, seems kinda large. Maybe I didn't pack it properly?
Sam Ravnborg (1):
m68k,m68knommu: merge header files
More review, testing, comments welcome...
Where to from here?
I'll pull from it and give it some m68k test builds.
After that, you can move it to for-next. If everything's well, it can go to
Linus.
Sounds like a plan.
Or should I amend and add my SoB and put it in m68k for-next?
I am happy to go either way.
Regards
Greg
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
---
[uClinux-dev] Re: [PATCH] m68k,m68knommu: merge header files
Hi Geert, Geert Uytterhoeven wrote: On Fri, 16 Jan 2009, Sam Ravnborg wrote: More review, testing, comments welcome... Where to from here? I'll pull from it and give it some m68k test builds. After that, you can move it to for-next. If everything's well, it can go to Linus. Sounds like a plan. Or should I amend and add my SoB and put it in m68k for-next? I am happy to go either way. For my part I like this to reach mainline ASAP. So whatever suits the two of you is fine with me. I pulled from Greg's tree, and built atari_defconfig, multi_defconfig, sun3_defconfig. Atari_defconfig runs fine under ARAnyM. As I'll be on a business trip to Japan next week, I probably won't be able to do a proper follow-up. So Greg, can you put it on your for-next branch and send it to Linus if everything goes well? Acked-by: Geert Uytterhoeven Yep, I can take care of that. Regards Greg ---- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] eDMA support for M5329 - uClinux-2.6.26-uc0
Hi Matt, Matt Waddel wrote: The attached patch adds support for the enhanced DMA (eDMA) driver found in many Coldfire platforms. This patch only provides support for the M5329 platform. The driver also contains a simple test program that can be used to validate the eDMA driver. If everything is working correctly you should see results like these when you insmod the test code: Do you want me to push this into the -uc releases only, or consider for merging into mainline? To goto mainline it will need a few cleanups :-) Run scripts/checkpatch.pl on it, there is a few things it complains about. One thing that I think needs looking at is the use of: #define MCF_EDMA_CR *(volatile unsigned long *)(0xFC044000) I think it would be better to just make these definitions the address only. Then use the appropriate readl() and writel() macros with these when used in the code. Regards Greg === Starting eDMA transfer tests! DMA channel 14 testing started. Data transfered correctly. DMA channel 14 testing complete. --- DMA channel 15 testing started. Data transfered correctly. DMA channel 15 testing complete. --- DMA channel 13 testing started. Data transfered correctly. DMA channel 13 testing complete. --- DMA channel 1 testing started. Data transfered correctly. DMA channel 1 testing complete. --- DMA channel 2 testing started. Data transfered correctly. DMA channel 2 testing complete. --- DMA channel 5 testing started. Data transfered correctly. DMA channel 5 testing complete. --- DMA channel 6 testing started. Data transfered correctly. DMA channel 6 testing complete. --- DMA channel 7 testing started. Data transfered correctly. DMA channel 7 testing complete. --- DMA channel 8 testing started. Data transfered correctly. DMA channel 8 testing complete. --- All tests have completed Automatically allocated 9 eDMA channels: 1, 2, 5, 6, 7, 8, 13, 14, 15, === Best regards, Matt ___ 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, a McAfee Company 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] Problem with the ColdFire mcf5407 2.6.25 kernel
Hi Oleksii, Oleksii wrote: I have got the problem running the newest uClinux (20080808, 2.6.25 kernel). Kernel BUG happens at the kmem_cache_create function (mm/slab.c) with default kernel config. The first sanity checks of this function fails, because in_interrupt () returns true. Actually preempt_count () at that place is equal to 0x1000, which means that hardirq count is 1. It is not the first call of kmem_cahce_create (), and usually happens in few calls after call of this function by the kmem_cache_init (). Changing of the Kbuild config (Processor Type and Features ---> Preemption Model) from "No Forced Preemption" to the "Preemptible Kernel" lets the BUG happen a bit later in the call of the kmem_cache_create (). Problem seems to happen after the kmalloc () call in the setup_cpu_cache () function which is called from kmem_cache_create(). In old version of uClinux (2.6.19) no problem happens. On ColdFire 5329 (which is also m68knommu arch) everything works ok on the 2.6.25. The same problem was previously posted at this mailing list: http://mailman.uclinux.org/pipermail/uclinux-dev/2008-October/047240.html, but I have not found any replies with solutions. Can somebody help with some ideas what was seriously changed from 19th kernel to 25th kernel? The first thought to comes to mind is that maybe CPU caching is buggy here. Can you run without the CPU cache enabled at all? (You will need to disable it in include/asm-m68knommu/mcfcache.h and include/asm-m68knommu/cacheflush.h. There has been a few small changes for some of the ColdFire CPU's in this area. Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] Using shadow passwords in Tinylogin with ftpd
Hi Peter, I have taken a long time to get around to looking at this :-( Peter Turczak wrote: while experimenting with the ftpd and telnetd shipped with uclinux-dist-2008... i found a strange situation appears when enabling tinylogin with shadow support. After setting up a new user using adduser and setting its password, telnetd would allow me to log in using this new user, whereas ftpd would always return "530 Login incorrect.". After fiddeling a litte around it seems that there was a quirk in the user/ftp/config.h, it would enable the header for shadow passwords (#define HAVE_SHADOW_H) but would disable getspnam (#undef HAVE_GETSPNAM) which is needed in auth.c to use shadow passwords. Please find attached a patch for this problem, hope it is correct. Feedback is welcome. I suspect you are right, and looking at how shadow.h processing is handled in here, this is the appropriate way to fix it. Applied to uClinux-dist. Regards Greg ---- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] [git pull] m68k and m68knommu merge of includes
Hi Linus,
Please consider pulling this merge of the m68k and m68knommu include files.
It comepletely moves include/asm-m68k to arch/m68k/include as part of the
process, and ultimately results in both m68k and m68knommu arch code using
the same set of includes. More cleanup can follow, but this is the
necessary first step.
Thanks
Greg
The following changes since commit ae04d1401577bb63151480a053057de58b8e10bb:
Benjamin Herrenschmidt (1):
powerpc: Fix cpufreq drivers after cpufreq core changes
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next
Sam Ravnborg (1):
m68k,m68knommu: merge header files
Makefile |4 +++
{include/asm-m68k => arch/m68k/include/asm}/Kbuild |0
arch/{m68knommu => m68k}/include/asm/MC68328.h |0
arch/{m68knommu => m68k}/include/asm/MC68332.h |0
arch/{m68knommu => m68k}/include/asm/MC68EZ328.h |0
arch/{m68knommu => m68k}/include/asm/MC68VZ328.h |0
.../m68k/include/asm}/a.out-core.h |0
.../asm-m68k => arch/m68k/include/asm}/a.out.h |0
.../asm-m68k => arch/m68k/include/asm}/adb_iop.h |0
.../asm-m68k => arch/m68k/include/asm}/amigahw.h |0
.../asm-m68k => arch/m68k/include/asm}/amigaints.h |0
.../asm-m68k => arch/m68k/include/asm}/amigayle.h |0
.../asm-m68k => arch/m68k/include/asm}/amipcmcia.h |0
arch/{m68knommu => m68k}/include/asm/anchor.h |0
.../asm-m68k => arch/m68k/include/asm}/apollodma.h |0
.../asm-m68k => arch/m68k/include/asm}/apollohw.h |0
.../asm-m68k => arch/m68k/include/asm}/atafd.h |0
.../asm-m68k => arch/m68k/include/asm}/atafdreg.h |0
.../m68k/include/asm}/atari_joystick.h |0
.../m68k/include/asm}/atari_stdma.h|0
.../m68k/include/asm}/atari_stram.h|0
.../asm-m68k => arch/m68k/include/asm}/atarihw.h |0
.../asm-m68k => arch/m68k/include/asm}/atariints.h |0
.../asm-m68k => arch/m68k/include/asm}/atarikb.h |0
arch/m68k/include/asm/atomic.h |5 +++
.../atomic.h => arch/m68k/include/asm/atomic_mm.h |0
.../asm/atomic.h => m68k/include/asm/atomic_no.h} |0
arch/{m68knommu => m68k}/include/asm/auxvec.h |0
arch/m68k/include/asm/bitops.h |5 +++
.../bitops.h => arch/m68k/include/asm/bitops_mm.h |0
.../asm/bitops.h => m68k/include/asm/bitops_no.h} |0
.../asm-m68k => arch/m68k/include/asm}/blinken.h |0
arch/m68k/include/asm/bootinfo.h |5 +++
.../m68k/include/asm/bootinfo_mm.h |0
.../bootinfo.h => m68k/include/asm/bootinfo_no.h} |0
arch/{m68knommu => m68k}/include/asm/bootstd.h |0
arch/m68k/include/asm/bug.h|5 +++
.../bug.h => arch/m68k/include/asm/bug_mm.h|0
.../asm/bug.h => m68k/include/asm/bug_no.h}|0
arch/m68k/include/asm/bugs.h |5 +++
.../bugs.h => arch/m68k/include/asm/bugs_mm.h |0
.../asm/bugs.h => m68k/include/asm/bugs_no.h} |0
.../m68k/include/asm}/bvme6000hw.h |0
arch/m68k/include/asm/byteorder.h |5 +++
.../m68k/include/asm/byteorder_mm.h|0
.../include/asm/byteorder_no.h}|0
arch/m68k/include/asm/cache.h |5 +++
.../cache.h => arch/m68k/include/asm/cache_mm.h|0
.../asm/cache.h => m68k/include/asm/cache_no.h}|0
.../asm-m68k => arch/m68k/include/asm}/cachectl.h |0
arch/m68k/include/asm/cacheflush.h |5 +++
.../m68k/include/asm/cacheflush_mm.h |0
.../include/asm/cacheflush_no.h} |0
arch/m68k/include/asm/checksum.h |5 +++
.../m68k/include/asm/checksum_mm.h |0
.../checksum.h => m68k/include/asm/checksum_no.h} |0
arch/{m68knommu => m68k}/include/asm/coldfire.h|0
arch/{m68knommu => m68k}/include/asm/commproc.h|0
.../asm-m68k => arch/m68k/include/asm}/contregs.h |0
.../asm-m68k => arch/m68k/include/asm}/cputime.h |0
arch/m68k/include/asm/current.h|5 +++
.../m68k/include/asm/current_mm.h |0
.../current.h => m68k/include/asm/current_no.h}|0
arch/{m68knommu => m68k}/include/asm/dbg.h |0
arch/m68k/include/asm/delay.h |5 +++
.../delay.h => arch/m68k/include/asm/delay_mm.h|0
.../asm/delay.h => m68k/include/asm/delay_no.h}|0
arch/{m68knommu => m68k}/include/asm/device.h |0
arch/m68k/include/asm/div64.h |5 +++
.../div64.h => arch/m68k/include/asm/div64_mm.h|0
.../asm/div64.h => m68k/include/asm/div64_no.h}|0
arch/m6
[uClinux-dev] Re: [git pull] m68k and m68knommu merge of includes
Hi Harvey, Harvey Harrison wrote: On Wed, 2009-01-21 at 10:58 +1000, Greg Ungerer wrote: Hi Linus, Please consider pulling this merge of the m68k and m68knommu include files. It comepletely moves include/asm-m68k to arch/m68k/include as part of the process, and ultimately results in both m68k and m68knommu arch code using the same set of includes. More cleanup can follow, but this is the necessary first step. Thanks Greg I think you need to check your arch/m68k/include/asm/swab.h as I get an empty file when I pull this. It looks like it needs a conditional include of swab_mm/swab_no similar to the other files. Yes, something went wrong there... Also, because of the byteorder changes, it looks like you don't need a separate byteorder_mm/no as they both just include the generic include/linux/byteorder/big_endian.h Are you happy to just apply your follow up patch to fix these issues, after this has been pulled? Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] Mount romfs without MTD?
Hi Stephane, Stephane Lambert wrote: I'm working on mounting romfs for kernel 2.6.19 on a new architecture and I have a question: It is possible to mount romfs without MTD support? Where does the romfs sit? If on a disk you would logically use IDE or SCSI block device. It it sits on raw flash then MTD is the logical choice. If its in RAM then either ramdisk or MTD would make sense. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] newest possible kernel version for trunk of uClinux-dist?
Hi Rainer, Rainer Keller wrote: My company is porting uClinux to our processor architecture that is used in several routers and some digital picture frames on the market. We started with the 20080808 distribution (2.6.25-uc0 kernel) and have a kernel up and are adding drivers and user mode code currently. Our architecture has nommu but SMP support, gpios and other things that we see are in great flux in the mainline kernel. The latest patch in http://www.uclinux.org/pub/uClinux/dist/patches/ is uClinux-dist-20080808-20090112.patch.gz, same as on http://sourceforge.net/project/showfiles.php?group_id=240583&package_id= 292947 both contain a patched 2.6.26 kernel now, also under http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/ I find linux-2.6.26-uc0.patch.gz as the latest patch. In one of the recent postings here I saw it mentioned that Linus has a -uc0 branch in addition to mainline. No, thats not the case. Linus has no separate branches for uClinux. I have patches that I version "-uc0", "-uc1", etc. But I generate those, not Linus. They are for testing out upcoming changes that I plan to send to Linus. And from another email I concluded that __uClinux__ is a conditional that surround nommu-isms in the kernel source but "grep -r __uClinux__ *" gives me nothing in the kernel from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git. No, not exactly either. Almost all of the current code in the kernel for non-mmu is conditional on CONFIG_MMU. I would encourage you to base anything non-MMU specific (not architecture specific) on this. The define __uClinux__ is a gcc definition used by compilers generated for uclinux. One of my colleagues says that uClinux is fully integrated in the mainline kernel now but seeing the patches for 2.6.26 and not finding anything with my grep confused me a bit and "just trying" with 2.6.28 or newer is several days of work. non-MMU support is fully integrated into the kernel (has been in all 2.6 series kernels). Could someone please tell me which kernel is the newest that I can use to put our architecture code in and run the uClinux userland code and libs underneath? I would use 2.6.28, if you are serious about pushing for main line inclusion. I will release a 2.6.28-uc0 in a couple of weeks time. But there is no reason to wait for that. I only checked the FAQs on uClinux and uCdot and I am reading uClinux-dev since about a month. If there is a better source of information I would be happy with any kind of: read this mailing archive / website kind of answer. They are about the best really... Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] Mount romfs without MTD?
Hi Stephane, Stephane Lambert wrote: Hi thanks for your answer. In my case, when the linux image is loaded, the _startup procedure copies the romfs image from the rom to the ram (at _ebss). So I can use RAMdisk or MTD. I have already tried with MTD, I create a partition but I have a probleme with the function mtd_blktrans_thread() which turns in endless loop. So I going to try only with ramdisk. It seems to be the easiest way to mount romfs. I have seen that we can specifie a command line initrd option 'initrd=0xaddr,sizeK'. Does 'addr' must be equal to _ebss? Yes, the actual address of _ebss. (This is the reason that uclinux.c map driver exits, to automate the _ebss starting address). Regards Greg If not what should I specify for this command line? Thanks very much in advance! Regards Greg Ungerer a écrit : Hi Stephane, Stephane Lambert wrote: I'm working on mounting romfs for kernel 2.6.19 on a new architecture and I have a question: It is possible to mount romfs without MTD support? Where does the romfs sit? If on a disk you would logically use IDE or SCSI block device. It it sits on raw flash then MTD is the logical choice. If its in RAM then either ramdisk or MTD would make sense. Regards Greg ---- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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, a McAfee Company 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] newest possible kernel version for trunk of uClinux-dist?
Hi Michael, Michael Schnell wrote: No, not exactly either. Almost all of the current code in the kernel for non-mmu is conditional on CONFIG_MMU. With user space stuff I always found the "EMDED" define which often is used to do a fork() vs. vfork() selection. That was certainly the case many years ago... (Which IMHO in many cases seems silly, as AFAIK, you can happily use vfork() if there is an MMU, too, in nearly (?) all cases when you can _simply_ (without any other code change) replace fork() with vfork() anyway. ) Yes, pretty much true... Moreover the name of the "EMBED" define seems quite outdated, as today, many embedded devices do provide an MMU. Yes, definitely true. I tend not to use it any more. I don't know if there is some change on that issue planned (e.g. using CONFIG_MMU, in User Land as well). Currently I use __uClinux__ in userland for this. (Which isn't perfect either, if you use a standard gnu linux configured gcc for compiling uCLinux systems you need to manually define it too). Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] eDMA support for M5329 - uClinux-2.6.26-uc0
Hi Matt, Matt Waddel wrote: Greg Ungerer wrote: Matt Waddel wrote: The attached patch adds support for the enhanced DMA (eDMA) driver found in many Coldfire platforms. This patch only provides support for the M5329 platform. The driver also contains a simple test program that can be used to validate the eDMA driver. If everything is working correctly you should see results like these when you insmod the test code: Do you want me to push this into the -uc releases only, or consider for merging into mainline? I'd be really happy if this went to mainline, so I'll work on the checkpatch complaints and submit a new patch (or would you prefer a patch against the patch?). A new complete patch is best. To push to mainline it is easiest if I have the complete patch, then I can just git commit it to the public m68knommu git tree on kernel.org. Thanks Greg To goto mainline it will need a few cleanups :-) Run scripts/checkpatch.pl on it, there is a few things it complains about. One thing that I think needs looking at is the use of: #define MCF_EDMA_CR *(volatile unsigned long *)(0xFC044000) I think it would be better to just make these definitions the address only. Then use the appropriate readl() and writel() macros with these when used in the code. Regards Greg 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, a McAfee Company 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] why no-mmu cannot support binfmt_aout.c
Hi Miloody, loody wrote: I try to compile kernel with support binfmt_aout.c, CONFIG_BINFMT_AOUT. but it says "fs/binfmt_aout.c:438: error: `TASK_SIZE_26' undeclared (first use in this function)", and I check in asm/memory.h, it only support TASK_SIZE_26 when kernel with mmu support. Does that mean kernel without mmu supporting cannot run a.out binary file? Yes, that is right. Seeya Gerg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] why no-mmu cannot support binfmt_aout.c
Hi Loody,
loody wrote:
I try 2 another cross-toolchains today.
1. buildroot,
2. arm-uclinux, download from Codesourcery.
The transformation of elf to FLAT of them is quite different.
I get help from buildroot maintainer, so I can build buildroot with
elf2flt successfully.
a.
When I use "-Wl,-elf2flt,-s32768" to compile my hellow.c.
it will say:
arm-linux-uclibcgnueabi/bin/ld.real: unrecognized option '-s32768'
arm-linux-uclibcgnueabi/bin/ld.real: use the --help option for usage information
collect2: ld returned 1 exit status
(it seems the ld doesn't recognize the option,-s32768).
b.
When I use "-Wl,-elf2flt" to compile my hellow.c.
it will say:
arm-linux-uclibcgnueabi/bin/ld.real: error: no memory region specified
for loadable section `.plt'
collect2: ld returned 1 exit status
c.
so I try to use arm-linux-uclibcgnueabi-elf2flt to meet my requirement.
And it say:
TEXT -> vma=0x0 len=0x24
DATA -> vma=0x0 len=0xc
ERROR: text=0x24 overlaps data=0x0 ?
it seems i need to modify some file to fix b and c. But I cannot find
any config about elf2flt.
2 can successfully get flt as I need even I don't pass
"-Wl,-elf2flt,-s32768" to it.
( I assigned the -isystem as buildroot lib, since I cannot find
stdio.h in Codesourcery toolchain)
So I use arm-linux to compile uxlinux kernel image and use 2,
Codesourcery toolchain, to compile my hello.c, put hello_flt to the
root file system and let kernel execute it.
And it seems ALMOST work.
ALMOST means I can see the kernel message says
"tart_thread(regs=0x83c15ef8, entry=0x83d60044,
start_stack=0x83d6ffb0)"
but I cannot see the "hello" that I am looking for.
My questions are:
1. I guess the reason why I cannot see the "hello" from console is due
to some lib I have to put at root file system/lib. But I don't know is
there any tool like readelf can tell me what lib flt needs? I only can
do is use "file". But it only can tell me the format not the detail
information. If someone knows any tool for flt, please let me know.
BTW, is my hello.c too complicate that it fail to print message on console?
#include
int main()
{
printf("Hello World");
return 0;
}
2. Does anyone use buildroot and successfully get flt file? If so,
please tell me how to solve a,b,c above?
3. is there any other pre-compiled toolchains I can try? I google the
"arm-elf download", but I cannot get any good result.
appreciate your help,
You are really making things difficult for yourself to start out.
My suggestion, get the uClinux-dist, use the arm-linux compiler
linked from uclinux.org. I specifically use the GDB/ARMulator
target. Build it "as is" and run it on the Skyeye emulator.
Use that as a starting point.
Regards
Greg
Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com
SnapGear, a McAfee Company 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] why no-mmu cannot support binfmt_aout.c
Hi Loody, loody wrote: You are really making things difficult for yourself to start out. My suggestion, get the uClinux-dist, use the arm-linux compiler linked from uclinux.org. I specifically use the GDB/ARMulator target. Build it "as is" and run it on the Skyeye emulator. Use that as a starting point. Regards Greg Hi: I feel it is too difficult either :-( It doesn't have to be :-) At beginning, I use the combination you suggest, but uclinux makes me cry when I find that the only executable file format that can run on uclinux is FLAT. No need to cry :-) Why is only supporting FLAT a problem for you? (It is not entirely true to say uClinux only supports FLAT, some uClinux architectures support fdelf-pic). I don't know how to make a flat with the arm-linux compiler linked from uclinux.org. You can see it in the previous letter. That is why I said to get the uClinux-dist. It builds applications with that compiler against its own uClibc. They work. I specifically test it for the GDB/ARMulator target before uClinux-dist releases. (GDB/ARMulator target emulates an ATMEL AT91x40 - an ARM7tdmi part). So, I ask for another cross-toolchain's help. I am sure others could pop up and give instructions on compilers and other tools they use. But I use the uClinux-dist with arm-linux tool (from uclinux.org link) to build working arm uclinux systems. Regards Greg ---- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] Nintendo GBA Supported?!?! When was this added to the ARM series?
Hi Gregg, Gregg Levine wrote: For the record when was the Nintendo GBA officially supported by this project? I dunno about for the record, but I first coded up some basic support in early 2003. That work has been in uClinux-dist code packages from then. I only ever worked on the GBA emulators, not on real hardware. All the work I did was linux-2.0.x. I recall quite a few others picked it up and did more with it. Though I don't think much of that work made its way back in the linux-2.0.x sources in uClinux.org or in the uClinux-dist. The steps to create a something also tell me that I am quite literally breaking new ground here. Does this mean that no one else has created something for the GBA? For example it suggested that I select a similar port and work from there. Good idea but there really isn't anything similar except yet another GBA. I don't exactly follow what you are saying here? Look in the any recent uClinux-dist. There is a Nintendo/GBA target. And the kernel code to support all its basic devices is in the linux-2.0.x sources in the uClinux-dist. Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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] build uclinux successfully but get cpu unknow exception
Hi Loody, loody wrote: my cpu is arm940T. Try adding "-mcpu=arm940t" to the GCC command, and remove "-march=armv4t" and "-mtune=arm9tdmi" from it (your example has them). Hi: Thanks for your help :) the situation is still the same when I follow the instructions you suggest. I will try another combinations as well. BTW, is there any tool like readelf, which can tell me what lib the flat used? Use readelf. FLAT format files are generated by a trivial conversion from ELF. (That is they are compiled as ELF, and a final conversion step is done to convert them to FLAT). There is another tool that is handy, fltdr (or in your case it would be arm-linux-flthdr). Is there any document which introduce the format of Flat? No. Use the source code, in the kernel fs/binfmt_flat.c. FLAT format is very simple (especially so if not using shared libraries). Regards Greg -------- Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear, a McAfee Company 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
