[01:25] someone knows if GNAT will be available with Ubuntu ARM ? [12:06] lool, so just not byteswapping the kernel doesnt solve the nslug bootprob [12:07] ogra: Does it help booting the Debian kernel? [12:08] you mean i should dump the debian kernel into d-i during build ? [12:08] (just curious) [12:08] ogra: No, serve it over HTTP and boot [12:08] ogra: Cause it was simply hanging in my tests [12:08] oh, i would have to reflash to redboot again [12:08] ogra: I guess it's the apex partition then [12:08] which is a bit tricky without a bootable system atm [12:08] Reflash to redboot? just load it from redboot over HTTP and exec it [12:08] You don't have redboot in your current image?! [12:09] its using apex [12:09] di-nslu2.bin has apex .... [12:09] APEX is loaded by RedBoot [12:09] di-nslu2.bin wont touch your redboot... [12:09] I hope you didn't erase the full flash, but the default in upslug is not to [12:09] oh, right, it scrolled off screen :P silly me [12:10] well, i'm ore intrested in why our kernel just dies ... [12:10] its not even uncompressing [12:12] and i would it to do so now that i have a di-nslu2.bin without changed byteorder [12:12] *would expect it to [12:48] ogra: From the nslu2 README: [12:48] In practice, this means that there is only 1 MB of space for [12:48] the kernel because the initrd starts 1 MB after the kernel. [12:48] meh [12:48] Might be why our initrds don't work with plain redboot [12:48] -rw-r--r-- 1 ogra ogra 1,9M 2009-02-10 12:34 vmlinuz-2.6.28-7-ixp4xx [12:49] That's ok [12:49] It's just when you use plain redboot [12:49] - A partition for the kernel: the kernel is split in two and each parts [12:49] have a header [12:49] However our redboot tests are useless [12:49] right [12:50] i want a working binary blob [12:51] * ogra wonders off reading http://www.nslu2-linux.org/wiki/Info/BootFlash [12:59] ogra: Would be nice to have the nslu2 firmware for the ethernet device in restricted and build with it [13:00] lool, definately [13:00] i dont get where they put the second half of the kernel [13:00] ogra: There's a single partition for the kernel, but it's written in two parts [13:00] how does a >1M kernel fit in there ? [13:01] debians is 1.3M, also bigger than 1M [13:02] [part 0 ][part 1 config][part 2 ][part 3 ] [13:02] The problem is that RedBoot looks at part 2 + 1M to find a special magic [13:02] We don't care about what it loads except that it loads apex fine [13:02] But it needs to find its magic [13:03] oh, so the whole device is 8M in any case, we just need to set the magic mark at the right point [13:03] * ogra slowly gets it [13:04] what a silly design [13:04] It's due to the restrictions of linksys' redboot [13:04] ah, right http://tech.groups.yahoo.com/group/nslu2-linux/message/33 doesnt talk about mtdblock3 at all [13:05] Wow the make foo in build/config/armel/ixp4xx/netboot.cfg is awful [13:05] heh [13:05] yeah [13:18] ogra: So how did you try to revert the endianess of the kernel? [13:19] I see nothing wrong with Colin's changes [13:19] i just commented the devio line and didnt use .swapped at the bottom [13:19] which should make it use the kernel 1:1 [13:20] but the behavior is identical, swapped or not [13:21] its just hangs after "copy -s fis://kernel 0x00008000" in both cases [13:22] hmm, though shouldnt that be 0x00010000 ? [13:22] ah, no, its right [13:23] This skips APEX [13:24] no [13:24] that is apex output [13:25] * ogra re-flashes the debian di binary to compare [13:25] I'm saying this offset is to skip APEX, but actually it's not [13:28] # copy -s $kernelsrc $bootaddr [13:28] # copy -s fis://kernel 0x00008000 [13:28] 1441760 bytes transferred [13:28] ok, thats the debian output [13:28] So this is in the APEX package which is built specifically for the NSLU2, how inelegant [13:28] complain to martin michlmayer :) [13:29] i think he rlled most of these packages initially [13:29] *rolled [13:30] No, Marc Singer did [13:30] he wrote apex [13:30] Well I'm complaining about apex [13:30] ah [13:30] i thought about how it was used [13:31] i mean apex is only a bootloader in the end, like uboot, no ? [13:31] Yes, my problem is that its script is hardcoded in the apex package [13:32] hmm, looking at the debian d-i code: [13:32] util/pad $(TEMP)/initrd.gz.nslu2 6291440 # size of partition - 16 for header [13:33] i wonder if colin didnt pick to high values [13:34] hmm, no the sum is identical [13:37] so what about raising the kernel partition size by 1 block [13:37] ogra: Do you have debian installed? [13:37] Could you run apex-env in it? [13:37] i.e. to 2228192 [13:37] I'd like to confirm that the script is like "copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr" [13:38] no, i dont, and it takes 8h to do so [13:38] yes, it is [13:38] actually: [13:38] copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C key to cancel autoboot.; boot [13:38] i can see that by using the di binary blob [13:38] its executed exactly in that order [13:39] Use the command 'help help' to get started. [13:39] # copy -s $kernelsrc $bootaddr [13:39] # copy -s fis://kernel 0x00008000 [13:39] 1441760 bytes transferred [13:39] # copy -s $ramdisksrc $ramdiskaddr [13:39] # copy -s fis://ramdisk 0x01000000 [13:39] 6291440 bytes transferred [13:40] # wait 10 Type ^C key to cancel autoboot. [13:40] Type ^C key to cancel autoboot. [13:40] # boot [13:40] there is a semicolon missing though, it doesnt wait at all [13:41] ogra: I wonder if this is an overrun ... [13:41] thats why i said we should probably give the kernel one more block [13:41] CONFIG_RAMDISK_LMA=0x01000000 [13:42] ogra: really? I think it does wait one second [13:42] I had the apex prompt more than once [13:42] it doesnt here [13:42] CONFIG_AUTOBOOT_DELAY=10 [13:42] * ogra tries again ... i might just be to slow [13:43] prompts the user and waits a specified number of 10ths of a second. [13:43] So it's 10th of a secnd [13:43] ah, yeah, constantly hitting ctrl-c while the ramdisk loads helps [13:44] i was expecting 10 secs :P [13:44] silly [13:44] I know [13:44] so while i'm at the apex prompt, anything you want from printenv ? [13:45] startup *= copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C key to cancel autoboot.; boot [13:45] ogra: Yeah, all values [13:45] apex> printenv [13:45] fis-drv *= nor:0x7e0000+4k [13:45] cmdline *= console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug [13:45] cmdline-alt *= console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug [13:45] startup *= copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C key to cancel autoboot.; boot [13:45] for bootaddr ramdiskaddr [13:45] ramdisksrc-alt *= fis://ramdisk [13:45] ramdisksrc *= fis://ramdisk [13:45] kernelsrc-alt *= fis://kernel [13:45] kernelsrc *= fis://kernel [13:45] ramdiskaddr *= 0x01000000 [13:45] bootaddr *= 0x00008000 [13:45] apex> [13:45] there you go [13:45] nor:0x7e0000+4k hmm [13:47] ogra: is this from debian or ubuntu? [13:47] debian [13:47] i cant get to the apex prompt on ubuntu [13:47] really? that's suspicious [13:47] no, thats logical [13:48] why so? [13:48] the prompt comes after loading [13:48] loading of apex [13:48] it gets stuck loading the kernel [13:48] Oh right [13:48] i can get into the redboot prompt [13:48] but not apex [13:48] the wait should be at the beginning [13:48] yeah [13:48] silly design [13:49] though you dont gain anything being in apex anywa [13:49] y [13:49] the whole config is readonly ... [13:49] you can only modify it from the running system via apex-env [13:50] Yes [13:50] ogra: setenv doesn't work? [13:50] so i dont know why it has a prompt at all [13:51] nope [13:51] i tried to change the cmdline parameter before ... doesnt apply [13:51] apex> setenv cmdline 'console=ttyS0,115200 noirqdebug' [13:51] Environment region is unwritable [13:52] so having a prompt is just fake [13:52] You can type commands [13:53] right, the ones that are executed anyway [13:54] the only most intresting thing, changing the cmdline doesnt work [13:55] ogra: You can pass cmdline to boot [13:55] "boot [-g ADDRESS] [COMMAND_LINE]\n" [13:55] oh, i didnt know that [13:55] ogra: Perhaps you should read apex [13:55] that makes it a bit more useful then [13:55] yeah [13:55] So the fis://kernel works even with a split kernel [13:56] Because APEX has an extension to RedBoot partitions [13:56] To skip some areas [13:56] Check README_fis in apex' source [13:57] I don't understand why it's not copy fis://kernel@16 $bootaddr [14:01] ogra: It might be best to not rely on byteswapping the kernel but rebuild it though [14:01] amitk: Hey [14:01] i'm just doing a build in the background with one more block shifted to the kernel [14:01] amitk: CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y is set in debian/config/armel/config.ixp4xx, but not in Debian [14:02] amitk: This needs fixing in all cases (even if that's correct) [14:02] amitk: Basically the hardware supports both, but we're an armel port and the debian tools assume a LE kernel which gets byteswapped at various places (flash-kernel, d-i) [14:02] swapped or unswapped, it doesnt load [14:02] amitk: So it's easier to have the same type of kernel in Ubuntu [14:02] so i expect we are exceeding the size [14:03] hrm, the other loic suddenly hunts me in #edubuntu ... i wonder what he wants [14:04] ogra: I think I'll drop the ball here on NSLU2; if you are stuck, you could try mailing Marc Singer, he helpfully replied to me when I asked about the shim's COPYING file being missing [14:04] lool: ack. We will stick to one type for the kernel. [14:04] ogra: If you show that you researched it that far, he might be willing to help !Debian [14:04] amitk: thanks; do you need a bug? [14:04] lool: I guess that CONFIG option automatically gets set on selecting ixp4xx, let me check [14:05] lool: if ARCH_IXP4XX [14:05] config ARCH_SUPPORTS_BIG_ENDIAN bool default y [14:06] in Kconfig [14:06] amitk: Ack; the device can do both so the upstream bit doesn't make any sense to me, but please force it to LE [14:13] amitk: Did you get your NSLU2 to work BTW? [14:15] lool: -EOUTOFSOLDER, will head to store a bit later [14:15] * ogra hopes amitk has a pump to get the solder out of the holes [14:15] its really painful without [14:16] amitk, ogra: I'd love if you two could sort this out quickly; I think I understand most of it, but can't usefully research without a device [14:16] well, let me builod a kernel if you think thats the solution [14:17] and inject it into the di binary [14:17] i still suspect its a size issue though [14:17] lool: I can give you a kernel if you need [14:17] ogra: size issue for initramfs? [14:17] amitk: I wouldn't have much use of it without a device :) [14:17] amitk, no issue with the apex partition shufflung we do to make our kernel fit [14:18] amitk, gimme kernel :) [14:18] amitk: The way the NSLU2 firmware is built is quite complex [14:18] amitk: Do not rely on RedBoot to do regular stuff, it hardcodes plenty of stuff and wont work correctly (can't pass cmdline, expects initrd at specific address etc.) [14:18] amitk, the prob is that our kernel is nearly 2M big, debians is only 1.3 [14:19] amitk: Debian/Ubuntu use APEX as a second state loader with some special partition mappings for redboot to be happy [14:19] so the apex partitioning for the di binary blob needs adjustment [14:19] ogra: You could try building an image with Debian's kernel to see if that boots [14:19] ogra: It might be that one of our binaries is broken [14:19] lool: so it was confirmed that redboot cmdline doesn't work [14:19] ? [14:19] lool, well, if amit has a kernel for me i'll try that first [14:19] amitk: Yes [14:19] ogra: You can try both :) [14:19] lool, well, the kernel loads if you load it from redboot via http [14:20] i'll try everything that can get me towards a solution indeed :) [14:20] ogra: Exactly my point, we know the Ubuntu kernel works and the Debian kernel as well; but the Debian one is smaller and not swapped [14:20] since thats our only arch we target for jaunty ;) [14:20] ogra: You could see if that helps, if amitk's kernel doesn't work and Debian's does, then you know that the partitioning changes are wrong [14:20] If both work, then we're done :) [14:20] well, amits kernel wont be smaller [14:21] ogra: Err yes, that's my point [14:21] ogra: Which is why I'm hinting at the Debian one? :) [14:21] Both are useful tests [14:21] ogra: It could be with allnoconfig I guess [14:21] oh, so you mean keep the shuffled partitions and just use debians kernel [14:22] ogra: No, you revert the partition shuffling and confirm that our d-i + apex + debian kernel and initrd work [14:22] ogra: or you keep the partition shuffling and confirm that our d-i + apex + debian kernel and initrd work [14:22] right, but then i need to change two aspects to try out ours [14:22] ogra: or you keep the partition shuffling and confirm that our d-i + apex + amitk's kernel and initrd work [14:22] which doesnt tell me much mor than i already know [14:22] doubt amitk will hand you an initrd though [14:23] * amitk agrees, he hates initrds [14:23] right, i need to do the tests both with a shuffled partitioning scheme to keep the same env [14:23] Anyway, use your logic [14:23] i dont care about initrd atm [14:23] * lool moves his brain to something else [14:55] lool, so it is definately partitioning scheme it stops with the exact same symptoms using debians kernel [14:56] i'll try to confirm by using their scheme with their kernel [15:20] ogra: it could be our APEX or whatever; you might want to try the debian kernel with the debian partitioning scheme [15:20] in our d-i with our apex etc. [15:21] yes, thats what i'm currently fiddling with [15:36] lool, yep. debian kernel and debian partitioning scheme works [15:36] ogra: Ok [15:37] even with our initrd.gz [15:37] ogra: Might be slugimage not liking this change then [15:37] yeah [15:37] sigh ... i have to dig out my perl foo i fear [15:37] Ah got it [15:37] my($kernel_offset) = 0x00060000; [15:37] my($kernel_size) = 0x00100000; [15:37] my($ramdisk_offset) = 0x00160000; [15:37] oh [15:38] That's likely the issue [15:38] IMO [15:38] shouldnt the first one be 80000 [15:38] (additionally to the size mistmach) [15:39] Hmm be careful, these are redboot partitions, not apex partitions [15:39] * ogra goes to try with 2M [15:39] yeah, i wont change the kernel offset [15:39] only size and ramdisk offset [15:41] You have a debug flag for slugimage [15:45] hrm, just changing to 0x00200000 and 0x00260000 respectively doesnt work [15:46] it doesnt have a ramdisk_size parameter [15:46] The kernel_size is just where to split the kernel [15:47] oh, so just bumping ramdisk_offset should suffice [15:47] Not sure, you could try [15:47] Bump it by 5 blocks [15:47] i will luckily the script is freindly nough to tell me if it breaks :) [15:48] 0x00200000 [15:48] oh i used 22 [15:49] Perhaps I miss computed [15:49] Ran out of flash space in - 0xA0000 bytes too large. [15:49] nope [15:49] That's what we added [15:49] ogra: Do you have a debug run? [15:50] http://paste.ubuntu.com/116488/ [15:51] Hmm it doesn't list the skip partitions [15:52] oh, wait i made a mistake i think ... i padded initrd twoce [15:54] yay [15:54] didnt choke [15:55] * ogra waits for upslug [15:57] ogh [15:57] that trashed apex [16:03] nope, no way [16:04] what if we just cut down our kernel ? [16:07] lool, i think slugimage is the wrong attempt [16:08] it just makes sure the redboot markers are in the right place [16:09] ogra: I'd like to see the final partition table [16:09] it's missing from your paste [16:09] print "after buildPartitionTable():\n"; [16:10] ogra: Ideally, compare the output from debian layout wiht debian kernel with ubuntu layout with debian kernel [16:10] because it failed :) [16:11] it didnt get to that point, you asked for a debug output when i did a failed attempt ... one sec [16:11] I know, but the most interesting output is when the image builds.. [16:11] http://paste.ubuntu.com/116497/ [16:12] thats with unmodified slugimage but our sizes [16:12] Loader 0x00060000 0x00020000 [0x00000/0x00010] [16:12] Kernel 0x00080000 0x00200000 [0x00000/0x00010, 0xE0000/0x00010] [16:12] The right part are skips [16:13] ogra: Would be nice to have a "normal" run with debian's configs [16:16] lool, http://paste.ubuntu.com/116499/ [16:18] comparing the two it seems to DTRT [16:18] it properly recognizes the different blocksizes and adjusts itself [16:21] i start to suspect its an apex limitation [16:24] hrm, d-i fails at the hw detection step without the firmware [16:24] which makes it pretty useless [16:31] Ok, now I know why it doesn't use fis://kernel@16 but just fis://kernel [16:36] Erf don't set ibase before obase in bc [16:37] The 0xE0000 skip is exactly on the initrd, that seems alright hmm [16:40] ogra: kernel size is too small [16:40] Kernel 0x000800000x00160000[0x00000/0x00010, 0xE0000/0x00010] [16:40] 0x00160000 is too small [16:40] our kernel is 1977064 [16:40] right [16:41] but kernel size needs to cooperate with ramdisk offset, no ? [16:41] or do you think just bumping it helps ? [16:42] hmm, slugimage doesnt complain [16:43] ogra: The kernel is presumably truncated; it seems to be a bug in the perl script [16:47] ogra: Oh was looking at the Debian output [16:47] So that's correct for Debian crap [16:49] lets see, i just bumped kernel size blindly to 0x00200000 [16:49] and padded the two files with our values [16:49] * ogra is upsluggin ... [16:50] * ogra has to go shopping soon, will be out for 1-1.5h [16:50] IIUC, you shouldn't have to touch slugimage; it's meant to be generic [16:50] yeah [16:51] and it didnt work anyway [16:51] ogra: So APEX hangs where exactly? [16:51] same symptoms as always [16:51] After the load? [16:51] # copy -s $kernelsrc $bootaddr [16:51] # copy -s fis://kernel 0x00008000 [16:52] / [16:52] the fan animation below does oen or two rotations and then stops [16:52] *one [16:53] I'll shoot an email to the apex maintainer [16:54] ogra: Hmm I don't understand how you achieve the ubuntu call to apex [16:55] ogra: Why does slugimage detect a changed kernel size when you're passing vmlinuz-2.6.26-1-ixp4xx.swapped in both cases [16:55] Oh nevermind, I get it [16:55] It's padded by d-i [16:57] grr [16:58] yes, as i suspected kernel_size has no influence at all [16:58] no matter what value i set for it it works [16:58] but as soon as i change the padding it breaks [16:59] i will find out how big the kernel partition can grow by adjusting it block by block after shoppin [16:59] g [17:00] we'll see where it chokes then [17:01] lool, hmm, are you aware that the apex version we use is ancient ? [17:02] heh, the version we use doesnt even exist upstream [17:02] ogra: ohhh [17:02] 2007.01.29 (apex-1.4.13) [17:03] ogra: Try adding one block more [17:03] 2007.02.15 (apex-1.4.16) [17:03] there are no .14 or .15 ones [17:03] apex | 1.4.15.2ubuntu1 | jaunty | source [17:03] ogra: Could you try adding one more block to the kernel and one less to the initrd? [17:03] and we use 1.4.15.2 according to the bootmessage [17:04] oh, you found out already :) [17:04] 1.4.15 works on Debian [17:04] and on Ubuntu with debain kernel [17:04] one more to our scheme or debians ? [17:04] ogra: To our scheme [17:04] ok [17:04] I think we're hitting a corner case with our value [17:07] flashing [17:07] now that would be cool [17:07] what got you the idea ? [17:08] Well it seemed the ramdisk would write exactly on top of the kernel's skip [17:09] ah [17:09] * ogra twiddles thumbs [17:09] resetting [17:09] nope :( [17:10] same symptoms [17:10] as i said, i'll start changing it block by block until it hits the fan if i'm back [17:10] so we see the exact limit [18:50] lool, hmm [18:51] lool, i dont get why colin cuts off 21bytes from the initrd instead of thw 16 debian does [18:51] *the [18:51] til/pad $(TEMP)/initrd.gz.nslu2 6291440 # size of partition - 16 for header .... thats debian ... [18:51] util/pad $(TEMP)/initrd.gz.nslu2 5636080 # size of partition - 21 for header .... thats ours [19:13] lool, sooo ... making the kernel partition one block smaller works fine [19:14] though it panics ... [19:14] * ogra tries if he can fit the ubuntu kernel into that [19:19] hmm, no [19:25] * ogra dances !! [19:26] err [19:26] hrm [19:28] argh [19:29] ok, its officially not my day ... [20:39] ogra: He didn't cut 21 bytes but 16 and I made him fix that comment in bzr already [20:39] ogra: (earlier this morning) [20:39] yeah [20:40] lool, so i think what we want is CONFIG_RAMDISK_SIZE=0x004CCCC0 in the apex config [20:40] Hmm [20:41] that gives us 5033152 bytes for the initramfs and leaves more than 1.9M for the kernel [20:41]