[uClinux-dev] linux-2.6.21-uc0 patch set released
Hi All, An update of the uClinux (MMU-less) code against 2.6.21. Quite a few changes, some cleanup, some bug fixes. Very soon I plan on switch out and use the new style ColdFire serial driver. It will also be platform device based, so there will be a bit of change in the ColdFire architecture config.c files. Look at the current arch/m68knommu/platform/520x/config.c as an example of the changes if interrested. http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0.patch.gz Change log: . Arctururs UC5272 and UC5282 board supportDavid Wu . use THREAD_SIZE for stack manipulation Philippe De Muyter . remove dead code from setup.cGreg Ungerer . remove dead cache code from mm Greg Ungerer . remove useless is_in_rom() Greg Ungerer . consolidate fixed bootparam code Greg Ungerer . no need to preserve THREAD_SR in resume Philippe De Muyter . implement irq_regs in interrupt service Greg Ungerer . remove machine specific irq code Greg Ungerer . fix timer step count for ColdFirePhilippe De Muyter . add chip select mappings for cobra5329 Thomas Brinker . remove old machine specific clock definesGreg Ungerer . improve readability of fec driver code Philippe De Muyter . do not read ICR before writing in fec driver Philippe De Muyter . fix INIT_WORK usage in fec driverGreg Ungerer . remove legacy PM code in 68328 serial driver Greg Ungerer . fix errno reporting in binfmt_flat loaderPhilippe De Muyter . create hw_irq.h for m68knommuGreg Ungerer . fix CLOCK_TICK_RATE for m68knommuPhilippe De Muyter . add expand_stack() funtcion to nommu Greg Ungerer . move to platform device setup for 520x Greg Ungerer . move to platform device setup for 5249 Greg Ungerer . new style serial driver for ColdFire UARTGreg Ungerer . add QSPI defines for 528x ColdFire parts David Wu . improve SoC device defines for 523x ColdFire Thomas Brinker I plan on pushing most of these to Linus for 2.6.22. The serial driver stuff not quite yet, maybe for 2.6.23 if it tests out ok. And by popular request here is a big patch that will bring a stock 2.6.21 kernel up to a uClinux-dist 2.6.x level kernel: http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.21-uc0-big.patch.gz There is quite a bit of work going on in the arm area to get the final uClinux support done. Targets like th ARMulator work nicely, but I expect a few more little changes in this area yet. Regards Greg Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a division of Secure Computing 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] Page Allocation Failure
How do i specify XIP in uClinux? I am compiling the linking the application using the following options: CFLAGS= -D_GNU_SOURCE -DDEBUG -fpic LDFLAGS= -Wl,-elf2flt -m5370 -msep-data -lpthread -lstdc++ -lc -lgcc I have to increase the RAMFS size of 1024 as the application size is itself 793780 bytes. Even with only "Allow allocating large blocks (> 1MB) of memory" and the stack size 4K, i am unable to execute the application. Gavin Lambert wrote: Quoth Praveen Chandrasekharaiah <>: I am trying to solve this "page allocation failure. order:8, mode:0x40d0" error but some how all the suggested solutions don't seem to work. I am using 2.6.16 uClinux on M5272C3. I selected Allow allocating large blocks (> 1MB) of memory and increased the RAMFS size to 1024K and also increased the stack size for 4k to 20K. The size of the application itself is 793780 bytes. The board has a ROM and RAM of 5 Meg each. Are you using XIP and running from ROM or is the kernel and ROMFS running from RAM? With an all-in-RAM setup and 8MB of RAM, I found there was only ~5MB free on initial boot, and about ~2MB free once it reached the shell. Unless you've got a very constrained system that means once you've loaded a 1MB app there's precious little room to move around in afterwards. (Incidentally, those steps you describe [apart from the first] would actually make the problem *worse* for an all-in-RAM setup.) ___ 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] 32-bit SDRAM and FLASH
We have just made our own MCF5208 board with 32-bit SDRAM and Flash memory. The original M5208EVB uses an 16-bit design. Now I would like to know, what do I need to change to get my mtd partition fully working again in this design? It seems to access the flash memory in 16-bit mode. We're using 2x 16-bit Flash memories S29JL032H. I only have to know what to change for the 32-bit part Flash memory. Like for instance do I need to change the #define BUSWIDTH 2 for this design in linux-2.4.x/drivers/mtd/maps/m5208.c? I've allready changed the flash bit width to 32-bit in block devices or do i need to make more specific changes. Erasing an sector seems to work almost fine. Except that it didn't fully erased the full memory range. For the SDRAM I changed the SDRAM Processor type features to 32-bit plus the changes in the files: linux-2.4.x/arch/m68knommu/platform/5208/crt0_ram.S linux-2.4.x/arch/m68knommu/platform/5208/ram.ld I don't suspect any complication on this part unless anybody says I need to change something specific? Ferry de Groot _ Het meest spraakmakende nieuws vind je op www.msn.nl http://www.msn.nl ___ 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] Adding IPtables on uClinux/snapgear
Jivin fara sam lays it down ... > Hi, > > I have added iptables to my uClinux via snapgear but > it seems not working properly because it doesn't know > any iptables command. Anyone has experience to use > iptables on uClinux? > I get messages such as bellow: > > # iptables -A INPUT -s 10.1.0.1 -j DROP > iptables v1.3.5: can't initialize iptables table > `filter': Table does not exist (do you need to > )Perhaps iptables or your kernel needs to be upgraded. Just to double check, have you enabled the appropriate iptables kernel modules ? Cheers, Davidm > #iptables -L INPUT > iptables v1.3.5: can't initialize iptables table > `filter': Table does not exist (do you need to > )Perhaps iptables or your kernel needs to be upgraded. > > # iptables -A > iptables v1.3.5: Unknown arg `-A' > Try `iptables -h' or 'iptables --help' for more > information. > > > Thank you in advance > Sam > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.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 McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.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] Adding IPtables on uClinux/snapgear
Hi, I have added iptables to my uClinux via snapgear but it seems not working properly because it doesn't know any iptables command. Anyone has experience to use iptables on uClinux? I get messages such as bellow: # iptables -A INPUT -s 10.1.0.1 -j DROP iptables v1.3.5: can't initialize iptables table `filter': Table does not exist (do you need to )Perhaps iptables or your kernel needs to be upgraded. #iptables -L INPUT iptables v1.3.5: can't initialize iptables table `filter': Table does not exist (do you need to )Perhaps iptables or your kernel needs to be upgraded. # iptables -A iptables v1.3.5: Unknown arg `-A' Try `iptables -h' or 'iptables --help' for more information. Thank you in advance Sam __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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] Compiling problems
Looks like you don't have zlib installed on your host (notice that it is doing a host build). On my Ubuntu system this is the zlib1g-dev package. Cheers, Steve On 01/05/2007, at 6:04 AM, Ron Jobmann wrote: (Posted again because I forgot subject line last time - sorry) I'm using Snapgear 3.4.0, building with the linux-2.6.x tree. Using the arm-linux-tools-20061213.tar.gz toolset, ixp420 processor, big endian. The kernel seemed to build OK. I haven't run it yet. Here's an example of an error message I'm getting now: arm-linux-ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o arm-linux-ranlib liblua.a ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o lua.o lua.c ucfront-gcc arm-linux-gcc -mbig-endian -o lua lua.o liblua.a -lm ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o luac.o luac.c ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -c -o print.o print.c ucfront-gcc arm-linux-gcc -mbig-endian -o luac luac.o print.o liblua.a -lm make[6]: Leaving directory `/opt/0427/user/lua/src' make[5]: Leaving directory `/opt/0427/user/lua/src' make[4]: Leaving directory `/opt/0427/user/lua' [ ! -d "mtd-utils" ] || ( touch mtd-utils/.sgbuilt_user && make -j1 -C mtd-utils ) || exit $? make[4]: Entering directory `/opt/0427/user/mtd-utils' [ -d build ] || mkdir build ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin erase.c -o erase ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin eraseall.c -o eraseall ucfront-gcc arm-linux-gcc -mbig-endian -O1 -pipe -fno-common -fno- builtin -Wall -Dlinux -D__linux__ -Dunix -DEMBED -D__USE_BSD -I. -g -fno-common -fno-builtin nandtest.c -o nandtest nandtest.c: In function `main': nandtest.c:120: warning: implicit declaration of function `memset' nandtest.c:266: warning: implicit declaration of function `memcpy' gcc -I/usr/include -I. -c -o build/crc32.o crc32.c gcc -I/usr/include -I. -c -o build/mkfs.jffs2.o mkfs.jffs2.c gcc -I/usr/include -I. -Dprintk=printf -DKERN_NOTICE= - DKERN_WARNING= -c -o build/compr_zlib.o compr_zlib.c compr_zlib.c:38:18: error: zlib.h: No such file or directory compr_zlib.c: In function ‘zlib_compress’: compr_zlib.c:81: error: ‘z_stream’ undeclared (first use in this function) compr_zlib.c:81: error: (Each undeclared identifier is reported only once compr_zlib.c:81: error: for each function it appears in.) compr_zlib.c:81: error: expected ‘;’ before ‘strm’ compr_zlib.c:91: error: ‘strm’ undeclared (first use in this function) compr_zlib.c:95: error: ‘Z_OK’ undeclared (first use in this function) compr_zlib.c:110: error: ‘Z_PARTIAL_FLUSH’ undeclared (first use in this function) compr_zlib.c:121: error: ‘Z_FINISH’ undeclared (first use in this function) compr_zlib.c:122: error: ‘Z_STREAM_END’ undeclared (first use in this function) compr_zlib.c: In function ‘zlib_decompress’: compr_zlib.c:143: error: ‘z_stream’ undeclared (first use in this function) compr_zlib.c:143: error: expected ‘;’ before ‘strm’ compr_zlib.c:150: error: ‘strm’ undeclared (first use in this function) compr_zlib.c:154: error: ‘Z_OK’ undeclared (first use in this function) compr_zlib.c:166: error: ‘Z_FINISH’ undeclared (first use in this function) compr_zlib.c:168: error: ‘Z_STREAM_END’ undeclared (first use in this function) make[4]: *** [build/compr_zlib.o] Error 1 make[4]: Leaving directory `/opt/0427/user/mtd-utils' make[3]: *** [mtd-utils] Error 2 make[3]: Leaving directory `/opt/0427/user' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/0427/user' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/opt/0427' make: *** [btr] Error 2 This all used to work. I'll try your suggestion and see what happens. I suspect it is hidden dependencies within the Makefiles that get all out of whack when things try to build in parallel. One thing I've done so far is to hardcode HOST_NCPU=1 but that hasn't fixed much. >>Jivin Ron Jobmann lays it down ... >> I just moved all my build tools over to a new machine, E6400 Core2 Duo >> processor. It's coming up with all sorts of compilation >>errors which I assume is because the makefiles are splitting up the >>work? The same tools and same source tree build fine on a >>single processor system. >> >>Is there something special I need to setup in my build environment on my >>new PC? >Which dist are you using ? What mods
