[01:25] <Ramon_Valdez> someone knows if GNAT will be available with Ubuntu ARM ?
[12:06] <ogra> lool, so just not byteswapping the kernel doesnt solve the nslug bootprob
[12:07] <lool> ogra: Does it help booting the Debian kernel?
[12:08] <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:09] <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:10] <ogra> well, i'm ore intrested in why our kernel just dies ...
[12:10] <ogra> its not even uncompressing
[12:12] <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:48] <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:49] <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:50] <ogra> i want a working binary blob
[12:51]  * ogra wonders off reading http://www.nslu2-linux.org/wiki/Info/BootFlash
[12:59] <lool> ogra: Would be nice to have the nslu2 firmware for the ethernet device in restricted and build with it
[13:00] <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:01] <ogra> debians is 1.3M, also bigger than 1M
[13:02] <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:03] <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:04] <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:05] <lool> Wow the make foo in build/config/armel/ixp4xx/netboot.cfg is awful
[13:05] <ogra> heh
[13:05] <ogra> yeah
[13:18] <lool> ogra: So how did you try to revert the endianess of the kernel?
[13:19] <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:20] <ogra> but the behavior is identical, swapped or not
[13:21] <ogra> its just hangs after "copy -s fis://kernel 0x00008000" in both cases
[13:22] <ogra> hmm, though shouldnt that be  0x00010000 ?
[13:22] <ogra> ah, no, its right
[13:23] <lool> This skips APEX
[13:24] <ogra> no
[13:24] <ogra> that is apex output
[13:25]  * 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:28] <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:29] <ogra> i think he rlled most of these packages initially
[13:29] <ogra> *rolled
[13:30] <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:31] <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:32] <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:33] <ogra> i wonder if colin didnt pick to high values
[13:34] <ogra> hmm, no the sum is identical
[13:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <ogra> so having a prompt is just fake
[13:52] <lool> You can type commands
[13:53] <ogra> right, the ones that are executed anyway
[13:54] <ogra> the only most intresting thing, changing the cmdline doesnt work
[13:55] <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:56] <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:57] <lool> I don't understand why it's not copy fis://kernel@16 $bootaddr
[14:01] <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:02] <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:03] <ogra> hrm, the other loic suddenly hunts me in #edubuntu ... i wonder what he wants
[14:04] <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:05] <amitk> lool: if ARCH_IXP4XX
[14:05] <amitk> config ARCH_SUPPORTS_BIG_ENDIAN bool default y
[14:06] <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:13] <lool> amitk: Did you get your NSLU2 to work BTW?
[14:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23]  * 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:55] <ogra> lool, so it is definately partitioning scheme it stops with the exact same symptoms using debians kernel
[14:56] <ogra> i'll try to confirm by using their scheme with their kernel
[15:20] <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:21] <ogra> yes, thats what i'm currently fiddling with
[15:36] <ogra> lool, yep. debian kernel and debian partitioning scheme works
[15:36] <lool> ogra: Ok
[15:37] <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:38] <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:39] <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:41] <lool> You have a debug flag for slugimage
[15:45] <ogra> hrm, just changing to 0x00200000 and 0x00260000 respectively doesnt work
[15:46] <ogra> it doesnt have a ramdisk_size parameter
[15:46] <lool> The kernel_size is just where to split the kernel
[15:47] <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:48] <lool> 0x00200000
[15:48] <ogra> oh i used 22
[15:49] <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:50] <ogra> http://paste.ubuntu.com/116488/
[15:51] <lool> Hmm it doesn't list the skip partitions
[15:52] <ogra> oh, wait i made a mistake i think ... i padded initrd twoce
[15:54] <ogra> yay
[15:54] <ogra> didnt choke
[15:55]  * ogra waits for upslug
[15:57] <ogra> ogh
[15:57] <ogra> that trashed apex
[16:03] <ogra> nope, no way
[16:04] <ogra> what if we just cut down our kernel ?
[16:07] <ogra> lool, i think slugimage is the wrong attempt
[16:08] <ogra> it just makes sure the redboot markers are in the right place
[16:09] <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:10] <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:11] <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:12] <ogra> thats with unmodified slugimage but our sizes
[16:12] <lool> Loader          0x00060000	0x00020000	[0x00000/0x00010]
[16:12] <lool> Kernel          0x00080000	0x00200000	[0x00000/0x00010, 0xE0000/0x00010]
[16:12] <lool> The right part are skips
[16:13] <lool> ogra: Would be nice to have a "normal" run with debian's configs
[16:16] <ogra> lool, http://paste.ubuntu.com/116499/
[16:18] <ogra> comparing the two it seems to DTRT
[16:18] <ogra> it properly recognizes the different blocksizes and adjusts itself
[16:21] <ogra> i start to suspect its an apex limitation
[16:24] <ogra> hrm, d-i fails at the hw detection step without the firmware
[16:24] <ogra> which makes it pretty useless
[16:31] <lool> Ok, now I know why it doesn't use fis://kernel@16 but just fis://kernel
[16:36] <lool> Erf don't set ibase before obase in bc
[16:37] <lool> The 0xE0000 skip is exactly on the initrd, that seems alright hmm
[16:40] <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:41] <ogra> but kernel size needs to cooperate with ramdisk offset, no ?
[16:41] <ogra> or do you think just bumping it helps ?
[16:42] <ogra> hmm, slugimage doesnt complain
[16:43] <lool> ogra: The kernel is presumably truncated; it seems to be a bug in the perl script
[16:47] <lool> ogra: Oh was looking at the Debian output
[16:47] <lool> So that's correct for Debian crap
[16:49] <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:50]  * 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:51] <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:52] <ogra>  /
[16:52] <ogra> the fan animation below does oen or two rotations and then stops
[16:52] <ogra> *one
[16:53] <lool> I'll shoot an email to the apex maintainer
[16:54] <lool> ogra: Hmm I don't understand how you achieve the ubuntu call to apex
[16:55] <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:57] <ogra> grr
[16:58] <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:59] <ogra> i will find out how big the kernel partition can grow by adjusting it block by block after shoppin
[16:59] <ogra> g
[17:00] <ogra> we'll see where it chokes then
[17:01] <ogra> lool, hmm, are you aware that the apex version we use is ancient ?
[17:02] <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:03] <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:04] <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:07] <ogra> flashing
[17:07] <ogra> now that would be cool
[17:07] <ogra> what got you the idea ?
[17:08] <lool> Well it seemed the ramdisk would write exactly on top of the kernel's skip
[17:09] <ogra> ah
[17:09]  * ogra twiddles thumbs
[17:09] <ogra> resetting
[17:09] <ogra> nope :(
[17:10] <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
[18:50] <ogra> lool, hmm
[18:51] <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
[19:13] <ogra> lool, sooo ... making the kernel partition one block smaller works fine
[19:14] <ogra> though it panics ...
[19:14]  * ogra tries if he can fit the ubuntu kernel into that 
[19:19] <ogra> hmm, no
[19:25]  * ogra dances !!
[19:26] <ogra> err
[19:26] <ogra> hrm
[19:28] <ogra> argh
[19:29] <ogra> ok, its officially not my day ...
[20:39] <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:40] <ogra> lool, so i think what we want is CONFIG_RAMDISK_SIZE=0x004CCCC0 in the apex config
[20:40] <lool> Hmm
[20:41] <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:42] <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:43] <ogra> we do
[20:43] <ogra> thats the prob
[20:44] <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:45] <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:46] <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:47] <lool> ogra: It's certainly not our bug as we hang in the kernel copy
[20:48]  * 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:49] <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:50] <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:51] <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:52] <lool> hmpf
[20:52] <ogra> i didnt see the second 5
[20:54] <ogra> ok, i'll do a testbuild of apex with the change lets see if i get it booting then
[20:55] <ogra> sorry for being so dense ... i really cant see any hex anymore