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