Re: [OpenWrt-Devel] svn write access
- Original Message From: Puchu rauchwo...@gmx.net if not ... what would i have to do to get it? transmit more patches on the mailing list? a pack of beer to every svn writer? :=) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt development process
Speaking of distributions, T2 is also worth looking at: http://www.t2-project.org/ I was going to spend some time in learning it deeper, but the Christmas holidays appeared to be too short :) - Original Message From: Jose Vasconcellos jva...@verizon.net I think this topic merits additional discussion. I'm not very familiar with OpenEmbedded but I'm starting to look into it. As I see it, OpenEmbedded is trying to create a platform for the creating of embedded distributions. OpenWrt is dealing with creating a distribution geared towards the specifics of routers (networking issues and HW specifics related to that). However, the approach of OpenEmbedded looks very good, at least, from their documentation. Has anyone compared the two build systems approaches? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] repeated kernel config questions
The makefiles override the kernel config each time you do make menuconfig. It's not a bug, it's so by design :) - Original Message From: Brian J. Murrell [EMAIL PROTECTED] To: OpenWrt Development List openwrt-devel@lists.openwrt.org Sent: Monday, November 10, 2008 2:53:35 PM Subject: Re: [OpenWrt-Devel] repeated kernel config questions On Mon, 2008-11-10 at 08:44 -0500, Robert P. J. Day wrote: typically, you will be perpetually asked about NEW kernel options if the default config file has no mention of them. Which default config file is this and why are my answers not being remembered from one make world to another as they are for every other umpteen options? for every valid kernel option, the default config file should either select that option, or have a line commented out saying that that option is not set. one or the other. Right. But why are my many iterations not remembering these options? This is where I believe the disconnect is. b. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] repeated kernel config questions
this is what I remember from the time I tried to adapt this to my needs. Remembering the values would not be too much of a critical thing, if the kernel parameters would be settable from the user files. There's a place for that in ./files, but this behavior is not implemented. - Original Message From: Robert P. J. Day [EMAIL PROTECTED] To: openwrt-devel@lists.openwrt.org Sent: Monday, November 10, 2008 3:36:44 PM Subject: Re: [OpenWrt-Devel] repeated kernel config questions Quoting Stanislav Sinyagin : The makefiles override the kernel config each time you do make menuconfig. It's not a bug, it's so by design :) really? i don't have the build structure in front of me, but the standard kernel config recipe is that, if you have no .config file, the build will grab the default (and, hence, you might have to answer questions about NEW options.) however, as long as you have an existing .config, the build process will use it. are you saying that any existing .config file will *always* be ignored in favour of the default? that would be unusual, and definitely non-standard behaviour. rday ___ 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] repeated kernel config questions
actually in my patch http://lists.openwrt.org/pipermail/openwrt-devel/2008-October/003249.html I offered a way to modify kernel config from a board profile-specific file. Same thing can be easily done for user files in ./files - Original Message From: Stanislav Sinyagin [EMAIL PROTECTED] To: OpenWrt Development List openwrt-devel@lists.openwrt.org Sent: Monday, November 10, 2008 3:44:55 PM Subject: Re: [OpenWrt-Devel] repeated kernel config questions this is what I remember from the time I tried to adapt this to my needs. Remembering the values would not be too much of a critical thing, if the kernel parameters would be settable from the user files. There's a place for that in ./files, but this behavior is not implemented. - Original Message From: Robert P. J. Day To: openwrt-devel@lists.openwrt.org Sent: Monday, November 10, 2008 3:36:44 PM Subject: Re: [OpenWrt-Devel] repeated kernel config questions Quoting Stanislav Sinyagin : The makefiles override the kernel config each time you do make menuconfig. It's not a bug, it's so by design :) really? i don't have the build structure in front of me, but the standard kernel config recipe is that, if you have no .config file, the build will grab the default (and, hence, you might have to answer questions about NEW options.) however, as long as you have an existing .config, the build process will use it. are you saying that any existing .config file will *always* be ignored in favour of the default? that would be unusual, and definitely non-standard behaviour. rday ___ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: ENC: Port solution to Our board Request
I wonder how inventive people are in trying to contact other people without leaving any contact information. Although there are phone numbers :) I've got a Brazilian colleague who speaks pretty well Portuguese, Spanish and English, and he's also quite flexible in Linux administration. Let me know if you need him as a communication channel :-) - Original Message From: Daniel Gimpelevich [EMAIL PROTECTED] [Sun 26 Oct 2008 08:55:44 PM PDT] we want that OpenWrt get ported to our Yanomami IXP435 Board, we want to partnership / sponsor it [Mon 27 Oct 2008 08:38:50 PM PDT] * TesHuneoejod has quit () ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Edimax BR6104KP profile with rootfs on a USB drive
Guys, what's the expectancy of this patch to be committed? If there is anything more I could do, please let me know. - Original Message From: Stanislav Sinyagin [EMAIL PROTECTED] To: openwrt-devel@lists.openwrt.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 21, 2008 11:55:27 PM Subject: [OpenWrt-Devel] [PATCH] Edimax BR6104KP profile with rootfs on a USB drive The Edimax BR6104KP router (also available as Omnima Embedded Controller from http://www.omnima.co.uk/ with JTAG and serial already soldered in) has only 2MB onboard flash, which is too small for any usable Linux setup. The board has also two USB1.1 interfaces, and this patch introduces a new profile that builds two images: the flash image containing the LZMA loader and the kernel (less than 900KB), and a tar.gz archive of the root filesystem. The kernel looks to mount the rootfs as ext3 or ext2 on /dev/sda1. The patches for include/image.mk and include/kernel-defaults.mk extend the existing functionality and should not hurt any existing profile. To use the new profile, choose in menuconfig: Target System: Infineon/ADMtek ADM5120 [2.6] Target Profile: Edimax BR-6104KP (USB Root FS) The patch was tested, and by default it supports the onboard switch and the USB storage. Other kernel modules should function as well. The next step will be to utilize the unused space in the onboard flash to store the persistent configuration, so that updating the rootfs would not hurt it. A copy of the patch is available at http://torrus.org/openwrt.trunk.13018.br6104kp-usbroot.20081021.patch It should work against the SVN trunk at revision 13018 Signed-off-by: Stanislav Sinyagin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Edimax BR6104KP profile with rootfs on a USB drive
Biff, I see your point, and I was thinking about this before I started to patch the makefiles. Of course, one would prefer the rootfs location as a configurable option for any target, but that involves too many changes: -- Kernel's CMDLINE is now hardcoded in the target-specific files -- Building the flash image is too platform-specific. For Edimax routers, you need to add the header, for other platforms you might not need it, or do something else. Also The Edimax makefiles always assume there's always a JFFS or Squashfs partition, while in my case there should be none. so, with these considerations, a separate profile for a Edimax-like router with USB rootfs is the thing that could be done with little blood (still, I require few updates in the core makefiles). It actually should run with BR-6204Wg: you just add the modules required for the wireless interface. regards, stan - Original Message From: bifferos [EMAIL PROTECTED] To: OpenWrt Development List openwrt-devel@lists.openwrt.org Sent: Wednesday, October 29, 2008 2:21:04 PM Subject: Re: [OpenWrt-Devel] [PATCH] Edimax BR6104KP profile with rootfs on a USB drive Stanislav, I don't wish to belittle your efforts, and I think this will be genuinely useful to quite a few people, however it's worth noting that BR6104KP is not the only target that could benefit from USB-root, therefore, one can see a series of profiles springing up alongside every single target capable of USB (why not 4MB devices as well?). Even in the Edimax range you have BR-6204Wg (2mb flash, USB). If I were a developer (and I'm not, I hasten to add), I would consider this a maintenance nightmare. Don't forget that USB-root is not the only possibility. You could also have MMC-root or NFS root on pretty much any router in existence. It would be far better if there were some configuration option which switched this, although I'm not sure exactly how that can be achieved. This might be why nobody has committed the patch. rgds, biff. --- On Wed, 29/10/08, Stanislav Sinyagin wrote: From: Stanislav Sinyagin Subject: Re: [OpenWrt-Devel] [PATCH] Edimax BR6104KP profile with rootfs on a USB drive To: OpenWrt Development List Date: Wednesday, 29 October, 2008, 12:33 PM Guys, what's the expectancy of this patch to be committed? If there is anything more I could do, please let me know. - Original Message From: Stanislav Sinyagin To: openwrt-devel@lists.openwrt.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 21, 2008 11:55:27 PM Subject: [OpenWrt-Devel] [PATCH] Edimax BR6104KP profile with rootfs on a USB drive The Edimax BR6104KP router (also available as Omnima Embedded Controller from http://www.omnima.co.uk/ with JTAG and serial already soldered in) has only 2MB onboard flash, which is too small for any usable Linux setup. The board has also two USB1.1 interfaces, and this patch introduces a new profile that builds two images: the flash image containing the LZMA loader and the kernel (less than 900KB), and a tar.gz archive of the root filesystem. The kernel looks to mount the rootfs as ext3 or ext2 on /dev/sda1. The patches for include/image.mk and include/kernel-defaults.mk extend the existing functionality and should not hurt any existing profile. To use the new profile, choose in menuconfig: Target System: Infineon/ADMtek ADM5120 [2.6] Target Profile: Edimax BR-6104KP (USB Root FS) The patch was tested, and by default it supports the onboard switch and the USB storage. Other kernel modules should function as well. The next step will be to utilize the unused space in the onboard flash to store the persistent configuration, so that updating the rootfs would not hurt it. A copy of the patch is available at http://torrus.org/openwrt.trunk.13018.br6104kp-usbroot.20081021.patch It should work against the SVN trunk at revision 13018 Signed-off-by: Stanislav Sinyagin ___ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Edimax BR6104KP profile with rootfs on a USB drive
The Edimax BR6104KP router (also available as Omnima Embedded Controller from http://www.omnima.co.uk/ with JTAG and serial already soldered in) has only 2MB onboard flash, which is too small for any usable Linux setup. The board has also two USB1.1 interfaces, and this patch introduces a new profile that builds two images: the flash image containing the LZMA loader and the kernel (less than 900KB), and a tar.gz archive of the root filesystem. The kernel looks to mount the rootfs as ext3 or ext2 on /dev/sda1. The patches for include/image.mk and include/kernel-defaults.mk extend the existing functionality and should not hurt any existing profile. To use the new profile, choose in menuconfig: Target System: Infineon/ADMtek ADM5120 [2.6] Target Profile: Edimax BR-6104KP (USB Root FS) The patch was tested, and by default it supports the onboard switch and the USB storage. Other kernel modules should function as well. The next step will be to utilize the unused space in the onboard flash to store the persistent configuration, so that updating the rootfs would not hurt it. A copy of the patch is available at http://torrus.org/openwrt.trunk.13018.br6104kp-usbroot.20081021.patch It should work against the SVN trunk at revision 13018 Signed-off-by: Stanislav Sinyagin [EMAIL PROTECTED] Index: include/image.mk === --- include/image.mk(revision 13021) +++ include/image.mk(working copy) @@ -63,12 +63,14 @@ ifeq ($(CONFIG_TARGET_ROOTFS_TGZ),y) define Image/mkfs/tgz $(TAR) -zcf $(BIN_DIR)/openwrt-$(BOARD)-rootfs.tgz --owner=root --group=root -C $(TARGET_DIR)/ . + $(call Image/Build,tgz) endef endif ifeq ($(CONFIG_TARGET_ROOTFS_CPIOGZ),y) define Image/mkfs/cpiogz ( cd $(TARGET_DIR); find . | cpio -o -H newc | gzip -9 $(BIN_DIR)/openwrt-$(BOARD)-rootfs.cpio.gz ) + $(call Image/Build,cpio) endef endif else Index: include/kernel-defaults.mk === --- include/kernel-defaults.mk (revision 13021) +++ include/kernel-defaults.mk (working copy) @@ -91,6 +91,10 @@ $(LINUX_CONFCMD) $(LINUX_DIR)/.config.target $(SCRIPT_DIR)/metadata.pl kconfig $(TMP_DIR)/.packageinfo $(TOPDIR)/.config $(LINUX_DIR)/.config.override $(SCRIPT_DIR)/kconfig.pl 'm+' $(LINUX_DIR)/.config.target $(LINUX_DIR)/.config.override $(LINUX_DIR)/.config + if [ -f $(PLATFORM_DIR)/config/profile-$(PROFILE) ]; then \ + mv $(LINUX_DIR)/.config $(LINUX_DIR)/.config.pkginfo; \ + $(SCRIPT_DIR)/kconfig.pl '+' $(LINUX_DIR)/.config.pkginfo $(PLATFORM_DIR)/config/profile-$(PROFILE) $(LINUX_DIR)/.config; \ + fi $(call Kernel/SetInitramfs) $(call Kernel/Configure/$(KERNEL)) rm -rf $(KERNEL_BUILD_DIR)/modules Index: target/linux/adm5120/router_le/profiles/Edimax.mk === --- target/linux/adm5120/router_le/profiles/Edimax.mk (revision 13021) +++ target/linux/adm5120/router_le/profiles/Edimax.mk (working copy) @@ -22,6 +22,30 @@ Package set optimized for the Edimax BR-6104KP endef +define Profile/BR6104KP_USBROOTFS + NAME:=Edimax BR-6104KP (USB Root FS) + PACKAGES:=kmod-usb-core kmod-usb-adm5120 +endef + +define Profile/BR6104KP_USBROOTFS/Config + deselect squashfs + deselect USES_SQUASHFS + deselect jffs2 + deselect USES_JFFS2 + select PACKAGE_kmod-usb-core + select PACKAGE_kmod-usb-adm5120 + select PACKAGE_kmod-usb-storage + select PACKAGE_kmod-fs-ext2 + select PACKAGE_kmod-fs-ext3 + select DEFAULT_kmod-ledtrig-adm5120-switch +endef + +define Profile/BR6104KP_USBROOTFS/Description + Package set for the Edimax BR-6104KP with rootfs on USB drive. + The resut consists of a packed kernel image and the root filesystem + in a tar.gz archive. +endef + define Profile/BR6104WG NAME:=Edimax BR-6104Wg (Unofficial, No WiFi) endef @@ -40,5 +64,6 @@ $(eval $(call Profile,BR6104K)) $(eval $(call Profile,BR6104KP)) +$(eval $(call Profile,BR6104KP_USBROOTFS)) $(eval $(call Profile,BR6104WG)) $(eval $(call Profile,BR6114WG)) Index: target/linux/adm5120/router_le/base-files-BR6104KP_USBROOTFS/etc/config/fstab === --- target/linux/adm5120/router_le/base-files-BR6104KP_USBROOTFS/etc/config/fstab (revision 0) +++ target/linux/adm5120/router_le/base-files-BR6104KP_USBROOTFS/etc/config/fstab (revision 0) @@ -0,0 +1,10 @@ +config mount + option target /home + option device /dev/sda1 + option fstype ext3 + option options rw,sync + option enabled 0 + +config swap + option device /dev/sda2 + option enabled 0 Index: target/linux/adm5120/image/router_le.mk
Re: [OpenWrt-Devel] setting kernel config parameters from ./files/
- Original Message From: bifferos [EMAIL PROTECTED] I should just point out that you can already have USB root in a way consistent with OpenWrt mainline and that is described here: http://wiki.openwrt.org/UsbStorageHowto if possibly a little out of date, you should get the idea. that one is too outdated. I've actually almost suceeded to build an image that contains the lzma-loader and kernel only. Still it's an open issue how to change the kernel's CMDLINE in a nice way. In one way it makes maintenance easier if only the kernel goes in the on-board flash, and everything else on the USB stick, but with OpenWrt the kernel changes so fast that I'm not sure how wise this really is (kernel modules have to be compatible, after all). What I'd really like to see (and I don't believe this would be too difficult) is a second-stage bootloader that actually pulls the kernel off the USB stick. For the Edimax BR-6104KP I have at least *some* of the code needed to do this - just haven't managed to finish it yet. Kexec is already in the Openwrt trunk, I'll give it a try as a next mini-project. Then it would be a stable and minimalistic kernel on the flash, which would immediately kexec a newest kernel from USB. Of course, one could try to create a new loader that would only have support for USB storage and ext3/ext2 filesystem. But that's a lot of work... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BUG: RouterBoard image broken in trunk/target/linux/adm5120/image/router_le.mk line 353
sorry, my mistake. I used a - symbol for my new profile name, and that has lead to wrong execution of makefiles. - Original Message From: Stanislav Sinyagin [EMAIL PROTECTED] To: openwrt-devel@lists.openwrt.org Sent: Sunday, October 19, 2008 9:59:13 PM Subject: [OpenWrt-Devel] BUG: RouterBoard image broken in trunk/target/linux/adm5120/image/router_le.mk line 353 trunk/target/linux/adm5120/image/router_le.mk line 353: ifeq ($(PROFILE),RouterBoard) At this moment $(PROFILE) is not yet defined, so this piece of makefle is never executed. regards, stan ___ 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
[OpenWrt-Devel] USB rootfs (Was: setting kernel config parameters from ./files/)
biff et al, In the meanwhile I gave it a second thought, and now I'm trying to produce a patch for a new target: define Profile/BR6104KP-USBROOTFS NAME:=Edimax BR-6104KP (Unofficial, USB Root FS) PACKAGES:=kmod-usb-core kmod-usb-adm5120 endef I looked a bit inside your Squidge source, and it appears that it stores a piece of basic squashfs root filesystem in the board flash, together with LZMA loader and the kernel. What I'm trying to achieve is a new target that would pack only the lzma-loader and the kernel into the flash image, and boot the kernel with root=/dev/sda1 It should be a system that compiles out of the box, and does not break after a subsequent make menuconfig. I don't see any difficulties with kernel changes, and will try to do it as version-independent as possible. Hopefully the patch will be accepted, but otherwise it's a good learning curve for me anyway. cheers, stan - Original Message From: bifferos [EMAIL PROTECTED] I should just point out that you can already have USB root in a way consistent with OpenWrt mainline and that is described here: http://wiki.openwrt.org/UsbStorageHowto if possibly a little out of date, you should get the idea. In one way it makes maintenance easier if only the kernel goes in the on-board flash, and everything else on the USB stick, but with OpenWrt the kernel changes so fast that I'm not sure how wise this really is (kernel modules have to be compatible, after all). What I'd really like to see (and I don't believe this would be too difficult) is a second-stage bootloader that actually pulls the kernel off the USB stick. For the Edimax BR-6104KP I have at least *some* of the code needed to do this - just haven't managed to finish it yet. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Leftover in include/target.mk
In the current SVN, in include/target.mk, Line 70: if [ -f ./config/profile-$(1) ]; then \ echo Target-Profile-Kconfig: yes; \ fi; \ It's obviously made for profile-dependent kernel options, but I can't find it implemented anywhere in kernel configuration makefiles. There's only one profile that tries to use this feature: target/linux/rdc/config/profile-dir450 but this feature was either never implemented or removed. I'd actually like to use it in my USB-rootfs profile. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] setting kernel config parameters from ./files/
Is there any reference document explaining the structure of ./files/ directory? For example, include/kernel.mk uses it to copy some custom modules into the target's lib/modules/$(LINUX_VERSION)/ What I'd like to have is a consistent, file-based way to influence the kernel config options, so that they are not overridden by the next make menuconfig. In the short term, I want to build a kernel which would have CONFIG_CMDLINE pointing the root to the USB stick -- basically it's what bifferos is doing in his squidge distribution. But I want to make it possible in a way that is consistent with the OpenWRT mainline. Another approach would be to add a menu option for CONFIG_CMDLINE into the OpenWRT's menuconfig script. It's not a problem for me to produce a patch for the makefiles, but I'd like to hear your opinions first. thanks, stan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] setting kernel config parameters from ./files/
I meant, having an option to add anything by just creating ./files/linux-2.6/.config looks a much more flexible approach than just adding another option to the Config.in. Ideally the makefiles would search for the custom kernel config in ./files/linux/.config ./files/linux-2.6/.config ./files/linux-2.6.26/.config sequentially - Original Message From: Stanislav Sinyagin [EMAIL PROTECTED] To: openwrt-devel@lists.openwrt.org Sent: Saturday, October 18, 2008 2:09:11 AM Subject: [OpenWrt-Devel] setting kernel config parameters from ./files/ Is there any reference document explaining the structure of ./files/ directory? For example, include/kernel.mk uses it to copy some custom modules into the target's lib/modules/$(LINUX_VERSION)/ What I'd like to have is a consistent, file-based way to influence the kernel config options, so that they are not overridden by the next make menuconfig. In the short term, I want to build a kernel which would have CONFIG_CMDLINE pointing the root to the USB stick -- basically it's what bifferos is doing in his squidge distribution. But I want to make it possible in a way that is consistent with the OpenWRT mainline. Another approach would be to add a menu option for CONFIG_CMDLINE into the OpenWRT's menuconfig script. It's not a problem for me to produce a patch for the makefiles, but I'd like to hear your opinions first. thanks, stan ___ 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
