Re: [OpenWrt-Devel] extroot not using overlay? (was Re : [OpenWrt] #8542: various hangs with extroo t (mini_fo) using ext4)
Hi, It would be neat to allow a poor man's kexec. Select kernel and initramfs. Then pick which root to use. Makes multiple iso type images much easier. I can see arguements for both pivot and overlay behavior. Stuff tied heavily to kernel in first filesystem. Heavy programs, on demand, in second filesystem. I have one partition with 4 iso images that can be selected from but kernel/initramfs is a pain. Wiz On Sun, 2 Jan 2011, Brian J. Murrell wrote: Stefan Monnier monnier at iro.umontreal.ca writes: As someone who uses an external root (tho using a hand-made patch rather than your extroot, mostly because your extroot came later), I don't want an overlay, but I indeed want a pivot_root rather than a chroot. I have to echo Stefan's sentiments exactly. I also use an extroot device, also with some hand-made patches (like Stefan, my patches pre-date the mainline extroot support), although I'd be more than happy to put them aside and use the mainline support -- if it supported real/stand-alone filesystems. I currently use ext3 for example. It also seems to me that extroot support should not be an either/or situation. I have not looked at the extroot implementation as it currently exists, but I would propose that the extroot feature should support both (overlay and stand-alone) and figure out which one to use on it's own. Why not have the implementation look at what's on the extroot device and if it's an overlay filesystem format then execute the overlay codepath(s) and otherwise assume it's a standalone filesystem and mount it and pivot_root to it. Cheers, b. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Builds since yesterday afternoon not succeeding
Hi, While I find the build process basically opaque, I think anything that can be done to make it better and ckearer is well worth it. For me some simple examples and some clearer explanation of the intent of the various makes would be a big help. i.e.- 1. rebuild all except toolset = ??? ( Saves LOTS of time ) 2. clear world and rebuild as if just downloaded to a new directory. 3. erase full directory tree, (try to) download all files and rebuild 4. save all downloaded files (somewhere) , erase full directory tree and rebuild FWIW - I usually do 4. manually but would rather do 1. if it really worked? Maybe it already does? warm regards, wiz On Tue, 27 Jul 2010, Jim Henderson wrote: On Tue, 27 Jul 2010 16:52:28 +0100, Matthias Buecher / Germany wrote: Just read this thread today and want to mention, that if you run into build problems you should issue a make distclean (not dirclean) to get rid of all old stuff and extra packages (create patches of your manual changes first, so you can later re-apply them). That's good to know - I didn't notice that distclean was an option, and have been just doing a make clean make world - so will change my workflow to do distclean instead. When I run into build issues, I normally wait at least one additional release before reporting an issue (and take some time to look through the svn logs to see what might've caused a problem - I usually try to pinpoint the cause of the problem so I can make a useful report). In this case, I'd had some troubles for about a day and nothing in the logs was making it clear to me why I was seeing a problem (indeed, the only updates seemed to be for a different platform than what I build for). Appreciate all the tips and everyone's help. I'm still fairly new to building this code - but I also like testing bleeding-edge code. :-) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wireless Interface
FWIW, the first interface has different properties from the others. wiz On Mon, 12 Jul 2010, Jo-Philipp Wich wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. If you rely on a certain order of wifi ifaces you're most likely doing sth. wrong. Explain some more why you need it. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw7O9EACgkQdputYINPTPPr1gCfVKNhS6oL9rWRL57fziydAzJ7 a9AAn3hx1s6707e4NTQ+ZU2Cgktlc7eL =5H35 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] no checksum error recording on WRT54G3GV2(-VF)
Hi, You gotta be kidding!! XX megabytes is enough for anyone! Shades of Bill Gates and early DOS :). IMHO - Linux is about being able to easily use the hardware, NO? On Fri, 2 Jul 2010, Markus Wigge wrote: Hi, I finally managed to port another patch for the flashmap driver and the firmware-tools to prevent overriding the second images space. Now the device works quite stable with 8MB and without any nvram tweeking. Actually, I do have 16MB total after flashing. (I just have to install packages which didn't fit in manually afterwards.) Why should you want to leave 8MB alone? because it should work for everybody out of the box without tweaking any nvram settings beyond normal usage. And for me 8MB is enough for most scenarios because the hardware is too slow to run too much simultaneously... /Markus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Openwrt package installation order
Hi All, Not strictly related to your question, but somewhat relevant. FWIW - The order of turning on the various ports of the atheros wifi driver *DOES* matter. Client mode MUST be the first one if enabled. I gather there are other significant but opaque requirements also :( warm regards, wiz On Mon, 31 May 2010, Felix Fietkau wrote: On 2010-05-31 1:19 PM, Filippo Sallemi wrote: Hi, could someone explain how to change the order to install certain packages? I need to overwrite some configuration files, but the system overrides in alphabetical order. Having packages overwrite files of other packages is *NOT* supported. This is intentional and unlikely to change. Please rework your packages to ensure that they can be installed in any order. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem
Hi, I wonder IF linux can be made small enough for some of the embedded chips to boot and then attach an SD card as the file system? warm regards, wiz On Mon, 10 May 2010 edgar.sol...@web.de wrote: On 10.05.2010 23:47, Bernhard Loos wrote: 2010/5/10 Bernhard Loos bernhardl...@googlemail.com: 2010/5/10 Matthias Buecher / Germany m...@maddes.net: The linux partition spans over the kernel and the complete rootfs for flashing. The maximum kernel size is 0x000bc000 (begin of rootfs) minus 0x0004 (begin of linux) equals 0x0007c000 (496KB). Maddes This is not the maximum kernel size, it's only the current kernel size. You could probably get a few kb more flash space (32 at average) by changing the aligment of the rootfs, squashfs is read only, so it doesn't have to start at an erase block boundary. To clarify myself, the size is calculated dynamically, so compiling stuff into the kernel doesn't gain much. at least for sqashfs images. All others would profit from it. Are there other space sensitive platforms? ..ede ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] menuconfig vs kernel_menuconfig
Hi Felix and All, Thanks so much for your note. Very insightful :). So I am trying to enable MMC on Kamikaze 8.0.9 [actually the village telco version]. I need to wind up with 3 kernel modules related to gpio and mmc. I gather I start with kernel_menuconfig at the main level and then do menuconfig? It is still confusing to me which boxes in the two menuconfigs I check to get the various kernel modules whose names I know compiled in. i.e.- the names on the selection boxes don't make it clear which modules are going to be compiled? I feel like I must be missing some simple step? That said I am pretty sure I am close to having it working :). Again thank you for your insightful response. warm regards to all, Wiz On Tue, 20 Apr 2010, Felix Fietkau wrote: On 2010-04-19 11:40 PM, RHS Linux User wrote: Hi All, rant This whole config business IMHO is a real mess! I disagree, it just takes a bit of getting used to. Can someone clarify what happens with target config, and whatever other .configs that happen to be around somewhere? It works like this: you have target/linux/generic-2.6/config-kernelversion, which contains the baseline settings for all targets. Each target can override and add any config option relative to that. The delta is stored in target/linux/platform/config-kernelversion. The reason for that is that maintaining one individual .config for each target would create a much bigger mess, as it makes common config changes that affect all targets much harder to implement. Also it seems to me HI TIME that .config became a VERY visible file. So much depends on the main .config and the .config in the kernel directory. For reasons stated above, we can't just stick the plain .config files from the kernel directories in the target dir, as this would mess up other things. Is running make kernel_menuconfig the same as going into the kernel directory and doing menuconfig there? (I hope so.) No, it's not. Make kernel_menuconfig does these things (simplified): - Generate the kernel's .config by merging the following files: - target/linux/generic-2.6/config-kernelver - target/linux/platform/config-kernelver - run make menuconfig in the kernel tree - subtract generic stuff from the kernel's .config and rebuild target/linux/platform/config-kernelver from that The idea is that you only need to hand-edit stuff if you want to make changes to the generic config template, which most of the time you don't have to. A bit more tricky is the interaction with the build system .config for selecting modules. The idea behind that is to not let the kernel build all modules all the time, but allow the user to select which modules to throw in binary packages. For this to work, the build system needs to make further modifications to the kernel's .config before launching the kernel module build, as having making these changes ahead of time for platform kernel configs would launch you into an unmanageable Dependency Tree From Hell. For all of the .config merges, scripts/kconfig.pl is used, which can do some very simple config merging/splitting operation. For the module selection it has a special operation that allows the merged-in config to only *upgrade* config selections. That means if you selected something as =y in kernel_menuconfig, the build system will not change that. It will however select stuff as =m or =y depending on the KCONFIG settings for kmod-* packages that you selected. Normally you don't have to be concerned with this process at all, however occasionally you may encounter undefined config symbols which make kernel_menuconfig or kernel_oldconfig won't show you. In this case, you need to add defaults for the missing symbols either to the KCONFIG line of the package that triggered them, or simply stick them into target/linux/generic-2.6/config-* I hope this clears things up a bit - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add option for block-extroot to mount a sub directory on the external USB device
Hi,
Neat... It would be *VERY* nice to be able to do the same thing with
one or *TWO* MMC cards since they can be easily kludged onto a few GPIO
pins. Maybe your patch already supports this?
Wiz
On Fri, 9 Apr 2010, Quentin Armitage wrote:
The block-extroot package adds the capability for preinit to mount /overlay
on an external USB device. The attached patch extends
the capability to allow /overlay to be mounted on a sub-directory of the
external USB device.
I can see two uses for this:
1. I want to be able to use the USB device for other purposes as well, and
this keeps all the files in one place on the USB device
2. I can have multiple difference configurations on the USB device, and
select which one to boot through UCI configuration.
The option is configured through /etc/config/fstab, with an extra option,
rootfs_subdir, which is the sub-directory relative to the
root of the USB device. For example:
option rootfs_subdir/openwrt
would mount /overlay on the /openwrt sub-directory of the USB device. The
patch to /lib/functions/block.sh are purely to support this
additional option.
The patch also adds one extra level of searching for /etc/config/fstab,
adding a first choice option of looking on the USB device,
and if the file does not exist there, then tries
/tmp/overlay/etc/config/fstab (i.e. the internal flash jffs2 fs) and lastly
the
/etc/config/fstab on the squashfs filesystem. This allows the configuration
to be managed entirely on the USB device, without touching
the internal flash, other than the initial setup of the internal
/etc/config/fstab to enable the external rootfs.
The patch has been done like this, rather than modifying
/lib/preinit/50-determine_usb_root, so that it works in conjunction with
the patch I submitted yesterday for kexec'ing a new kernel from the USB
device during the preinit process.
Signed-off-by: Quentin Armitage quen...@armitage.org.uk
Index: package/block-extroot-subdir/files/52_usb_root_subdir
===
--- package/block-extroot-subdir/files/52_usb_root_subdir (revision 0)
+++ package/block-extroot-subdir/files/52_usb_root_subdir (revision 0)
@@ -0,0 +1,79 @@
+#!/bin/sh
+# Copyright (C) 2010 OpenWrt.org
+
+# This is free software, licensed under the GNU General Public License v2.
+#
+# /etc/config/fstab configures this script. It requires that the extroot
mount
+# was successful, and uses /overlay that it mounted.
+#
+#Example config:
+#config mount
+#option enabled 1
+#option is_rootfs 1
+#option rootfs_subdir /usbroot
+#
+# This will remount /overlay/$rootfs_subdir on /overlay
+
+. /etc/functions.sh
+. /lib/functions/block.sh
+
+config_fstab_extroot() {
+ local cfg=$1
+ local find_rootfs=$2
+
+ mount_cb() {
+ shift
+ local enabled=$6
+ shift
+ local is_rootfs=$9
+ shift
+ local rootfs_subdir=$9
+
+ if [ $is_rootfs = 1 ]; then
+ extroot_enabled=$enabled
+ extroot_subdir=$rootfs_subdir
+ fi
+ }
+ config_get_mount $cfg
+ reset_block_cb
+}
+
+check_extroot_enabled_or_subdir() {
+ local OLD_UCI_CONFIG_DIR=$UCI_CONFIG_DIR
+
+ [ $pi_extroot_mount_success = true ] || return 0
+
+ # If the extroot (mounted on /overlay) has a config, use it, otherwise
+ # try jffs2 overlay
+ if [ -r /overlay/etc/config/fstab ]; then
+ UCI_CONFIG_DIR=/overlay/etc/config
+ elif [ $jffs = /tmp/overlay ] [ -r
/tmp/overlay/etc/config/fstab ]; then
+ UCI_CONFIG_DIR=/tmp/overlay/etc/config
+ fi
+
+ extroot_enabled=0
+ extroot_subdir=
+
+ config_load fstab
+ config_foreach config_fstab_extroot mount 1
+
+ # check we want this enabled
+ if [ $extroot_enabled = 0 ]; then
+ # No
+ pi_extroot_mount_success=false
+ umount /overlay
+ pi_mount_skip_next=$pi_pre_extroot_skip_next
+ pi_extroot_mount_success=0
+ else
+ [ -n $extroot_subdir ] [ -d /overlay/$extroot_subdir ]
+ mkdir -p /tmp/overlay1 \
+ mount --bind /overlay/$extroot_subdir /tmp/overlay1
\
+ umount /overlay \
+ mount --move /tmp/overlay1 /overlay
+ fi
+
+ UCI_CONFIG_DIR=$OLD_UCI_CONFIG_DIR
+ return 0
+}
+
+boot_hook_add preinit_mount_root check_extroot_enabled_or_subdir
Index: package/block-extroot-subdir/files/49_save_skip_next
===
--- package/block-extroot-subdir/files/49_save_skip_next (revision 0)
+++ package/block-extroot-subdir/files/49_save_skip_next (revision 0)
@@ -0,0 +1,12 @@
+#!/bin/sh
Re: [OpenWrt-Devel] Howto debug init scripts like preinit?
Hi, I often use a simple bit-bang function at some high buad rate and one gpio pin. I hook a serial terminal to it. Depending on CPU speed, etc. interrupts may have to be disabled during the time the character is actually being sent. One character at 115,200 is 0.1ms so unless the CPU is very busy with time dependent stuff, most applications don't seem to mind that much. As an additional variation of this scheme, I make the pin bi-directional and hook my full software debugger to it. I can peek, poke and monitor memory in more or less real time. Works great. Saves LOTS of time. And makes things really clear. This feature would be a good add to OpenWRT in my copious spare time :)). regards, Wiz On Wed, 24 Mar 2010, Ferenc Wagner wrote: Daniel Dickinson csh...@csolve.net writes: You won't see anything from preinit with set -x because when preinit is first called there is no stdin/stdout. One of the things preinit does is attach itself to a terminal, if there is one (otherwise it just connects to a pseudo-terminal) Would putting /dev/console in the root filesystem solve this? Fakeroot could be used for that without requiring real root for image generation. -- Thanks, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Serial port - Atheros - WORKS
Hi, Works !!! OpenWRT Mesh Potato - Village Telco version. 1. disable ttyS0 line in inittab. 2. recompile 8250.c in ../david/ directory with define fastISR disabled. 3. rmmod 8250mp 3.5 insmod serial_core if needed 4. insmod 8250new.ko 5. minicom /dev/ttyS0 WORKS :))) So now I can get to my data acquisition serial hardware over the batman mesh with a fully wireless connection !! OpenWRT ROCKS !! Thanks to all, Wiz On Tue, 23 Mar 2010, RHS Linux User wrote: Hi, Thanks. I'll try your idea later today :). There are three entries for shell terminals in inittab. One confuses me tty/0. Any idea what that entry is for? Wiz p.s.- my last change, yesterday, modifying preinit gave a kernel panic and I had to rebuild the whole mess. The joys of embedded programming :). On Mon, 22 Mar 2010, Spudz76 wrote: You probably need to comment out the console entries for the serial port(s) in /etc/inittab and then try again. That should free up the port for use with minicom (or any other serial app). You have to reboot to have the change take effect, unless you customize your busybox (compile your own image) to allow a kill signal to force an inittab reload. Also, of course, doing this disables the serial console completely (after boot messages, no shell), so don't biff your networking setup or you'll be forced to reflash. On Mon, 2010-03-22 at 16:47 -0500, RHS Linux User wrote: Hi, On a Meraki mini, Atheros ar2315 SOC I am trying take over the serial port as in: minicom -s [/dev/ttyS0]. Lock file gets made OK. I notice there are MANY serial port related entries in System.map (serial, tty, uart, etc.) And several /dev entries. I have yet to figure out what to do so minicom can talk over the SOC serial port??!! It ought to be simple ;-). Has anyone found a simple way to do this? Thanks, Wiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Serial port question - Atheros
Hi, Thanks. I'll try your idea later today :). There are three entries for shell terminals in inittab. One confuses me tty/0. Any idea what that entry is for? Wiz p.s.- my last change, yesterday, modifying preinit gave a kernel panic and I had to rebuild the whole mess. The joys of embedded programming :). On Mon, 22 Mar 2010, Spudz76 wrote: You probably need to comment out the console entries for the serial port(s) in /etc/inittab and then try again. That should free up the port for use with minicom (or any other serial app). You have to reboot to have the change take effect, unless you customize your busybox (compile your own image) to allow a kill signal to force an inittab reload. Also, of course, doing this disables the serial console completely (after boot messages, no shell), so don't biff your networking setup or you'll be forced to reflash. On Mon, 2010-03-22 at 16:47 -0500, RHS Linux User wrote: Hi, On a Meraki mini, Atheros ar2315 SOC I am trying take over the serial port as in: minicom -s [/dev/ttyS0]. Lock file gets made OK. I notice there are MANY serial port related entries in System.map (serial, tty, uart, etc.) And several /dev entries. I have yet to figure out what to do so minicom can talk over the SOC serial port??!! It ought to be simple ;-). Has anyone found a simple way to do this? Thanks, Wiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Serial port question - Atheros
Hi, On a Meraki mini, Atheros ar2315 SOC I am trying take over the serial port as in: minicom -s [/dev/ttyS0]. Lock file gets made OK. I notice there are MANY serial port related entries in System.map (serial, tty, uart, etc.) And several /dev entries. I have yet to figure out what to do so minicom can talk over the SOC serial port??!! It ought to be simple ;-). Has anyone found a simple way to do this? Thanks, Wiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Fix kexec support on brcm47xx
Hi All, FANTASTIC I can't wait to get it running here !! Wiz On Sun, 21 Mar 2010, Florian Fainelli wrote: Hi Adrian, Le dimanche 21 mars 2010 17:02:24, Adrian Byszuk a écrit : Dear developers, This kernel patch fixes problems with kexec call on some devices. It allows booting whole system (incl. kernel!) from e.g. USB disk. I tested it on Asus WL-500gP v2. I suppose it would behave well on all MIPS machines. Applicable to 2.6.32 and 2.6.33 Do you mind posting this on linux-m...@linux-mips.org with your Signed-off-by? Thank you! Signed-off-by: Adrian Byszuk adebex_at_gmail.com --- --- a/arch/mips/kernel/machine_kexec.c 2010-03-15 15:52:04.0 + +++ b/arch/mips/kernel/machine_kexec.c 2010-03-21 15:25:13.953615489 + @@ -52,7 +52,8 @@ reboot_code_buffer = (unsigned long)page_address(image-control_code_page); - kexec_start_address = image-start; + kexec_start_address = + (unsigned long) phys_to_virt(image-start); kexec_indirection_page = (unsigned long) phys_to_virt(image-head PAGE_MASK); ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] block-mount, block-extroot, and other Wiki documentation
Hi, Gotta check this out. Maybe I can get time to take a pass at the docs? Wiz On Sat, 27 Feb 2010, Daniel Dickinson wrote: [NON-Text Body part not included] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?
Hi All, I support a 2mb version for a somewhat different reason. It seems to me that the base router kernel/boot loader should be VERY small. It optionally does a 'kexec' to a possibly attached USB/MMC memory card. In this way router firmware can be totally upgraded. Can be as large as needed. A known good version can be on one card and an under development on another. And so on. It's a MUCH better development model. Wiz On Sat, 20 Feb 2010, Daniel Dickinson wrote: [NON-Text Body part not included] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
Hi, I have one further suggestion. I have HAVE a DUAL mips3 with 64 megabytes of ram RUNNING on an FPGA. However, mips3 has a VERY small instruction set. So far I haven't been able to get the kernel to run AT ALL. The reason is because some of the more elegant MIPS instructions are used by the kernel even when compiled in mips3 mode :(. So I suggest ONE additional flag. __ - Emulate unimplemented mips instructions When my or your mips3 ( with its mini instruction set ) encounters an instruction it doesn't know how to handle, it is handled in emulation software. I presume there are already such emulators out there (PLEASE, PLEASE tell me where!). Also, custom instructions can EASILY be added without modifying the FPGA code! __ - Emulate USER special instructions warm regards, wiz (pen name) On Sun, 21 Jun 2009, Jonas Gorski wrote: 2009/6/21 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 23:56:51 Jonas Gorski wrote: 2009/6/20 Michael Buesch m...@bu3sch.de: On Saturday 20 June 2009 00:09:56 Jonas Gorski wrote: If we do _not_ gain performance, it certainly is not a good idea to waste space. I would be very surprised if we wouldn't. Every kernel emulated floating point operation results in an exception and the appropriate handling (fpu emulation is ugly), while soft-float should stay completely in user space. Also, the mips fpu emulator itself suggests that. Quoting linux/arch/mips/math-emu/cp1emu.c: * Note if you know that you won't have an fpu, then you'll get much * better performance by compiling with -msoft-float! To get some numbers: Perhaps could somebody test with 'sample' from libmpcdec the difference in speed between in-kernel emulation and soft-float? https://dev.openwrt.org/ticket/4715 suggests that the library depends heavily on floating point when not using fixed point math. No you completely got me wrong. I am talking about the performance gain in real life. userspace soft float certainly _is_ faster than kernel float. But _if_ userspace soft float is bigger in size than kernel float, it probably is not worth the space tradeoff, because floating point is hardly used on a router. I apology, I really did misunderstand you. Did somebody test this: * Image with kernel FP emu disabled and userspace softemu enabled. * Image with kernel FP emu enabled and userspace softemu disabled. Which one is smaller? Disabling the kernel fpu emu isn't intended in linux, so I had to hack the emulation away, mainly by removing any fpu references in arch/mips/kernel/ until it compiled. I don't know if it really works, I don't have a second device for testing. I used the brcm47xx/default profile for testing, making distclean before compiling. With kernel-fpuemu and no softfloat: 256 openwrt-brcm47xx-squashfs.trx Without fpuemu and with softfloat: 2625536 openwrt-brcm47xx-squashfs.trx So the image with soft-float instead of the in-kernel fpu emulation uses one block more. For me this would be an acceptable increase. So what about the following. We introduce another option in the kernel config to disable fpuemu. This way the user can select either useremu, kernelemu or no emu at all. This probably is a win-win situation then. Because if I do care about space, I can turn off _both_ emulators. And you, who do care about performance, can set the openwrt default to kernelemu-off useremu-on. This would probably the best option. We should then test which applications/libraries need floating point support and mark these with an appropriate dependency. Going with no float support might require additional tweaking, as busybox seems to use floating point. Regards, Jonas Gorski ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ping Re: RFC: LuCI Web Interface Image Format
Hi All, You have some very good ideas. I would like to suggest using [requiring] BOTH md5sum and sha1. This is much harder to fake. I have already seen TWO DIFFERENT VERSIONS of the same wireless driver in the wild ??!! It seems that those of us who are successful [openwrt] attract a lot of vultures! Real time monitoring of the executable portion of running code would probably also be wise. In this way the processor can hopefully eventually notice that code has been patched or otherwise changed and cause a reboot. Write once devices look better and better. Comment: There are lots of smart people who want to join our party without a proper invitation :)). warm regards to all, Wiz (pen name) On Tue, 16 Jun 2009, Daniel Dickinson wrote: [NON-Text Body part not included] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Does anyone know the GPIO address for Meraki Mini?
Hi, I am trying to add MMC support for Meraki Mini, Atheros ar2315 chip. I am stuck as to where to find the correct GPIO address? Also, I am wondering where this hardware address should be in the openwrt Atheros related sources. So far I am getting reboots when I use the io program to poke various places :(. Thanks to all for your great work. warm regards, Wiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kexec on mips
Hi, Dunno about kexec, but I am interested too. Wiz On Mon, 11 May 2009, Brian J. Murrell wrote: [NON-Text Body part not included] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introduce new router board
Hi, New Router board VERY good idea I AM willing to get envolved to help with whatever (BSE(EE),MSEE, etc.). Features I need: VERY cheap basic unit available. Good OEM package. Full sources for whole design. OEM engineers available. Copies of current engineering package for PCBs, VHDL, Code, etc. Design available in form suitable for use with open source tools!! Provision for add on modules: Piggy back or plug-in feature modules. And the usual feature set you probably already have identified. 1. GPIO - SPI/Serial to peripheral(s) with or without their own processor MMC/SD (of course) BIG DDR - Suggest 256MB min. DDR module plug-in? 2. I TOO see NO NEED for large on PCB flash. Just boot flash with rest of load on plug-in MMC card warm regards to all, Wiz (pen name) On Tue, 5 May 2009, Weedy wrote: Ondrej Zajicek wrote: On Tue, May 05, 2009 at 09:27:26PM +0300, Linkodas wrote: Hi list/community, we would like to introduce new router supporting OpenWRT. It is only in development stage and we are looking for community opinion regarding its features and possibilities. There still currently a chance to change something and take into community response. I would suggest to add bootable CF or SD card connector (or two). There are two use cases for such cards: - Installation of Debian Linux (or another 'normal' Linux distribution compiled for ARM). It is much simpler to install such distribution on CF or SD card than on internal NAND flash. - Persistent storage of system logs and other runtime writable data. It should be possible to implement CF or SD card slot using a couple of GPIOs. A nice and useful feature is also onboard piezobuzzer like one on newer Mikrotik Routerboards. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel http://www.dealextreme.com/details.dx/sku.11164 http://www.dealextreme.com/details.dx/sku.19904 http://www.dealextreme.com/details.dx/sku.15665 http://www.dealextreme.com/details.dx/sku.17790 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Where is the code that causes jffs2 to be built-in
Hi All, A good idea IMHO. Small boot up means more stuff in removeable memory means MUCH easier to try new versions. If we have a small simple bootup all the heavy stuff could be on one plug-in memory or better two. One for known good stuff and one for stuff being tested. Just my 2 cents. warm regards to all, John On Tue, 16 Dec 2008, Stefan Monnier wrote: I see. Sounds like a lot of trouble just to remove jffs2. Yes. Is there any particular reason you're trying to do so? I see what you're trying to do, but no why. JFFS2 is rather well suited for the hardware OpenWRT is targeted at, integrated HD or not. Does the 700gE not have any flash at all? What do you hope to gain by propagating yet another edge case? The WL-700gE only has 2MB of flash, so if you're careful to strip down the firmware image, you get a tiny jffs2 partition that's half-working (too few erase blocks available for jffs2 to work reliably), and in any case the jffs2 is only used to override the squashfs files to make them mount /dev/hde1 and pivot to it early in the boot process (e.g. by replacing /sbin/init with a script that does mount+pivot+exec/sbin/init). And with more recent images, I even find it difficult to get a small enough image that there is space at all for a jffs2 partition. So instead, I change the source code so there's no need to use a jffs2 to override the squashfs files (basically I add a few lines to /sbin/mount_root to try and mount /dev/hde1 and pivot to it). Not using a jffs2 partition gives me very valuable space to add some handy tools (handy when the /dev/hde drive somehow fails to mount), and removing the jffs2 code would give me yet a bit more space for more such tools. But it's not like it's a big deal. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] About the ramdisk image generated by openWRT
Hi, So exactly what do I have to do? Can I just load it into memory by whatever means (my debugger) and just start it? Does the file relocate itself once started? GOTTA get this working!! Sounds VERY useful :). warm regards, John On Thu, 18 Dec 2008, Stephen Gutknecht (hilltx) wrote: Yes, I have used it with u-boot to perform a tftp boot of OpenWRT without touching the flash memory of a router. Example on the OpenWRT forum: http://forum.openwrt.org/viewtopic.php?id=17975 Really ideal way to test experimental builds. Stephen On Thu, Dec 18, 2008 at 7:23 AM, mike xu clums...@gmail.com wrote: Hi All, Could somebody explain to me that the purpose of setting the target to ramdisk in openWRT? Target Images --- [*] ramdisk Does the final image contains both of the kernel image and ramdisk rootfs ? Best regards Thanks ! Mike ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Smallest Linux
Hi All, Thanks for all your comments so far. Of interest, elinux.org has some real data about very small linux versions. From what I see it is VERY hard to determine what RAM is really needed by the kernel??!! So any cleanup and shrink effort could be quite a large effort? That said, we REALLY need to have available a BARE MINIMUM kernel that is clearly documented so the MINIMUM requirements to run any sort of linux can be easily determined. I am NOT planning to become the focal point person for such an effort, but it is probably worth being said :). Further comments welcome. warm regards, John On Mon, 13 Oct 2008, bifferos wrote: --- On Sun, 12/10/08, RHS Linux User [EMAIL PROTECTED] wrote: From: RHS Linux User [EMAIL PROTECTED] Subject: Re: [OpenWrt-Devel] Smallest Linux To: OpenWrt Development List openwrt-devel@lists.openwrt.org Date: Sunday, 12 October, 2008, 11:26 AM I am very much looking forward to anyone's further comments and suggestions. I can only suggest looking at NetBSD instead if memory and flash is really tight. You'll do better than with OpenWrt (if you leave aside the lack of tiny dhcp client daemon and 'micro' versions of other useful utils), but you still won't get anywhere near what you want. Here's some info on running NetBSD on an Edimax router: http://linux-adm5120.sourceforge.net/netbsd/ Bear in mind that LwIP (http://www.sics.se/~adam/lwip/), a tcp/ip stack for embedded systems itself takes up 'tens of kilobytes' of RAM, so how you do with 50KB will depend on whether you need tcp/ip or not presumably. Also, the discussion on the OpenWrt list focuses around a complete OpenWrt installation, whereas you can just use a kernel. There was an interesting article in Linux Journal explaining how to write an ftp client as a kernel module: http://www.linuxjournal.com/article/7660 One could simply write one's application by inserting one's own code into the C entry point in the kernel, but I think there would need to be a lot of money in it to make it worthwhile. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Smallest Linux
Hi All, Thanks to everyone who has commented so far. Some VERY good points. It IS a VERY small space. On the other hand: With some attention being now given to what REALLY needs to happen on boot, I think Linux's REAL minimum requirements is a VERY good question to ask AND ANSWER! Plus it will make the boot process MUCH faster. From what I can see looking at a compiled and linked kernel image there is a LOT of stuff that really doesn't not need to be done or could be done MUCH later (when and if drivers are loaded for example). So some clarity and transparency and MINIMALIZATION of the whole getting linux started process seems to me to be a good thing for all of us to give attention to ( in our copious spare time !! ) :). FWIW That is what I have been looking at. I have still to figure out the whole process of getting some of my stuff into the working tree. OpenWRT is a brilliant piece of code !! So I still have things to learn !! I am very much looking forward to anyone's further comments and suggestions. warm regards to all, John On Sat, 11 Oct 2008, RB wrote: 50kB of RAM is *far* from sufficient. OpenWRT runs in 8MB of RAM, and might even do something useful in 4MB, but muh below that doesn't sound promising at all. Under 1MB doesn't even sound promising for an utterly minimal 2.4 kernel. OWRT may be pretty tiny, fitting into 2-3MB of flash sometimes, but 50k/500k is a completely different class of tiny. Seriously - the floppy Linux distros you speak of are ~3x the size and are barely functional; do you really think one could reduce that by 70% and still be functional? There is a great deal of documentation that none of the BSDs will run in under 8MB and that Linux really isn't functional under 4. As Jose suggested, there are alternatives, but Linux just won't cut it in this small of space. Heck, computers in the mid-80's were coming out with 64k of RAM and 180k floppies - not too far off of this platform you're wanting to run on. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt as non-profit
Hi all, ... Who cares Maybe just suggest that donations be sent to help for the (few?) of us who are making ANY money. Seems like a lot of work. Maybe it will only divert some of us from getting real code running? Just my Two Cents or Euros or whatever :)). On Tue, 23 Sep 2008, RB wrote: There has for a while been discussions amongst the dev-group about making the big step towards OpenWrt.org achieving non-profit status. I've been wondering about this, and am pleased to see it's actually being discussed/considered. I, for one, would love to see more openness and improvement on the donation process. Nothing quite like shipping a piece of mildly expensive equipment to $random_dev's house. However, I also echo Simon's concerns with diversion of energies - as long as it can happen without detracting too much from the work (as in art) at hand, I'm all for it. 1. Build an independent non-profit foundation Like starting a small business or sole proprietorship, this has the greatest flexibility and allows real control, but requires a sizeable amount of dedication and effort on the part of at least one individual. It is my observation that maintaining a foundation isn't terribly difficult or time-consuming, but startup (or re-startup, as the case may be if the foundation is allowed to lapse) is definitely more painful. 2. Join on eof the exisitng umbrella entities, such as; The biggest argument I've seen against joining such entities is that the POC on both sides is usually restricted to a 1:1 relationship. Enter hit-by-a-bus discussion. What is OpenWrt's current relationship with private business interests? How will that play into a transition? RB ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] trying to get a usb storage mounted on root
Hi All, If I understand your point about the 3rd option? 1. The driver(s) could either be in the kernel, 2. In the greater kernel image (flash chip) as drivers loaded after kernel boot. 3. On some removeable device (USB or whatever). If the drivers are capable of being loaded by the kernel, then they could be either in 2 or 3. Except that the drivers necessary to mount or make available the device of #3 (USB or whatever), must reside in 2. These drivers could be either linked statically to the particular kernel image or not. There is one additional point that is probably relevant. The boot kernel could be replaced by a kernel and filesystem provided by the USB or whatever device. IMHO getting this sort of KERNEL-PIVOT operation really working would be the best of all. The boot kernel would only be used for boot and debug and a real kernel could run real applications on the USB. The boot kernel could even become a task running under the new kernel. USBs are now at at least 8 GBytes which means a pretty healthy linux system could be up and running once the USB image is booted ! warm regards, John On Sat, 12 Jul 2008, Brian J. Murrell wrote: [NON-Text Body part not included] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt-devel Digest, Vol 29, Issue 25
Hi Harald, Thanks for your reply. I am not sure what you mean by don't break threads? Do you mean leave the subject line as this mail has? I hope so. I tried a bunch of things as you can see below. I wasn't aware of the headers. That sounds like my problem. Thanks. I'll try what you suggest later today. You ask whether JFFS2 is endian specific? From what I can tell, yes it is. I get different results if I do jssf2dump with the -l verses the -b flag. warm regards, John 1. Re: Xilinx Spartan 3E Starter Kit port- JFFS2 question (Harald Schi?berg) Hi Harald, I tried to mount jffs2 today with Ubuntu (please see below) without success. I know the jffs2 file is OK since I install it in a Meraki Mini and the Meraki Mini runs OK. However, I tried to mount the file on the Meraki Mini with mount file.jffs2 mnt -t jffs2. Again it didn't work. I just tried with a recent asus-image on ubuntu = works. You must not take the images from bin/ , because they usually contain headers for the bootloader, the kernel and the image in some mangled layout. (This may be different on the meraki, it's totaly arch specific) Take the raw jffs2 images from build_dir/linux-subarch/*.jffs Thanks for the pointer to image.sh I will look at it tomorrow. Is there more than one JFFS2 format? I don't know whether jffs2 is fixed-endian or host-endian. harald ps: please try not to break threads by replying to arbitrary mails. - --- notes 1. mtd-20050122 was recently downloaded from debian.org as source and compiled for i386 (on Knoppix 5.0.1 dist. of Debian). The results are the same when the Debian.org .deb file is used for jffs2dump. 1.5. There is a jffsreader program that does not compile here. 2. The version downloaded from Debian.org seems to match the version in use by OpenWRT. Perhaps there is some sort of header problem?? (wrong crc header being used in one compilation or the other)? 3. Running jffs2dump suggests that the actual CRC used by OpenWRT when meraki-atheros.jffs2 is created is different??!! Also, the bitmask doesn't match (whatever that means). 4. This was the closest I could come to a version of jffs2dump that appeared to work somewhat. --- pwd - /mount/jmhwork/mtd/mtd-20050122.orig/util -- jffs2dump command of known good meraki-atheros jffs2 file ./jffs2dump -v -c /mount/jmhwork/meraki/openwrt-atheros-2.6-root.jffs2-64k -- result of running jffs2dump command --- Wrong bitmask at 0x, 0x8519 Wrong hdr_crc at 0x0001612c, 0x33c467e2 instead of 0x5152c1df Wrong bitmask at 0x00016130, 0xfb53 Wrong hdr_crc at 0x000a1248, 0x1d673ef0 instead of 0xf52eba1a Wrong bitmask at 0x000a124c, 0x7d61 Wrong hdr_crc at 0x000a5d74, 0x8836a835 instead of 0x184e0842 Wrong bitmask at 0x000a5d78, 0xfea5 Wrong hdr_crc at 0x0010f8c8, 0x0acd1072 instead of 0xfcdbe3f5 Wrong bitmask at 0x0010f8cc, 0x6fcf Wrong hdr_crc at 0x0011b31c, 0x06f8f0f1 instead of 0x16fd3147 Wrong bitmask at 0x0011b320, 0x73ee Wrong hdr_crc at 0x001c4010, 0x7fa02471 instead of 0x1d214567 Wrong bitmask at 0x001c4014, 0xfa03 Wrong hdr_crc at 0x001ddce8, 0xafc759ad instead of 0x80ca45d0 Wrong bitmask at 0x001ddcec, 0xa95d Wrong hdr_crc at 0x001e9c08, 0xafac8f01 instead of 0xd74e3520 Wrong bitmask at 0x001e9c0c, 0x12f2 Wrong hdr_crc at 0x00201a38, 0x207e3dc8 instead of 0x3543f8a7 Wrong bitmask at 0x00201a3c, 0xf1f7 Wrong hdr_crc at 0x0021179c, 0xd4603883 instead of 0xd106f254 Wrong bitmask at 0x002117a0, 0x4b8c Wrong hdr_crc at 0x00283f20, 0x416226c1 instead of 0x7bf15829 Wrong bitmask at 0x00283f24, 0xe63b Wrong hdr_crc at 0x002962c0, 0x9f836b1f instead of 0x743050c5 Wrong bitmask at 0x002962c4, 0xd45d Wrong hdr_crc at 0x002a301c, 0x70fcb8e1 instead of 0xc3591420 Wrong bitmask at 0x002a3020, 0x3900 Wrong hdr_crc at 0x002ee494, 0x0c2dd7ac instead of 0x52f69d3a Wrong bitmask at 0x002ee498, 0xdd6f Empty space: 26992, dirty space: 3643024 ___ 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 - 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
Re: [OpenWrt-Devel] Xilinx Spartan 3E Starter Kit port
Hi All, I am pretty sure that the OpenWRT is still NOT compiling the Linux kernel and modules for mips1 when the main menuconfig Advanced configuration options (for developers) -mips1 -march=r3000 -mtune=r3000 flag is given. The packages seem to compiled correctly for mips1, but when I reverse assemble the Linux binary I still see non-mips1 instructions such as MOVN, etc. So far I haven't discovered where this problem is actually coming from. I have tried changing various Config.in, etc. but still have yet to really change things. ANY further suggestions would be greatly appreciated! Thanks to your advice, I have created a Spartan 3E version of OpenWRT and I now have a seperate Spartan 3E SK directory. Also, as far as I can tell, gcc correctly compiles various test programs using only mips1 instructions when gcc gets the -mips1 flag. That is good! I tweaked the opencores-mlite reverse assembly tool to disassemble JUST mips1 instructions and to print ??? when a non mips1 instruction is encountered. Using this and hexdump to verify what I think I find, I can see non-mips1 instructions in the Linux kernel. So, I am still looking for the real problem, kernel flags or whatever. Any further thoughts and ideas GREATLY appreciated! Thanks in advance for your time and help. wiz ___ 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
Hi Florian, Thanks so much for your ideas. I will look into config.in Monday. Also, thanks for letting me know there are no known good R3k ports. So I guess I will be the first. Let's hear it for the pioneers. ( You can tell a pioneer from the arrows in his back :) ). I am pretty sure my MIPS and DDR are OK. They run live stuff on the web (as the mlite project on opencores.org). I am not the mlite author, but have been working on an FPGA product design for some time and corresponding with Steve, mlite's author. Right now I have 2 x MIPS, 1 picoblaze and 1 FastPIC all running at the same time in the Spartan 3E Starter kit. Steve is serving web pages from his Starter Kit. So I am pretty sure that the MIPS and DDR work OK. Also, my own tests and running programs indicate that things OK. For example, I can run my debugger in the main mips using the first 3E serial port and simultaneously run a copy of my debugger in the DDR MIPS using the other 3E serial port. These connect to ttyS0 and ttyS1 of my Linux box. I run two copies of minicom, so I can see both ports at once. When I download OpenWRT into the 2nd MIPS I can watch the load pointers from the main MIPS. All this in real time :). . I can modify the code of the 2nd MIPS as it is running from the 1st MIPS. I can modify the PicoBlaze program and the FastPIC programs in real time as well. It makes code development quick, painless and fun. Its all working pretty well :). Maybe this product idea will actually get all the way to hardware ? The main MIPS runs my debugger. It has access to one port of the dual port block rams. So from the main MIPS I can reset and restart the 2nd MIPS which has 64MB of DDR on it. I can actually watch it run real-time. Pretty neat. I can seperately reset and restart the DDR, so I am pretty sure that is all OK too. I can also reset and reload the other processors. The FastPIC is my own design (based on opencores stuff). It runs at 100mhz and I am planning to use it for a software based network interface, eliminating many chips from my final product :). Thanks again to you all the other fine OpenWRT folks. wiz On Sun, 23 Mar 2008, Florian Fainelli wrote: Hi Wiz Le dimanche 23 mars 2008, RHS Linux User a écrit : From what I can tell, however, the kernel and modules are not (from what I can tell) being compiled for MIPS1 but rather for MIPS32? This MAY be the reason I have yet to see any boot up serial output? I have yet to find the right place to modify in the build tree to get MIPS1 kernel and module compilation? Suggestions please If your kernel is correctly compiled for MIPS-1, you should be able to see it running on your FPGA. Are you sure the IP cores (UART, DDRAM ...) are working fine ? Most of the time problems come from here, but I am sure you did validate all the cores. From the OpenWrt perspective, if you did change the CFLAGS to match the MIPS-1 instruction set in toolchain/Config.in when selecting your architecture, those CFLAGS will be passed to the kernel and so will the modules be compiled with. I would GREATLY appreciate any other suggestions any of you might have as to how you did your port, etc. Maybe there is another version that is already known to run on R3000? This would, I suspect, make my port MUCH easier. There is currently no OpenWrt port on the MIPS R3K architecture. -- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
