**** BEGIN LOGGING AT Fri Mar 30 02:59:56 2007 Mar 30 05:32:01 <[florian]> sn9_: looks like an old snapshot, I will post a recent and working this morning Mar 30 05:32:48 i already fixed it: http://homepage.mac.com/danielg4/rdc-2.4.tar.bz2 Mar 30 05:33:46 also contains a fixed kernel config -- buildroot didn't like yours Mar 30 05:35:00 make world completed just seconds ago -- wish me luck! Mar 30 05:40:05 [florian]: router flashed and ready for reboot... Mar 30 05:44:12 not good -- kernel did not see a flash device Mar 30 05:52:14 wtf??? now the patch i removed is needed! Mar 30 05:57:39 put the patch back in, and it won't build again Mar 30 06:04:28 oh, i see Mar 30 06:04:47 i think i fixed it now, will try again Mar 30 07:20:55 [florian]: redownload that url now. it should be a working target Mar 30 07:22:57 hcg * r6761 /trunk/target/linux/at91-2.6/ (config/default patches/005-activity-led.patch): Moved activity led to correct IO ports Mar 30 07:29:08 nico * r6762 /packages/libs/avahi/ (Makefile files/avahi-daemon.conf): update avahi to 0.6.17, fix dependencies on libexpat & libpthread, remove "enable-dbus" from config file since dbus is disabled (closes: #1534) Mar 30 08:24:56 [florian]: problem: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0xa82b instead Mar 30 08:25:11 tons of messages like that Mar 30 10:03:01 [florian]: hello? Mar 30 10:23:19 mbm * r6763 /trunk/target/sdk/files/package/rules.mk: Remove extra - Mar 30 12:50:19 sn9_: that jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0xa82b instead (does it scroll all down the screen ?) I have had it on 2 different platforms don't know why Mar 30 12:54:21 that looks like the opposite endianness Mar 30 12:57:56 <[mbm]> at 0x0? with an error like that I question if the jffs2 partition is in the wrong pace Mar 30 12:58:34 <[mbm]> shouldn't have a jffs2 error at the start of the jffs2 partition Mar 30 14:30:59 <[florian]> sn9_: yeah, I am here Mar 30 14:47:43 h3sp4wn, [mbm], [florian]: the guy who originally got me interested in this platform gave up months ago when he encountered something similar when trying to rebuild the stock firmware as an exercise. i rebuilt that with no problems, so i'm sure this can be overcome Mar 30 14:48:57 btw, this error is the same whether i use a jffs2 image or a squashfs image Mar 30 14:56:57 h3sp4wn, [mbm]: [florian] probably already knows this, but this flash map has fixed, hard-coded boundaries for mtdblocks 0, 2, 3, and 4. mtdblock 1 overlaps the latter part of mtdblock 0, beginning at an arbitrary offset that is calculated on the fly -- so having that partition in the wrong place is to be expected Mar 30 14:59:48 <[mbm]> not sure what platform you're using but we overlap the mtdblocks on pretty much all of them] Mar 30 15:00:18 rdc (airlink ar525w) Mar 30 15:00:52 <[mbm]> eg. [cfe][linux [kernel] [squashfs] [jffs]] [nvram] Mar 30 15:01:15 since [florian] said on the wiki that 2.4 works fine, i figured i'd try that first Mar 30 15:01:32 it's not fine yet Mar 30 15:02:49 mind if i paste what the kernel found in mtdblocks, one per line? Mar 30 15:03:22 seems too little for a pastebin Mar 30 15:05:57 in the absence of objections, i shall paste in about 60 seconds Mar 30 15:06:42 <[mbm]> just pastebin it Mar 30 15:07:16 well, if i pastebin, i might as well pastebin the whole boot log Mar 30 15:09:11 hmm, pastebin.ca is down Mar 30 15:10:06 odd, www.pastebin.ca instead works Mar 30 15:12:31 http://www.pastebin.ca/416863 Mar 30 15:13:20 lines 51-55 are what i was gonna paste in-channel Mar 30 15:15:05 <[mbm]> nothing odd about that map Mar 30 15:15:34 except that mtdblock1 begins at a nice, round offset Mar 30 15:15:47 i don't think that should be Mar 30 15:16:20 <[mbm]> you mean romfs? Mar 30 15:17:06 yes, the root filesystem, which is presumably where any jffs2 would be Mar 30 15:17:51 <[mbm]> writable filesystems on an mtd have to be aligned to a multiple of the eraseblock size on that device, otherwise the partition gets marked as readonly Mar 30 15:20:23 <[mbm]> not sure what you have on your mtd, but its odd that it seems to be in 0x24 chunks Mar 30 15:20:28 <[florian]> sn9_: I am aware of the checksum stuff Mar 30 15:20:37 um, would "that device" refer to mtdblock0 or mtdblock1 here? Mar 30 15:21:10 <[florian]> sn9_: the kernel command line cannot be changed in the redboot Mar 30 15:21:13 <[mbm]> the erase block size is global across the flash chip Mar 30 15:21:20 [florian]: noted; dealing with an unrelated issue here Mar 30 15:21:36 <[florian]> sn9_: for now, yes Mar 30 15:21:37 [mbm]: but alignment isn't Mar 30 15:22:36 the eraseblock size is 64k, btw Mar 30 15:23:17 <[florian]> sn9_: with 64k it should work, that is what I tested here Mar 30 15:23:36 <[mbm]> sn9_: yes, but you have the kernel before that Mar 30 15:24:10 [mbm]: that's what i mean Mar 30 15:24:10 <[mbm]> so it needs to be the next 64k multiple after the end of the kernel Mar 30 15:24:28 doesn't mean it is Mar 30 15:25:37 <[mbm]> 0xc0000 gives you 768k for the kernel Mar 30 15:26:11 which may be more than the image actually gives it Mar 30 15:26:42 <[mbm]> doesn't matter if you give the kernel more than it actually uses Mar 30 15:26:58 <[mbm]> what you want to avoid is overwriting the end of the kernel with jffs data Mar 30 15:27:18 this is all with a squashfs image, btw Mar 30 15:28:05 <[mbm]> hmm.. that really should be specified on the commandline as rootfstype Mar 30 15:28:17 * [mbm] pokes [florian] Mar 30 15:28:23 <[florian]> is here Mar 30 15:28:31 <[florian]> I did not meet this problem with my ar525w Mar 30 15:28:37 <[florian]> sn9_: which device do you use ? Mar 30 15:28:55 that would involve recompiling redboot, which has no available source afaict Mar 30 15:29:03 [florian]: ar525w Mar 30 15:29:08 <[florian]> sn9_: ok, so same as me Mar 30 15:29:14 <[mbm]> sn9_: no, it means the openwrt kernel doesn't specify rootfstype Mar 30 15:29:25 <[mbm]> which is why I poked florian Mar 30 15:29:40 <[florian]> [mbm]: how do you force the command line on i386 ? Mar 30 15:29:52 Kernel command line: console=ttyS0,38400 root=/dev/mtdblock1 noinitrd Mar 30 15:29:56 <[mbm]> seems to me it was hardcoded into the kernel Mar 30 15:30:14 that line is hardcoded into redboot Mar 30 15:30:16 <[mbm]> right, that's missing a rootfstype=squashfs Mar 30 15:30:31 <[mbm]> it seems to be trying to mount it as jffs Mar 30 15:31:10 identical results with a jffs2 image, btw Mar 30 15:31:27 <[mbm]> did you actually load the root onto flash> Mar 30 15:31:28 <[florian]> yes, the kernel command line is hardcoded in redboot Mar 30 15:31:28 <[mbm]> ? Mar 30 15:31:35 it's just that the pastebin happens to be from the squashfs results Mar 30 15:31:39 <[florian]> [mbm]: yes it is mandatory with this redboot Mar 30 15:32:04 <[florian]> [mbm]: you flash the device with a new firmware, it closes the tftpd, then boot on the newly installed kernel Mar 30 15:32:07 <[mbm]> [florian]: kernel can always be programmed to ignore/override the commandline Mar 30 15:32:26 <[florian]> [mbm]: I tried with a 2.6, not a with a 2.4 Mar 30 15:32:47 <[mbm]> hmm Mar 30 15:32:52 <[mbm]> why 2.4 anyways? Mar 30 15:32:56 * sn9_ hits himself in the forehead, and assumes [florian] does same Mar 30 15:33:13 [mbm]: because [florian] said it works fine Mar 30 15:33:17 sn9_: how are you booting the kernel in redboot? Mar 30 15:33:22 <[florian]> [mbm]: because I knew it working Mar 30 15:33:24 sn9_: go or exec? Mar 30 15:33:34 <[florian]> malbon: don't know, it is a modified redboot Mar 30 15:33:39 malbon: actually, i just use "reset" Mar 30 15:33:54 <[florian]> malbon: which triggers a tftpd if the checksum on the flash is wrong Mar 30 15:34:01 <[mbm]> reset will run fconfig Mar 30 15:34:11 <[mbm]> well, boot script from fconfig Mar 30 15:34:19 <[florian]> [mbm]: if you can reacht the fconfig command, which has been disabled Mar 30 15:34:23 yes exactly. Mar 30 15:34:55 [florian]: is it the same on an edimax? Mar 30 15:35:13 <[florian]> malbon: I do not know, we can compare command and version / timestamps (if any) Mar 30 15:35:50 well you should be able to do a 'fis load linux' or whatever your linux kernel partition is called Mar 30 15:35:51 i have the edimax source tarball; will check it for redboot Mar 30 15:36:09 <[florian]> malbon: they disabled all fis * commands as well Mar 30 15:36:10 and then an 'exec -c ' to set the command line. Mar 30 15:36:15 malbon: no "fis" command here Mar 30 15:36:17 <[florian]> malbon: it is damn modified Mar 30 15:36:28 then how does it load the kernel? Mar 30 15:36:35 sounds broken. Mar 30 15:36:42 <[florian]> using internal crappy stuff Mar 30 15:39:20 <[florian]> sn9_: rebuilding the rdc-2.4 port right now Mar 30 15:41:12 [florian]: you will need my modified target; did you download it after 0720 UTC? Mar 30 15:41:29 <[florian]> sn9_: I do not need your modified target yet, thanks, I will forward port changes Mar 30 15:41:48 <[florian]> sn9_: unless you changed things in the image/Makefile ? Mar 30 15:42:02 i changed the kernel config Mar 30 15:42:17 and the flash map patch Mar 30 15:42:39 <[florian]> sn9_: ok Mar 30 15:47:36 no redboot in the edimax source tarball -- only in airlink Mar 30 15:47:59 and both have binary-only checksum tools Mar 30 15:50:17 <[florian]> sn9_: there are redboot sources in linksys wrt54gr tarball Mar 30 15:50:30 not applicable Mar 30 15:50:48 <[florian]> why ? Mar 30 15:50:53 unless it is the same modified version Mar 30 15:51:02 <[florian]> I do not know Mar 30 15:51:10 i will take a look Mar 30 15:53:04 this? ftp://ftp.linksys.com/opensourcecode/wrt54gr/ecos_WRT54GR/ecos_WRT54GR_RedbootSRC_GPL.zip Mar 30 15:54:02 32MB -- wow Mar 30 16:02:51 heh, it's a tgz inside a zip Mar 30 16:48:46 you're not gonna believe this, but the redboot image in the airlink source tarball is very different from what airlink really used; however, the one in the linksys tarball is identical to what they used Mar 30 16:49:21 leave it to linksys to provide airlink's sources for them Mar 30 17:01:46 [08:30:45] [mbm] did you actually load the root onto flash> Mar 30 17:02:11 isn't it part of the image? Mar 30 17:16:05 [mbm], [florian]: the thing is that the kernel is looking for mtdblock1 to begin at 000c0000, while the openwrt image generator puts it at 000b0000, and the gemtek one does not even give it a 64k alignment Mar 30 17:25:33 oh, i see: [florian] mangled the rdc3210.c file, in both 2.4 and 2.6 Mar 30 17:35:09 [florian]: if i give you a better rdc3210.c, would you replace the one in the 2.6 svn with it, and the 2.4 target you have also? Mar 30 17:57:08 malbon: (or anybody: ) so that i do this right, how does buswidth generally relate to eraseblock size? Mar 30 17:57:55 sn9_: it doesn't Mar 30 17:58:26 hmm. then where in the flash map driver is eraseblock size defined? Mar 30 18:01:00 nowhere Mar 30 18:01:28 then where does "cat /proc/mtd" get the info? Mar 30 18:02:30 the eraseblock size is detected by the flash chip driver Mar 30 18:03:09 ok. is that in a data structure accessible in the flash map driver? Mar 30 18:03:50 yes Mar 30 18:03:57 mtd->erasesize Mar 30 18:04:57 what is the struct name? Mar 30 18:05:32 let me check Mar 30 18:05:42 thanx Mar 30 18:05:58 struct mtd_info Mar 30 18:06:13 ok, and the value is in bytes, right? Mar 30 18:06:18 yep Mar 30 18:06:25 awsome Mar 30 18:06:35 *awesome Mar 30 18:06:40 there are quite a few flash map drivers that you can use as reference Mar 30 18:06:53 btw. if the rdc thing uses redboot, you don't have to write your own flash map driver Mar 30 18:07:07 just use physmap and let it detect the redboot partition table through the generic code Mar 30 18:10:40 it already has its own flash map driver. i'm gonna make that driver better, since [florian] made it slightly worse Mar 30 18:11:50 don't spend too much time on the 2.4 port, btw. Mar 30 18:12:01 we don't want to add new 2.4 based targets in openwrt Mar 30 18:12:13 since it's a dead end anyway Mar 30 18:12:20 <[florian]> sn9_: thanks Mar 30 18:12:41 <[florian]> sn9_: actually the patch is not from me, but try driving the flash with cfi commands, and you will see Mar 30 18:12:41 nbd: this driver will be for both 2.4 and 2.6 Mar 30 18:13:38 [florian]: you weren't the one who messed with the "#if 0" stuff? Mar 30 18:14:14 sn9_: but if the device uses redboot, we don't need a separate flash map driver, since the kernel already has support for parsing redboot partitions Mar 30 18:15:58 nbd: there are no fis commands in the rdc redboot -- look at the linksys tarball Mar 30 18:16:13 ah, ok Mar 30 18:16:20 so, yes, a separate flash map driver is necessary Mar 30 18:16:22 then a separate driver makes sense Mar 30 18:19:03 <[florian]> sn9_: actually, no, but do whatever you want you feel appropriate and will make a working rdc port soon :) Mar 30 18:20:58 <[florian]> nbd: unfortunately, last I tried with a 2.4 kernel, the flash would not accept being driven via cfi, but there might other things as well Mar 30 18:40:46 nbd, [florian]: is it safe to assume that the erasesize is an exponent of two, or am i gonna have to check for that? Mar 30 18:44:56 <[florian]> usually for 4Mb flash drives it is 64k, so yes, this is a power of 2 Mar 30 18:45:25 <[florian]> sn9_: but you should not have to check it Mar 30 18:46:48 so i can assume the value in mtd_info->erasesize will be a power of 2? Mar 30 18:51:44 is that in the spec for that struct member? Mar 30 18:55:05 <[mbm]> it should be, but I doubt that should be assumed Mar 30 18:55:42 <[mbm]> typically 64k or 128k Mar 30 18:57:18 ok, i won't make the code assume the value is a power of 2, then Mar 30 19:36:44 ok Mar 30 19:38:46 here is the new flash map driver: http://homepage.mac.com/danielg4/rdc3210.c Mar 30 19:39:30 here is the replacement image generator to match: http://homepage.mac.com/danielg4/airlink.c Mar 30 19:41:33 [florian]: can you commit both right now, or does something need to be tested first? Mar 30 19:57:19 oops, made a mistake in airlink.c -- corrected now Mar 30 20:18:05 i have now updated the rdc-2.4.tar.bz2 file; will now test Mar 30 20:36:18 * armijn pings random people Mar 30 20:38:48 * sn9_ is the only one who pongs Mar 30 20:39:24 I don't know if you want to be victim of my questions :P Mar 30 20:39:30 * random_people pings armijn Mar 30 20:39:48 ... Mar 30 20:39:57 that was...nerdy Mar 30 20:40:13 lol. yeah Mar 30 20:40:39 nbd: can I borrow you for a minute? Mar 30 20:40:43 who was that masked developer? Mar 30 20:40:48 armijn: sure Mar 30 20:40:59 sn9_: why does it have to be a developer? Mar 30 20:41:10 nbd: I'd like to know which tools are involved in the creation of a valid image for a wrt54g Mar 30 20:41:19 maybe because this is -devel Mar 30 20:41:29 nbd: so apart from the toolchain, uclibc Mar 30 20:41:50 firmware-utils/src/trx.c? Mar 30 20:41:53 trx and addheader Mar 30 20:41:59 those are the only ones? Mar 30 20:42:12 well, mksquashfs as well Mar 30 20:42:17 :) Mar 30 20:42:27 but other than that ... nothing, i think Mar 30 20:42:49 in OpenWrt? Mar 30 20:42:54 yeah Mar 30 20:43:13 call me stupid, but I can't find "addheader" :( Mar 30 20:43:41 sorry, addpattern Mar 30 20:43:45 addheader was something else Mar 30 20:43:49 heh, ok Mar 30 20:43:55 so can I call you stupid then? Mar 30 20:43:57 please? Mar 30 20:44:04 :P Mar 30 20:44:43 yeah Mar 30 20:44:52 * nbd is stupid Mar 30 20:45:07 oh, definitely! Mar 30 20:45:16 as long as you realise it, it is ok Mar 30 20:47:12 nbd: probably no use to just grab those C files and compile, right? Mar 30 20:47:43 if I would want to use it outside of the OpenWrt buildsystem Mar 30 20:48:01 what do you want to do? Mar 30 20:48:33 build a "hello world" firmware? Mar 30 20:48:40 something like that Mar 30 20:49:00 I'm also dissecting the build system to learn more Mar 30 20:49:28 read target/linux/brcm-2.4/image/Makefile Mar 30 20:49:31 to make up for my lack of a social life Mar 30 20:49:37 that shows you how to use these utils Mar 30 20:50:04 I was actually wondering a bit about the CFLAGS, especially endian.h Mar 30 20:50:20 is it necessary? Mar 30 20:50:37 to make it more portable, yes Mar 30 20:52:30 wow...there is so much board specific stuff in that Makefile Mar 30 20:52:37 you would suspect it would be more or less generic :S Mar 30 20:53:30 nah Mar 30 20:53:31 never Mar 30 20:53:32 :) Mar 30 20:56:07 still slightly confused Mar 30 20:56:49 but I guess I will have to read some GNU make docs for that first Mar 30 20:58:37 hehe, yeah, i abused make in weird ways Mar 30 20:59:34 define trxalign/squashfs Mar 30 20:59:34 -a 1024 Mar 30 20:59:35 endef Mar 30 20:59:39 what does that do?!? Mar 30 21:00:07 it burns! it burns! Mar 30 21:00:14 aaah! my eyes! Mar 30 21:00:16 :-P Mar 30 21:03:11 it is just kind of..weird Mar 30 21:17:37 ffs, the kernel now sees the squashfs in the right place, but still thinks it's jffs2 Mar 30 21:24:20 rdc3210.c and rdc-2.4.tar.bz2 updated one final time Mar 30 21:28:52 oh, crap Mar 30 21:49:14 <[florian]> sn9_: ok, great Mar 30 21:49:23 <[florian]> sn9_: I will commit the airlink fix Mar 30 21:49:27 wait Mar 30 21:49:38 <[florian]> ok, I will be off to bed now Mar 30 21:49:40 i just updated both files again, seconds ago Mar 30 21:49:49 download them again now Mar 30 21:50:03 <[florian]> ok Mar 30 21:50:40 commit the new rdc3210.c and the previously downloaded airlink.c Mar 30 21:51:51 florian * r6764 /trunk/tools/firmware-utils/src/airlink.c: airlink generation fix, thanks st9_ Mar 30 21:52:06 <[florian]> made a typo error with your nickname :( Mar 30 21:52:24 the "_" is because i'm logged in twice Mar 30 21:52:33 <[florian]> sn9_: for the flash map driver is it 2.6 compatible ? Mar 30 21:53:10 well, since you made no other modifications to the original to use in 2.6, i would assume so Mar 30 21:53:41 <[florian]> ok Mar 30 21:55:30 note that the new airlink.c is incompatible with your image/Makefile Mar 30 21:56:10 florian * r6765 /trunk/target/linux/rdc-2.6/ (10 files in 6 dirs): Split up drivers and specific files, update flash map driver Mar 30 21:56:18 <[florian]> sn9_: what needs to be changed ? Mar 30 21:56:53 comment out the execution of the generator for now Mar 30 21:57:49 florian * r6766 /trunk/target/linux/rdc-2.6/image/Makefile: Disable firmware creation for the moment Mar 30 21:59:40 <[florian]> off to bed, really Mar 30 21:59:53 <[florian]> thanks for your help, we can make things working better tomorrow Mar 30 22:00:10 not gonna wait for the recompile so i can see if it really worked? Mar 30 22:00:15 <[florian]> sn9_: last time I tried with 2.6 kernel, I add to disable some functions, because if not, the kernel was too big and did not output anything Mar 30 22:00:35 <[florian]> sn9_: I will wait few minutes, I hope you have a fast machine ;) Mar 30 22:01:17 unfortunately, the fast machines are not the ones i am doing this on, but it's almost done anyway Mar 30 22:12:25 ok, it's on the last step of the build process now Mar 30 22:20:05 finished Mar 30 22:21:40 hey Mar 30 22:24:01 no, seems i screwed up the flash map driver Mar 30 22:24:19 divide by zero Mar 30 22:24:53 back to the drawing board... Mar 30 22:26:01 to make things worse, the checksum does not match Mar 31 00:39:57 nbd * r6767 /trunk/package/dnsmasq/files/dnsmasq.init: allow dhcp sections for dnsmasq to add command line options Mar 31 00:59:51 nbd * r6768 /trunk/package/base-files/files/sbin/ (hotplug-call mount_root): /sbin/hotplug-call: export the hotplug event type through the environment for hotplug scripts Mar 31 01:19:47 nbd: i have fixed http://homepage.mac.com/danielg4/airlink.c and http://homepage.mac.com/danielg4/rdc3210.c again, hopefully right this time. can you please commit them, since you appear to be awake? Mar 31 01:20:03 sorry, i'm rather busy at the moment Mar 31 01:45:15 anybody else? Mar 31 02:07:07 sn9 * r6767 /trunk/target/linux/rdc-2.4/files/drivers/mtd/maps/rdc3210.c: fixed division by zero Mar 31 02:07:07 sn9 * r6768 /trunk/tools/firmware-utils/src/airlink.c: finally made the crc32 work, and fixed endianness, too Mar 31 02:07:07 ^^^^^^^^ one can always dream... Mar 31 02:08:46 oops, that should be rdc-2.6 **** ENDING LOGGING AT Sat Mar 31 02:59:56 2007