**** BEGIN LOGGING AT Sat Jan 14 02:59:58 2006 Jan 14 04:42:42 hmm, still having troubles booting into debianslug; inititally thought perhaps the partition was too big so moved to a smaller one (1.5 GB) but that does not help. I never leave the flashing orange led state Jan 14 04:42:50 anyone a suggestion? Jan 14 04:43:17 nope, put serial on it :-) Jan 14 04:43:49 yeah, should do that, did have troubles getting the holes open and don't have the gear Jan 14 04:44:20 use the "push the pins through from the other side while heating" trick. Jan 14 04:44:48 the middle two clear easily (even by using the "percussive method" if you have no solder sucker) Jan 14 04:45:01 yes, need to find myself the cable stuff as well Jan 14 04:45:03 the outside two have the internal planes to suck the heat Jan 14 04:45:05 * NAiL testifies that the percussion method works ;-) Jan 14 04:45:50 ok, I'll get a cable a.s.a.p. (i think we should have these at work) and try it Jan 14 04:46:48 orange flashing means it is still in the boot stage isn't it? Jan 14 04:50:00 well, there's nothing in debian yet to change it, so it could mean anything Jan 14 04:51:06 ah ok, Jan 14 04:51:42 will re-check my work first to see if I didn't make any mistake Jan 14 04:55:19 eFfeM: you've got a debianslug-image? Jan 14 04:55:45 NAiL, where should that one be ? Jan 14 04:56:09 i asked something to that extend yesterday, but did not really get an answer Jan 14 04:56:36 what did you flash your slug with? Jan 14 04:56:41 should I have an image somewhere on my boot partition? and if so, where should it come from and go to ??????? Jan 14 04:57:23 I was wondering if you had the image you used to flash your slug Jan 14 04:57:28 NAiL, I did do a make debianslug-image with the master makefile Jan 14 04:57:31 03rwhitby * 10debian/.cvsignore: Updated to match Makefile Jan 14 04:57:45 yeah, did that work at all? Jan 14 04:57:58 then got this in tmp/deploy/images: Jan 14 04:57:59 debianslug-nslu2-20060111212325.flashdisk.img Jan 14 04:58:04 mine boots, but the network doesn't work Jan 14 04:58:16 it boots fine Jan 14 04:58:26 BTW, you guys are choosing a very volatile time to be building images. Jan 14 04:58:36 even the network is working for me, I can get in using ssh Jan 14 04:58:55 rwhitby: isn't HEAD always volatile? ;) Jan 14 04:59:07 rwhitby, yeah, I know my timing is not that good. I was too eager to see if an LE driver would solve my audio problems Jan 14 04:59:37 and next week I'm on a business trip for a week. this seemed a nice project for a free saturday... Jan 14 05:00:16 for me the network does work and I can into the slug with ssh, but then I cannot get to booting from hard disk Jan 14 05:00:40 well, all I can say is that I haven't tested an image since before the start of the big OE breakage Jan 14 05:00:55 rwhitby, should there be a debian image on the harddisk when booting from there? Jan 14 05:01:11 doesn't need to be Jan 14 05:01:59 ah, ok, at some point I had the impression that the LE openslug image in the flash was used as a booter for a real debian kernel Jan 14 05:02:41 eFfeM: mind sending me your image? I'd like to try and see if that works better on my box Jan 14 05:04:23 NAiL, sure Jan 14 05:04:36 dcc send ok ? Jan 14 05:04:47 might work Jan 14 05:05:28 it tells me here offering Jan 14 05:05:45 normally I would put this on my web server dir on my slug :-) Jan 14 05:06:18 doesn't seem to work, no Jan 14 05:06:24 could you mail it to me? Jan 14 05:06:34 np, address ? Jan 14 05:06:44 pm Jan 14 05:09:57 NAiL, it is uploading, takes a little bit of time, 8MB img, 512 kbit uplink (also in use for other things and yahoo doesn't seem very fast either) Jan 14 05:11:30 NAiL, it is gone here, let me know if this works for you Jan 14 05:11:56 build from the head, partially thu, partially fri Jan 14 05:12:04 in a clean env Jan 14 05:13:52 thanks Jan 14 05:13:54 downloading now Jan 14 05:14:11 yw Jan 14 05:14:22 actually i did all of the instructions except for two: Jan 14 05:14:24 Add your name to the DebianSlugUsers list. Jan 14 05:14:24 Reboot into Debian. Jan 14 05:14:38 I decided to reverse the order, never got past the reboot .... Jan 14 05:16:36 03rwhitby * 10debian/Makefile: Made it only build the nslu2 flavour instead of all arm flavours. Jan 14 05:42:18 rwhitby, apparently leds do work on debianslug as these are e.g. in /boot/disk and that is the same as the openslug one Jan 14 05:55:57 rwhitby: I figured out what was wrong with my debianslug image... It doesn't read the ip from SysConf, and goes dhcp. Since I don't have a dhcp-server, it simply doesn't come up. Jan 14 05:56:09 The dhcp client just forks off into the background Jan 14 05:56:48 so now I just have to set up a dhcp server :P Jan 14 06:28:48 NAiL, that is why my slug got a fixed ip address Jan 14 06:32:51 The past few days, compiling Unslung has given me: Jan 14 06:32:52 ERROR: Nothing provides gmp-native Jan 14 06:32:54 ERROR: dependency gmp-native (for gcc-cross) not satisfied Jan 14 06:32:55 NOTE: no buildable providers for virtual/armeb-linux-gcc Jan 14 06:32:57 ERROR: dependency virtual/armeb-linux-gcc (for unslung-packages) not satisfied Jan 14 06:32:58 NOTE: no buildable providers for unslung-packages Jan 14 06:33:00 make: *** [distro] Error 1 Jan 14 06:33:01 Any idea, anyone? **** BEGIN LOGGING AT Sat Jan 14 06:41:03 2006 Jan 14 07:36:53 eFfeM: I just booted to debianslug successfully Jan 14 07:37:18 sda: assuming drive cache: write through Jan 14 07:37:23 oops Jan 14 07:37:53 NAiL, very good. from the hard disk? what did you do? Jan 14 07:40:33 i seem to be stuck in init Jan 14 07:43:49 I didn't have to do anything special Jan 14 07:43:55 actually ixp400_eth seems to start but that's about the end Jan 14 07:43:58 of course, the led still blinks though Jan 14 07:44:15 how long did you have to wait Jan 14 07:44:44 couple of minutes or so Jan 14 07:45:02 dhcp or fixed ip ? Jan 14 07:45:06 fixed Jan 14 07:45:28 I've got a serial console though, so I'm cheating :-P Jan 14 07:46:15 ah ok Jan 14 07:46:54 can you do me a favor and reboot and tell me when it is through ? Jan 14 07:47:10 There's a slight problem with that Jan 14 07:47:22 because when the slug goes down, so does my internet Jan 14 07:47:37 and right now, it's a rather long list of manual tasks to get it back up :P Jan 14 07:48:43 ah, ok, nevermind then Jan 14 07:49:10 actually i did not see you go away .... Jan 14 07:50:39 no, that's because I'm ssh'ing to a server in another town where I've got a screen-session ;-) Jan 14 07:50:59 understood Jan 14 07:54:35 NAiL, it is using the same fixed address as without hd I assume Jan 14 07:54:43 it is booting now for five minutes Jan 14 07:55:49 hmm Jan 14 07:58:05 my root fs is 1.5 G and on /dev/sda2, I assume this is not a problem Jan 14 08:33:15 Got it working!!!!!!!!! Jan 14 08:33:34 finally figured out that i was on dhcp (stupid me) Jan 14 08:33:47 i'll immediately update the wiki Jan 14 08:41:57 NAiL, you did't follow the instructions! you're not in http://www.nslu2-linux.org/wiki/DebianSlug/DebianSlugUsers Jan 14 08:42:01 :-) Jan 14 08:42:15 this will put you out of the top 10 as I just took the 10th spot .... Jan 14 08:42:21 Jan 14 10:22:56 hi, for whom this concerns/interests Jan 14 10:23:30 I just installed debianslug, but apparently the filesystem after turnon does not contain ipkg Jan 14 10:23:44 for the time I've resolved this by coping everything with ipkg from /initrd Jan 14 10:25:21 i tried to build ipkg; earlier today I got a compile error, but now it does work Jan 14 10:25:51 (and for those who wonder why the heck I would need ipkg since I have apt-get: ipkg is still needed to get your own modules installed) Jan 14 10:32:34 btw when installing a package I also get Jan 14 10:32:35 Architecture-specific modutils configuration for arm not found, using defaults Jan 14 10:32:43 decided to ignore that for now Jan 14 10:35:49 anybody an idea where this symbol should come from: xscale_mc_clear_user_page Jan 14 10:35:54 it is used by videobuf.ko Jan 14 11:59:54 eFfeM-log: I think the videobuf.ko symbol is a change in 2.6.15 (i.e. I suspect it is a bug and videobuf hasn't been updated). Jan 14 12:00:07 I didn't think Debian used ipkg - don't you want dpkg? Jan 14 13:12:41 hmm Jan 14 13:12:47 I can't edit the wiki again Jan 14 13:13:15 Could anyone add a line about "dpkg reconfigure locales" fixing the LC_ALL, LANG etc. errors? Jan 14 13:15:45 NAiL: did you put in the author field? Jan 14 13:16:27 quite possibly not, my dear watson Jan 14 13:16:52 other than locales being unconfigured, the system works great Jan 14 13:17:03 oh, and the led still blinking ;-) Jan 14 13:20:06 Again, brilliant work by whoever did it :-) Jan 14 13:21:40 led blinking will be handled by the nslu2-tools debian package when it is done Jan 14 13:22:05 I'll add a note about that on the wiki Jan 14 14:01:54 YAY :D. I got my USB-scanner to work! Jan 14 14:06:17 due to LE? Jan 14 14:09:31 yup Jan 14 14:11:40 so I guess you're a proponent of debianslug/LE now :-) Jan 14 14:14:47 It does look very, very nice Jan 14 14:15:00 I still have BE OpenSlug running though Jan 14 14:51:33 tbm: let's discuss the booting of debian here. Jan 14 14:51:40 so rwhitby and I were discussing about how to boot Debian. I'm not quite happy about the 1 meg kernel restriction and some other things Jan 14 14:51:55 so my idea was to use RedBoot to load AMEX from flash where Linux normally is Jan 14 14:52:06 then AMEX could load the real kernel and initrd. This would give us Jan 14 14:52:17 the option to change the boot loader w/o having to change redboot, fix the Jan 14 14:52:33 system id, have a kernel that's bigger than 1 meg, have command line/env Jan 14 14:52:38 variables in flash, etc etc Jan 14 14:52:55 s/AMEX/APEX/ ? Jan 14 14:53:02 yeah, sorry Jan 14 14:53:08 http://wiki.buici.com/bin/view/Main/ApexBootloader Jan 14 14:54:28 we could also see what the developer of Apex thinks of adding an usb stack. (It has ext3 support already). Then we could directly boot from a usb disk without an initramfs. Jan 14 14:54:37 It's also possible to work round the 1MByte limit using an initramfs Jan 14 14:54:38 Although that's not strictly needed but probably wouldn't hurt either Jan 14 14:54:55 jbowler-away: how? Jan 14 14:55:14 That is, use a <1M kernel and load modules from kinit - the package kernel+initramfs is the kernel Jan 14 14:56:40 right. But 1M is really not much. I wouldn't mind having the option to have bigger kernels. Jan 14 14:57:01 and apex also gives you environment variables which might be handy. Jan 14 14:57:45 tbm: a few people already run apex on the nslu2, and beewoolie hangs out in #openslug sometimes Jan 14 14:57:52 ~seen beewoolie Jan 14 14:58:05 beewoolie was last seen on IRC in channel #openjtag, 20h 41m 49s ago, saying: 'ka6sox-office: Apparently, I was wrong about ep1220's board. There is nSRST line.'. Jan 14 14:58:34 [g2] was running it for a while Jan 14 14:59:07 I'm running APEX on my test slug Jan 14 14:59:29 the problem with apex is no NPE Jan 14 15:00:08 NPE? Jan 14 15:00:32 ixp ethernet Jan 14 15:00:35 the network interface doesn't work in APEX Jan 14 15:01:09 So you can brick the slug just by damaging the rootfs Jan 14 15:01:49 Then you'll need serial or JTAG to recover Jan 14 15:02:28 I don't see why it would be necessary to have an NSLU2-specific kernel >1MByte, - even with kernel bloat there is still stuff which can be removed, just so long as it can be loaded from kinit (which it can - e.g. the RTC) Jan 14 15:03:09 well, you can always unbrick it with uplug2 in that case. Jan 14 15:03:26 the nice thing about using apex is that it would actually allow you to change environment variables via upslug2 Jan 14 15:04:24 jbowler-away: I'd like to avoid having a nslu2 specific kernel in Debian. We have a generic ixp4xx image but that's currently much larger than 1 meg and I'm not sure modularizing it is such a good idea. Jan 14 15:04:42 it's sometimes quite helpful to have stuff like nfs in the kernel Jan 14 15:04:45 e.g. Jan 14 15:05:15 The generic ixp4xx we are generating for OE is 900k Jan 14 15:05:39 Well, 916028 bytes Jan 14 15:06:12 I don't see why nfs modules in kinit are functionally any different from nfs non-modules in the kernel. Jan 14 15:06:51 So far as I am aware the system behaves the same way on boot (i.e. the same way for kernel+nfs as for kernel+insmod nfs-module). Jan 14 15:08:09 yeah, but it's more work for users than simply compiling it in. Anyway, and you're not bothered by the functionality apex potentially provides Jan 14 15:08:15 e.g. no longer needing to fix the system id Jan 14 15:08:17 The problem with the boot loader approach is that the boot loader sucks up 1MByte of flash. Jan 14 15:08:19 having environment variables Jan 14 15:08:27 that's right Jan 14 15:08:44 hmm, I suppose that's less of an issue for me than for you because I'm interested in running from usb disk Jan 14 15:08:48 while you want a system in flash Jan 14 15:08:54 tbm: note that nslu2-linux also supports configurations where everything (including user applications) are in flash for diskless applications Jan 14 15:09:11 (even usb flash disk-less) Jan 14 15:09:17 yeah Jan 14 15:09:19 No - it doesn't make any difference to me, the slugos stuff will run off the generic 1MByte kernel regardless. Jan 14 15:09:57 <[g2]> tbm IMHO just replacing the Redboot kernel with a full one makes lots of sense Jan 14 15:10:00 I would be hesitant to create a separate booting strategy just for debianslug Jan 14 15:10:13 <[g2]> re APEX Jan 14 15:10:33 for Debian, I'm not bothered by wasting 1MB since we don't need flash but (like rwhitby just says) I'm not sure it makes sense to diverge from how openslug is done Jan 14 15:10:38 regarding flash layout Jan 14 15:10:51 <[g2]> tbm rwhitby is totally correct the vast majority of users are Unslung users Jan 14 15:10:59 [g2]: replacing redboot means that some people might brick their machines Jan 14 15:11:15 whereas that won't happen if you leave redboot alone and add apex in addition Jan 14 15:11:29 The problem is that if Debian expects nfs support in the kernel by default then it doesn't matter if it is in the kernel or initramfs - it takes about the same amount of flash - and that won't work with the maximally deconfigured systems. Jan 14 15:12:15 If the base system is minimal you can add stuff to it, but if the base system isn't minimal some things can't be added - they won't fit. Jan 14 15:12:38 jbowler-away: it doesn't expect nfs support or anything; it was just one example of a feature some people might want in an ARM kernel. Probably not the best example tho. Jan 14 15:12:42 So either you are saying that some applications are unsupported (because they won't fit) or it isn't really the base system ;-) Jan 14 15:13:46 tbm: a bootable ixp4xx (no NPE) requires a kernel <1MByte, but not much less, so 1MByte is the bottom line. Add anything to that and someone will need to remove it. Jan 14 15:14:46 <[g2]> jbowler-away that kernel on the NSLU2 is 99.99% useless as only 0.01 % have serial Jan 14 15:15:19 Right, so the NPE has to be added for NSLU2, but not for loft or avila. Jan 14 15:15:46 <[g2]> Loft / Avila has JTAG, Serial etc... Jan 14 15:15:55 <[g2]> Redboot source Jan 14 15:16:05 <[g2]> different world Jan 14 15:16:08 by the way, those Intel access libraries the ixp400 eth driver needs are a GPL violation (since they link against the kernel). Jan 14 15:16:09 But we can't put the NPE in the kernel because of the license, so it has to be insmodded somewhere. Jan 14 15:16:24 I'll try to talk to a contact at Intel and see if they can raise this issue within the company. Jan 14 15:16:42 tbm: that's a matter of legal opinion Jan 14 15:16:58 yeah, let's not get into that discussion rat-hole :-) Jan 14 15:17:00 So far as I know Linus's lawyers haven't contacted us yet... Jan 14 15:17:00 <[g2]> tbm GL and godspeed Jan 14 15:17:20 So anyway, here was my thoughts about booting debian. Jan 14 15:17:29 1) normal redboot as today Jan 14 15:17:43 jbowler-away: when you have some time could you test something for me? I tried again loading an ext2 initrd and an initramfs but it doesn't work. Loading an cramfs initrd works tho. Can you see if it works for you (and yes, I compiled ext2 support into the kernel). Jan 14 15:17:57 2) normal nslu2-flavour kernel as today (it needs to have a different cmdline from the generic ixp4xx debian kernel anyway) Jan 14 15:18:20 right, 2) is another thing apex would solve :) Jan 14 15:18:23 either: Jan 14 15:18:48 <[g2]> tbm I think the default config may have ext2 as a module Jan 14 15:18:57 [g2]: yeah but I changed it Jan 14 15:19:00 3a) have debian-installer in a normal initrd after you flash the image, and at the end of the installation, it writes a new kernel which loads a recovery/pivot rootfs from jffs2 Jan 14 15:19:29 <[g2]> tbm where were you loading it from FLASH ? Jan 14 15:19:51 [g2]: from the network. (load -r -b 0x01000000 initrd) Jan 14 15:20:09 3b) have debian-installer work from a jffs2 partition, and on first boot it loads debian-installer and after the installation it sets a flag in the jffs2 to say "look for this disk partition before running debian-installer again" Jan 14 15:20:29 <[g2]> tbm I think that's a bad addr Jan 14 15:20:34 <[g2]> 1 too many 0s Jan 14 15:21:03 <[g2]> maybe not but how big was it ? Jan 14 15:21:04 [g2]: initrd is normally loaded at 0x01000000 and vmlinuz at 0x01d00000 Jan 14 15:21:15 I've taken it from http://www.nslu2-linux.org/wiki/HowTo/TestAnImageInRamUsingRedBoot Jan 14 15:21:17 and initrd is 10MB max Jan 14 15:21:23 tbm: yep, that's correct. Jan 14 15:22:12 okay, let's discuss 2) again. I'd really like to avoid having a specific slug kernel image and just go with a generic ipx4xx kernel. But I need a specific kernel command like to boot the slug Jan 14 15:22:23 is there a way to change the command line in a compiled kernel binary? Jan 14 15:22:31 <[g2]> so initramfs 0x1000000-0x1A00000 and kernel @ 0x1d00000-1dfffff Jan 14 15:22:50 tbm: there is - we did that for Unslung 1.0 (a binary sed changed /dev/ram0 to /dev/slug) Jan 14 15:23:15 but it's a tedious process with needs to uncompress and edit vmlinux (not vmlinuz) Jan 14 15:23:17 <[g2]> or just recompile the kernel Jan 14 15:23:38 rwhitby: right, I've done something similar. I should be more precise: can you do it if you have no cmdline set by default. Jan 14 15:23:41 [g2]: recompiling negates tbm's goal of having a single standard ixp4xx debian kernel Jan 14 15:23:51 i.e. instead of just changing e.g. /dev/ram0 to /dev/slug, adding a new cmdline where there's none Jan 14 15:24:06 tbm: you'd need a large default cmdline to give you the space to overwrite Jan 14 15:24:34 or you could probably do a kernel prepend which sets something up in ATAGs and then passes that to the kernel. Jan 14 15:24:43 (like we currently do for the machine id) Jan 14 15:24:59 hmm, interesting. Do you know how to do that? Jan 14 15:25:05 (or can you find out? :) Jan 14 15:25:19 nope, it's pure speculation on my part. jbowler is our prepend expert. Jan 14 15:25:37 ok, maybe he knows. Jan 14 15:25:54 <[g2]> right I think a prepend shim is the way to fix it Jan 14 15:26:09 tbm: yes, the command line has a default allocation, you can just overwrite it Jan 14 15:26:21 * [g2] thinks the way to _really_ fix it is with the bootloader Jan 14 15:26:23 ATAG is ARM specific, right? Something similar won't work on MIPS? (I have a similar problem on a different device) Jan 14 15:26:25 rwhitby: the data for the command line has a fixed size IIRC Jan 14 15:26:30 <[g2]> but that's the tolerable solution Jan 14 15:27:10 I would like to avoid the need for a command line. Can we set this stuff in the board setup? Jan 14 15:27:22 jbowler-away: wanna show me some devio code to add/change a command line when you're not-away? Jan 14 15:27:43 tbm: that's gonna be difficult, cause you need to uncompress the kernel first Jan 14 15:28:03 and the padding at the end had to be found by trial and error. Jan 14 15:28:08 tbm: it's fairly obvious, you just read the address from System.map and overwrite that address. Jan 14 15:28:35 jbowler-away: it wasn't obvious for me to look at System.map, doh! Thanks a lot. Jan 14 15:28:53 You need to find the right symbol, the code is baroque. Jan 14 15:29:20 jbowler-away: another question you might be able to answer: is there a way to add an initramfs to a kernel binary w/o recompiling it. Jan 14 15:29:25 jbowler-away: would a target-specific cmdline shim mean we could use a single kernel binary for nslu2, nas100d and loft? Jan 14 15:29:31 I suppose cat kernel foo.cpio.gz > bar won't simply work? Jan 14 15:29:40 <[g2]> rwhitby tbm this is really just an issue for the Nslu2/Lude etc Jan 14 15:29:55 arch/arm/kernel/setup.c "default_command_line" Jan 14 15:30:22 tbm: no, well, you could relink it, it's just pulled in as a binary. Jan 14 15:30:23 <[g2]> its not an issue for the Loft as I can ship Intel binaries as Loft customers bought HW Jan 14 15:30:43 jbowler-away: what command line do you want to hardcode into the kernel source? Jan 14 15:30:50 The problem is that there is an 'end' symbol which gets compiled into the code to find the lenght. Jan 14 15:31:30 tbm: I don't, I want the board setup to be able to set the rootfs device on NSLU2 (and probably nas100d), and I want the board setup to poke the RTC probe parameters. Jan 14 15:31:59 I can't get a command line which will work with both NAS100D and NSLU2 - one needs /dev/mtdblock4, the other /dev/mtdblock2 Jan 14 15:32:12 board setup = ATAG? Jan 14 15:32:20 jbowler-away: ah, so do it based on partition data Jan 14 15:32:21 ? Jan 14 15:32:42 rwhitby: how? I'd like /dev/Flashdisk ;-) Jan 14 15:33:04 jbowler-away: do you want to hardcode it in arch/arm/mach-*/*nslu2-setup.c or add a code so you can prepend a command line with atag? Jan 14 15:33:13 hmm - the mtd table is available, so you could do it by name. Jan 14 15:33:18 I want to hard code it into nslu2-setup.c Jan 14 15:33:39 what's the dev name for the buzzer? openslug-3.1 doesn't seem to have it created unless It changed name? Jan 14 15:33:42 right, I'm not sure that's such a good idea. Because not everyone might use the same flash layout Jan 14 15:33:51 rwhitby: it has to be in the init rootfs name space... that has mtdblock? Jan 14 15:33:53 going by mtd name like rwhitby says sounds good tho Jan 14 15:34:04 Here's the current generic command line: Jan 14 15:34:08 "root=/dev/mtdblock4 rw rootfstype=jffs2 mem=32M@0x00000000 init=/linuxrc rtc-x1205.hctosys=1 rtc-x1205.probe=0,0x6f rtc-ds1672.probe=0,0x68 rtc-ds1672.hctosys=1 pcf8563.hctosys=1 noirqdebug console=ttyS0,115200n8" Jan 14 15:34:14 Bad things: Jan 14 15:34:17 root= Jan 14 15:34:23 mem= Jan 14 15:34:32 But I think all the other stuff is ok. Jan 14 15:34:35 Poor things: Jan 14 15:34:41 Having to list every rtc probe Jan 14 15:34:54 Not having the EEPROM work on Loft (I think it will need a probe too) Jan 14 15:38:33 but so it's not possible to change the cmd line by prepending something to the kernel image, right? Jan 14 15:38:36 jbowler-away: I'd have to look where flash probe is done Jan 14 15:38:50 tbm: I'm sure it is Jan 14 15:39:17 After all, the command line is passed in by the boot loader. Jan 14 15:39:34 jbowler-away: if you have some time do you think you could find out how and give me an example. Jan 14 15:39:36 It must be possible to change that Jan 14 15:40:09 I don't actually know where to look - it's this 'tag' (atag?) stuff, it causes 'command_line' to be copied over 'default_command_line' Jan 14 15:40:35 there is an ATAG document on kyllikki's site I think ... Jan 14 15:44:28 Here's the minimal loft command line (assuming you want the serial to work): Jan 14 15:44:31 root=/dev/mtdblock2 rootfstype=jffs2 init=/linuxrc mem=64M@0 console=ttyS0,115200 Jan 14 15:44:52 The mem setting is required, though you can do mem=32M@0 and it will still boot. Jan 14 15:45:02 http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html Jan 14 15:45:28 The only thing in there which is a real problem is the /dev/mtdblock2 Jan 14 15:46:45 Oh well, that's easy isn't it. Jan 14 15:48:14 We just need to find the ATAG for the command line - this only goes wrong if NSLU2 (and possibly NAS100D) don't have a command line, but I think NSLU2 does. Jan 14 15:49:12 jbowler-away: we should be able to prepend a shim which overrides ATAG_CMDLINE anyway ... Jan 14 15:50:27 Or ATAG_NONE if it isn't there. Jan 14 15:50:55 Why doesn't loft boot unless I put a mem= in the command line? Jan 14 15:53:27 * rwhitby imagines jbowler-away reading the atag document and coding up a shim as we wait :-) Jan 14 15:56:12 * rwhitby fixes the unslung build during this quiet break .. Jan 14 15:57:53 jbowler-away: kernel.bbclass was broken for unslung - it was assuming include/sound/* existed. Jan 14 15:58:02 I've pushed a fix. Jan 14 15:58:11 <[g2]> jbowler-away dunno about the mem Jan 14 15:58:32 rwhitby: that was a very recent change (yesterday) Jan 14 15:58:55 [g2]: it looks like RedBoot isn't passing in an ATAG_MEM Jan 14 15:59:26 [g2] has the source for Loft's redboot, so we should be able to tell for certain Jan 14 15:59:38 This is the minimum command line: root=/dev/mtdblock4 rootfstype=jffs2 init=/linuxrc console=ttyS0,115200 mem=32M Jan 14 15:59:58 That should work on NSLU2 (though the RTC won't come up). Jan 14 16:02:09 Since the mem has to be specified for the board code to run mem=32M should be in the ixp4xx default I think. Jan 14 16:02:25 Along with the console Jan 14 16:05:46 jbowler-away: looks like something has broken glibc-2.2.5 being found for unslung too ... Jan 14 16:09:07 hmm - glibc-2.2.5 get's built early, but unslung-image seems to want to build something else which glibc-2.2.5 doesn't provide but a later version does Jan 14 16:10:35 yes, and a multiple-provider glibc,glibc-intermediate whine has appeared while building slugos-packages Jan 14 16:10:43 Here's the fix from slugos.conf: Jan 14 16:11:14 +PREFERRED_PROVIDERS += "virtual/${TARGET_PREFIX}libc-for-gcc:glibc" Jan 14 16:11:39 I think that will probably solve the unslung problem too. Jan 14 16:13:16 [g2]: with beewoolie's latest changes to apex (enable MMU) I get a 31secs boot with the latest openslug. Not too shabby at all! Jan 14 16:14:09 although we've been getting some explained crashes so I'm investigating those. I wonder if they could be related to the kernel command-line ovridde that apex uses or the MMU stuff. Jan 14 16:14:40 jbowler-away: yeah, just trying that fix now Jan 14 16:15:14 jbowler-away: nope, that didn't fix it Jan 14 16:15:20 <[g2]> jbowler-away I'll have to look at that ATAG in redboot Jan 14 16:16:26 <[g2]> BBL Jan 14 16:16:30 <[g2]> I'll check the logs Jan 14 16:18:23 jbowler-away: PROVIDES = "virtual/libc ${@['virtual/${TARGET_PREFIX}libc-for-gcc', '']['nptl' in '${GLIBC_ADDONS}']}" Jan 14 16:18:31 nptl is not in GLIBC_ADDONS in 2.2.5 Jan 14 16:25:01 Who changed it? Jan 14 16:26:11 jbowler-away: I think the depends is new Jan 14 16:26:33 and I think it should be satisfied by glibc-intermediate, cause it does not have the conditional Jan 14 16:28:18 so I've added a glibc-intermediate_2.2.5.bb and set the provider to that. Jan 14 16:29:24 Ok, the DEPENDS is really an RDEPENDS I think - unslung-image now DEPENDS on everything in RDEPENDS too (i.e. it will build the RDEPENDS as well as the DEPENDS). Jan 14 16:30:06 It should be possible (and is a good idea) to remove the DEPENDS, although I had to fix stuff up in the RDEPENDS to get that to work in slugos-image. Jan 14 16:31:51 tbm: beewoolie is the author of apex Jan 14 16:32:16 speak of the devil. Jan 14 16:32:37 rwhitby: do you mind answering a circuits question? Jan 14 16:32:55 jbowler-away: unslung-image still needs to build libc to get the additional libraries for the rootfs which are not provided by linksys Jan 14 16:33:24 beewoolie: shoot. if I can answer I will. if I can't, I'll do my best to hide my ignorance and give you a wishy-washy half-answer. Jan 14 16:33:32 :-> Jan 14 16:34:41 So, I've been testing my dweeby little jtag circuit. I've found that the nTRST portion has a very long rise time. Jan 14 16:34:59 hm, http://ipkg.nslu2-linux.org/feeds/unslung/native/Packages.gz is empty Jan 14 16:36:05 The circuit came from Tiersten, IIRC. It is driven by an SN3904. I believe the circuit is design as a open collector... OTP... Jan 14 16:36:59 Sorry. Jan 14 16:37:21 The question is this. Should nTRST be driven both high and low in order to get good frequency response? Jan 14 16:38:30 winkle: you're right. that's not supposed to be like that. the autobuilder must have failed. all the packages are still there if you want to get them individually Jan 14 16:39:09 I think what's happening on that particular line is that it only drives the line low. it looks like it letting the signal float high which makes for a poor signal Jan 14 16:39:35 beewoolie: I expect it can. the only reason I can think of it being open collector is if there are devices which drive TRST to reset other chips on the board, but that would be very suss. Jan 14 16:39:40 rwhitby: if this isn't your baliwick, then so be it. I recall that you were around when I was getting help with it. Jan 14 16:40:14 let's see if I have my copy of the jtag standard handy ... Jan 14 16:40:33 You've got it? I haven't been willing to pay the price. Is it worth buying? Jan 14 16:40:45 I believe the spec says that there should be pull-ups. Jan 14 16:41:23 nope, it's at work. Jan 14 16:41:43 there should at least be pullups if it's OC Jan 14 16:42:06 rwhitby: is that spec worth paying the $$$$ Jan 14 16:42:37 rwhitby: BTW, my circuit does work, it's just not very clean so it doesn't run very fast. Jan 14 16:42:48 beewoolie: dunno. I wouldn't buy it just to answer that question :-) Jan 14 16:45:06 rwhitby: I've been using the ARM TRM to understand the TAP interface. I suspec that I'm OK at this point with what it gives. It may be important for other parts of the standard that I don't yet understand. For instance, I have a BSDL parser that is based on reading BSDL files. There's lots that I can onlyguess. Jan 14 16:46:18 beewoolie: feel free to ping me on Monday at work Jan 14 16:46:47 jbowler-away: I just had to correct the FILESPATH to make glibc-intermediate_2.2.5 work Jan 14 16:47:17 rwhitby: thx. Jan 14 16:49:37 beewoolie: see /msg Jan 14 16:54:48 beewoolie: Hey, I've tried various scenario and it seems the new apex causes my slug to go nuts on me. even with the MMU option disabled. very odd. Jan 14 16:55:01 VoodooZ: Hmm. Jan 14 16:55:13 I wonder if there isn't something else that isn't being properly initialized. Jan 14 16:55:18 I tried updating the kernel command line to match openslug's but no diff. Jan 14 16:55:29 That should be done at a minimum. Jan 14 16:55:35 yep. Jan 14 16:55:38 it's good that it doesn't seem to be the MMU code. Jan 14 16:55:50 BTW, the jtag circuit that I published *does* work. Jan 14 16:55:54 I think it's really really slow. Jan 14 16:56:06 I'm working to evaluate the performance of it right now. Jan 14 16:56:14 jbowler-away: for some reason glibc-intermediate doesn't build, so I'm just making the provide for libc-for-gcc be unconditional for unslung Jan 14 16:56:16 well, i was only able to do quick tests so... I'll have to do more. Jan 14 16:56:54 Did somebody successfully recompiled redboot for the slug btw? Jan 14 16:58:32 VoodooZ: not that I know of Jan 14 16:58:37 VoodooZ: BTW, which kernel version are you using? Jan 14 16:58:37 beewoolie: unless openslug "assumes" the MMU is in a certain state on startup? Jan 14 16:58:50 2.6.15 which comes standard with openslug-3.1 Jan 14 16:58:52 VoodooZ: yeah. All kernels do. They assume that the MMU is off. Jan 14 16:58:55 OK. Jan 14 16:59:16 As I wrote before, it'll be a while before I can setup my slug test gear. Jan 14 16:59:38 plus apex does turn it off before booting the kernel. unless it's not?? Jan 14 16:59:58 That's ok. I'll try to do the testing for you. But I might need your input though. Jan 14 17:09:11 VoodooZ: OK. I've checked my jtag hardware again. It looks like it can run just fine at the speed of the parallel port. Jan 14 17:09:24 It needs a pull-up on the nTRST line, but that seems to be the only issue. Jan 14 17:09:45 In other words, if you are looking for a really cheap JTAG solution, that one can work. Jan 14 17:11:13 how cheap is cheap? :) Jan 14 17:11:29 The parts were about $5. Jan 14 17:11:44 unslung-image now builds again ... Jan 14 17:11:59 * beewoolie cheers Jan 14 17:15:11 AwayNAiL: http://wiki.buici.com/twiki/bin/view/Main/SimpleJTAG Jan 14 17:16:55 cool Jan 14 17:16:56 thanks Jan 14 17:20:51 AwayNAiL: if you have a problem reading the page or the site, let me know. I think I've got something borked in the apache setup, but I haven't figured it out, yet. Jan 14 17:22:35 looked ok here Jan 14 17:23:09 * AwayNAiL leaves Jan 14 17:23:11 back later Jan 14 18:13:29 jbowler-away: load -r -b 0x01000000 jffs2.image Jan 14 18:14:05 jbowler-away: when I do this the kernel doesn't recognize it as a valid initrd Jan 14 18:14:09 surely that should work, though Jan 14 18:26:32 okay, I just tried the following: upslug2 -k kernel -r ./initramfs.gz Jan 14 18:26:43 and initramfs.gz.swapped. neither worked. something seems to be wrong here Jan 14 18:35:54 I'm not sure that the upslug2 -r gets the byte swapping correct. Part of the problem is that it is loaded by RedBoot (like the kernel) Jan 14 18:36:25 <[g2]> tbm are you running BE or LE ? Jan 14 18:36:36 LE Jan 14 18:36:43 This is the Debian kernel Jan 14 18:37:11 <[g2]> jbowler-away I've built the Loft kernel LE and Redboot BE Jan 14 18:37:35 <[g2]> I think Redboot may actually be building a LE image and byteswapping it to BE Jan 14 18:37:52 I just tried BE with straight 2.6.15 Jan 14 18:37:55 Loft kernel LE should be fine Jan 14 18:38:02 again it says Jan 14 18:38:02 checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd Jan 14 18:38:09 and then: Jan 14 18:38:10 RAMDISK: Compressed image found at block 0 Jan 14 18:38:10 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Jan 14 18:38:11 RedBoot LE builds an LE RedBoot image - it has to. Jan 14 18:38:12 <[g2]> jbowler-away I need to have Redboot bot the box in LE Jan 14 18:38:37 <[g2]> So I can ship the Debian ARM LE Loft box to the UK for the Debian devs Jan 14 18:38:56 That's fine. Let me test it with slugos-ltu Jan 14 18:39:35 ... well, in a bit ... Jan 14 18:41:12 ok, I think I tried every combination Jan 14 18:41:14 be, le kernel Jan 14 18:41:20 debian kernel, straight 2.6.15 Jan 14 18:41:28 swapped and non-swapped initrd Jan 14 18:41:52 initramfs doesn't boot, ext2 (plus kernel with ext2 built in) doesn't boot Jan 14 18:42:01 a cramfs initrd boots though Jan 14 18:42:14 it would be nice if someone could try if they can boot an initramfs Jan 14 18:43:11 night Jan 14 18:56:14 <`skyhawk> Hello all! Jan 14 18:56:24 <`skyhawk> i got a very important question concering unslug 5.5 and php and apache and php module... is there anyway to get gallery and the dam config.php page to work with this config and software? i tried everything i could come up with as a novice linux user.. no luck. tried thttpd+php didnt work either, couldnt get cherokee to work properly either am i out of luck? Jan 14 18:56:39 <`skyhawk> what configuration does work so i can run gallery and the config.php page? Jan 14 18:56:54 <[g2]> tbm I can try BE Jan 14 18:58:08 that'd be great Jan 14 18:58:28 <[g2]> initramfs is on my list of things todo anyway Jan 14 18:59:25 <[g2]> tbm you are loading at 0x1d ? Jan 14 18:59:32 yes Jan 14 18:59:44 <[g2]> how big is your initramfs ? :) Jan 14 18:59:48 <`skyhawk> any help please? Jan 14 18:59:51 smaller than 10 megs Jan 14 19:00:06 <[g2]> It's gotta be smaller than 3 I think :) Jan 14 19:00:17 <[g2]> 0x20 == 32MB right ? Jan 14 19:01:11 <[g2]> tbm so I think you load is wrapping in memory Jan 14 19:01:18 <[g2]> and trashing the low part of memoy Jan 14 19:01:24 <[g2]> s/memoy/memory Jan 14 19:01:53 it's smaller than 3 megs too Jan 14 19:02:05 <[g2]> well actually 2 Jan 14 19:02:17 <[g2]> 1d + 1 for the kernel= 1E Jan 14 19:02:25 <[g2]> so E and F are left Jan 14 19:02:34 <[g2]> is it smaller than 2 ? Jan 14 19:02:47 the cramfs is almost 3 megs and loads fine. the initramfs is ~1 meg and doesn't Jan 14 19:03:53 <[g2]> you'll have to watch the cramfs as anything > 2MB may have issues Jan 14 19:04:11 <[g2]> tbm THX for the input Jan 14 19:04:29 <[g2]> sounds like size _isn't_ an issue with initramfs Jan 14 19:04:42 yeah Jan 14 19:05:25 <[g2]> tbm you initrd ext2 does work right ? Jan 14 19:05:46 no Jan 14 19:05:56 ext2, jffs2 and initramfs don't work Jan 14 19:05:57 cramfs does Jan 14 19:07:10 <[g2]> tbm I don't thing jffs2 _should_ work as initramfs Jan 14 19:07:19 <[g2]> jffs2 has to be a mtd device Jan 14 19:07:24 <[g2]> right ? Jan 14 19:08:06 I don't know. But ext2 definitely should work and doesn't; same for initramfs Jan 14 19:08:28 maybe I'm getting something obvious wrong; but I cannot see what and think it may be a bug Jan 14 19:11:22 <[g2]> tbm fully agree on the ext2 Jan 14 19:12:03 <[g2]> tbm does ext2 work as an initrd ? Jan 14 19:12:45 normally, yes. not on the slug Jan 14 19:13:35 <[g2]> tbm you are using the bork Redboot on the slug Jan 14 19:13:52 <[g2]> and you've built the cmdline into the kernel you are loading right ? Jan 14 19:15:15 <[g2]> tbm is the ext2 roofs for 2.6.15 ? Jan 14 19:15:22 yes, root=/dev/ram initrd=0x01000000,10M Jan 14 19:15:34 it cannot even mount the ext2 so this doesn't matter Jan 14 19:15:37 and yes redboot from the slug Jan 14 19:15:45 anyway, gotta sleep now Jan 14 19:15:57 <[g2]> tbm ok... could you e-mail me the initrd ? Jan 14 19:16:11 <[g2]> I should be able to load it and boot to it on my Loft Jan 14 19:16:18 <[g2]> as it's just a rootfs Jan 14 19:17:02 <[g2]> sweet dreams Jan 14 19:17:12 for initramfs just do 'find . | cpio --quiet -o -H newc > gzip -9c > initramfs.cpio.gz Jan 14 19:17:36 it doesn't really matter what it contains since it cannot actually mount/detect it Jan 14 19:17:50 the initrd I have here is LE Jan 14 19:17:57 <[g2]> ah ok Jan 14 19:18:11 <[g2]> but I could byte swap it Jan 14 19:18:30 <[g2]> anyway sweet dreams THX for all your great work Jan 14 19:23:37 [g2]: Hey man Jan 14 19:27:52 <[g2]> beewoolie ! Jan 14 19:36:48 [g2]: Guess what. That JTAG board that I build is perfectly fine. I thought it was broken all this time. Jan 14 19:37:31 <[g2]> beewoolie awesome Jan 14 20:34:18 current unslung build boots Jan 14 22:29:55 03bzhou * 10unslung/ (4 files in 3 dirs): ruby cross ready, upgrade from 1.8.3 to 1.8.4 Jan 14 23:12:24 testing Jan 14 23:12:37 testing failed Jan 14 23:12:43 s/est/estest/ Jan 14 23:12:44 jacques meant: testesting Jan 14 23:12:47 :-) Jan 14 23:13:01 this is wrong Jan 14 23:13:13 s/wrong/what I meant/ Jan 14 23:13:13 jacques meant: this is what I meant Jan 14 23:13:24 cool, ibot has a new trick Jan 14 23:13:50 rather in this channel, jbot Jan 14 23:14:00 jbot, botsnack Jan 14 23:14:01 thanks, jacques Jan 14 23:18:41 jbot, pi Jan 14 23:18:46 pi is, like, 3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091 Jan 14 23:18:59 yeah, OK **** ENDING LOGGING AT Sun Jan 15 02:59:58 2006