Re: [OpenWrt-Devel] rebooting from a kernel on external storage
Hi, Brian J. Murrell wrote: > I wonder what the feasibility is of instead of putting a linux kernel in > the kernel portion of the flash image and essentially what's an initrd > in the filesystem portion (because remember, all the / in the flash > image does for me is mount USB storage on /), putting a simple boot > loader that can load the kernel from the USB storage based filesystem. > > It's worth recognizing and mentioning that perhaps this boot loader > could actually be a full linux kernel and a very small / that simply > "kexec"s a new kernel from the USB storage once it's mounted at /. I > wonder how portable kexec is amongst the processors Linux runs on. This is close to what we do for the PS3 game console (powerpc64). We use an initramfs so have a single (kernel + filesystem) image that is put into flash. We use petitboot for the UI. It can load kernels via nfs, http, tftp, usb mass storage, etc. It also understands how to use the info returned from the dhcp server to load a kernel. We have an ncurses petitboot UI also that can be used over telnet, but it is being re-worked currently and has not been committed to the OpenWrt repo yet. The whole of petitboot is being reworked and that rework will provide better support for other platforms. http://ozlabs.org/~jk/projects/petitboot/ http://git.infradead.org/ps3/petitboot-multiple-ui-patches.git -Geoff ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rebooting from a kernel on external storage
On Thu, Jan 22, 2009 at 06:46:10PM +0100, Steven Barth wrote: > Why emulate a 1 dimensional limited configuration system for all platforms, > with a maximum capacity of 32kiB just because ONLY some old broadcom based > routers use it? Right. NVRAM was usually a 32k block of consecutive name=value string pairs. - limitations on the size and character set of 'name' and 'value' - no ability to add comment or make the configuration user friendly and no ability to temporarily comment out an item - naming scheme for variables was nonstandard with each vendor using slight variations - certain variables were required at bootup before the firmware loaded, erasure of those variables or the inability of the loader to parse them rendered the device unbootable until nvram could be reprogrammed externally with a JTAG After running a few different firmwares you often had a multiple sets of variables, each conforming to whatever oem naming scheme that firmware used, making it difficult to tell which set of variables controlled the current configuration. The "reset to defaults" button found in many firmwares didn't attempt to clear out old variables, it simply reset the variables used by that firmware to default values. It was nearly impossible to clean out the unused variables for fear that the variable might be required by the boot loader of that particular device, rendering the device unbootable if that variable was removed or changed. Some devices included boot loaders that would repopulate NVRAM with a default set of variables if none were found, other devices had boot loaders which would attempt to repopulate NVRAM but would do so using variables/values that were incorrect for that type of device -- the result of the same boot loader code being used on multiple devices. We wanted to keep the unix style of human readable configuration files stored in /etc, but it was impractical to write a web interface when each utility used a slightly different config format -- you needed to be able to read in the entire configuration file, understand it, make one small change to the appropriate line in the file and then write out the new configuration file. UCI was created as a very user friendly confile file which could be easily parsed with a few lines of shell script. Of course, now that we'd chosen to remove NVRAM, and put the configuration data in the filesystem, how do you keep the filesystem across a firmware upgrade? Or, rephrased, why does the filesystem get nuked durring an upgrade? The problem really comes down to space -- 4M of flash isn't much space when you have to share it with bootloader, kernel, filesystem, nvram .. etc. The bootloader and NVRAM are pretty much fixed, but the firmware is allowed to do whatever it wants with the remaining space, so pack a kernel into the smallest possible size and then immediately after it, create a filesystem. Great. Now what happens if the next version of the kernel is a different size? Now you need to move that filesystem. Why can't we put the kernel in the filesystem so we'd never need to move the filesystem? Good idea, except how do you boot it? There needs to be some code at bootup that understands the filesystem and is able to extract the kernel, between the new bootup code and the overhead of the filesystem you've now used more space than just putting the kernel directly on flash where it could be booted by the exisitng bootloader. Similarly, we don't want to have free space between the kernel and filesystem to allow future kernel growth -- we don't exactly have a luxury of space on most devices. We came up with the idea of switching to a ramdisk and reflashing fairly early in the kamikaze development. The concept is pretty straight forward -- stop whatever you're doing that uses flash, copy the running system to a ramdisk, reflash, copy back -- the actual implementation isn't as simple, you can't just tell an application "stop using flash", it's often impossible to get it to free file descriptors without killing it, so it's only with in the last few release canidates that we've had sysupgrade functionality working. I could probably go on for several more chapters, but that's enough of an explaination for now. - Mike. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] xt_TARPIT patch needs update for 2.6.28.x kernel
https://dev.openwrt.org/ticket/4432 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] chaostables need update for 2.6.28.x
chaostables are obsolete for some time now as they have been merged into xtables-addons https://dev.openwrt.org/ticket/4431 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] yaffs 2.6.28.1 patch
http://bbs.archlinux.org/viewtopic.php?pid=484856 Signed-off-by: Alexandros C. Couloumbis --- linux-2.6.28.1/fs/yaffs2/yaffs_fs.c.orig2009-01-22 23:47:36.0 +0200 +++ linux-2.6.28.1/fs/yaffs2/yaffs_fs.c 2009-01-22 23:48:20.0 +0200 @@ -711,7 +711,7 @@ pgoff_t index = pos >> PAGE_CACHE_SHIFT; int ret = 0; - pg = __grab_cache_page(mapping, index); + pg = grab_cache_page_write_begin(mapping, index, flags); if (!pg) return -ENOMEM; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rebooting from a kernel on external storage
> I disagree because that would create an unwanted relationship between > ipkg and sysupgrade and also will result in having old configuration > files if new versions of packages also have updated > configuration files. Why would you not want such a relationship. [io]pkg's conffiles are meant to solve the exact same problem of upgrading packages without messing up the package's configuration. So if the conffile info you get from [io]pkg isn't right for sysupgrade it won't be right for [io]pkg either (and vice versa). As for handling conflicts between user changes and package changes to conffiles, this problem is also faced by [io]pkg, and I see no reason why sysupgrade can't use the same solution(s). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] linux-2.6.23 linux/time.h gcc-4.3 patch
http://acassis.wordpress.com/2008/07/01/erro-compilando-kernel-2622-no-opensuse11-gcc-431
Signed-off-by: Alexandros C. Couloumbis
--- linux-2.6.23.17/include/linux/time.h.orig 2009-01-22
23:18:04.0 +0200
+++ linux-2.6.23.17/include/linux/time.h2009-01-22
23:25:17.0 +0200
@@ -177,6 +177,9 @@
{
ns += a->tv_nsec;
while(unlikely(ns >= NSEC_PER_SEC)) {
+// The following asm () prevents the compiler from
+// optimising this loop into a modulo operation.
+ asm("" : "+r"(ns));
ns -= NSEC_PER_SEC;
a->tv_sec++;
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rebooting from a kernel on external storage
> > thats why UCI was invented > > I would have suggested some kind of "on disk" nvram emulation for such > non-nvram capable systems so that the nvram paradigm remains the same > for nvram capable systems and is emulated for others that have, say, > persistent disk. Why emulate a 1 dimensional limited configuration system for all platforms, with a maximum capacity of 32kiB just because ONLY some old broadcom based routers use it? In this one dimension you cannot clearly create relationships between configuration options, you technically only have 1 datatype and you mess configurations together. I've heard that some other firmware projects use nvram-emulation but this is definitely very ugly. You will end up having lots and lots of abandoned configuration strings in your nvram if you use it overtime, install and uninstall packages etc. Clearly nvram has only disadvantages compared to UCI. > > But given the advances made with sysupgrade, this might be getting moot. > I guess only time will tell if my fears of synchro problems between > config files and sysupgrade manifest themselves. That is a problem that OpenWrt will face in the future when it comes to changes in some package/subsystem UCI format but you would and already had faced similar problems with nvram. > > That said, I wonder if sysupgrade has a "user driven" inventory list -- > that is, a list of files to be included in the sysupgrade save set that > the user can define. It has. > > > It think this is a clean way > > Agreed, with the above idea. > I disagree because that would create an unwanted relationship between ipkg and sysupgrade and also will result in having old configuration files if new versions of packages also have updated configuration files. > > anyway - if a config file changes you have always some fiddling by > > manual configuration. The most important thing is IMHO, that all > > network related stuff starts as usual. Probably networking stuff just just be kept backwards-compatible and/or include a conversion mechanism if a change is needed. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rebooting from a kernel on external storage
On Thu, 2009-01-22 at 09:39 +0100, Bastian Bittorf wrote: > > only very few computersystems have NVRAM s/computersystems/[wireless] routers/ ? OpenWRT is targeted at [wireless] routers. > thats why UCI was invented I would have suggested some kind of "on disk" nvram emulation for such non-nvram capable systems so that the nvram paradigm remains the same for nvram capable systems and is emulated for others that have, say, persistent disk. But given the advances made with sysupgrade, this might be getting moot. I guess only time will tell if my fears of synchro problems between config files and sysupgrade manifest themselves. That said, I wonder if sysupgrade has a "user driven" inventory list -- that is, a list of files to be included in the sysupgrade save set that the user can define. > It think this is a clean way Agreed, with the above idea. > anyway - if a config file changes you have always some fiddling by > manual configuration. The most important thing is IMHO, that all > network related stuff starts as usual. Agreed on the networking stuff. :-) b. 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
[OpenWrt-Devel] update shorwall shell & common to 4.2.4
greets puchu Index: feeds/packages/net/shorewall-common/Makefile === --- feeds/packages/net/shorewall-common/Makefile(Revision 14144) +++ feeds/packages/net/shorewall-common/Makefile(Arbeitskopie) @@ -9,12 +9,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=shorewall-common -PKG_VERSION:=4.2.1 +PKG_VERSION:=4.2.4 PKG_RELEASE:=1 PKG_SOURCE_URL:=http://www.shorewall.net/pub/shorewall/4.2/shorewall-$(PKG_VERSION)/ PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 -PKG_MD5SUM:=cd90a367f687977a13403bd5249a6639 +PKG_MD5SUM:=888130a12280f7bf9022009153ac63cd include $(INCLUDE_DIR)/package.mk Index: feeds/packages/net/shorewall-shell/Makefile === --- feeds/packages/net/shorewall-shell/Makefile (Revision 14144) +++ feeds/packages/net/shorewall-shell/Makefile (Arbeitskopie) @@ -9,12 +9,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=shorewall-shell -PKG_VERSION:=4.2.1 +PKG_VERSION:=4.2.4 PKG_RELEASE:=1 PKG_SOURCE_URL:=http://www1.shorewall.net/pub/shorewall/4.2/shorewall-$(PKG_VERSION)/ PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 -PKG_MD5SUM:=7790bb23c7df834549f4f4ec195f37ee +PKG_MD5SUM:=95a645963e541aef5a39c707f67874b5 include $(INCLUDE_DIR)/package.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] htpdate-1.0.4 uClibc-0.9.30 patch
http://www.mail-archive.com/ucl...@uclibc.org/msg02985.html
Signed-off-by: Alexandros C. Couloumbis
--- htpdate-1.0.4/htpdate.c.orig2009-01-22 11:20:54.0 +0200
+++ htpdate-1.0.4/htpdate.c 2009-01-22 11:18:55.0 +0200
@@ -359,7 +359,7 @@
/* Read current kernel frequency */
tmx.modes = 0;
- ntp_adjtime(&tmx);
+ __adjtimex(&tmx);
/* Calculate new frequency */
freq = (long)(65536e6 * drift);
@@ -377,7 +377,7 @@
printlog( 1, "seteuid()" );
exit(1);
} else {
- return( ntp_adjtime(&tmx) );
+ return( __adjtimex(&tmx) );
}
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rebooting from a kernel on external storage
* Brian J. Murrell [21.01.2009 16:15]: > On Wed, 2009-01-21 at 15:41 +0100, Bastian Bittorf wrote: > > > > KISS! > > Heh. KISS would have been leaving the config in the NVRAM as it was > intended. :-) only very few computersystems have NVRAM - thats why UCI was invented > Maybe the list of configuration files can be queried from the package > inventory database. That would depend on developers correctly flagging > configuration files. What happens when the format of a configuration It think this is a clean way > file changes from one release to another? You can't just roll a tarball > down and overwrite newer formatted files with older formatted ones. > This just feels like a fragile solution. anyway - if a config file changes you have always some fiddling by manual configuration. The most important thing is IMHO, that all network related stuff starts as usual. bye, Bastian signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
