=== jmc93739653 is now known as jmc93739653_ === jmc93739653_ is now known as jmc93739653 [04:08] lol [04:08] "This is the bug tracker, with mail notifications going to developers who have" [04:08] many things to work on. Please keep the discussion to necessary technical [04:08] details. Refusal to do so may result in termination of your account. We hope [04:08] for your understanding. === asac_ is now known as asac [08:31] gregoiregentil: Thanks; I had not tested it, will look at fixing the patch to use MOUNTPOINT === ogra_ is now known as ogra [11:11] fresh uboot-imx is uploaded with the lastest patchset ... [11:18] lool, i could need some expert help with image partitioning .... http://paste.ubuntu.com/354966/ has the script that alex and i worked out for uboot images based on redboot-install, but somehow that results in a vfat partition uboot only reads corrupted data from [11:19] you probably see something obvious we both dont find [11:21] Hi there... does anyone know why there were no armel daily-live images for the last couple of days? [11:22] 20100108 seems to work well, but the more recent images seem to have no armel variants. [11:23] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-imx51/ doesnt indicate that there were any builds [11:23] not even attempts [11:24] Is that expected, or did something go wrong? [11:25] http://cdimages.ubuntu.com/ports/daily-live/ has 20100110 and 20100111, but they only seem to have ia64 and powerpc [11:26] ogra: Does it relate to some other script? [11:26] dmart: That's when the build failed [11:26] Hmm someone dropped the weather report from the topic [11:28] sorry reconnect [11:28] Ah perhaps only -mobile had it [11:28] dmart: http://qa.ubuntu.com/reports/ogasawara/weatherreport.html [11:28] no hanging procs on the main buildserver [11:28] i wonder why there are no buiold attempts then [11:29] dmart: So what it means is that either the ISO or the livefs failed to build [11:29] dmart: livefs http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ [11:29] No log at all :-/ [11:30] Strange [11:30] right, as i said, no attempt [11:30] x86 built though ... so the builds were not disabled [11:32] The crons certainly list armel [11:32] right [11:32] hello .. I'm happy :) .. Karmic is running fine on my new board ( http://www.technexion.com/index.php/thunderpack ) [11:33] great to hear === ogra_ is now known as ogra [11:38] Can I add this board to "ARM/DeviceSupport" on ubuntu wiki ? [11:39] ===== Downloading live filesystem images ===== [11:39] Mon Jan 11 05:35:27 GMT 2010 [11:39] Read error (Connection reset by peer) in headers. [11:39] That's how the CD build fail [11:39] I suspect the livefs builder is down [11:39] yep [11:40] i pinged lamont already [11:41] ADcomp: Which kernel tree supports the board? [11:41] ADcomp: Does linux-omap support it? linux? [11:42] lool: 2.6.31 [11:43] ADcomp: You mean naked linux 2.6.31 will support this board? [11:46] lool: compiling this one : https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-stable [11:46] ogra: touch can be dropped at the start of the script [11:46] thats from linux-omap [11:47] lool, yeah, i noted that too, alex added it, but thats surely not the issue [11:47] ogra: I'm reading it anyway, so better making comments on all things I see [11:48] UBOOT_SIZE=$(wc -c $UBOOT_BIN |cut -d ' ' -f1) => stat much better [11:48] i also want to switch to your ingenious way of creating the empty image without time loss [11:48] lool: diff = http://pastebin.com/f60903eb6 [11:48] stat -c %s foobar [11:48] lool, yeah, i havent ported all the functions yet, stat will be used in the next iteration [11:48] yep [11:48] the other script has a proper function for it [11:49] ogra: The first partition seems too small to me [11:50] 142848B [11:51] ogra@osiris:~/Desktop/uboot$ ls -l uboot-imx51_to3.bin [11:51] -rwxr-xr-x 1 ogra ogra 142952 2010-01-07 17:20 uboot-imx51_to3.bin [11:51] You changed FIS_SIZE to UBOOT_SIZE, but the FIS starts at offset zero of the disk while UBOOT starts at offset zero of the partition [11:51] hrm [11:51] you are right [11:51] You need to add 512 to UBOOT_SIZE - 1 [11:51] * ogra slaps forehead ... [11:51] oh my ! [11:51] * ogra blushes [11:51] indeed [11:51] asac, ^^^ [11:52] Ah hold on, you actually seek and skip 1024 bytes in UBOOT_BIN [11:52] Where do these 1024 come from? Is this padded? [11:52] yes, so it needs to be 1024 [11:52] no [11:52] could be 512 [11:52] well. [11:52] i am sure i did that [11:53] i even aligned it to cluster sizes [11:53] I don't understand what asac is saying; can I get a sample binary? [11:53] like looking what cluster size the real SD card would have and then see that [11:53] asac, its not the cluster sizes or anything [11:53] asac, the uboot partition is smaller than uboot itself [11:53] sure. i aligned by 512 ... using integer match [11:54] e.g. so the size was bigger [11:54] but i wont remove the hope. so give it a try ;) [11:54] math [11:54] asac: I'm asking about the 1024 offset in the binary and in the dd output; I don't understand where the 1024 come from if it's not padded [11:54] its padded [11:55] and i had a working uboot image with that ... just tat that partitioning was manually done on the SD before [11:55] i seriously dont know exactly why its there, but it clearly worked here [11:55] we dont add any extra padding during package build [11:56] so it should be unpadded [11:56] right. but the .bin itself has probably a MBR at the beginning or something [11:56] So if it's padded, you need to remove 1024 to uboot_size when creating the partition [11:56] it shouldnt [11:56] feel free to put the full .bin onto it [11:56] What do you use as input? [11:56] lool: remove size? why would a too big partition cause any issues? [11:56] lool, input ? [11:57] ogra: as input uboot .bin [11:57] asac: It wouldn't be the issue, but it's still wrong [11:57] the uboot-imx51 package [11:57] the to3.bin from the current uboot-imx51 package [11:57] yeah. [11:57] and we dont pad it during build, i dont think it gets padded upstream, so there should be no padding at all [11:58] ogra: can you pload the DEBUG build? [11:58] or want to wait f you find something here? [11:58] gimme some time, i will upoload it with the rest of the default config changes later today [11:58] I checked and it's padded with 0x400 bytes [11:58] if we get the image going i'd like to add all changes in one go [11:59] yes, so skipping 1024 makes sense [11:59] Yes [11:59] +ok, thats 1024 [11:59] -+ [11:59] Unless the first 4 bytes are a jump or something 'b601 00ea' not sure [11:59] Certainly the next 1020 bytes are zeroes, so I'm tempted to think it's padded [12:00] intresting, that must come from upistream then [12:00] most likely for if you load it into flash or something [12:00] Stupid openid prevents me from using my editor on the paste stuff [12:01] yes [12:01] thats annoying [12:01] i want openid to go away for past.ubnutu.com [12:01] you cannot even wget the "download " link anymore [12:01] asac: Exactly [12:01] Not even with w3m which I think might actually process javascript; you hit a Continue button [12:02] i complained now [12:02] just FYI, clementine needs a powercycle [12:02] dmart, ^^^ the builder hangs [12:02] Is the script kept in bzr somewhere? [12:02] lool, not yet [12:02] Can I patch it in place and send you the new version? [12:02] we're in very early stages [12:02] ogra was too lazy for that ... so we used pastebin ;) [12:02] yeah [12:02] sorry [12:02] me ?!? [12:02] bah [12:02] * ogra throws a snowball at asac [12:02] yes, you are the owner, so you are supposed to do that in bzr :) [12:02] I don't know whom [12:03] i am just the peer poking you [12:03] pfft [12:04] For the 1024 bytes padding issue in U-Boot, I think the on-SoC low-level bootloader ignores the first K and executes the bootloader binary from offset 1024 in the boot device. This seems to apply to RedBoot and U-Boot (I've successfully booted U-Boot this way at my end) [12:05] It has nothing to do with any notional block size on the device AFAUK [12:05] (afaik) [12:05] dmart: Agreed; we're just trying to get the math right [12:05] We're not writing the full image to disk as it would erase the partition table [12:05] dmart, yes, i'm just wondering what adds the padiing, in redboot we add it during package build iirc, while we dont do that in the uboot build [12:06] ogra: God [12:06] Dunno there. The U-Boot build process may add it. [12:06] You copied the PART1_ID_OFFSET="$(hex2dec 0x1c2)" [12:06] That's probably the issue [12:06] it must be something before uboot [12:06] Oh no that's always correct [12:06] Nevermind :) [12:06] right [12:06] i checked that manually [12:06] ogra: i found a bug in that [12:06] I thought it was the offset of the data, not in the partition table [12:07] but that didnt change a thing [12:07] ogra: with sh the data fs partition string dding breaks [12:07] you have to wrap it with bash -c "..." [12:07] otherwise that printf outputs 3 bytes [12:07] not here [12:07] and you end up with this odd E.. FS partitoin [12:07] ogra: ppost what you have for fdisk -l [12:08] first partitoin isnt Non-FS data iirc for you [12:08] thats the bug [12:08] ogra@osiris:~/Desktop/uboot$ fdisk -l test.img |grep test.img1 [12:08] test.img1 1 1 139+ da Nicht-DS-Daten [12:08] looks like it should [12:09] strange [12:09] then i dont know whats going on with my dash ;) [12:09] it definitly is broke here [12:09] its your vanilla kernel breaking it :P [12:10] bah [12:11] I had a check for the size of the partition and there is none here [12:11] none? [12:11] ogra, asac: Do you have a run with debug output of the script? [12:12] what did you try? [12:12] i dont even know which version of the script you are using [12:12] ogra: can you push whatever you currently have to some bzr branch so we have the same baseline ;)? [12:12] asac: I'm not using any; I'm changing the one ogra pinged me with earlier here [12:12] I will give you an updated one fixing the issues I listed [12:12] lool: so ogra gave you a script [12:13] asac, waiting for what lool will send me and put that in bzr [12:13] ok. getting cigarettes ... hope its there after that [12:14] want to give it a try ;) [12:14] now that the bbg2 works [12:17] lool, adding the 512 to UBOOT_SIZE doesnt change a thing here [12:18] shenki: anything you needed from me? [12:18] BBG U-Boot > fatload mmc 0:2 0x90008000 /uimage [12:18] reading /uimage [12:18] still hangs there [12:18] * asac out for cigarettes for real now ;) [12:20] * lool pushes lp:~lool/+junk/uboot-image-script [12:21] ogra: I don't have babbage 2, so I can't try the output on a babbage board; I could perhaps run the script but that's the best I can do; I'm still finishing the review, if I don't have any idea, I will ask for the output of the script and the boot output [12:22] ok [12:22] UBOOT_SIZE=$(($(stat -c %s "$UBOOT_BIN") - 1024)) ?? [12:22] why do you subtract the padding ? [12:24] ./uboot-image-script: 67: arithmetic expression: expecting primary: ""62914560" / 1024" [12:24] * ogra checks [12:29] I pushed sanity checks [12:29] ogra: Looks like parted output is bofus [12:30] ah [12:30] ogra: Could you send a set -x run output? [12:30] * lool goes to lunch and will look at this when coming back [12:30] will do [12:30] I will add further checks at the end of the script [12:31] hmm, seems that trashed the uboot binary [12:31] doesnt get to a prompt [12:35] lool, http://paste.ubuntu.com/354994/ [12:36] the uboot binary is definately truncated in this version though [12:36] one question i am not sure about: man parted say that mkpart takes [start] [end] .. we seem to pass [start] [size] though. is manpage really wrong? [12:37] hmm, we should pass [start] [size+start] [12:37] yes [12:38] * ogra will try that but needs some food too now [12:50] ok repushed lp:~ubuntu-armel/+junk/uboot-image-script [12:54] asac: Did you talk to lutin about the EFL stuff? [12:56] the inclusion thing? i told him to think about it [12:56] but he didnt like it. [12:56] havent got a final decision yet [12:57] asac: ah, OK [13:00] ogra: Just looking at the script... [13:01] 39: UBOOT_SIZE=$(($(stat -c %s "$UBOOT_BIN") - 1024)) [13:01] pushed a few fixes so it works oob here [13:01] 40: log_run parted -s "$IMAGE" mkpart primary fat32 "512B" "$(($UBOOT_SIZE - 1))B" [13:01] That makes the partition size = UBOOT_SIZE - 512 [13:01] This is `stat -c %s "$UBOOT_BIN"` - 1536... is the U-Boot binary getting truncated by the fs partition? [13:01] On line 40, maybe you want UBOOT_SIZE + 512 - 1. [13:01] dmart: pull again [13:01] lp:~ubuntu-armel/+junk/uboot-image-script [13:02] i already ensured that last parameter is END now rather than size [13:02] Ah, that should work :) [13:02] (I think) [13:07] doesnt work here [13:07] i still end up with a truncated uboot [13:07] tried my branch? [13:08] yes [13:08] just zeroed my Sd to make sure its actually using the proper image [13:09] ogra i get uboot promot ;) [13:09] i dont [13:09] In: serial [13:09] Out: serial [13:09] Err: serial [13:09] Net: FEC0 [PRIME] [13:09] thats it [13:09] hangs there forever [13:09] In: serial [13:09] Out: serial [13:09] Err: serial [13:09] Net: FEC0 [PRIME] [13:09] Hit any key to stop autoboot: 0 [13:09] BBG U-Boot > mmcinfo [13:10] even powering off the board doesnt change it [13:10] whats the imagezize you give on the cmdline ? [13:10] ./uboot-image-script ../out.img ../data/vmlinuz-2.6.31-601-imx51 ../data/uboot-imx51_to3.bin 90M [13:11] oh, you give it in M [13:11] yes [13:11] its in M ;) [13:11] * ogra tries that [13:11] * asac thinks about building his own uboot on jocote [13:11] * asac has never seen the .bin work there ;) [13:11] are you sure it ever worked? [13:12] ogra: can you create the partitions manually and see if that really helps still? [13:12] oh damned !!!! [13:12] just want to be sure we are not running after a bad horse [13:12] * ogra durses chromium [13:12] what? [13:12] *curses even [13:12] heh [13:12] crashed? [13:12] it created a ton of scripts on my desktop [13:12] enumerating them [13:13] instead of overwriting when i download a new version [13:13] so i copied the same all the time into my workdir :P [13:13] yes [13:13] ogra: use bzr branch ;) [13:13] bzr ftw [13:14] * asac schedules a bzr brain-wash session for sprint [13:14] heh [13:15] still not reading uImage though [13:15] yes [13:15] ogra: we need the DEBUG build asap [13:15] we are moving in circles ;) [13:15] maybe we just see whats going on there [13:15] * asac hopes [13:16] what do you expect to achieve from a DEBUG build beond that it will tell you earlier that the image is corrupted (bad CRC) [13:16] ogra: if you can make a image that works manually, we can dd the partition table and the first few K off and use that rather than parted [13:16] nah [13:16] then i'd rather use fdisk scripts [13:16] i want to see details [13:16] we dont see anything atm [13:16] we do [13:17] just wait about 20min [13:17] uboot will restart [13:17] what does that tell you? [13:17] and will exec the commands over again ... then it shows a bad CRC for the image [13:18] so are you 100% sure that the current .bin works right if you do the part table manually? [13:19] it worked before, yes [13:19] i'm still using the one from friday which worked fine [13:19] what partition sizes did you use there? [13:24] hmm, doesnt seem like uboot for imx has any debug config options at all [13:26] but fat.c etc. [13:26] they want -DDEBUG [13:26] Number Start End Size Type File system Flags [13:26] 1 1024B 143359B 142336B primary [13:26] 2 143360B 63058431B 62915072B primary fat32 lba [13:26] the first partition is to small [13:27] ogra@osiris:~/Desktop/uboot$ ls -l uboot-imx51_to3.bin [13:27] -rwxr-xr-x 1 ogra ogra 142952 2010-01-07 17:20 uboot-imx51_to3.bin [13:27] 616 bytes to small [13:27] how did we get there ? [13:28] err [13:28] uboot_start=1024 ??? [13:28] why 1024 ? [13:28] ogra: So the /boot partition is miscomputed [13:29] otherwise the script will bail out below [13:29] log_run parted -s "$IMAGE" mkpart primary fat32 "$((${PART1_END_B%B} + 1))B" "${BOOT_SIZE}B" [13:29] maybe that was a bug in first place [13:29] That should be PART1_END + 1 + BOOT_SIZE as second arg [13:29] (end) [13:29] Instead of size [13:29] yes [13:29] we use that for redboot though [13:29] lool: is that in latest? [13:29] Also, it's inclusive, so you can substract one [13:29] i wonder why it doesnt break there [13:29] asac: Dunno, I'm working of my branch [13:29] i thought i made it use end everywhere now [13:30] asac, 1024 is way to much offset for the start [13:30] the ~ubuntu-armel branch [13:30] i fixed [13:30] Oh [13:30] asac, 512 for the MBR ... [13:30] * lool merges [13:30] i fixed a bunch ;) [13:30] ogra: 512 for MBR, 512 for part table? [13:30] err, yes [13:30] mbr has part table included [13:30] well, 512 for offset :) [13:31] 1024 leaves a gap [13:32] die "UBoot partition starts at $PART1_START_B but needs to start at 1024B for the ROM to find the bootloader" [13:32] thats why we needed it [13:32] Hmm actually 512B is enough for both [13:32] thats nonsense [13:32] so either we need to adjust that or 1024 is ok [13:32] where did you get that from ? [13:32] good [13:32] asac: Why do you start the partition at 1024B instead of 512B?> [13:32] lets use uboot_start there [13:32] and use that in both places ;) [13:32] * asac commits [13:33] asac: I merged though, you might have to merge now [13:33] /me branches this time [13:33] silly chromium [13:33] done [13:33] -log_run parted -s "$IMAGE" mkpart primary fat32 "512B" "$(($UBOOT_SIZE - 1))B" [13:33] +log_run parted -s "$IMAGE" mkpart primary fat32 "${uboot_start}B" "$(($UBOOT_SIZE - 1 + $uboot_start))B" [13:33] That doesn't make any sense to me [13:33] err. thats bad habit ;) [13:33] anyway [13:33] merging [13:34] asac: Why did you add uboot_start? [13:34] so we can just flit one var now ;) [13:34] asac: Yes but it used to start at 512B, right? [13:35] lool: you added the die check so i fixed the start ... and made a variable out of it [13:35] so now we go back to 512 [13:35] ok merge mess finished [13:37] Gah [13:37] uboot_start doesn't mean the same thing now [13:38] UBOOT_SIZE is wrong now [13:39] yes. thats an oversight [13:39] should use the same [13:39] well [13:39] not [13:39] UBOOT_SIZE 1024 is the padding [13:39] the uboot_start is the partition start [13:40] the dd is wrong a bit yes. [13:41] no. no idea what you meant by the die test [13:41] Ok fixed now [13:41] i definitly used thie uboot_start only for partition bits [13:41] I renamed to PART1_START and added a real UBOOT_START if you prefer that [13:42] ok [13:42] whatever works ;) [13:42] lool: thats not good [13:42] "136376 - "1024"" [13:42] ./uboot-image-script: 44: arithmetic expression: expecting primary: "136376 - "1024"" [13:42] * asac fixes [13:43] done [13:44] + 1 - 1 ? [13:44] why dont you just drop +1 [13:45] ogra: To avoid someone adding +1 again :) there wasn't any in the first version AFAIR [13:45] That's odd, I didn't know $(()) wasn't doing expansion [13:45] uboot-image-script/uboot-image-script: 44: arithmetic expression: expecting primary: "142952 - "1024"" [13:45] doesnt change a thing for me [13:46] odd. on bbg2 reset powers off [13:46] ;) [13:46] Yup [13:46] old bug [13:47] yes. wasnt sure that uboot reset command has same effect [13:47] ericm_: cooloney: hi [13:47] ericm_: cooloney: any update on kernel upload? [13:50] he mailed the kernel list with a pull request [13:50] i guess its up to apw to pull and roll now [13:50] ogra: btw, replacing ../out.img with /dev/mmblk0 ... it doesnt help ... isnt that the way you did it? [13:50] cool [13:50] asac, marvell patch rebase finished but seems there are many issues with recent lucid [13:50] not atm, no [13:51] asac, will check with NCommander for that [13:51] ogra: how did you create the good partition table? [13:51] asac, i roll an image and dd it currently ... [13:51] asac, I've already sent the status report but would like to hold on for a while til those issues are solved [13:51] i dont have a good part table atm ... [13:51] ogra: but how did you do it when you had that [13:51] ;) [13:51] ericm_: what issues are those? [13:51]