**** BEGIN LOGGING AT Wed Apr 04 02:59:57 2007 Apr 04 09:05:38 mbm * r6860 /trunk/rules.mk: revert [6857] for rules.mk; make cannot parse dependancies properly Apr 04 09:06:15 <[mbm]> :/ Apr 04 10:05:35 kaloz * r6861 /trunk/target/linux/ixp4xx-2.6/patches/ (2 files): set up the NPEs and microcode loading on the Pronghorn Metro Apr 04 12:54:45 Kaloz: are you here ? Apr 04 14:33:56 hcg * r6862 /trunk/ (7 files in 4 dirs): Apr 04 14:33:56 Cleanups on romboot and u-boot. Apr 04 14:33:56 Conditionally apply ldd and ldconfig support on at91 platform Apr 04 14:53:21 [florian]: Thanks for ldconfig (ldd the old way was fine) Apr 04 15:13:57 nbd * r6863 /packages/lang/jamvm/Makefile: add workaround for the jamvm sdk compile - the sdk does not understand DEPENDS:=@!mips yet Apr 04 16:11:29 nbd * r6864 /trunk/ (package/busybox/Makefile scripts/gen_busybox_config.pl): replace gen_busybox_config.pl with a simple sed command Apr 04 16:13:56 nbd * r6865 /trunk/ (2 files in 2 dirs): move gen_busybox_menuconfig.pl to package/busybox Apr 04 17:26:36 [florian]: Breaks gentoo but its fine with debian (as far as I can tell) Apr 04 18:02:32 <[florian]> h3sp4wn: seems to be broken here too :/ Apr 04 19:02:50 [florian]: still there? Apr 04 19:05:11 <[florian]> sn9_: yep Apr 04 19:05:24 got the url's? Apr 04 19:05:39 <[florian]> sn9_: yes it is ok Apr 04 19:06:07 i am at a loss regarding the flash-writing bug Apr 04 19:06:16 <[florian]> sn9_: what kind of a bug ? Apr 04 19:06:53 http://openwrt.org/logs/openwrt-devel.log.20070404 at [04:31] Apr 04 19:08:57 <[florian]> by the way, why use vmalloc instead of kmalloc ? Apr 04 19:09:21 because k- has a 128k limit Apr 04 19:09:34 <[florian]> ah right Apr 04 19:09:43 i am reading the whole kernel into the buffer Apr 04 19:10:03 <[florian]> yeah to crc32 on it ? Apr 04 19:10:11 yes Apr 04 19:10:45 <[florian]> the crc32 on the kernel should not changed once reflashed should it ? Apr 04 19:10:55 correct Apr 04 19:11:05 <[florian]> but you need to calculate it the first time Apr 04 19:11:09 correct Apr 04 19:11:27 <[florian]> I go eating, will come back in few minutes, we can talk about it ;) Apr 04 19:11:49 but somehow, when i reflash, what ends up in flash differs from the buffer by one byte Apr 04 19:53:19 <[florian]> sn9_: re Apr 04 19:53:28 ok Apr 04 19:55:04 <[florian]> sn9_: ok, just one byte is different , Apr 04 19:55:05 <[florian]> ? Apr 04 19:55:34 yes, the "pid" field gets zeroed in the flash somehow Apr 04 19:55:54 it is supposed to be a 32bit value of 5 Apr 04 19:56:04 <[florian]> ok Apr 04 19:56:52 <[florian]> have you managed finding what changes it ? Apr 04 20:04:10 [florian]: it is apparently not "changed" as it is correct in the buffer, just not in the flah Apr 04 20:04:14 *flash Apr 04 20:08:02 <[florian]> cannot we just use the original rdc driver principle : adjusting parts of the flash, without taking into account the crc32 stuff ? Apr 04 20:08:29 then one cannot make the root jffs2 Apr 04 20:08:41 <[florian]> yeah, that is what I forgot last time :/ Apr 04 20:09:20 <[florian]> we might just propose another bootloader then Apr 04 20:10:18 one cannot reflash the bootloader until an alternative firmware is already functioning Apr 04 20:10:38 the stock firmware offers no mechanism for it Apr 04 20:11:00 <[florian]> do we have a shell login on the serial console with the stock firmware ? Apr 04 20:11:05 yes Apr 04 20:11:11 <[florian]> ok, is dd there ? Apr 04 20:11:14 <[florian]> and wget ? Apr 04 20:11:15 no Apr 04 20:11:22 wget is there, not dd Apr 04 20:11:38 <[florian]> ah, ok, so not possible, unless there is a mtd-like utility Apr 04 20:11:48 again, not there Apr 04 20:12:10 otherwise, i would have done that already Apr 04 20:12:18 <[florian]> we can ask to reflash with squashfs first, then with jffs2 once the bootloader is updated Apr 04 20:12:39 i even recompiled the bootloader with a check for a zero fastcksum Apr 04 20:12:50 but had no way to get it on there Apr 04 20:13:21 <[florian]> you can try with the static mapping first Apr 04 20:13:21 to use squashfs, one must patch either the kernel or the bootloader, too Apr 04 20:13:44 <[florian]> why patch the kernel ? Apr 04 20:13:44 static mapping offers no advantages here Apr 04 20:14:01 rootfstype=squashfs Apr 04 20:14:19 otherwise, it seems to assume jffs2 Apr 04 20:14:55 <[florian]> overriding the kernel command line is not a problem once you have a custom kernel running on it Apr 04 20:15:05 true Apr 04 20:15:40 i have already added a patch for 2.4 providing that since the last tarball upload Apr 04 20:16:18 i have not tested it yet, because i was hoping to get some idea about the bug i mentioned, first Apr 04 20:21:33 <[florian]> I think you can test it Apr 04 20:22:18 yes, but i doubt i will learn any new information from doing so Apr 04 20:22:44 OTOH, if somebody has an idea about the flashing bug... Apr 04 20:22:55 <[florian]> well, at least, if you have a working image you can reflash with a stock redboot Apr 04 20:23:24 <[florian]> which has a fis directory and consequently dynamic partition support Apr 04 20:23:24 oh, you meant test my recompiled redboot? Apr 04 20:23:42 <[florian]> yes Apr 04 20:23:49 i thought you were referring to the kernel patch for squashfs Apr 04 20:23:54 <[florian]> unless you reflashed it via jtag ? Apr 04 20:24:08 florian * r6866 /trunk/ (package/base-files/Makefile toolchain/uClibc/Makefile): Remove ldd/ldconfig for the moment (#1551) Apr 04 20:24:49 i do not know the jtag pinout for the device, nor do have the inclination to make a jtag cable atm Apr 04 20:24:59 <[florian]> ok Apr 04 20:26:12 i have come to the conclusion that all bootloader-related problems are possible to work around in the kernel Apr 04 20:26:44 <[florian]> except maybe, the use of jffs2 with the stock bootloader ? Apr 04 20:26:52 unless the kernel size specified in the bootloader is exceeded Apr 04 20:27:11 i have no idea at this point what will happen then Apr 04 20:27:42 no, i no longer believe the use of jffs2 to be an exception, either Apr 04 20:27:47 <[florian]> it would when we will want to add a more complete networking stack Apr 04 20:28:02 i am not so sure Apr 04 20:28:22 <[florian]> well, when the kernel is too big, it just does not output anything on the serial console Apr 04 20:28:33 <[florian]> make the test Apr 04 20:28:44 i thought you said that was pci-related Apr 04 20:29:06 <[florian]> that is what I thought, because enabling the pci subsystem added few kbs to the kernel Apr 04 20:29:13 oh Apr 04 20:29:22 <[florian]> we can also workaround this by compressing the kernel with lzma Apr 04 20:29:37 i think a pci subsystem will be necessary, anyway Apr 04 20:29:47 <[florian]> it is, for both wifi and ethernet Apr 04 20:30:00 lzma would require bootloader support, too Apr 04 20:30:14 <[florian]> not necesarily, just the proper lzma-loader Apr 04 20:30:31 have the kernel decompress itself? Apr 04 20:30:45 <[florian]> be decompressed by the packed lzma-loader, yes Apr 04 20:31:01 <[florian]> the lzma loader will uncompress the kernel in ram, then jump to the kernel entry point Apr 04 20:31:08 <[florian]> it is a kind of proxy Apr 04 20:31:09 we'll cross that bridge when we get to it Apr 04 20:32:08 <[florian]> as nbd explained, it should be something similar to creating a bzImage Apr 04 20:32:09 in any case, if we accept the use of the stock bootloader and allow a jffs2 root, the flashing bug is the immediate problem Apr 04 20:32:32 <[florian]> absolutely Apr 04 20:32:42 sn9_: do you need any more info on how to do that? Apr 04 20:33:06 btw. i'd consider the kernel more important than jffs2 root Apr 04 20:33:13 i mean the lzma compression Apr 04 20:34:41 nbd: info on lzma, or flashing? yes, the kernel is more important in the long run, but fixing that will be much easier when the flash mapper works as now designed Apr 04 20:35:19 i mean info on how to do the jffs2root workaround Apr 04 20:36:18 nbd: it's not the general method i need more info on, but more the specific quirks that may lead to the current problem Apr 04 20:36:38 ? Apr 04 20:36:54 http://openwrt.org/logs/openwrt-devel.log.20070404 at [04:31] Apr 04 20:37:16 <[florian]> sn9_: could not it be your code having side effects ? Apr 04 20:37:47 sn9_: show me the code that has this behavior Apr 04 20:37:54 [florian]: i am more inclined to believe the problem lies in improperly copying code from brcm47xx-2.6 Apr 04 20:38:14 <[florian]> sn9_: might be Apr 04 20:38:43 nbd: http://homepage.mac.com/danielg4/rdc-2.4.tar.bz2 Apr 04 20:39:04 untar into trunk/target/linux Apr 04 20:39:17 <[florian]> sn9_: I think he knows how to use it ;) Apr 04 20:39:26 just making sure Apr 04 20:41:15 sn9_: #if RDC3210_NVRAM_IS_JFFS2 -- wtf is that? Apr 04 20:41:34 for using jffs2 as non-root Apr 04 20:41:50 using #ifdef for that is not acceptable Apr 04 20:41:56 why? Apr 04 20:41:59 the flash map driver must be able to figure this out dynamically Apr 04 20:42:17 because the kernel is built once for multiple filesystem types Apr 04 20:43:01 that is not possible -- there is no info to base such a decision on, and the exact fstype is irrelevant to the decision. it must be decided by whomever builds the firmware image Apr 04 20:43:39 using jffs2 for root is a different story Apr 04 20:43:43 <[florian]> sn9_: no matter, ifdef in a driver is not acceptable, turn it into a Kconfig at least Apr 04 20:43:53 sn9_: the broadcom driver figures this out dynamically Apr 04 20:43:55 [florian]: that was my plan Apr 04 20:43:57 sn9_: other drivers do it as well Apr 04 20:44:10 sn9_: btw. on 2.6 you don't even have to detect squashfs yourself Apr 04 20:44:27 sn9_: a patch to the mtd subsystem handles this automatically Apr 04 20:44:52 nbd: no other driver even has this functionality as far as i've seen, so there is nothing for broadcom to figure out dynamically Apr 04 20:45:36 didn't you mean squashfs and jffs2 as overlay? Apr 04 20:45:40 or what was it that you meant? Apr 04 20:46:25 yes, but without combining them into one partition, so as not to panic the bootloader Apr 04 20:48:00 i think it makes the idea of using squashfs slightly even more viable Apr 04 20:48:21 sn9_: the code on 2.6 does exactly that Apr 04 20:48:26 sn9_: e.g. on fonera Apr 04 20:48:26 it wouldn't be of much use if root is already jffs2, except for testing Apr 04 20:48:39 <[florian]> squashfs + jffs2 as overlay is done automatically if you name the partition rootfs Apr 04 20:48:43 sn9_: there you make the rootfs partition cover the whole available firmware space except for the kernel Apr 04 20:48:55 sn9_: and it automatically detects where the squashfs ends and adds an extra partition there Apr 04 20:49:02 that is what i was trying to avoid Apr 04 20:49:05 we've had that quite a while and you can do it with much less hacks Apr 04 20:49:27 and if you stop caring about 2.4 compatibility, you can throw out a lot of code from that flash map driver Apr 04 20:49:52 to add an extra partition, the map driver must be modified, because there is no redboot table Apr 04 20:50:07 that is exactly what i did Apr 04 20:50:26 all the map driver has to do is create *one* single partition called 'rootfs' with all available space, no matter if it's squashfs or jffs2 Apr 04 20:50:34 and fix up the crc for the jffs2-only case Apr 04 20:50:43 the rest will be done by the generic mtd subsystem with our patches Apr 04 20:51:04 you save a lot of code that way and it would make the flash map driver a lot cleaner Apr 04 20:51:19 so have the crc end in the middle of a partition? i did not think of that -- sorry Apr 04 20:51:58 i think the best way would be to unconditionally modify the boot loader's firmware size so that it only covers the kernel and then fix up the crc Apr 04 20:52:12 as long as you know where the kernel ends and where the boot loader config starts, you simply register that as a single partition Apr 04 20:52:18 and the kernel will do the rest of the work for you Apr 04 20:52:43 the various read operations that you put in the flash map driver can also be removed Apr 04 20:52:51 and replaced with simple_map_init(&mtd); Apr 04 20:53:34 it wasn't so much 2.4 compatibility that i was thinking about, but rather the usefulness of the driver beyond openwrt for eventual inclusion in the kernel.org trees, in the absence of openwrt's elegant subsystems Apr 04 20:54:01 most of it is not openwrt specific Apr 04 20:54:12 the only openwrt specific part is the one of handling squashfs+jffs2 together Apr 04 20:54:23 which is not really something that you should move in your own flash map driver when submitting it for kernel.org Apr 04 20:54:36 <[florian]> sn9_: you could have used the static mapping I rewrote as a basis Apr 04 20:54:38 so if you write it in the way that i told you, it will be fine for upstream inclusion Apr 04 20:54:38 i did not put any extra read operations in aside from reading the kernel for the crc Apr 04 20:54:56 i mean __u8 rdc3210_map_read8(struct map_info *map, unsigned long ofs) Apr 04 20:54:59 that can be nuked Apr 04 20:55:02 yes Apr 04 20:55:15 that was already there, and is unnecessary Apr 04 20:55:20 ok Apr 04 20:55:33 so do you see my point with only registering one rootfs partition? Apr 04 20:56:40 yes, but i disagree about extending the case of having the crc cover the kernel only to the use of a squashfs root -- there is no longer a reason for that Apr 04 20:57:06 [florian]: for AR7 2.6 should I choose squashfs or jffs2? Apr 04 20:57:14 the crc can cover the squashfs without any disadvantages Apr 04 20:57:16 what i mean is if you do it unconditionally then it will just work and the flash map driver won't have to care about differences between jffs2 and squashfs Apr 04 20:57:23 that makes the code cleaner Apr 04 20:57:32 not by much Apr 04 20:57:42 just gets rid of a single if() Apr 04 20:57:46 <[florian]> armijn: I would recommend squashfs for now, until we change the kernel command line to make it run on jffs2 as well Apr 04 20:57:59 sn9_: ok, do it if you want Apr 04 20:58:08 ok Apr 04 20:58:29 anyway, all this assumes the reflashing of the crc to work properly, which it does not yet do Apr 04 21:00:46 <[florian]> nbd: we can first use a gzipped kernel instead of lzma's one Apr 04 21:01:46 i offer another possible advantage of not using a single rootfs partition: Apr 04 21:02:38 if squashfs does not need to begin on an erase block boundary, it is occasionally possible for more space to be available for jffs2 Apr 04 21:11:59 still, nobody has ideas as to why the flash does not reflect the buffer? Apr 04 22:03:21 hm Apr 04 22:03:39 wondering if I could upload firmware upgrade to c54apra via firefox on Linux Apr 04 22:03:42 it might need IE Apr 04 22:04:57 nbd * r6867 /trunk/target/linux/brcm47xx-2.6/files/drivers/ssb/driver_pci/pcicore.c: add pci latency timer workaround for atheros cards (from #1546) Apr 04 22:05:14 well, only one way to try Apr 04 22:52:43 the libc symbol problem seems exclusive to a jffs2 root -- with a kernel patched for squashfs, everything boots fine Apr 04 22:55:38 [florian]: the C54APRA webinterface doesn't like my new firmware image Apr 04 22:56:06 dunno if it is just the webinterface, or the firmware upgrade program on the device Apr 04 23:00:38 probably has to do something with offsets Apr 04 23:01:00 [florian]: how did you install it? Apr 04 23:27:46 hmm, i think i found why this problem occurred... Apr 05 00:40:10 gah...c54apra also doesn't like tftp nor ftp Apr 05 00:40:24 rdc-2.4.tar.bz2 updated one final time; it is now officially abandoned in favor of 2.6 Apr 05 00:40:25 * armijn starts to wonder how [florian] flashed the device Apr 05 00:41:18 hm...sleep Apr 05 02:07:53 nbd * r6868 /trunk/target/linux/brcm47xx-2.6/files/drivers/ssb/driver_pci/pcicore.c: brcm47xx-2.6: reset the pci core at boot time (see #464) **** ENDING LOGGING AT Thu Apr 05 02:59:56 2007