Re: [OpenWrt-Devel] Xilinx Spartan 3E Starter Kit port - JFFS2 question
Hi Harald and Florian, Thanks. I realize I forgot to ask the obvious question: How does the OpenWRT tree create the original JFFS2 filesystem? Would be simple to write an "unmake JFFS2" program? Is there one already in the OpenWRT tree? warm regards, John > >I can't seem to figure out how to either "mount" or uncompress the > > jffs2 filesystem that is produced by the OpenWRT compile. > > > >I try the obvious and get an unknown filesystem error. > > > >>mount file.jffs2 mnt -o loop -t jffs2 > > > >Help Please. > > You cannot mount jffs2 from a block device, it is designed to work an > raw flash devices only. > If you want to mount it from something not a physical flash dev, you > need the block2mtd emulation. > > http://gentoo-wiki.com/Mounting_a_block_device_with_JFFS2 > > harald ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] fix missing IPKG_INSTROOT in tar postinst
This patch ought to fix ticket #3436 by using ${IPKG_INSTROOT} in the
destination for the symlink created by postinst.
Signed-off-by: Tripp Lilley <[EMAIL PROTECTED]>
Index: packages/utils/tar/Makefile
===
--- packages/utils/tar/Makefile (revision 11125)
+++ packages/utils/tar/Makefile (working copy)
@@ -36,7 +36,7 @@
if [ -e $${IPKG_INSTROOT}/bin/tar ]; then
rm -r $${IPKG_INSTROOT}/bin/tar;
fi
-ln -sf $${IPKG_INSTROOT}/usr/bin/tar /bin/tar
+ln -sf $${IPKG_INSTROOT}/usr/bin/tar $${IPKG_INSTROOT}/bin/tar
endef
define Package/tar/postrm
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding new platform to openWRT
On 2008.05.12. 22:45:53 RB <[EMAIL PROTECTED]> wrote: >> to the workspace. I've added a patched-2.6.20 directory to >> target/linux/generic-2.6 and this allows me to control exactly which >> patches are applied against my kernel, but it seems wrong to have to >> modify the generic-2.6 folder to get what I want. If there is a way to >> accomplish this inside my target/linux/ dir, that would >> seem a better way to go. > > If your platform doesn't fit within any of the existing MIPS/MIPSEL > designations, you'll probably have to add your own platform's > directory. Just use one of the existing ones as a template, and of > course make sure your changes are as non-invasive to the rest of the > tree and as atomic as possible so you can feed the patches back here. Board specific patches go into target/linux/$platformname/patches (or optionally patches-x.y.z if you have different kernel versions for it). Config file should be either target/linux/$platformname/config-default or config-x.y.z Probably not all patches Brian wants to use are board specific. Those patches have to go into target/linux/generic-2.6/patches-x.y.z > I, for one, am fascinated with the possibility of a new SMP MIPS > implementation. I am one voice. You are not alone ;) Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding new platform to openWRT
On 2008.05.12. 20:31:38 Brian Oostenbrink <[EMAIL PROTECTED]> wrote: > We certainly will consider donating a couple of boards. They are in a > bit of short supply right now, so not sure yet when we'd be able to free > a couple up. > However, I'm not sure how having hardware would help to answer the > questions I raised, as they are really about the architecture of the > build system. Sounds good, thanks! I think Gregers meant that we could actually answer better to the integration/optimization questions given we have the hardware, too. Of course your current questions were mostly "starters before the lunch" I think :) I would be happy to help in getting the needed patches working with newer kernels, too. > I managed to resolve the third question I raised > (compilation error), and have managed to build a working image for my > board, using a ram filesystem. I'm now working on getting the squashfs > filesystem working with our kernel. I've chosen to work with the 7.09 > release of kamikaze for now, and have simply added my own kernel version > to the workspace. I've added a patched-2.6.20 directory to > target/linux/generic-2.6 and this allows me to control exactly which > patches are applied against my kernel, but it seems wrong to have to > modify the generic-2.6 folder to get what I want. If there is a way to > accomplish this inside my target/linux/ dir, that would > seem a better way to go. What you did sounds right. If general, if you want to add support for a different kernel version, you have to place the patches in target/linux/generic-2.6/patches-x.y.z and create a target/linux/generic-2.6/config-x.y.z if needed, too. If you don't want to have all the current generic openwrt patches, you can simply avoid them in the new directory. Cheers, Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding new platform to openWRT
Hello Brian, Sorry for the late reply, but I was on a trip and hardly had usable internet connectivity. On 2008.05.06. 18:47:48 Brian Oostenbrink <[EMAIL PROTECTED]> wrote: > I'm working on adding a new platform to openWRT. The platform is > multi-processor MIPS cpu that runs SMP Linux. I have a few questions: > 1. We currently have Linux 2.6.20 + busybox + squashfs running and > stable on our platform (using an old, customized buildroot-based > system), and have customers that require this kernel version. Any > suggestions regarding the best release of kamikaze to work with this > kernel version? Personally I would base it on trunk, but that's because I know the current status only, 7.09 was long ago. However I would do that locally and forward port the needed patches/platform support in the same time, too. > 2. I'm currently trying to get this working with kamikaze 7.09. I see > patch files in target/linux/generic-2.6/patches (and patches-2.6.22). > Is it the intent that these patches apply to *all* platforms, and each > platform can then add additional patches as needed? Our kernel version > has many patches, and since it is already working and stable, I'd like > to apply as few openwrt patches as possible to get a system running > quickly (and then later work on applying all the patches). Is this a > reasonable approach, or are the kernel patches required to support > openwrt features? Sounds reasonable. There are some patches that are required, but I think you can easily figure out those. One example is the rootfs splitting patch. > 3. As I started building, I quickly came upon this error during the > "make -j1 -C kernel compile" step: > cp: cannot stat > `/home/oostenbr/kamikaze_7.09/build_mips/linux-2.6-pmc71xx/linux-2.6.20. > 21/net/ipv4/ne > tfilter/ipt_iprange.ko': No such file or directory > I used a kernel .config file that already works with our system, which > statically links all parts of the kernel. Is it necessary to use > modules in openwrt? We compile statically to allow careful control of > code alignment in memory for optimal cache utilization (=performance), > so requiring the use of LKMs is a serious drawback in our application. You can make specific patches depend on !TARGET locally. Cheers, Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding new platform to openWRT
> to the workspace. I've added a patched-2.6.20 directory to > target/linux/generic-2.6 and this allows me to control exactly which > patches are applied against my kernel, but it seems wrong to have to > modify the generic-2.6 folder to get what I want. If there is a way to > accomplish this inside my target/linux/ dir, that would > seem a better way to go. If your platform doesn't fit within any of the existing MIPS/MIPSEL designations, you'll probably have to add your own platform's directory. Just use one of the existing ones as a template, and of course make sure your changes are as non-invasive to the rest of the tree and as atomic as possible so you can feed the patches back here. I, for one, am fascinated with the possibility of a new SMP MIPS implementation. I am one voice. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding new platform to openWRT
> -Original Message- > From: Gregers Petersen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 1:24 AM > To: Brian Oostenbrink > Subject: Re: [OpenWrt-Devel] Adding new platform to openWRT > > > > Brian Oostenbrink wrote: > > Hello: > > I'm working on adding a new platform to openWRT. > > In this respect it would be really productive if you could to donate a > couple of devices/boards - A lot of your questions are difficult to > answer when the actual hardware is unavailable. > > Sincerely > > -- > Gregers Petersen > People-stuff, layer 8 and anthropology > glp on irc > We certainly will consider donating a couple of boards. They are in a bit of short supply right now, so not sure yet when we'd be able to free a couple up. However, I'm not sure how having hardware would help to answer the questions I raised, as they are really about the architecture of the build system. I managed to resolve the third question I raised (compilation error), and have managed to build a working image for my board, using a ram filesystem. I'm now working on getting the squashfs filesystem working with our kernel. I've chosen to work with the 7.09 release of kamikaze for now, and have simply added my own kernel version to the workspace. I've added a patched-2.6.20 directory to target/linux/generic-2.6 and this allows me to control exactly which patches are applied against my kernel, but it seems wrong to have to modify the generic-2.6 folder to get what I want. If there is a way to accomplish this inside my target/linux/ dir, that would seem a better way to go. Regards, Brian Oostenbrink ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] wl500gp v2 + HUAWEI E226
I install the kernel 2.4.36.4, worked quite well. Already the USB port using
the HSDPA modem E226 presents an inconsistency, and that after a certain
period of time the system restarts (Reboot).
the best configuration of modules in openwrt was:
kmod-usb-core, kmod-usb-serial, kmod-usb-uhci, kmod-usb-uhci-iv, kmod-USB2,
kmod-usb-acm, kmod-usb-storage, kmod-fs-vfat, kmod - Nozomi, kmod-dpi,
kmod-mppe, kmod-dpi-synctty.
The module kmod-ohci caused an inconsistency.
Another effort was the use of driver pl2303 with compatibility with this
modem, working the same way.
People, something Idea
diff -rc --exclude='*.o' --exclude='.*'
/opt/openwrt-2.4.36.4/build_dir/toolchain-mipsel_gcc3.4.6/linux-2.4.36.4/drivers/usb/serial/pl2303.c
/opt/openwrt-2.4.36.4/build_dir/linux-brcm-2.4/linux-2.4.36.4/drivers/usb/serial/pl2303.c
***
/opt/openwrt-2.4.36.4/build_dir/toolchain-mipsel_gcc3.4.6/linux-2.4.36.4/drivers/usb/serial/pl2303.c2008-05-06
19:00:29.0 -0400
---
/opt/openwrt-2.4.36.4/build_dir/linux-brcm-2.4/linux-2.4.36.4/drivers/usb/serial/pl2303.c
2008-05-12 10:16:05.0 -0400
***
*** 115,120
--- 115,121
{ USB_DEVICE(DATAPILOT_U2_VENDOR_ID, DATAPILOT_U2_PRODUCT_ID) },
{ USB_DEVICE(BELKIN_VENDOR_ID, BELKIN_PRODUCT_ID) },
{ USB_DEVICE(ALCOR_VENDOR_ID, ALCOR_PRODUCT_ID) },
+ { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_ID) },
{ USB_DEVICE(WS002IN_VENDOR_ID, WS002IN_PRODUCT_ID) },
{ USB_DEVICE(COREGA_VENDOR_ID, COREGA_PRODUCT_ID) },
{ USB_DEVICE(HL340_VENDOR_ID, HL340_PRODUCT_ID) },
diff -rc --exclude='*.o' --exclude='.*'
/opt/openwrt-2.4.36.4/build_dir/toolchain-mipsel_gcc3.4.6/linux-2.4.36.4/drivers/usb/serial/pl2303.h
/opt/openwrt-2.4.36.4/build_dir/linux-brcm-2.4/linux-2.4.36.4/drivers/usb/serial/pl2303.h
***
/opt/openwrt-2.4.36.4/build_dir/toolchain-mipsel_gcc3.4.6/linux-2.4.36.4/drivers/usb/serial/pl2303.h2008-05-06
19:00:29.0 -0400
---
/opt/openwrt-2.4.36.4/build_dir/linux-brcm-2.4/linux-2.4.36.4/drivers/usb/serial/pl2303.h
2008-05-12 10:16:47.0 -0400
***
*** 112,114
--- 112,118
/* Y.C. Cable U.S.A., Inc - USB to RS-232 */
#define YCCABLE_VENDOR_ID 0x05ad
#define YCCABLE_PRODUCT_ID 0x0fba
+
+ /* Huawei E626 UMTS/HSDPA card (ID: 12d1:1001) --fmay*/
+ #define HUAWEI_VENDOR_ID 0x12d1
+ #define HUAWEI_PRODUCT_ID 0x1003
diff -rc --exclude='*.o' --exclude='.*'
/opt/openwrt-2.4.36.4/build_dir/toolchain-mipsel_gcc3.4.6/linux-2.4.36.4/drivers/usb/serial/usbserial.c
/opt/openwrt-2.4.36.4/build_dir/linux-brcm-2.4/linux-2.4.36.4/drivers/usb/serial/usbserial.c
***
/opt/openwrt-2.4.36.4/build_dir/toolchain-mipsel_gcc3.4.6/linux-2.4.36.4/drivers/usb/serial/usbserial.c
2008-05-07 23:41:06.0 -0400
---
/opt/openwrt-2.4.36.4/build_dir/linux-brcm-2.4/linux-2.4.36.4/drivers/usb/serial/usbserial.c
2008-05-12 10:17:44.0 -0400
***
*** 1558,1568
--- 1558,1572
err("No free urbs available");
goto probe_error;
}
+ /FMAY HSDPA adaptation
#ifdef CONFIG_USB_SERIAL_GENERIC
buffer_size = (endpoint->wMaxPacketSize > maxSize) ? endpoint->wMaxPacketSize
: maxSize;
+ /FMAY HSDPA adaptation
+ buffer_size = (serial->vendor==0x12d1 && serial->product==0x1003) ? 4096 :
buffer_size;
#else
buffer_size = endpoint->wMaxPacketSize;
#endif
+ printk("KERNEL DEBUG => USBSERIAL.O buffer_size = %d", buffer_size);
port->bulk_in_endpointAddress = endpoint->bEndpointAddress;
port->bulk_in_buffer = kmalloc (buffer_size, GFP_KERNEL);
if (!port->bulk_in_buffer) {
***
*** 1864,1869
--- 1868,1877
generic_device_ids[7].idVendor = 0x1410;
generic_device_ids[7].idProduct = 0x1430;
generic_device_ids[7].match_flags = USB_DEVICE_ID_MATCH_VENDOR |
USB_DEVICE_ID_MATCH_PRODUCT;
+ /* Huawei E226 *///FMAY
+ generic_device_ids[8].idVendor = 0x12d1;
+ generic_device_ids[8].idProduct = 0x1003;
+ generic_device_ids[8].match_flags = USB_DEVICE_ID_MATCH_VENDOR |
USB_DEVICE_ID_MATCH_PRODUCT;
/* register our generic driver with ourselves */
usb_serial_register (&generic_device);
#endif
diff -rc --exclude='*.o' --exclude='.*'
/opt/openwrt-2.4.36.4/build_dir/toolchain-mipsel_gcc3.4.6/linux-2.4.36.4/drivers/usb/storage/initializers.c
/opt/openwrt-2.4.36.4/build_dir/linux-brcm-2.4/linux-2.4.36.4/drivers/usb/storage/initializers.c
***
/opt/openwrt-2.4.36.4/build_dir/toolchain-mipsel_gcc3.4.6/linux-2.4.36.4/drivers/usb/storage/initializers.c
2008-05-06 19:00:29.0 -0400
---
/opt/openwrt-2.4.36.4/build_dir/linux-brcm-2.4/linux-2.4.36.4/drivers/usb/storage/initializers.c
2008-05-12 09:57:20.0 -0400
***
*** 41,46
--- 41,60
#include "debug.h"
#include "transport.h"
+ /* This places the HUAWEI E226 devices in multi-port mode --fmay*/
+ int usb_stor_huawei_e226_init(struct us_data *us)
+ {
+ unsigned char data = 0x1;
+ int result;
+
+ result = usb_stor_control_msg(us, usb_sndctrlpipe(us->pusb_dev, 0),
+ USB_REQ_SET_FEATURE,
+ USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+ 0x01, 0x0, &d
Re: [OpenWrt-Devel] Xilinx Spartan 3E Starter Kit port
Hello John, Le Monday 12 May 2008 02:56:24 RHS Linux User, vous avez écrit : >I can't seem to figure out how to either "mount" or uncompress the > jffs2 filesystem that is produced by the OpenWRT compile. > >I try the obvious and get an unknown filesystem error. > >>mount file.jffs2 mnt -o loop -t jffs2 This is the right way to mount a JFFS2 filesystem on your host. It requires your kernel to support the JFFS2 filesystem, which in turn, implies you enable the MTD subsystem. So basically, you have to recompile your host kernel with the following changes : Device Drivers -> Memory Technology Device (MTD) device File systems -> Miscellaneous filesystems -> Journalling Flash File System v2 (JFFS2) support And you should now be able to mout images on your host. When you get your board booting, please submit a patch for the Asics MIPS core to be supported in OpenWrt :D -- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Etrax target
nice to see someone actually use it. The build works succesfully on my machine. the cris-axis-elf thin is what i was thinking of aswell. i am on the move atm. but will contact you again about this john Quoting Hinko Ko?evar <[EMAIL PROTECTED]>: > Hinko Ko?evar wrote: > >> >> Next problem emerges when using $(CROSS_COMPILE)gcc instead of cris-gcc - >> toolchain that buildroot creates is cris-linux-uclibc and does not recognize >> -melf switch when linking head.o. Using $(CROSS_COMPILE)gcc fails >> with assembler >> errors Error: Illegal operands. > > Above errors are only seen when creating final linux kernel image.. > > I've hacked the openWRT rules.mk to define different type of final target - > instead of cris-linux-uclibc I used cris-axis-elf and rerun the make > procedure. > Binutils and gcc get built, but if fails at uClibc. It makes sense. Then I > reverted the rules.mk and proceeded with normal installation. Now (using > cris-axis-gcc for head.o compilation) linux kernel is compiled with success. > > Now, how would one integrate build of two different target compilers: > - cris-linux-uclibc > - cris-axis-elf > > into the openWRT buildroot? > > I guess we need only binutils and gcc stages (no libc part). > > Regards, > Hinko > > -- > ?ETRTA POT, d.o.o., Kranj > Planina 3 > 4000 Kranj > Slovenia, Europe > Tel. +386 (0) 4 280 66 03 > E-mail: [EMAIL PROTECTED] > Http: www.cetrtapot.si > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -- John Crispin hacking, coding, etc blogic on irc ___ __ | |.-.-.-.| | | |..| |_ | - || _ | -__| || | | || _|| _| |___|| __|_|__|__||||__| || |__| W I R E L E S S F R E E D O M KAMIKAZE (bleeding edge) --- * 10 oz Vodka Shake well with ice and strain * 10 oz Triple sec mixture into 10 shot glasses. * 10 oz lime juice Salute! --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Etrax target
Hinko Kočevar wrote: > > Next problem emerges when using $(CROSS_COMPILE)gcc instead of cris-gcc - > toolchain that buildroot creates is cris-linux-uclibc and does not recognize > -melf switch when linking head.o. Using $(CROSS_COMPILE)gcc fails with > assembler > errors Error: Illegal operands. Above errors are only seen when creating final linux kernel image.. I've hacked the openWRT rules.mk to define different type of final target - instead of cris-linux-uclibc I used cris-axis-elf and rerun the make procedure. Binutils and gcc get built, but if fails at uClibc. It makes sense. Then I reverted the rules.mk and proceeded with normal installation. Now (using cris-axis-gcc for head.o compilation) linux kernel is compiled with success. Now, how would one integrate build of two different target compilers: - cris-linux-uclibc - cris-axis-elf into the openWRT buildroot? I guess we need only binutils and gcc stages (no libc part). Regards, Hinko -- ČETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenia, Europe Tel. +386 (0) 4 280 66 03 E-mail: [EMAIL PROTECTED] Http: www.cetrtapot.si ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Etrax target
Hi, I see that OpenWRT has support for etrax target - cris architecture. I'm looking for flexible buildroot. I see openWRT is uclibc buildroot based. I would like build an image for this target, but it fails during kernel compilation: CC arch/cris/arch-v10/lib/usercopy.o AR arch/cris/arch-v10/lib/lib.a LD vmlinux.o MODPOST vmlinux.o WARNING: modpost: Found 7 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD vmlinux SYSMAP System.map OBJCOPY arch/cris/boot/Image BFD: Warning: Writing section `.text' to huge (ie negative) file offset 0xc0004000. BFD: Warning: Writing section `__ex_table' to huge (ie negative) file offset 0xc0143b18. BFD: Warning: Writing section `.rodata' to huge (ie negative) file offset 0xc0146000. BFD: Warning: Writing section `__ksymtab' to huge (ie negative) file offset 0xc01754b4. BFD: Warning: Writing section `__ksymtab_gpl' to huge (ie negative) file offset 0xc0178e7c. BFD: Warning: Writing section `__ksymtab_strings' to huge (ie negative) file offset 0xc017a53c. BFD: Warning: Writing section `__param' to huge (ie negative) file offset 0xc018611c. BFD: Warning: Writing section `.data' to huge (ie negative) file offset 0xc0187000. BFD: Warning: Writing section `.data.cacheline_aligned' to huge (ie negative) file offset 0xc0193b00. BFD: Warning: Writing section `.data.init_task' to huge (ie negative) file offset 0xc0194000. BFD: Warning: Writing section `.init.text' to huge (ie negative) file offset 0xc0196000. BFD: Warning: Writing section `.init.data' to huge (ie negative) file offset 0xc01a2548. BFD: Warning: Writing section `.init.setup' to huge (ie negative) file offset 0xc01a3860. BFD: Warning: Writing section `.initcall.init' to huge (ie negative) file offset 0xc01a3a70. BFD: Warning: Writing section `.init.ramfs' to huge (ie negative) file offset 0xc01a3c94. /usr/local/cris/objcopy-cris: arch/cris/boot/Image: File truncated make[6]: *** [arch/cris/boot/Image] Error 1 make[5]: *** [zImage] Error 2 make[5]: Leaving directory `/work/stage/opewrt-trunk/build_dir/linux-etrax/linux-2.6.25.1' make[4]: *** [/work/stage/opewrt-trunk/build_dir/linux-etrax/linux-2.6.25.1/.image] Error 2 make[3]: *** [install] Error 2 make[2]: *** [target/linux/install] Error 2 make[1]: *** [/work/stage/opewrt-trunk/staging_dir/cris/stamp/.target_install] Error 2 make -r world: build failed. Please re-run make with V=99 to see what's going on make: *** [world] Error 1 No biggie - dont't use /usr/local/cris/objcopy-cris, but $(CROSS_COMPILE)objcopy instead and it should fix the BFD: Warning: ... I've fixed the remaining hardcoded tool paths in arch/cris/*/* Makefiles. Next problem emerges when using $(CROSS_COMPILE)gcc instead of cris-gcc - toolchain that buildroot creates is cris-linux-uclibc and does not recognize -melf switch when linking head.o. Using $(CROSS_COMPILE)gcc fails with assembler errors Error: Illegal operands. Has anyone found the solution to this? I know I could use Axis compiler distro, but since buildroot creates one for us lets use that.. Best regards, Hinko ČETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenia, Europe Tel. +386 (0) 4 280 66 03 E-mail: [EMAIL PROTECTED] Http: www.cetrtapot.si ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Xilinx Spartan 3E Starter Kit port
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >I can't seem to figure out how to either "mount" or uncompress the > jffs2 filesystem that is produced by the OpenWRT compile. > >I try the obvious and get an unknown filesystem error. > >>mount file.jffs2 mnt -o loop -t jffs2 > >Help Please. You cannot mount jffs2 from a block device, it is designed to work an raw flash devices only. If you want to mount it from something not a physical flash dev, you need the block2mtd emulation. http://gentoo-wiki.com/Mounting_a_block_device_with_JFFS2 harald -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKCorJgyxs71kcx4RAmfFAKDqsFboMeTohkepJRS7DJNDKPPlbQCg75sw stC0qjyNXCZusgieyGz3bdg= =JhMD -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Xilinx Spartan 3E Starter Kit port
>I can't seem to figure out how to either "mount" or uncompress the > jffs2 filesystem that is produced by the OpenWRT compile. I had your same problem some time ago... JFFS2 filesystem can't be mounted in the obvious way :| You need a further step regarding the mtd device Here some good documentation: http://gentoo-wiki.com/Mounting_a_block_device_with_JFFS2 Anyway I'm not very skilled, so "take it as it is". I don't know if this is the correct answer to your problem :) Regards! Saverio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
