| lool | ogra: So this smells the overflow if 15 -> 16 blocks don't work | 07:54 |
|---|---|---|
| lool | It's not, it's APEX being clobbered by the kernel! :-) | 09:27 |
| lool | ogra: Quick, try Marc's suggestion! | 09:27 |
| ogra | lool, if my eyes are open enough :) | 09:45 |
| * ogra yawns and goes to look for coffee | 09:45 | |
| lool | ogra: Dude why did you mail debian-arm@? | 09:45 |
| lool | I told you I would mail him and I Cc:ed you | 09:45 |
| ogra | whats wrong with asking in multiple places ... | 09:46 |
| lool | It creates duplicate work? | 09:46 |
| ogra | and brings more ideas in in case the solution isnt clear | 09:47 |
| lool | I absolutely hate IRC users coming to multiple channels I'm in and copy-pasting the same question | 09:47 |
| lool | Sorry but it's resource abuse | 09:47 |
| lool | I value the high quality of the responses I get so far, I don't think Marc will give us much attention if we keep asking at multiple places | 09:48 |
| lool | It's exactly like researching before asking | 09:48 |
| ogra | well, to me it wasnt clear it was apex | 09:48 |
| ogra | apart from that the next guy having this prob will find it in the ML archive | 09:50 |
| lool | That's an issue I created, but your fix is worse than the disease | 09:51 |
| lool | It's like these cross-posts spanning multiple lists, but it's worse in that these are separate threads | 09:52 |
| ogra | well, sorry for that if you feel like that, but i still think it was okayish to have it on a public ML my questio was different and contained other information than yours, but i'll keep away from such things in the future now that i know you dont like it | 09:58 |
| lool | I basically don't want to take any chance to piss off valuable people we rely on (how would we move forward if we lose help from these folks?) | 09:59 |
| lool | And here Marc had to reply to both and said he did | 09:59 |
| lool | Probably he doesn't mind much, I'd hate if we'd do that again | 09:59 |
| lool | s/doesn't/didn't | 09:59 |
| ogra | right, i'll be more cautious about that in the future ... | 10:00 |
| lool | Thanks, I appreciate your effort | 10:02 |
| ogra | lool, hmm changing CONFIG_KERNEL_LMA=0x00008000 to 0x01000000 means that it will have the identical address CONFIG_RAMDISK_LMA has ... | 10:35 |
| ogra | i suspect we need to do some more math with that ... but will test first | 10:37 |
| * ogra goes to rebuild apex | 10:37 | |
| ogra | lool, well, it doesnt boot ... | 10:48 |
| ogra | ... but it get kernel and ramdisk loaded | 10:48 |
| ogra | lool, http://paste.ubuntu.com/116755/ | 10:49 |
| * ogra starts shuffling the ramdisk address around | 10:56 | |
| ogra | hmm, so moving the ramdisk to 0x011FFFE0 les it panic but the kernel unpacks .... | 11:09 |
| ogra | *lets | 11:09 |
| ogra | bah and our kernel stops after uncompressing | 11:19 |
| ogra | (using it unswapped, else it doesnt work at all) | 11:19 |
| ogra | hrm | 11:46 |
| ogra | lool, any idea ? the kernel is 0x00200000 big, so i add that to CONFIG_RAMDISK_LMA (making it 0x01200000) that makes the kernel load but apparently it doesnt find the initramfs and panics now | 11:48 |
| ogra | intrestingly it seems to find the start of the ramdisk ... "[42949378.630000] RAMDISK: Compressed image found at block 0" | 11:50 |
| lool | ogra: Sorry didn't follow; do you have an idea of the memory map since the board powers up down to apex calling into the kernel? | 12:00 |
| lool | I would start by writing that down | 12:00 |
| ogra | well, when i move the kernel from 8000 to 1000000 i need to move the ramdisk up by the size of the kernel | 12:01 |
| ogra | since the ramdisk used to live at 1000000 | 12:01 |
| ogra | so the kernel occupies 1000000 to 1200000 (as its 200000 big) | 12:03 |
| ogra | so naturally the ramdisk load address needs to be 1200000 | 12:03 |
| ogra | HA ! lool !! got it :) indeed we also need to adjust the max size of the ramdisk, it boots with CONFIG_RAMDISK_SIZE=0x00400000 | 12:15 |
| ogra | i'll try to bump that up bock by block now to find the possible max limit, then we should be done ... only a fixed eb kernel is missig | 12:16 |
| lool | Right, kernel is being loaded at 0x00008000, ramdisk at 0x01000000 | 12:17 |
| ogra | right, now kernel is 0x01000000, ramdisk is at 0x01200000 and ramdisk size is 0x00400000 ... with these values it boots just fine | 12:18 |
| lool | ogra: That's only 2M for kernel | 12:18 |
| lool | ogra: Where is the kernel unpacked? | 12:19 |
| * lool lunch & | 12:19 | |
| ogra | erm, its unpacked in ram, these values are flash | 12:20 |
| ogra | its only about the flash partitions apex uses | 12:21 |
| ogra | err, strike that | 12:27 |
| ogra | apex assigns 8M in ram it seems and then copies itself and the flash partitions to that area | 12:28 |
| ogra | why would you want more than 2M for the kernel ? | 12:30 |
| ogra | all former debian kernels are below 1.5M and i expect us to still drop some bload from the 1.9M we have now | 12:39 |
| ogra | *bloat | 12:39 |
| lool | ogra: ?? | 13:14 |
| lool | ogra: isn't 0x00008000 the address where to copy to? | 13:14 |
| lool | ogra: The flash read address is fis://kernel, the RAM write address 0x00008000 | 13:15 |
| ogra | yeah, ignore me | 13:15 |
| lool | ogra: "why would you want more than 2M for the kernel" well we just hit the case where the preceeding assumptions were not enough | 13:15 |
| ogra | i thought we had the 8M limit in ram as well, but that doesnt seem to be the case at all | 13:15 |
| lool | Why not make sure we cover all cases and solve the problem once and for all? | 13:15 |
| lool | slugimage works no matter what sizes you pass to it for instance | 13:15 |
| ogra | yes, i just booted with a ramdisk at 0x01400000 | 13:16 |
| lool | So if the contents are discarded, I'd recommend loading apex, kernel, and initrd at 0, 8M, and 16M | 13:16 |
| lool | that way we shouldn't ever have to worry about them | 13:16 |
| ogra | i'm just trying with 6M for the kernel | 13:16 |
| lool | The flash is 8M right? | 13:16 |
| ogra | i'll do 8 next | 13:16 |
| ogra | yes | 13:16 |
| ogra | so the bigger the kernel gets the more we limit ourselves on the ramdisk wrt flash ... | 13:17 |
| ogra | lool, ok, seems the max limit for the ramdisk size is actually 5636080 bytes (our flash ramdisk partition size ...) if i go above it it corrupts the initrd ... | 13:22 |
| ogra | and it seems it doesnt matter where i load it to so 0 and 8M wont be an issue, but 16M wont be possible due to the 8M flash constraint | 13:23 |
| lool | ogra: I want us to plan the apex script to accept any theoritical initrd or kernel sizes | 13:24 |
| lool | And apex' builtin defaults | 13:25 |
| ogra | not for jaunty though | 13:25 |
| lool | Why not? | 13:25 |
| ogra | that really requires deep apex tinkering and a proper spec imho | 13:25 |
| ogra | feature freeze is in 8 days | 13:25 |
| lool | So you prefer learning it all, implementing a workaround, then having to learn it all again to fix it properly or simply not bother to fix it properly? | 13:26 |
| ogra | no, i prefer to have sane defaults for now and to add additional features if we have time for that | 13:26 |
| ogra | i havent touched the touchscreen issues at all yet, we dont even have a working kernel for the slug etc etc ... | 13:27 |
| lool | Why would a ramdisk size larger than 5636080 corrupt the initrd? | 13:27 |
| lool | I hate leaving things half fixed when we can fix them properly | 13:28 |
| lool | This is seriously not fun for me to invest so much time on an issue and then look back and think "I didn't really fix it" | 13:28 |
| ogra | i guess thats a question for marc ... using any bigger size than the one we padded it to simply results in a panicking kernel | 13:28 |
| lool | I think I shouldn't have looked at this issue at all, it's too frustrating, we don't have the same goals | 13:29 |
| ogra | right, so do you want me to drop all my specs for supporting an arch nobody uses ? | 13:29 |
| lool | I guess it depends how much time you think you need to fix it properly versus implementing a workaround | 13:30 |
| ogra | the only committment i have atm is to get a working d-i image for that thing | 13:30 |
| ogra | which i have now module a decision on the proper default values for apex | 13:30 |
| ogra | and a working kernel ... which isnt in my hands | 13:31 |
| ogra | lool, moving the apex VMA adress to 3MiB seems to work as well as shuffling kernel and rmadisk adresses, given that we differ in only one value from debian here (and will likely be able to convince tham to accept that as default) i'll g with that ... the ramdisk size propblem persists though and i think its likely due to the fact that apex tries to assign a memory area but the ramdisk image itself doesnt fill that up with zeroes as soon as the apex va | 15:07 |
| ogra | lue is bigger than the actual partition ... values between the actual initrd.gz size up to the padded partition size do work well, i'll ask on debian-arm to get a confirmation from marc about the theory | 15:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!