**** BEGIN LOGGING AT Mon Oct 06 11:05:36 2008 Oct 06 12:05:52 nbd * r12865 /trunk/package/mac80211/ (14 files in 3 dirs): add the new compat-wireless for 2.6.27 + multi-rate retry and minstrel patches, rename patches/ for old compat-wireless to patches-old/ Oct 06 12:22:34 nbd: \o/ Oct 06 12:23:10 now somebody needs to test minstrel with non-atheros cards ;) Oct 06 12:31:34 matteo * r12866 /packages/ipv6/aiccu/ (Makefile files/aiccu.conf): aiccu: fix config file path **** BEGIN LOGGING AT Mon Oct 06 12:54:21 2008 Oct 06 14:04:48 Anyone familiar with mtd partitions? I'm unable to open the "FIS directory" in R/W mode. Oct 06 14:10:51 MateIn4: why would you wanna open it from userland ? Oct 06 14:11:18 check the kernel sources... would not suprise me if the reboot.c flags te partition as ro Oct 06 14:11:32 I've modified the mtd program to update the FIS entry for a partition to set the crc correctly for redboot. Oct 06 14:11:41 ok Oct 06 14:12:04 I'm looking at the kernel sources now. I've compiled without the read-only flag. Oct 06 14:13:30 hmm Oct 06 14:13:33 dunno then Oct 06 14:13:51 OK, I'll dig deeper. thanks Oct 06 14:21:12 OK, I found the problem: the kernel always treats redboot partitions as read-only (RedBoot, RedBoot config, FIS directory). This is probably done to avoid bricking the unit. But how does one update those partitions? Oct 06 14:23:08 This exercise started because I want to upgrade the kernel from usermode. The alternative is to disable crc checking on redboot. But I think this is a good feature. Oct 06 14:29:43 you should not disable crc :) Oct 06 15:23:29 MateIn4: Have you tried using the fis.c linux program ? Oct 06 16:26:06 is there a way to transfer binary files using only telnetd? Oct 06 16:27:44 h3sp4wn: I'm not familiar with the fis program. I'm not sure how this get's around the RO partition issue. Oct 06 16:29:42 MateIn4: Its a version of the redboot fis command that runs under linux I have compiled it and that is about it Oct 06 16:30:06 (like fconfig is the same idea and already in openwrt) Oct 06 16:31:17 h3sp4wn: I'll look into it. Where did you find it? http://svn.chezphil.org/utils/trunk/fis.c here? Oct 06 16:31:56 Yes Oct 06 16:33:17 h3sp4wn: I don't see how this get's around the issue that the kernel marks the 'FIS directory' as read-only. Oct 06 16:34:47 Wait a minute the fis directory ? You can change anything in that with fconfig Oct 06 16:34:54 nbd * r12869 /trunk/package/busybox/patches/310-passwd_access.patch: fix busybox http auth if the root user has an empty password Oct 06 16:35:28 nbd * r12870 /trunk/include/target.mk: enable luci by default Oct 06 16:35:49 \o/ ... yay :) Oct 06 16:35:54 nbd: webif by default??????? Oct 06 16:36:05 nbd * r12871 /trunk/scripts/metadata.pl: don't print warnings for undefined DEFAULT_* symbols on menuconfig. generate those in config-target.in instead of config-package.in Oct 06 16:37:22 h3sp4wn: no, fconfig only works on the 'RedBoot config' partition and it's read-only if it's on an mtd partition. Oct 06 16:37:32 sn9: not webif, luci Oct 06 16:37:34 ;) Oct 06 16:42:03 nice Oct 06 16:42:19 luci is still a webif Oct 06 16:43:14 more a framework Oct 06 16:44:38 xMff: Der Stylesheet kommt kommt jetzt ohne CSS 3 aus und validiert so gegen CSS 2.1 und 2. :) Kuemmer mich jetzt noch um die Warnungen... Oct 06 16:44:54 nbd: btw, AndyI dcc'ed me a 2008-09-25 snapshot of your swconfig, which i intend to try soon Oct 06 16:46:25 is there any way to transfer binary files using only telnetd? Oct 06 16:47:53 i don't think so. but you can use netcat Oct 06 16:48:02 no, i can't Oct 06 16:48:47 i have a device with an unknown bootloader, and i want to dump its flash using the original firmware for bootloader analysis Oct 06 16:49:10 nbd * r12872 /packages/ipv6/aiccu/Makefile: fix aiccu compile Oct 06 16:52:06 nbd * r12873 /branches/8.09/ (3 files in 3 dirs): merge r12869-12871 to 8.09 Oct 06 16:52:54 x-alina: okay Oct 06 16:57:05 [florian]: have you dealt with any non-redboot rdc devices yet? Oct 06 17:06:16 nbd * r12874 /packages/utils/hd-idle/Makefile: packages must not be moving targets that reference HEAD of a foreign svn. move hd-idle over to a generated tarball Oct 06 17:17:00 I found the problem regarding read-only 'FIS directory' partition. Redboot puts the 'RedBoot config' in the same sector so it treats both as read-only. Oct 06 17:17:51 How do people update the kernel image from user mode when using Redboot? Oct 06 17:18:43 by not touching redboot Oct 06 17:19:37 sn9: I don't follow. Do you expect users to go into redboot to upgrade? Oct 06 17:19:42 no Oct 06 17:20:03 ok, then how to upgrade? Oct 06 17:20:10 users are expected not to touch redboot Oct 06 17:20:26 understood, but how to upgrade? Oct 06 17:20:33 just flash "linux" Oct 06 17:21:02 that doesn't work if redboot has been compiled with the crc check option which I think is a good idea. Oct 06 17:21:22 it checks the crc of the kernel? Oct 06 17:22:18 yes, it checks the crc of the partition generated when it was created Oct 06 17:22:58 when what was created? Oct 06 17:23:06 right now running the "mtd write zImage linux" correctly writes the image to the 'linux' partition but the 'FIS directory' is not updated with the proper crc. Oct 06 17:23:31 the crc is stored in redboot? Oct 06 17:23:56 the crc is stored in the 'FIS directory' entry for the partition. Oct 06 17:24:16 that's in redboot, right? Oct 06 17:26:00 redboot creates 3 partitions: 'RedBoot' is the first one and contains the bootloader itself; 'FIS directory' has a list of all partitions along with other data such as the actual length, location, etc, and crc; 'RedBoot config' is the last one and contains redboot variables. Oct 06 17:26:12 juhosg * r12875 /trunk/target/linux/generic-2.6/patches-2.6.27/213-mini_fo_2.6.27_fixes.patch: [kernel] update mini_fo fix for 2.6.27 Oct 06 17:26:37 the problem comes in cases where the 'FIS directory' and 'RedBoot config' are put in the same sector. Oct 06 17:27:26 the crc is automatically generated when you flash? Oct 06 17:28:09 from redboot, a 'fis create' command will create the partition and update the data including crc in the 'FIS directory' Oct 06 17:28:41 are you required to do that to flash? Oct 06 17:29:05 yes, otherwise the redboot command 'fis load' will fail with incorrect crc. Oct 06 17:29:19 you can build redboot without crc checking. Oct 06 17:29:45 the other possibility is to put the 'RedBoot config' on a separate sector. Oct 06 17:29:49 wait, you have to create the partition _after_ flashing it, not before? Oct 06 17:30:11 In that case, the 'FIS directory' can be R/W. Oct 06 17:30:43 sn9: I don't follow. are you familiar with redboot? Oct 06 17:30:51 yes, but not fis Oct 06 17:31:27 i don't follow what you are saying Oct 06 17:31:40 maybe you disabled crc checking in your redboot build. Oct 06 17:31:47 no Oct 06 17:31:59 what are you required to do to flash? Oct 06 17:32:04 then you can't use the mtd command to update the kernel. Oct 06 17:32:26 i can, as long as the crc is there Oct 06 17:32:45 but you're describing something different Oct 06 17:32:58 what are you required to do to flash? Oct 06 17:33:04 it doesn't work for me or other users as mentioned in the forums. Oct 06 17:33:08 what are you required to do to flash? Oct 06 17:34:13 I'm trying to update the kernel image that is in the 'linux' partition. the mtd command can do this just fine but the 'FIS directory' is not udpated so when redboot starts and executes the 'fis load linux' command it fails because there's no valid image. Oct 06 17:35:18 I've modified the mtd command to update the 'FIS directory' taking into consideration the 'RedBoot config' but the kernel doesn't allow me to change it. Oct 06 17:36:09 how did the kernel image get into the 'linux' partition? Oct 06 17:36:31 Justs to be clear, I'm using a ixp425 target with redboot that has crc checking turned on and the 'FIS directory' and 'RedBoot config' on the same sector. Oct 06 17:37:02 The first time, it's done using redboot. Oct 06 17:37:15 in what sequence? Oct 06 17:37:29 <[Fate]> how difficult is it actually to change a device's bootloader? eg. to build reboot? Oct 06 17:37:40 <[Fate]> no chance without jtag? Oct 06 17:37:44 <[Fate]> or precisely: Oct 06 17:37:50 <[Fate]> not a good idea at all without jtag? Oct 06 17:38:03 [Fate]: it's dead simple to do, and dead simple to screw it up Oct 06 17:38:23 sn9: 'load -r -b %{FREEMEMLO} linux ; fis create linux' Oct 06 17:38:51 <[Fate]> there's this one nearly-ideal AP I'd like to see openwrt run on Oct 06 17:38:59 <[Fate]> but of course it comes with vxworks :/ Oct 06 17:39:00 MateIn4: IOW, you tftp to ram, calc the crc, then flash? Oct 06 17:39:01 Fate: I upgrade redboot all the time from redboot itself. Oct 06 17:39:31 <[Fate]> atheros, 2 antennas, poe... Oct 06 17:39:43 sn9: the load command does a tftp; the fis create writes to flash and computes crcs. Oct 06 17:39:52 ok Oct 06 17:40:09 is there any way to bypass "fis create" ? Oct 06 17:40:43 yes, but that is getting off-topic Oct 06 17:40:52 no, it's not Oct 06 17:41:21 maybe the easiest solution is to force two separate sectors for the 'FIS directory' and 'RedBoot config' Oct 06 17:41:22 there may be escape code that allows exactly what you're after Oct 06 17:41:53 then my patch should work. Oct 06 17:41:55 the crc checker may treat a zero crc specially Oct 06 17:42:17 one would need to read your redboot source to know for sure Oct 06 17:42:20 the point is that I want the crc protection; think this is a good feature Oct 06 17:42:55 you cannot afford to store a crc in a possibly read-only partition Oct 06 17:43:25 without fis, the redboot crc is in the linux partition Oct 06 17:43:32 this is what redboot does. Like I said maybe the best solution is to use different sectors. Oct 06 17:44:10 does your flash chip by any chance use 128K blocks? Oct 06 17:44:26 we're talking about different crc's I think. I'm using Redboot commands (fis load and exec) to boot Oct 06 17:44:33 yes Oct 06 17:44:44 a crc is a crc is a crc is a crc Oct 06 17:44:58 I don't follow you Oct 06 17:45:46 i'm guessing your redboot was compiled for 64K blocks Oct 06 17:46:11 you're guessing wrong. If you look at the forums I'm not the only one with this problem. Oct 06 17:46:53 just because the redboot came that way doesn't automatically mean that's not the case Oct 06 17:47:54 I think you are suggesting not using FIS partitions. I'm not quite clear Oct 06 17:48:08 i'm not suggesting that Oct 06 17:48:28 do fis partitions require 64K blocks? of course not Oct 06 17:48:29 The point is how does openwrt work with standard redboot? Oct 06 17:48:40 agreed Oct 06 17:49:25 *if* the standard redboot cannot account for 128K blocks, *then* the standard redboot cannot be used Oct 06 17:50:04 redboot is working find with 128K blocks. Oct 06 17:50:16 in contrast, the pspboot loader determines where its config partition is as a function of the block size Oct 06 17:50:17 s/find/fine/ Oct 06 17:50:44 what you need is for redboot to do the same Oct 06 17:51:10 we're talking about redboot. I don't think highly of redboot but it has one great feataure: allows telnet access so users don't have to hack HW to add serial port. Oct 06 17:51:38 that's an optional feature, btw Oct 06 17:52:05 yes, I've enabled it on my HW Oct 06 17:53:15 if redboot knows how to deal with 128K blocks correctly, then there must be some kind of trigger for it to locate the fis directory elsewhere automagically Oct 06 17:53:43 just like in pspboot Oct 06 17:54:39 even if I redbuild redboot to put the 'FIS directory' and 'RedBoot config' on separate sectors, the current mtd command will not work as it doesn't update the 'FIS directory'. I've made a patch to fix that. Oct 06 17:54:58 one obstacle at a time Oct 06 17:55:15 My point is that openwrt should have a set of guidelines on how to build redboot to work with openwrt utilities. Oct 06 17:55:37 my point is that if redboot is written right, it should not need any rebuild Oct 06 17:56:34 redboot is a dinosaur that I have little control over. Oct 06 17:56:43 have you looked at your redboot source to determine whether it hardcodes the location of the fis directory itself? Oct 06 17:56:53 the point is not to need control Oct 06 17:57:03 yes, I can change that Oct 06 17:57:20 that doesn't answer the question Oct 06 17:57:37 is it hardcoded? Oct 06 17:57:51 yes, it's configurable Oct 06 17:57:57 at compile time Oct 06 17:58:00 again, that doesn't answer the question Oct 06 17:58:13 is it compile-time only? Oct 06 17:58:48 Redboot is build using something called ecosconfig where one can set many parameters and then builds the image Oct 06 17:59:11 then, you have not looked at the source... Oct 06 17:59:34 for all you know, the parameters may be irrelevant Oct 06 17:59:40 Of course I've looked at the source. I've even ported redboot to my HW Oct 06 18:00:16 Ok, I don't think we're going anywhere. Oct 06 18:00:49 _in the source,_ does it determine the fis directory location _solely_ from the ecosconfig parameter? Oct 06 18:01:01 yes Oct 06 18:01:18 but what's the point. the original issue was the crc Oct 06 18:01:21 that's what i was asking by "hardcoded" Oct 06 18:02:37 in the scenario you have established, there are exactly two options, not more: Oct 06 18:03:04 1) rebuild redboot to be more openwrt-friendly Oct 06 18:03:06 nbd * r12876 /packages/net/olsrd/Makefile: use $(FPIC) in olsrd Oct 06 18:03:19 2) telnet to redboot for every upgrade Oct 06 18:03:41 option #2 is preferable for the biggest audience Oct 06 18:04:43 #1 still requires a patch to mtd; #2 doesn't allow for upgrading from a web interface Oct 06 18:05:37 iirc the crc check of redboot usually gets disabled if you set the CRC to 0 Oct 06 18:05:47 if that is the case, a user space util could fix it up Oct 06 18:06:13 in the end, we don't want to have split images for kernel and rootfs forever Oct 06 18:06:26 patches to mtd are relatively trivial, since mtd is part of openwrt. as for #2, that's just the way things have to be Oct 06 18:06:29 nbd: I've made changes to set the proper crc if the 'FIS direcotry' is RW Oct 06 18:06:40 as soon as i have the time for it, i will make a new image format that combines kernel and rootfs and allows for a second stage loader in the first block Oct 06 18:06:57 nbd: please don't do that Oct 06 18:07:04 why not? Oct 06 18:07:16 having a kernel/rootfs split in the boot loader is just stupid Oct 06 18:07:20 wastes precious flash space Oct 06 18:07:24 makes upgrades more complicated Oct 06 18:07:33 a new image format can be handled in a generic way across different platforms Oct 06 18:07:37 on some devices, having them separate is critical for the original bootloader to work Oct 06 18:07:41 maybe another solution is to enable jffs2 in redboot and put the zImage in the jffs2 partition Oct 06 18:07:52 sn9: it's not mandatory for all platforms Oct 06 18:07:58 ah, ok\ Oct 06 18:08:18 MateIn4: that wastes space as well Oct 06 18:08:52 I'm just trying to brainstorm here. Right now there's no solution at all. Oct 06 18:09:20 just make redboot behave like on most other platforms that we support Oct 06 18:09:29 i mean most other redboot based platforms Oct 06 18:09:34 MateIn4: nbd seems to have contradicted the scenario you have established Oct 06 18:09:36 let it write a kernel without crc Oct 06 18:10:11 i.e., it is possible to disable crc for the kernel without rebuilding redboot Oct 06 18:10:27 if that is so, that is the preferred solution Oct 06 18:10:38 I don't like that idea because it can easily brick the system, but if that is the openwrt community position then it should be documented. Oct 06 18:10:52 how can it brick the system? Oct 06 18:11:00 if there's recovery access to redboot Oct 06 18:11:19 if redboot is not touched, and telnet is enabled, bricking is an impossibility Oct 06 18:11:20 the "fis load" could load a bad image Oct 06 18:11:32 so? Oct 06 18:11:32 so? Oct 06 18:11:35 ;) Oct 06 18:11:54 see here's how i think boot loader recovery should work Oct 06 18:12:10 by default it should not allow network access and it should immediately load the image Oct 06 18:12:16 if you want recovery, press reset while booting Oct 06 18:12:28 Normally, I use 'fis load linux;exec' as the redboot boot script. Oct 06 18:12:41 that way it's secured against remote access Oct 06 18:12:48 but easily recoverable with physical access Oct 06 18:13:03 then you don't need a crc in the image at all Oct 06 18:13:10 even if it loads a bad image, who cares? Oct 06 18:13:13 it can simply crash Oct 06 18:13:22 and if the user wants a working system, he can press reset while booting Oct 06 18:13:22 OK, I'll turn off crc checking. Oct 06 18:13:52 nbd: if you have a crc in the image, it can autodetect having had a power cut during a flash Oct 06 18:14:21 ok, different approach: Oct 06 18:14:26 we mostly use compressed images Oct 06 18:14:31 if decompression fails, die Oct 06 18:14:38 doesn't catch all flash interruptions Oct 06 18:14:49 but it does catch the simple ones Oct 06 18:15:07 for anything beyond that, you have to press reset Oct 06 18:15:10 which is not hard to do ;) Oct 06 18:15:13 nbd: the original firmware on the WRTU54G-TM has an extremely user-friendly recovery mechanism Oct 06 18:15:27 but we can fix that if we're replacing the boot loader Oct 06 18:15:49 or is this chat not about replacing the boot loader? Oct 06 18:15:49 did i misread something? Oct 06 18:16:25 I'm open to using a different bootloader but it has to support telnet access. Oct 06 18:17:12 nbd: the chat is about whether or not replacing the bootloader is preferable to some other way to get around the problem MateIn4 and others are having Oct 06 18:18:01 The default config for redboot has crc enabled. This is how commercial shops ship redboot. Oct 06 18:19:03 MateIn4: yes, but as nbd said, the crc can be set to zero from telnet to tell it to ignore that Oct 06 18:19:15 i don't know Oct 06 18:19:24 I'm not sure how to do that. Oct 06 18:19:30 but most of the devices i have here seem to handle a reflash from mtd gracefully Oct 06 18:19:44 so maybe they're not using crc Oct 06 18:19:54 I think that is the case. Oct 06 18:19:59 nbd: how many of those devices have 128K blocks? Oct 06 18:20:09 1 Oct 06 18:20:20 I believe proghorn does Oct 06 18:20:34 but I don't think the sector size is relevant Oct 06 18:21:21 MateIn4: sector size is what makes your problem a problem, since otherwise, the fis directory would already be writable Oct 06 18:21:54 yes, but the crc would still not be updated in the 'FIS directory' Oct 06 18:21:54 why is it not writable? Oct 06 18:22:23 it's not writable when the 'FIS directory' and 'RedBoot config' share the same sector. Oct 06 18:22:23 and not writable for the kernel or for the boot loader? Oct 06 18:22:26 nbd: shares an erase block with redboot itself, which has the protect bit Oct 06 18:22:49 for the kernel Oct 06 18:23:01 the kernel makes it non-writable in mtdpart.c when a partition is not a multiple of the erase size. Oct 06 18:23:12 is there actual redboot code/data in that block? Oct 06 18:23:23 in that erase block, yes Oct 06 18:23:33 that sucks Oct 06 18:23:52 no, only the 'FIS directory' and the 'RedBoot config' Oct 06 18:24:08 actual code is found in the 'Redboot' partition. Oct 06 18:24:10 ah, redboot config is a different issue than redboot itself ;) Oct 06 18:24:25 oh, i misunderstood, then Oct 06 18:24:44 the fis directory is before the redboot config, right? Oct 06 18:24:54 yes Oct 06 18:25:10 ok, why not just patch the kernel to pad the FIS directory size up to eraseblock size? Oct 06 18:25:26 having mtd partitions overlap is not a big deal Oct 06 18:25:27 all you have to do in this case is patch the kernel to consider fis directory and redboot config to be a single partition Oct 06 18:25:36 as long as the user mode code toucching it is careful Oct 06 18:25:40 I'm rebuilding the kernel now where I've take out the check so that I make make these partitions writable. Then my patch will work. Oct 06 18:25:52 don't take out the check Oct 06 18:25:55 that's a bad idea Oct 06 18:25:59 don't take out the check Oct 06 18:26:06 use my apprach Oct 06 18:26:22 or mine -- either will work Oct 06 18:26:32 if you patch out the check then using raw access to /dev/mtd* will kill the redboot config Oct 06 18:26:39 because it erases more than it rewrites Oct 06 18:27:06 if you make them overlap, then fis.c could access the device without using explicit erasing Oct 06 18:27:19 it could mmap the partition, make its changes, recalculate the crc, then do msync() Oct 06 18:27:23 true, but perhaps we can add other checks Oct 06 18:27:27 without damaging the redboot config Oct 06 18:27:33 why should we add other checks? Oct 06 18:27:40 why not do it the easy and uncomplicated way? Oct 06 18:28:10 if you make them overlap, you cannot control what accesses which from userspace, unless you implement some kind of locking Oct 06 18:28:14 I'm trying to make it easy. Oct 06 18:28:26 you're doing a simple thing which makes a lot of things complicated Oct 06 18:28:39 and i'm proposing a simple thing which makes other things simple Oct 06 18:28:45 there's a difference there ;) Oct 06 18:29:11 if you have a single partition, you can abstract away unauthorized access Oct 06 18:29:11 So, to recap, your position is to disable crc checking in redboot. Oct 06 18:29:33 MateIn4: yes, but at runtime, not compiletime Oct 06 18:29:38 my position is to get access to the FIS table first Oct 06 18:29:47 and then see what we do about the rest Oct 06 18:30:08 sn9: your position is to change redboot source Oct 06 18:30:19 MateIn4: absolutely not Oct 06 18:31:54 if you want the crc check to be preserved, the most trouble-free way to access the fis table is to have the kernel treat it and the rb config as one partition Oct 06 18:32:30 I think we should have a set of guidelines for configuring redboot so it's compatible with openwrt. I also think that the upgrade process should be possible from the web interface, i.e. not require access to redboot for normal conditions. Oct 06 18:33:02 i don't think it makes sense to maintain a custom version of redboot Oct 06 18:33:15 at some point we want our own loader which is not as braindead as everything else out there Oct 06 18:33:28 I agree with that! Oct 06 18:33:41 MateIn4: if by "configuring redboot" you mean at compile time, nbd's idea of throwing redboot out altogether is much more workable Oct 06 18:34:26 I'm open to alternatives; like Isaid the only requirement is that it can provide telnet access. Oct 06 18:34:39 nbd: on that note, what do you think of the WRTU54G-TM's recovery mechanism? Oct 06 18:34:48 i haven't looked at it yet Oct 06 18:34:54 how does it work? Oct 06 18:35:25 nbd: before i describe that, take a look at its flash layout: http://openwrt.org/logs/openwrt-devel.log.20081006 Oct 06 18:36:53 except for the padding between kernel and rootfs it looks somewhat sane Oct 06 18:37:26 if the normal kernel/rootfs combo fail crc, uBoot will substitute the minikernel and minirootfs for recovery automatically Oct 06 18:37:51 though you don't really need a rootfs for the recovery kernel Oct 06 18:37:59 that's what initramfs is for Oct 06 18:38:00 ;) Oct 06 18:38:27 the minirootfs brings up a webif that only allows reflashing the main kernel/rootfs and has no other functions Oct 06 18:39:33 yeah, you could throw that in initramfs and save space Oct 06 18:39:48 still, i think in the future we can have such a web interface in the boot loader itself Oct 06 18:40:01 makes it smaller Oct 06 18:40:36 I thought about using Apex and replacing the network part with uIP. Oct 06 18:40:38 if you put that functionality into initramfs, you lose isolation from the main firmware image, which is what gets flashed Oct 06 18:41:01 no, i mean initramfs of the recovery kernel Oct 06 18:41:05 not of the main kernel Oct 06 18:41:18 MateIn4: uIP is pretty bone-headed -- lwip is more usable Oct 06 18:41:44 either way, they both can provide a simple tcp layer Oct 06 18:42:05 i would like a boot loader project that is closer to the linux codebase Oct 06 18:42:13 without sacrificing too much space Oct 06 18:42:24 nbd: yes, true; i think there might be some kind of limitation preventing that in their uBoot Oct 06 18:42:34 u-boot is structually messed up Oct 06 18:42:36 initramfs, that is Oct 06 18:42:52 there is no limitation on initramfs usage in the boot loader Oct 06 18:43:04 because initramfs is linked into the kernel image Oct 06 18:43:10 doesn't need to be loaded separately like initrd Oct 06 18:43:27 Maybe have the bootloader be a specialed kernel image with a simple prelude that initializes ram; then it can kexec the actual image. Oct 06 18:43:32 yes, but that needs 2.6, and they used 2.54 Oct 06 18:43:35 *2.4 Oct 06 18:43:38 MateIn4: the kernel itself is way too fat Oct 06 18:43:55 MateIn4: what i mean is something that is close on a source code level Oct 06 18:44:04 MateIn4: but compiles to something much smaller Oct 06 18:44:19 and not close to the whole kernel Oct 06 18:44:26 just similar subsystems, similar driver api Oct 06 18:44:39 but without the whole kobject/class structure Oct 06 18:44:51 without filesystems Oct 06 18:44:58 etc. Oct 06 18:58:14 cyrus * r12877 /packages/net/tinyproxy/files/tinyproxy.init: tinyproxy: Allow option is a list not an atom Oct 06 19:36:01 nbd * r12878 /packages/net/icecast/Makefile: icecast: add missing dependency Oct 06 20:12:03 <[florian]> sn9: with some lag, I have never seen any non-redboot rdc devices Oct 06 20:12:22 <[florian]> sn9: btw, I just got an eval board from them which should help debugging rdc devices with newer kernels Oct 06 20:23:53 [florian]: i'm examining the ar360w3g, and so far, it does not appear to use redboot Oct 06 20:26:35 <[florian]> sn9: is that also rdc based ? Oct 06 20:26:48 yes Oct 06 20:26:56 xMff: CyrusFF: Achja, Die min-width's hab ich mit dem Patch auch auf alle neuen Sprachen usw. aktualisiert. Oct 06 20:27:17 i am trying to come up with a way to get a dump of the existing flash Oct 06 20:27:44 how do i override the console=whatever kernel arg after boot? Oct 06 20:28:14 x-alina: okay, currently working on making 0.8 stable, will look at the patch within the next few days Oct 06 20:28:14 <[florian]> after the kernel booted ? Oct 06 20:28:29 yes Oct 06 20:28:54 <[florian]> I think you have to patch the binary Oct 06 20:29:32 isn't there something in /proc i can write to? Oct 06 20:29:45 <[florian]> I do not think so but I may be wrong Oct 06 20:29:56 <[florian]> at least not something you can permanently change Oct 06 20:29:59 xMff: Tested in Firefox, Opera, Konqueror, Google Chrome, IE 5, 5.5, 6 and 7. Oct 06 20:30:03 i'm sure i've seen it done somewhere Oct 06 20:30:15 i don't want it permanent Oct 06 20:30:20  x-alina: sehr schön Oct 06 20:31:38 i just want to override Oct 06 21:11:32 noz * r12879 /branches/8.09/target/linux/brcm47xx/patches-2.6.25/210-b44_phy_fix.patch: [bcrm47xx] Apply r12829 from trunk: Fix eth0/1 PHY on WRTSL54GS Oct 06 22:45:16 [florian]: confirmed -- redboot is not used Oct 06 23:26:53 nbd * r12880 /branches/8.09/package/opkg/files/opkg.conf: adjust opkg.conf for future release repository Oct 07 00:16:47 nbd * r12881 /trunk/target/linux/atheros/files/arch/mips/atheros/ar5315/board.c: don't register GPIO 0 as LED. it drives the chip select line of the SPI flash on most AR2317 boards. fixes strange jffs2 errors on bootup Oct 07 00:18:14 nbd * r12882 /branches/8.09/target/linux/atheros/files/arch/mips/atheros/ar5315/board.c: merge r12881 to 8.09 Oct 07 01:41:20 nbd * r12883 /trunk/package/madwifi/patches/ (10 files): madwifi: allow ad-hoc mode with software based TSF merging (hardware merging can screw up the internal timers and cause transmit hangs) - based on a patch by sven-ola. activated by wlanconfig's nosbeacon flag Oct 07 01:41:48 nbd * r12884 /trunk/package/madwifi/patches/381-ibss_modes.patch: fix mode setup for ibss/ahdemo - preserve existing modes and use HOSTAP mode for AHDEMO instead of IBSS to prevent unwanted IBSS merges Oct 07 01:42:15 nbd * r12885 /trunk/package/madwifi/patches/352-ani_fix.patch: madwifi: re-enable the MIB interrupt flood protection fix - apparently it's still necessary in some extreme cases Oct 07 01:42:41 nbd * r12886 /trunk/package/madwifi/patches/382-relax_bintval.patch: allow larger beacon interval values - useful for big mesh networks (patch by sven-ola) Oct 07 01:45:10 nbd * r12887 /branches/8.09/package/madwifi/patches/ (10 files): merge r12883-12886 to 8.09 **** ENDING LOGGING AT Tue Oct 07 02:59:57 2008