**** BEGIN LOGGING AT Fri Nov 06 02:59:57 2009 Nov 06 04:19:55 nbd: ping Nov 06 04:20:34 or anyone that know if issues with brcm-platform was fixed? Nov 06 04:23:10 my last try was 5 hours ago Nov 06 04:23:25 and It was not work Nov 06 06:21:22 Bartman007: ping? Nov 06 06:35:03 fofware: pong Nov 06 06:36:27 hello Bartman007, can you tell me what i'm doing wron, I trying to build image to brcm-2.4 and BCM47 and my images don't boot Nov 06 06:36:41 wrong* Nov 06 06:38:08 just now I done with BCM47 and my image is smaller than openwrt, but my include webif Nov 06 06:39:04 the only broadcom board I've run trunk on recently is my wgt634u, and that seemed to work fine. Nov 06 06:40:58 I did download the image from http://downloads.openwrt.org/snapshots/trunk/brcm47xx/openwrt-wrt54g-squashfs.bin and this work in WRT54GL, but when i build my own do not boot Nov 06 07:37:31 Bartman007: are the snapshot build dirs always cleaned before rebuild? Nov 06 07:48:59 nbd: yes. Nov 06 07:50:17 hm, then we still have weird issues with brcm stuff Nov 06 07:58:13 <[florian]> sn9: I managed to get .30 booting on my ar525w using a host-side lzma, not the openwrt one Nov 06 08:20:52 {Nico}: you here? Nov 06 08:31:58 [florian]: details? Nov 06 08:33:22 <[florian]> sn9: openwrt's lzma just screws the compression enough for the early decompression code to do nothing, using lzma 4.65 and the original cmd_lzma command in scripts/Makefile.lib and the box just boots Nov 06 08:34:50 why does openwrt still have its own early lzma decompression if that is now upstream? Nov 06 08:35:31 <[florian]> oh no it's not the in-kernel decompression code which causes problems, it's the lzma tool that you use, which can can cause breakages Nov 06 08:35:45 <[florian]> lzma 4.32 from openwrt is a no go, while lzma 4.65 from debian or whatever plain works Nov 06 08:36:27 <[florian]> I have had that problem already with .28 but the one-liner thing that calls the right tool in lost in the middle of a bigger patch Nov 06 08:36:44 is this issue unique to rdc321x? Nov 06 08:37:18 <[florian]> certainly not, any x86/arm/mips using the mainline lzma decompression feature will face it Nov 06 08:37:42 how is it handled on other targets? Nov 06 08:37:46 <[florian]> for arm, nbd patched the decompression code such that the issue does not show up as it uses the right lzma parameters Nov 06 08:38:18 <[florian]> for now, mips does not have that feature enabled since it requires the backport of a patch which adds lzma/bzip2/gzip decompression to it Nov 06 08:38:33 <[florian]> so we stick to the good old lzma-loader thing Nov 06 08:38:42 <[florian]> like I just said, arm was patched Nov 06 08:38:54 <[florian]> so there is only x86 suffers from this in real life Nov 06 08:40:54 you just merged the olpc target Nov 06 08:41:04 <[florian]> sn9: ye Nov 06 08:41:18 <[florian]> and so will I in a couple of days for rdc Nov 06 08:42:43 florian * r18325 /trunk/target/linux/rdc/ (3 files in 2 dirs): [rdc] use host-side lzma decompression tool, lzma-4.32 from openwrt produces non-working bzImages, switch to 2.6.30, strip down kernel configuration Nov 06 08:42:43 @florian: I get a memory leak on latest brcm47xx which is corrected if I compile in kernel CONFIG_LEGACY_PTYS (this is not a new issue) Nov 06 08:43:36 the x86 target uses .31 atm Nov 06 08:47:30 florian * r18326 /trunk/target/linux/rdc/Makefile: [rdc] add the prereq-check on lzma Nov 06 09:17:08 [florian]: you forgot: http://openwrt.pastebin.com/f42adb9dd Nov 06 09:18:26 also nuke target/linux/rdc/patches-2.6.30/003-rootfstype.patch Nov 06 09:41:41 [florian]: how about adjusting the lzma parameters with the openwrt lzma tool on rdc instead of using that prereq check? Nov 06 09:41:48 i don't think it's the tool itself Nov 06 09:42:14 maybe removing -lc1 -lp2 -pb2 from the lzma command line for x86 is enough Nov 06 09:42:24 those parameters are good for mips, but not so good for x86 Nov 06 09:43:41 also: does the rdc thing not have an fpu? Nov 06 09:43:46 or why was math emulation enabled Nov 06 09:44:23 i don't think he's there Nov 06 09:44:44 he'll probably read backlog Nov 06 09:45:08 full spec sheet was on oldwiki; not sure whether it still is. if so, you can check for fpu Nov 06 09:47:10 can't find any mentions of fpu on this chip Nov 06 09:47:50 http://oldwiki.openwrt.org/RDCPort.html Nov 06 09:48:08 yeah, i was looking at that Nov 06 09:48:25 the pdf should be saved somewhere, since it did not survive the nuwiki migration Nov 06 09:50:16 http://wiki.openwrt.org/oldwiki/rdcport looks ok to me Nov 06 09:51:30 <[florian]> nbd: no way, we need to get rid of our old lzma Nov 06 09:51:45 <[florian]> nbd: I do not see any point in patching the kernel to make it work with *our* lzma Nov 06 09:51:58 those options were added by one of our patches Nov 06 09:52:05 <[florian]> and they do not work Nov 06 09:52:05 they're not in upstream Nov 06 09:52:08 nbd: the pdf is 404 Nov 06 09:52:26 <[florian]> nbd: I will try remove the parameters you mention Nov 06 09:52:34 sn9: ah, that one. yes Nov 06 09:52:47 <[florian]> nbd: but still, the new lzma version gives a slightly better compression ratio which is just what is required to make the kernel fit under 768KB Nov 06 09:53:00 nbd: -G is the RoHS version Nov 06 09:53:08 [florian]: are you sure it's the new lzma version and not the different compression settings? Nov 06 09:53:21 [florian]: i didn't notice any difference in my tests on other platforms Nov 06 09:53:27 but yes, we should get rid of the old stuff Nov 06 09:54:31 <[florian]> nbd: humm could be related to the compression settings, they actually differ Nov 06 09:54:40 <[florian]> nbd: I will try that later when I am back home Nov 06 09:55:20 [florian]: in the meantime, http://openwrt.pastebin.com/f42adb9dd and target/linux/rdc/patches-2.6.30/003-rootfstype.patch Nov 06 09:56:53 <[florian]> sn9: you just happen to broke ar525w with that patch Nov 06 10:00:17 <[florian]> nbd: also not sure it is true on x86, but it is on ARM, we need to append the size of the compressed kernel at the end of the file, otherwise the early decompressor code is lost Nov 06 10:00:26 you tested? Nov 06 10:00:46 <[florian]> sn9: yes I tested it on .28 and there was no partitions created Nov 06 10:01:03 [florian]: please show log Nov 06 10:01:03 [florian]: for arm, the -eos option is enough to make it work Nov 06 10:02:53 <[florian]> nbd: would not it be a reasons to install the new lzma version that we already build somewhere in staging_dir/host? Nov 06 10:03:09 <[florian]> nbd: if it can remove the lzma arm-specific hack Nov 06 10:04:44 last time i tested, my code was more efficient than the upstream code Nov 06 10:04:59 i think the code in the decompress_*.c files is weird Nov 06 10:05:26 <[florian]> yes it is, but it's mainline thus patching it is not quite what I would like to do Nov 06 10:06:05 once we've tested the new tools with the various targets, i'm fine with moving them to tools/ Nov 06 10:06:21 i will then do some more testing with the upstream code vs my code Nov 06 10:06:27 <[florian]> sounds good Nov 06 10:06:35 but if the difference is as big as it was when i last tested it, i vote for keeping my code Nov 06 10:07:08 [florian]: do you remember offhand what the partitioning error msg was? Nov 06 10:07:50 i don't think it's worth sacrificing efficiency for the sake of dropping a patch that has very low maintenance overhead Nov 06 10:08:56 nbd: either drop or put in generic-2.6, but maintaining per-target is a bad idea Nov 06 10:09:15 at the moment it's per-arch Nov 06 10:09:23 as my code is not a drop-in replacement for decompress_unlzma.c Nov 06 10:09:35 because it provides a simpler interface, which is part of what makes it more efficient Nov 06 10:09:43 it needs less malloc'd buffers Nov 06 10:09:43 <[florian]> sn9: sorry I do not Nov 06 10:10:30 [florian]: can we fix it later, and complete the partial commit above for now? Nov 06 10:10:52 because now, all rdc321x devices except ar525w will break Nov 06 10:10:55 <[florian]> nbd: rdc is a an excellent example of maintenance nightmare, because we need to be very careful about any change that is added and which significantly increase the size of the kernel, and we need to make sure that the lzma decompressor works Nov 06 10:11:18 sure, but integrating decompressor code and making it work is easy Nov 06 10:11:35 <[florian]> nbd: then make sure it reachs mainline if you think it is worth Nov 06 10:11:47 will do some comparisons first Nov 06 10:11:58 though mainline will probably not pick up the changes Nov 06 10:12:08 <[florian]> at least it can start the discussion Nov 06 10:12:21 my patch duplicates code and mainline doesn't like code duplication Nov 06 10:12:55 however i think for us efficiency is more important than getting rid of a minor piece of source code duplication Nov 06 10:13:08 <[florian]> right Nov 06 10:14:43 maybe i will find some time to optimize the mainline lzma decompress code in a way that i can submit, but at the moment i care more about working on our config infrastructure Nov 06 10:14:57 and about working on wifi driver stuff Nov 06 10:14:59 ;) Nov 06 10:15:20 <[florian]> sn9: you are right it breaks other rdc devices, but I think that we might be able to address that problem with the cpuid patch that I checked in a while ago Nov 06 10:15:55 [florian]: what does cpuid have to do with it? Nov 06 10:16:00 <[florian]> sn9: it seems to provide a fairly reliable way of identifying devices, and the list comes from rdc directly Nov 06 10:16:16 [florian]: what does identifying devices have to do with it? Nov 06 10:17:08 <[florian]> sn9: you can provide the right partition mapping and check for the specific mtd headers Nov 06 10:17:55 i'll believe that when i see it, but i think that would be easier to merge into something that works Nov 06 10:18:23 <[florian]> ok Nov 06 10:18:36 there is no way in hell i can imagine rdc knowing about all the vendor flash mappings Nov 06 10:19:19 <[florian]> no this is not what I told you Nov 06 10:19:29 <[florian]> I told you that they know whom they sold chip to Nov 06 10:19:38 <[florian]> and they burn a different cpu identifier depending on the manufacturer Nov 06 10:19:57 that may or may not be helpful Nov 06 10:19:57 <[florian]> which allows you to distinguish a sitecom device from an airlink one Nov 06 10:20:07 <[florian]> it is helpful to have per-chip quirks Nov 06 10:20:10 <[florian]> including mtd partitioning Nov 06 10:20:29 mtd partitioning is not necessarily per-chip Nov 06 10:20:56 such info needs empirical verification to be useful in the manner you intend Nov 06 10:21:41 and it will ultimately have only a minor impact on the code Nov 06 10:23:04 my current plan for rdc321x is this: (and i say rdc321x and not rdc because they use other cores in other series) Nov 06 10:23:28 1) get existing supported devices working correctly again Nov 06 10:23:46 2) add d-link support and things that go with it Nov 06 10:24:23 3) rewrite the ar525w flash mapping code to be maintainable, using physmap Nov 06 10:24:47 4) unfuck gpio for known devices Nov 06 10:26:44 <[florian]> 5) merge rdc as a subtarget of x86 Nov 06 10:27:37 of a lower priority would be reverse-engineering the zyxel and amit firmware generation tools which must currently be manually inserted as binaries into the staging dir Nov 06 10:29:50 <[florian]> sn9: sounds like a good plan to me Nov 06 10:30:13 also, somewhere in there would be merging the dev-board specific files Nov 06 10:31:23 sysupgrade procedures should also be developed separately for each device Nov 06 10:31:33 <[florian]> yes Nov 06 10:32:01 most of them will involve reading existing flash and patching it Nov 06 10:33:47 and i don't think we ever got an explanation for yenta_mystery Nov 06 10:37:51 [florian]: so, can you please delete target/linux/rdc/patches-2.6.30/003-rootfstype.patch and commit http://openwrt.pastebin.com/f42adb9dd? Nov 06 10:53:17 florian * r18327 /trunk/target/linux/rdc/ (3 files in 3 dirs): [rdc] provide the correct flash mapping on non airlink devices, remove the rootfs_type hacks, patch from sn9 Nov 06 10:54:30 ty Nov 06 10:55:31 <[florian]> yw Nov 06 16:03:45 ping @devs Nov 06 16:03:54 I'll take the wiki down in a minute Nov 06 16:04:09 I expect not a too long downtime (10-60mins max) Nov 06 16:04:31 reason: gotta move to another machine, as both (!) harddrives on the actual machine are failing! Nov 06 16:04:41 excuse the inconvenience Nov 06 16:05:02 shore Nov 06 16:05:18 ping Kaloz Nov 06 16:06:09 Kaloz: as soon as the new machine is up, I ping ya so you can change the dns. meanwhile I'll then forward all traffic from the old to the new machine. Nov 06 16:06:36 new ip will be: 188.40.166.25 Nov 06 17:38:20 xMff: did you find any problems with opkg, or was it just something I've broken and haven't found? Nov 06 17:39:23 I couldn't find any obvious problem yet Nov 06 17:40:26 ok, I will have to look at it more later Nov 06 18:19:44 can someone please take a look at CONFIG_INITRAMFS_SOURCE in target/linux/au1000/au1550/config-default and tell me the point of that? thx Nov 06 18:20:45 same with target/linux/pxcab/config-2.6.30 Nov 06 18:30:19 [florian]: necessary for .30 to boot on amit: http://openwrt.pastebin.com/f7e9a0641 Nov 06 18:30:34 note the deleted files Nov 06 18:55:31 ping blogic Nov 06 19:37:26 i guess it's friday night in europe... Nov 06 19:41:06 it's not Nov 06 19:41:40 8:41pm, no? Nov 06 19:42:33 thats late afternoon ;) Nov 06 19:50:28 yes but we're all pandemic, so everyone is getting ready to go to bed Nov 06 19:50:44 are we? Nov 06 19:51:49 wiki.openwrt.org is back Nov 06 19:54:01 apparently so Nov 06 19:54:05 ONE PERSON ALREADY DIED Nov 06 19:54:23 :-o Nov 06 23:53:12 can someone please take a look at CONFIG_INITRAMFS_SOURCE in target/linux/au1000/au1550/config-default and tell me the point of that? same with target/linux/pxcab/config-2.6.30; thx Nov 07 00:03:21 xMff: Nov 07 00:03:23 Updating feed 'luci' from 'http://svn2.luci.freifunk-halle.net/luci/branches/luci-0.9/contrib/package' ... Nov 07 00:03:24 svn: No such revision 5504 Nov 07 00:09:55 jow * r18328 /trunk/feeds.conf.default: [feeds] switch back to LuCI main repo Nov 07 00:14:00 xMff: while you're at it, most of the warnings on make menuconfig are trivial Nov 07 00:21:45 there will be some bigger reorganizing tomorrow, will nuke off obsolete stuff then Nov 07 00:22:53 i'm still wondering about that CONFIG_INITRAMFS_SOURCE junk Nov 07 00:24:43 don't know about that Nov 07 00:26:42 and http://openwrt.pastebin.com/f7e9a0641 is still waiting for [florian] to commit Nov 07 00:27:14 xMff: hows the rewrite coming ? still a work in progress? Nov 07 00:27:41 rogue_: pretty much, yeah. **** ENDING LOGGING AT Sat Nov 07 02:59:57 2009