**** BEGIN LOGGING AT Sun Apr 15 02:59:56 2007 Apr 15 03:20:52 nope -- still broken Apr 15 04:01:49 ejka * r6948 /trunk/target/linux/ar7-2.6/ (config/default files/drivers/mtd/ar7part.c): Apr 15 04:01:49 ar7: improve search for image start (thanks matteo), add support for avm eva Apr 15 04:01:49 image format (thanks unverbraucht, #1566), support jffs2 images. Apr 15 04:25:45 r6445 still builds, r6945 does not, r6700 does not, r6600 does not (tried on two hosts), r6500 builds ok. always failing in toolchain/gcc-install if it fails -- build platform centos/rhel-4.4.2. currently trying to find out where between 6500 and 6600 the break starts Apr 15 07:22:13 nbd * r6949 /trunk/package/base-files/files/sbin/ifdown: fix bogus "interface not found" errors in ifup -a (#1580) Apr 15 07:23:29 nbd * r6950 /trunk/package/base-files/files/sbin/ifdown: fix ifdown hotplug event (#1576) Apr 15 09:53:05 nbd * r6951 /trunk/target/imagebuilder/files/Makefile: export the IMAGEBUILDER variable so that makefiles can test for the image builder run Apr 15 13:55:16 florian * r6952 /trunk/target/linux/brcm63xx-2.6/files/drivers/mtd/maps/bcm963xx-flash.c: Restore the old flash mapping, no brcm63xx has the HDR0 header Apr 15 14:08:01 florian * r6953 /packages/net/ctorrent/Makefile: Update ctorrent to dnh3 (#1587) Apr 15 14:10:40 florian * r6954 /trunk/target/linux/brcm-2.4/profiles/WL500GP.mk: Add kmod-usb-uhci instead of ohci as defaults for WL500GP (#1589) Apr 15 14:47:41 florian * r6955 /trunk/ (3 files in 3 dirs): Build usbnet modules for brcm targets (#1481) Apr 15 18:28:26 nbd * r6956 /trunk/include/ (depends.mk host-build.mk package-ipkg.mk package.mk): clean up dependency handling for autorebuilds Apr 15 19:08:56 florian * r6957 /packages/utils/scponly/ (. Makefile): Add scponly (#1581) Apr 15 19:44:16 florian * r6958 /trunk/package/broadcom-diag/src/diag.c: Fix reverse polarity on WGT634U (was : green while booting, amber when ready) Apr 15 19:53:07 [florian]: are you able to test a build yet? Apr 15 19:55:42 <[florian]> sn9: yep, I will have a rdc test in few minutes Apr 15 19:56:31 [florian]: uudecode this, then apply to current svn: http://pastebin.ca/441629 Apr 15 19:56:59 after that, build away Apr 15 19:57:26 do not tftp flash the standard way Apr 15 19:58:03 there is an alternate procedure necessary temporarily to overcome the bootloader kernel size limitation Apr 15 19:58:10 <[florian]> ok Apr 15 19:58:30 tell me when the images are built Apr 15 19:59:09 you will get a build error if you don't apply the patch in the pastebin Apr 15 19:59:55 the pastebin will expire 45 min after i posted it Apr 15 20:00:07 <[florian]> I have downloaded it, thanks Apr 15 20:01:50 <[florian]> might take some minutes to recompile the toolchain Apr 15 20:02:01 you had it on 2.4? Apr 15 20:02:42 <[florian]> I made few distcleans between our last talk :p Apr 15 20:03:07 same thing; you need to distclean between 2.4 and 2.6 builds Apr 15 20:03:32 <[florian]> yes, not the same gcc version/ kernel headers Apr 15 20:06:11 <[florian]> ca me va Apr 15 20:06:33 that quick? Apr 15 20:07:07 <[florian]> oh sorry, wrong window Apr 15 20:09:05 while waiting for the build, there are couple of steps to prepare Apr 15 20:10:05 put the ethernet interface to which the device is physically connected on 192.168.1.2 Apr 15 20:10:28 start up a tftp _server_ on that machine Apr 15 20:18:30 <[florian]> is that a hardcoded address ? Apr 15 20:18:46 no Apr 15 20:19:01 but you will refer to it in subsequent steps Apr 15 20:19:06 <[florian]> ok Apr 15 20:19:11 it must be on that subnet, though Apr 15 20:19:33 bootloader needs it Apr 15 20:19:54 well, not really, but it will simplify matters Apr 15 20:41:24 <[florian]> by the way, I will test the lzma target for x86 Apr 15 20:41:53 one thing at a time Apr 15 20:42:50 <[florian]> I did not say right now :) Apr 15 21:11:40 [florian]: how far along is the build? Apr 15 21:12:19 <[florian]> sn9: done, just figured out I could not test, forgot my serial adapter, hummr, somewere :/ Apr 15 21:12:34 [florian]: i forgot something anyway Apr 15 21:13:07 <[florian]> this is bad, because it was in a box I needed :( Apr 15 21:13:55 <[florian]> let's solder one Apr 15 21:14:45 <[florian]> and take another tea Apr 15 21:22:13 <[florian]> ok, built the serial adapter Apr 15 21:22:18 <[florian]> sn9: what's next ? Apr 15 21:22:28 well: Apr 15 21:22:34 make target/clean Apr 15 21:22:44 svn revert -R target/linux/rdc-2.6/ Apr 15 21:23:12 <[florian]> what changeset would you like to revert ? Apr 15 21:23:24 the latest big.patch Apr 15 21:23:42 make it the same as the trunk in svn Apr 15 21:23:45 then: Apr 15 21:23:51 wget http://pastebin.ca/raw/441794 Apr 15 21:24:05 patch -p0 < 441794 Apr 15 21:24:09 make Apr 15 21:24:25 oops Apr 15 21:24:33 forgot the uudecode Apr 15 21:26:19 <[florian]> it seems to be the same patch as before ? Apr 15 21:26:29 except one line Apr 15 21:26:33 <[florian]> ah no, there is one line more :) Apr 15 21:26:47 not more, just different Apr 15 21:28:44 <[florian]> is this kernel configuration supposed to work ? it does not output anything here Apr 15 21:29:07 "output" ? what did you mean by that? Apr 15 21:29:47 you flashed it the standard way? Apr 15 21:29:48 <[florian]> the serial console does not show anything Apr 15 21:29:59 <[florian]> yes, I flashed it using the embedded tftp server Apr 15 21:30:09 [12:57:24] sn9 do not tftp flash the standard way Apr 15 21:30:09 [12:58:00] sn9 there is an alternate procedure necessary temporarily to overcome the bootloader kernel size limitation Apr 15 21:30:38 <[florian]> can you detail me this procedure ? Apr 15 21:30:45 yes, step by step Apr 15 21:31:13 first, is the physically connected eth interface on 192.168.1.2? Apr 15 21:31:27 <[florian]> absolutely Apr 15 21:31:45 is it running a tftp _server_? Apr 15 21:32:16 <[florian]> it is Apr 15 21:32:41 put the squashfs image in the root of the tftproot Apr 15 21:33:29 make sure it's accessible to a 127.0.0.1 client without a path Apr 15 21:34:02 use ctrl-C in the serial console during power up to get a redboot prompt Apr 15 21:34:21 type three commands: Apr 15 21:34:31 the first command is: Apr 15 21:35:09 load -r -v -h 192.168.1.2 -b 0x400000 openwrt-rdc-2.6-squashfs-ar525w.img Apr 15 21:36:16 make a note of the "raw file loaded" line it outputs Apr 15 21:36:53 transform the second hex address in it like so: Apr 15 21:37:32 change the leading "0x005" to "001" Apr 15 21:38:30 then put that address into the second command, like so: (assuming the address was 0x0057fc8a) Apr 15 21:38:48 dflash -l 0017fc8a Apr 15 21:39:03 the third command is: Apr 15 21:39:21 linux -c "console=ttyS0,38400 root=/dev/mtdblock1 noinitrd" Apr 15 21:39:32 nbd * r6959 /trunk/include/kernel-build.mk: remove reference to unused .kernel.mk Apr 15 21:40:06 all of these steps are necessary on every boot for the moment Apr 15 21:40:51 [florian]: got it? Apr 15 21:42:01 <[florian]> sn9: ok, I will tell you Apr 15 21:42:29 <[florian]> sn9: you could have told me to count the size of the file loaded, I would have understood ;) Apr 15 21:43:04 yes, but it must be formatted as an eight-digit hex value Apr 15 21:43:19 <[florian]> that is probably what the tftp server does more or less, don't you think so ? Apr 15 21:43:26 this is a very convenient way of determining that quickly Apr 15 21:43:57 no, the embedded server has a maximum size for the file Apr 15 21:44:11 <[florian]> ah, nice job, it works fine Apr 15 21:44:32 <[florian]> it still does not want to mount the rootfs, but that is another thing Apr 15 21:45:37 then you were not working off a fresh svn checkout, because the root mounts just fine; the latest problem occurred after it passed that stage Apr 15 21:46:52 this is the squashfs image, right? Apr 15 21:48:21 <[florian]> this is a squashfs image yes Apr 15 21:48:32 <[florian]> it just hangs after freeing kernel memory Apr 15 21:52:27 something is different about your setup; maybe the .config? Apr 15 21:54:32 <[florian]> I do not know Apr 15 21:57:47 my .confing: http://pastebin.ca/raw/441864 Apr 15 21:58:18 diff it against your own Apr 15 21:58:31 <[florian]> why do you use bas64 encoding ? you are on low bandwitdh connection ? Apr 15 21:58:48 to preserve whitespace Apr 15 21:59:15 otherwise the patch command may balk Apr 15 21:59:45 or in this case, the configure script Apr 15 22:03:42 <[florian]> there is absolutely no config difference Apr 15 22:04:01 <[florian]> so the only working explanation is some martians just broke the image while I was downloading it Apr 15 22:04:21 or the repository Apr 15 22:05:13 <[florian]> you use svn r6958, like me Apr 15 22:07:25 wait, is freeing kernel memory the last line you see? Apr 15 22:07:36 or do you see a warning after that? Apr 15 22:08:15 <[florian]> I see the warning, cannot open initial console Apr 15 22:08:36 ah, so you do get the same Apr 15 22:09:21 what is the line immediately prior to freeing kernel memory? Apr 15 22:09:44 <[florian]> VFS: Mounted root (squashfs filesystem) readonly. Apr 15 22:09:44 <[florian]> Freeing unused kernel memory: 120k freed Apr 15 22:09:45 <[florian]> Warning: unable to open an initial console. Apr 15 22:10:10 you said it did not mount, and here it states it did Apr 15 22:10:57 i can't think why it can't open /dev/console if /init is run first Apr 15 22:11:25 i'm gonna ask an additional tester to join the channel Apr 15 22:11:45 [florian]: that damn warning is there, and it's just a warning Apr 15 22:11:50 hey all. Apr 15 22:12:23 [florian]: feel free to yell at anyone and direct him to google :P Apr 15 22:12:57 i think the warning is indicative of a bigger problem, and once it's taken care of, the boot will go further Apr 15 22:13:18 rotfl Apr 15 22:13:45 Kaloz: i was going by the source in init/main.c in the kernel tree Apr 15 22:14:04 that warning is harmless, it's there on every device and if you want to look into the "issue" then google will help if you search for 2.6 and this message Apr 15 22:14:42 then where could the hang be? Apr 15 22:15:37 about 1000 different places Apr 15 22:16:05 you can add echos to the bootscripts and find where does it stop Apr 15 22:16:05 it maybe on every other device, but i did things a bit differently on this one, and that seems to be blowing up Apr 15 22:16:25 assuming it even gets to the bootscripts Apr 15 22:17:17 Collecting package info: package/bzip2find: /home/jan/buildroot/brcm/build_mipsel: No such file or directory Apr 15 22:17:32 same thing for clinkcfind and libbfdfind Apr 15 22:17:40 [florian]: you've seen some of what i did. anything jump out as obviously causing a problem? Apr 15 22:23:29 Sargun, [florian]: try turning off CONFIG_BUSYBOX_CONFIG_FEATURE_DEVFS and see whether it makes a difference Apr 15 22:26:51 ok Apr 15 22:27:12 [florian], you have serial to your airlink too? Apr 15 22:27:19 he does Apr 15 22:27:23 Cool. Apr 15 22:27:29 sn9, Did you ever get serial? Apr 15 22:28:16 Sargun: i told you last night how i last left mine -- it's still in the trunk of the car, needing that flux cleanup Apr 15 22:28:33 flashing. Apr 15 22:28:39 still... Apr 15 22:28:41 :-( Apr 15 22:29:20 flashing Apr 15 22:29:20 Sargun: you're sure it rebuilt busybox after that .config change? Apr 15 22:30:02 Now it takes a crap. Apr 15 22:30:18 empty_blocks 0, bad_blocks 0, c->nr_blocks 11 Apr 15 22:30:18 VFS: Cannot open root device "mtdblock1" or unknown-block(31,1) Apr 15 22:30:18 Please append a correct "root=" boot option Apr 15 22:30:18 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1) Apr 15 22:30:18 something different? Apr 15 22:30:38 oh, right Apr 15 22:30:52 i forgot about that Apr 15 22:31:21 that was the whole reason for the initramfs i got rid of Apr 15 22:31:27 its doing it. Apr 15 22:31:32 haha Apr 15 22:31:48 rebuilding the -entire thing- Apr 15 22:31:54 I accidentally make cleaned in the wrong dir Apr 15 22:31:55 :-( Apr 15 22:38:38 comgt Apr 15 22:39:05 sn9, BTW: I found it was a label she sharpie was on Apr 15 22:39:20 like a paint-coated foil label Apr 15 22:39:35 slightly off-topic Apr 15 22:40:12 and underneath it, its just a v02 Apr 15 22:40:14 same board. Apr 15 22:40:30 so the layout isn't different? Apr 15 22:40:35 I don't think so. Apr 15 22:41:15 means little, since the picture on the mhos site has some components that are unpopulated on mine Apr 15 22:41:43 mostly capacitors Apr 15 22:41:52 but resistors, too Apr 15 22:43:38 loading new firmware. Apr 15 22:43:42 let's try this Apr 15 22:44:13 ff is even, right? Apr 15 22:44:18 odd Apr 15 22:44:22 gah. Apr 15 22:44:26 Gotta change that Apr 15 22:44:27 well Apr 15 22:44:47 <[mbm]> ff = 255 Apr 15 22:44:54 I thought it was 256 Apr 15 22:45:11 <[mbm]> nope. that'd be 0x100 Apr 15 22:45:29 actually, it will round up for you; i said to round up just to avoid the annoying announcement that it's rounding up for you Apr 15 22:45:59 oh, cool. Apr 15 22:46:18 <[mbm]> (to confuse things more, from 0-ff are 256 numbers -- including the zero) Apr 15 22:50:46 Sargun: still no worky? Apr 15 22:51:44 no, it tries to read it as a JFFS2 file system now Apr 15 22:51:49 when I disable udev Apr 15 22:51:50 er Apr 15 22:51:51 devfs Apr 15 22:52:02 that's odd Apr 15 22:52:14 pastebin the whole bootlog Apr 15 22:55:40 http://pastebin.ca/441946 Apr 15 22:57:09 <[mbm]> should specify a rootfstype on the kernel commandline Apr 15 22:57:33 <[mbm]> looks like it attempted squashfs and then fell back to jffs2 Apr 15 22:57:35 [mbm]: that's taken care of with a kernel patch Apr 15 22:57:51 this is a squashfs image Apr 15 22:58:28 <[mbm]> hmm Apr 15 22:58:30 the question is why it failed squashfs this time Apr 15 22:58:56 <[mbm]> mtd map failed to line up the start of the partition with the actual start of squashfs? Apr 15 22:59:51 unlikely, since i synched the code that generates the start of the partition with the code that detects it Apr 15 23:00:10 <[mbm]> truncated? Apr 15 23:00:28 apparently, but i can't think why Apr 15 23:00:54 unless... Apr 15 23:00:59 <[mbm]> actually it is truncated, it even says so on 72 Apr 15 23:01:09 <[mbm]> # Apr 15 23:01:09 <[mbm]> attempt to access beyond end of device Apr 15 23:01:09 <[mbm]> # Apr 15 23:01:10 <[mbm]> mtdblock1: rw=0, want=1460, limit=1458 Apr 15 23:01:28 Sargun: what was the last dflash line you used? Apr 15 23:03:07 <[mbm]> you're off by 2 there which exactly the block size used by squashfs on the following lines Apr 15 23:03:51 <[mbm]> tehre is a nopad option to squashfs Apr 15 23:04:12 for the mount, or the creation? Apr 15 23:04:33 <[mbm]> make sure that you didn't base the sizes on the non padded Apr 15 23:04:54 i padded to a 32-byte boundary Apr 15 23:05:05 <[mbm]> for the creation of squashfs Apr 15 23:05:46 I no longer have it Apr 15 23:05:48 the root.squashfs file's size is the non-padded? Apr 15 23:05:51 Let me try to reflash Apr 15 23:06:40 0x0057ff09 Apr 15 23:06:48 that's what its loaded to Apr 15 23:06:50 so Apr 15 23:06:51 that's Apr 15 23:06:56 0017ff10? Apr 15 23:07:03 yep Apr 15 23:07:10 nope\ Apr 15 23:07:13 hex Apr 15 23:07:16 oh Apr 15 23:07:21 I hate hex Apr 15 23:07:22 0017ff0a Apr 15 23:07:43 but it will do that for you Apr 15 23:07:46 <[mbm]> sn9: right, look at include/image.mk as it calls squashfs Apr 15 23:08:07 Ok, booting up Linux. Apr 15 23:08:15 Still tries to load the root as JFFS2 Apr 15 23:08:33 [mbm]: so, it tries to mount as padded? Apr 15 23:09:34 <[mbm]> sn9: in the image.mk it uses the -nopad option Apr 15 23:09:56 <[mbm]> this tell squashfs not to write out the 0 padding to the end of the squashfs image, padding it to the next block size Apr 15 23:10:32 <[mbm]> but you're still expected to have padding on the actual filesystem Apr 15 23:10:52 the next squash block size? Apr 15 23:11:33 <[mbm]> actual filesystem should be a multiple of 4k Apr 15 23:12:42 why does it need that much padding for read-only data? Apr 15 23:12:49 <[mbm]> think there's a note somewhere about it in the squashfs docs Apr 15 23:13:11 <[mbm]> *shrug* I didn't write it Apr 15 23:13:27 the start of the squashfs isn't even aligned on 4k Apr 15 23:13:36 <[mbm]> that's fine Apr 15 23:13:55 <[mbm]> I'm just telling you that the end is truncated Apr 15 23:13:58 i will look at the stock firmware makefile to see what they did Apr 15 23:14:44 mksquashfs romfs images/romfs.sqsh -le -all-root Apr 15 23:17:06 looks like the easiest way to fix this is to get rid of the -nopad for this target Apr 15 23:18:15 <[mbm]> think we padded it so the length was a multiple of 1k Apr 15 23:18:51 how much does the mount code really expect? Apr 15 23:18:54 <[mbm]> should be somewhere in the image/Makefiles Apr 15 23:22:39 <[mbm]> been too long since I've looked at that level of the code Apr 15 23:22:54 back! Apr 15 23:24:31 trxalign is defined, but apparently never used for squash Apr 15 23:24:41 so there is no padding at all Apr 15 23:29:56 <[mbm]> looks like for the broadcom platforms we aligned the start to 1k and then aligned the total firmware image to an mtd block size Apr 15 23:33:39 i align the start to 32 bytes, then align the total to erase block size Apr 16 01:42:28 [florian], Sargun: up for another test? Apr 16 01:46:31 hey Apr 16 01:46:34 Not right now Apr 16 01:46:36 Doing home work. Apr 16 01:47:21 i have stuff to do right now, too, but i've already built images **** ENDING LOGGING AT Mon Apr 16 02:59:57 2007