| 00:04.28 | rwhitby | RobNC: morning |
| 00:12.29 | RobNC | Hi, rwhitby. evening my time :-) |
| 00:12.37 | rwhitby | ~ugt |
| 00:12.38 | jbot | from memory, ugt is Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html |
| 00:12.59 | rwhitby | Did you try the latest slugimage? |
| 00:12.59 | RobNC | ah thanks! :-) didn't know that. |
| 00:13.15 | RobNC | after "make distclean; make slugosbe"? |
| 00:16.29 | rwhitby | RobNC: nm - I have now reproduced your problem locally. |
| 00:16.41 | RobNC | yes, the disassembly of the image via slugimage still says it's 16-bytes too large to re-assemble. However, if you could send me the RedBoot you got to work, I'll update the wiki and do diffs to compare yours versus the one on the wiki. It seems that mine is partially modified, enough to see the 16MB flash but not enough to look for sercomm trailer at end of flash perhaps. that's why I get the "not have eRcOmM" messa |
| 00:17.08 | RobNC | Sorry about that - was hoping it was something I was doing. |
| 00:17.38 | rwhitby | don't be sorry - finding bugs is a good thing |
| 00:17.50 | ka6sox-work | :D |
| 00:18.18 | RobNC | heh so it seems I am truly in the bleeding edge :-) |
| 00:20.16 | rwhitby | RobNC: 385d5a9b4263570885b83f13b3a904eb redboot.bin |
| 00:20.29 | RobNC | rwhitby: would it be easier to build a new redboot from sources than byte hack? Seems like RedBoot has to be built by makes from svn anyway, unless it's just some binary dump. |
| 00:21.27 | rwhitby | we don't build redboot in our build process, cause it requires the Intel proprietary microcode |
| 00:21.36 | rwhitby | that's why it's a binary modification |
| 00:22.24 | RobNC | Ah I thought that was only for NPE, didn't realize redboot wasn't built without a plugin-type module (ala nvidia and others) |
| 00:24.00 | RobNC | Not to stray too far off topic, but I believe the latest kernels have open-source version of IXP eth driver. Is it now possible to build redboot w/opensrc driver or even apex with opensrc driver? |
| 00:25.13 | rwhitby | both are possible - it just needs someone to do the work (which is not trivial) |
| 00:25.29 | RobNC | oh I see, can't even imagine. |
| 00:26.26 | rwhitby | BTW, we have a svn repo where we can build redboot (it's called sluggo), but we haven't tested it on a real device yet. |
| 00:27.56 | RobNC | With redboot-16MB.bin I'll xdiff and update wiki. |
| 00:29.19 | RobNC | Dumb question but can I modify RedBoot from within RedBoot? I.e., does RedBoot copy itself to RAM and then run from RAM? |
| 00:30.02 | rwhitby | RobNC: I have a paper copy here of the mods I made - 9 different places |
| 00:30.15 | rwhitby | yes, you should be able to install a new redboot from inside redboot |
| 00:30.25 | rwhitby | flash offsets of my modifications are: |
| 00:31.25 | rwhitby | cf54, cfb0, d030, d048, doe8, d104, d110, d11c, d128, d5b0, d934, d944 |
| 00:31.43 | rwhitby | let me know if you see diffs other than at those locations. |
| 00:31.58 | rwhitby | once you've got the wiki page up, I'll check it and annotate it with comments |
| 00:32.03 | RobNC | ok, will do, compare to normal 8MB flash redboot image |
| 00:32.37 | RobNC | I made some mods initially but it seems that it needs polishing. |
| 00:32.47 | rwhitby | I did it by looking at the redboot source code we have, then working out what needed to change in the C code, then finding those bits in the disassembly, then modifying the binary. |
| 00:33.26 | RobNC | wow great job! |
| 00:34.11 | rwhitby | It all comes down to changing FLASH_SIZE in the source code, and working through all the places that is used. |
| 00:35.26 | rwhitby | Being able to redbuild RedBoot from source helped, cause I didn't have to disassemble from binary, I could just compile C to assembly to find the right places. |
| 00:36.31 | rwhitby | Anyway, I might have time this arvo to look at slugimage. In the meantime, you might be able to just cut a block off the end of Flashdisk and try that. |
| 00:37.37 | RobNC | that at least helps. Thanks for your efforts, indeed! Didn't know if flashdisk was sectorized and size as prefix. |
| 00:38.43 | rwhitby | Flashdisk doesn't have a size prefix. Ramdisks do, but slugimage adds that. |
| 00:38.59 | rwhitby | You can look at the start of the unpacked file to see if the size has been mistakenly put there. |
| 00:39.21 | RobNC | So is "Flashdisk" same as "Ramdisk"? |
| 00:39.36 | rwhitby | no |
| 00:39.54 | rwhitby | ramdisk always starts at a specific location, and has a size header. |
| 00:40.12 | rwhitby | flashdisk (jffs2) cannot start at that location, it needs to start at the next block, so it can start from the start of the block |
| 00:40.35 | RobNC | Of course, just realized that. I meant ramfs. |
| 00:41.19 | rwhitby | Debian images have kernel and ramdisk. SlugOS and OpenWrt images have kernel and flashdisk. |
| 00:41.35 | RobNC | i.e., the filesystem uncompressed into ram. Ah ok that makes sense now - thanks! |
| 00:43.51 | RobNC | I'll try out mods and get back to you. Thanks again for help with RedBoot FatFlash mods. I'll also have to look at slugimage to see diffs between 8MB and 16MB. You'd think that only flashdisk would be larger, since 32-bit addressing and no extra space by anything else. |
| 00:50.44 | rwhitby | yeah, the bug is in slugimage - the flashdisk is the same for both |
| 00:50.56 | rwhitby | (it's only built once and packed into an image twice) |
| 00:53.45 | RobNC | I see. perhaps process of packing twice has an error. Might matter for devices that can do 2x, 4x, 8x 8MB flash. BTW, I wonder if 32MB flash would work for NSLU2 (missing high address bit). It seems my company's software folks are greedy and want more than they need. :-) |
| 00:56.47 | rwhitby | no, slugimage is called twice, once for 8mb once for 16mb - the same flashdisk image is used for each |
| 00:57.15 | rwhitby | it's definitely a slugimge bug |
| 01:20.00 | RobNC | rwhitby: just did xxd and doing diff shows huge differences between my redboot and yours, as well as downloaded 4.8-beta-slugosbe slugimage disassembled RedBoot. If I concentrate on just the differences shown above, looks like the addresses are off. Are you using 16-bit addressing or 8-bit? One difference I happened to see (in text window of xxd) is eCos: Feb 3 2004 and the other is eCos: July 4, 2007. |
| 01:20.52 | RobNC | The Feb 3 2004 is what is found in the downloaded "slugosbe-4.8 beta" RedBoot disassembly with slugimage. |
| 01:23.29 | rwhitby | interesting |
| 01:23.45 | rwhitby | we get the redboot for the built images from linksys firmware images |
| 01:24.00 | RobNC | Weird, hmm, even the built version I made has the Feb 3 2004 date. |
| 01:24.01 | rwhitby | where did you get the July 4 one from ? |
| 01:24.26 | RobNC | July 4 is yours. Look at location 0x26a0 thereabouts |
| 01:25.46 | RobNC | What made me look for this is the fact that it seems there are thousands of lines differences (when converting both your 16mb redboot to hex, and the one I made, as well as the one from the 4.8 download page). |
| 01:26.45 | rwhitby | back later ... |
| 01:26.59 | RobNC | ok thanks rwhitby. ttyl |
| 02:35.21 | RobNC | Anyone here ever built u-boot for NSLU2? Looks like it builds, had to replace references to IPL_ixp400NpeLibrary-2_1.zip with IPL_ixp400NpeLibrary-2_4.zip however... |
| 02:56.52 | RobNC | hmm, u-boot loads, just overwrote redboot (note: I have JTAG - this is a *MUST*!!) |
| 03:09.46 | rwhitby | RobNC: I've built u-boot for NSLU2 - we're working on getting it into the standard tree |
| 03:16.32 | RobNC | rwhitby: cool, needs some work as it won't find eth PHY but at least it does ymodem (reverting to old redboot). |
| 03:17.59 | rwhitby | there is a gpio reset required to find the phy |
| 03:18.04 | RobNC | guys at work are experts at this - we've used it for several generations of products (not me personally) |
| 03:18.34 | rwhitby | jacques knows what it is - basically you need to set the phy reset line as an inactive output (it defaults to an input and floats) |
| 03:18.46 | rwhitby | perhaps you can make the change and test it? |
| 03:18.49 | RobNC | with gpio reset, does that imply that power cycle will allow u-boot to find the phy? |
| 03:19.07 | RobNC | oh I think I understand - some config register. |
| 03:19.36 | rwhitby | in the u-boot board file, you need to configure GPIO13 as an output and drive it high. |
| 03:19.49 | rwhitby | once that is done, the phy (and networking) should work |
| 03:20.16 | rwhitby | See http://www.nslu2-linux.org/wiki/Info/GPIOConnections |
| 03:20.18 | RobNC | cool, that should probably be pushed into source tree once verified |
| 03:20.26 | rwhitby | we believe the pci reset is also connected to the phy |
| 03:20.44 | rwhitby | RobNC: you're using our patch from the nslu2 kernel svn repo? |
| 03:20.52 | RobNC | correct. |
| 03:21.10 | rwhitby | http://svn.nslu2-linux.org/svnroot/kernel/trunk/patches/u-boot/0001-ixp-Support-for-NSLU2.patch ? |
| 03:21.49 | rwhitby | yes, it's probably two lines added to nslu2.c in that patch. I simply haven't had time to set up jtag to test it. |
| 03:21.53 | RobNC | yup I have that file under kernel/u-boot/patches |
| 03:21.59 | rwhitby | if you can test it, we'll put it in immediately. |
| 03:22.25 | rwhitby | there are some other comments from the u-boot ixp maintainer that we need to fix too, but once that's done it will be accepted upstream |
| 03:22.36 | RobNC | ok, gotta patch first, then recompile right? |
| 03:22.40 | rwhitby | yep |
| 03:23.06 | rwhitby | at some point I would like to take the upgrade protocol code from Redboot and add it to u-boot so you can upslug2 to u-boot |
| 03:23.32 | rwhitby | Note that netconsole works nicely with u-boot on the nslu2, so you don't need a serial console to get to the u-boot command line |
| 03:24.01 | RobNC | that's clever - I thought upslug2 used some proprietary mechanism inside the IXP420? It doesn't seem to be redboot |
| 03:24.01 | rwhitby | (BTW, I'm the author of that u-boot nslu2 patch you're using) |
| 03:24.17 | RobNC | Cool! :-) Wow lots of work... |
| 03:24.20 | rwhitby | no, it's a redboot low-level protocol that linksys/sercomm added to the redboot source |
| 03:24.46 | rwhitby | there is a file called upgrade.c in the redboot source for nslu2 which implements the protocol |
| 03:25.07 | RobNC | Ok that makes sense, as looking at console you don't see same thing as tftp network sends |
| 03:27.40 | RobNC | sweet - it even has a section for physical RAM :-) |
| 03:30.41 | rwhitby | ah, yes - it's only written for 32MB so far, it would need to scan for up to 256MB automatically to support larger ram sizes - there are examples of this in other boards |
| 03:31.31 | RobNC | would I have to "patch -p0 u-boot/patches/0001-ixp-Support-for-NSLU2.patch" - and extraneous text is ignored (without + or == or --- or @@)? |
| 03:31.44 | rwhitby | yep |
| 03:31.53 | rwhitby | our makefile just applies it using quilt |
| 03:32.23 | rwhitby | using the series file in the same directory |
| 03:32.58 | RobNC | ah that must be the easier way to do this automatically per your build daemons. |
| 03:33.54 | RobNC | weird, getting some messages about reversed patch detected. |
| 03:35.50 | RobNC | need better desktop environment - brb |
| 03:35.53 | rwhitby | bbiab (lunch) |
| 03:40.45 | *** join/#nslu2-linux DrZimmerman (n=theo@77-56-246-76.dclient.hispeed.ch) |
| 04:04.32 | RobNC | it seems that "cd ~/kernel; make clobber; tar xzvf downloads/u-boot-v1.3.2.tar.gz; patch -p0 <patches/u-boot/0001-ixp-Support-for-NSLU2.patch" gets the patches applied. But if I use "make u-boot-nslu2.bin" it seems that it does a distclean, which I assume cleans out the patched files. Is the best way to do this to essentially re-tar.gz the source file u-boot-v1.3.2.tar.gz or is there another easier way I'm missing. |
| 04:22.30 | RobNC | ok, apparently, during "make u-boot", which actually does "make u-boot-nslu2.bin", the patches are included. Unless there are some other patches that somehow superceded the 0001-ixp patch. |
| 04:25.00 | *** join/#nslu2-linux Sinclair73de_ (n=Sinclair@p57B491CC.dip0.t-ipconnect.de) |
| 06:00.20 | *** join/#nslu2-linux drath_ (i=vmaster@p5B07E30B.dip.t-dialin.net) |
| 06:23.32 | *** join/#nslu2-linux ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 06:35.55 | *** join/#nslu2-linux erikja (n=erikja@0x57314066.abnxx10.adsl-dhcp.tele.dk) |
| 06:41.23 | *** join/#nslu2-linux erikja (n=erikja@0x57314066.abnxx10.adsl-dhcp.tele.dk) |
| 06:43.17 | *** join/#nslu2-linux erikja (n=erikja@0x57314066.abnxx10.adsl-dhcp.tele.dk) |
| 08:04.28 | *** join/#nslu2-linux lyakh (n=lyakh@p57BD2BDB.dip0.t-ipconnect.de) |
| 08:10.35 | *** join/#nslu2-linux x29a (n=x29a@unaffiliated/x29a) |
| 08:34.35 | *** join/#nslu2-linux handzisk (n=handzisk@svetlana.tkn.TU-Berlin.DE) |
| 08:35.45 | *** join/#nslu2-linux handzisk (n=handzisk@svetlana.tkn.TU-Berlin.DE) |
| 08:54.49 | *** join/#nslu2-linux pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 10:30.04 | *** join/#nslu2-linux kolla (n=kolla@haugum.uninett.no) |
| 11:23.40 | *** join/#nslu2-linux pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 11:31.38 | *** join/#nslu2-linux GPSFan (n=kenm@12.10.255.246) |
| 11:57.36 | *** join/#nslu2-linux osas (n=nnnnnnnn@nslu2-linux/osas) |
| 12:00.46 | *** join/#nslu2-linux x29a_ (n=x29a@unaffiliated/x29a) |
| 13:40.17 | CIA-45 | 03rwhitby * r111 10slugimage/trunk/slugimage: Now catches the error of a Ramdisk offset that exceeds the required value (usually caused by not specifying a new name for the partition. |
| 13:40.33 | *** join/#nslu2-linux nhoman (n=homann@79.97.106.107) |
| 13:55.47 | CIA-45 | 03rwhitby * r112 10slugimage/trunk/slugimage: Moved the error check to prevent false triggering. |
| 13:57.20 | rwhitby | RobNC: use -r Flashdisk:Flashdisk to prevent the problem occurring. It was user error and a poor error message from slugimage, rather than a real bug. |
| 14:07.56 | *** join/#nslu2-linux Ragnor (n=Ragnor@dslb-084-062-091-176.pools.arcor-ip.net) |
| 15:42.16 | *** join/#nslu2-linux kolla_ (n=kolla@firda.kolla.no) |
| 16:07.07 | *** join/#nslu2-linux kolla (n=kolla@firda.kolla.no) |
| 16:31.22 | CIA-45 | 03bzhou * r8282 10optware/trunk/make/dokuwiki.mk: dokuwiki: 2007-06-26 -> 2008-05-05 |
| 16:42.37 | CIA-45 | 03bzhou * r8283 10optware/trunk/make/streamripper.mk: streamripper: 1.62.1 -> 1.63.0 |
| 17:50.56 | *** join/#nslu2-linux test (n=ch4os@gen2.org) |
| 18:41.05 | *** join/#nslu2-linux Reedy (n=Reedy@wikimedia/Reedy-Boy) |
| 18:49.14 | Sinclair73de | when reflash a today build slugosle image i get "bad Kernel size (1059200, max 1048576)". Is the kernel size wrong or is this a problem of my old reflash-tool? |
| 19:06.21 | *** join/#nslu2-linux osas (n=nnnnnnnn@nslu2-linux/osas) |
| 20:06.21 | *** join/#nslu2-linux HopsNBarley (n=hops@nslu2-linux/HopsNBarley) |
| 20:16.42 | Sinclair73de | anyone running an actual slugosle-image and can send me the MTD partition names and sizes? |
| 20:36.24 | CIA-45 | 03bzhou * r8284 10optware/trunk/make/ (apr-util.mk apr.mk): apr/apr-util: -> 1.2.12 |
| 20:47.24 | *** join/#nslu2-linux hillct (n=H@cpe-024-211-242-232.nc.res.rr.com) |
| 22:03.26 | *** join/#nslu2-linux kowalczyk (n=kowalczy@128.80-202-137.nextgentel.com) |
| 22:04.10 | kowalczyk | Im having trouble with my nslu2. I have installer debian firmware. the unofficial one. It rebootet but then nothings happen:( |
| 22:04.46 | kowalczyk | just orange light and nothing more happens |
| 22:06.28 | kowalczyk | I get like this: 7fffff+000000 ...VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV |
| 22:06.28 | kowalczyk | Rebooting... done |
| 22:06.33 | kowalczyk | and then nothing happens |
| 22:08.29 | ka6sox-work | turn it off, wait 5 seconds, turn it on |
| 22:08.57 | kowalczyk | ok. Il try |
| 22:11.20 | kowalczyk | have tried it. I have a usb harddrive attached to it. but the led doesnt light either:( |
| 22:13.01 | ka6sox-work | did you install it with the HD attached? |
| 22:13.18 | kowalczyk | the firmware? no. the guide told me to detach it |
| 22:13.22 | ka6sox-work | okay good. |
| 22:14.08 | kowalczyk | but when I connect the drive to it nothing happens. Maybe ill try install the original firmware and try update via the browser |
| 22:14.14 | ka6sox-work | which proceedure did you use? |
| 22:15.02 | kowalczyk | http://www.cyrius.com/debian/nslu2/install.html this one:) |
| 22:15.11 | kowalczyk | I used upslug2 |
| 22:18.14 | kowalczyk | but now my gf is going to bed and my slug is in the closet. so I have to shut it down now. I will try again tomorrow |
| 22:21.25 | ka6sox-work | okay |
| 22:21.58 | kowalczyk | but any idea what can be wrong? |
| 22:22.53 | ka6sox-work | unfortunately no, best to ask tbm about that if you see him. |
| 22:24.06 | kowalczyk | ok:) but I try to once more tomorrow |
| 22:24.35 | ka6sox-work | k |
| 22:47.23 | *** join/#nslu2-linux HopsNBarley (n=hops@nslu2-linux/HopsNBarley) |
| 23:07.42 | *** join/#nslu2-linux nhoman_ (n=homann@79.97.106.107) |
| 23:11.17 | *** join/#nslu2-linux nhoman_ (n=homann@79.97.106.107) |
| 23:29.40 | CIA-45 | 03bzhou * r8285 10optware/trunk/make/finch.mk: finch: 2.3.1 -> 2.4.1 |