=== jmc93739653 is now known as jmc93739653_ | ||
=== jmc93739653_ is now known as jmc93739653 | ||
pwnguin | lol | 04:08 |
---|---|---|
pwnguin | "This is the bug tracker, with mail notifications going to developers who have" | 04:08 |
pwnguin | many things to work on. Please keep the discussion to necessary technical | 04:08 |
pwnguin | details. Refusal to do so may result in termination of your account. We hope | 04:08 |
pwnguin | for your understanding. | 04:08 |
=== asac_ is now known as asac | ||
lool | gregoiregentil: Thanks; I had not tested it, will look at fixing the patch to use MOUNTPOINT | 08:31 |
=== ogra_ is now known as ogra | ||
ogra | fresh uboot-imx is uploaded with the lastest patchset ... | 11:11 |
ogra | 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:18 |
ogra | you probably see something obvious we both dont find | 11:19 |
dmart | Hi there... does anyone know why there were no armel daily-live images for the last couple of days? | 11:21 |
dmart | 20100108 seems to work well, but the more recent images seem to have no armel variants. | 11:22 |
ogra | http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-imx51/ doesnt indicate that there were any builds | 11:23 |
ogra | not even attempts | 11:23 |
dmart | Is that expected, or did something go wrong? | 11:24 |
dmart | http://cdimages.ubuntu.com/ports/daily-live/ has 20100110 and 20100111, but they only seem to have ia64 and powerpc | 11:25 |
lool | ogra: Does it relate to some other script? | 11:26 |
lool | dmart: That's when the build failed | 11:26 |
lool | Hmm someone dropped the weather report from the topic | 11:26 |
ogra_ | sorry reconnect | 11:28 |
lool | Ah perhaps only -mobile had it | 11:28 |
lool | dmart: http://qa.ubuntu.com/reports/ogasawara/weatherreport.html | 11:28 |
ogra_ | no hanging procs on the main buildserver | 11:28 |
ogra_ | i wonder why there are no buiold attempts then | 11:28 |
lool | dmart: So what it means is that either the ISO or the livefs failed to build | 11:29 |
lool | dmart: livefs http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ | 11:29 |
lool | No log at all :-/ | 11:29 |
dmart | Strange | 11:30 |
ogra_ | right, as i said, no attempt | 11:30 |
ogra_ | x86 built though ... so the builds were not disabled | 11:30 |
lool | The crons certainly list armel | 11:32 |
ogra_ | right | 11:32 |
ADcomp | hello .. I'm happy :) .. Karmic is running fine on my new board ( http://www.technexion.com/index.php/thunderpack ) | 11:32 |
ogra_ | great to hear | 11:33 |
=== ogra_ is now known as ogra | ||
ADcomp | Can I add this board to "ARM/DeviceSupport" on ubuntu wiki ? | 11:38 |
lool | ===== Downloading live filesystem images ===== | 11:39 |
lool | Mon Jan 11 05:35:27 GMT 2010 | 11:39 |
lool | Read error (Connection reset by peer) in headers. | 11:39 |
lool | That's how the CD build fail | 11:39 |
lool | I suspect the livefs builder is down | 11:39 |
ogra | yep | 11:39 |
ogra | i pinged lamont already | 11:40 |
lool | ADcomp: Which kernel tree supports the board? | 11:41 |
lool | ADcomp: Does linux-omap support it? linux? | 11:41 |
ADcomp | lool: 2.6.31 | 11:42 |
lool | ADcomp: You mean naked linux 2.6.31 will support this board? | 11:43 |
ADcomp | lool: compiling this one : https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-stable | 11:46 |
lool | ogra: touch can be dropped at the start of the script | 11:46 |
ogra | thats from linux-omap | 11:46 |
ogra | lool, yeah, i noted that too, alex added it, but thats surely not the issue | 11:47 |
lool | ogra: I'm reading it anyway, so better making comments on all things I see | 11:47 |
lool | UBOOT_SIZE=$(wc -c $UBOOT_BIN |cut -d ' ' -f1) => stat much better | 11:48 |
ogra | i also want to switch to your ingenious way of creating the empty image without time loss | 11:48 |
ADcomp | lool: diff = http://pastebin.com/f60903eb6 | 11:48 |
lool | stat -c %s foobar | 11:48 |
ogra | lool, yeah, i havent ported all the functions yet, stat will be used in the next iteration | 11:48 |
ogra | yep | 11:48 |
ogra | the other script has a proper function for it | 11:48 |
lool | ogra: The first partition seems too small to me | 11:49 |
ogra | 142848B | 11:50 |
ogra | ogra@osiris:~/Desktop/uboot$ ls -l uboot-imx51_to3.bin | 11:51 |
ogra | -rwxr-xr-x 1 ogra ogra 142952 2010-01-07 17:20 uboot-imx51_to3.bin | 11:51 |
lool | 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 |
ogra | hrm | 11:51 |
ogra | you are right | 11:51 |
lool | You need to add 512 to UBOOT_SIZE - 1 | 11:51 |
* ogra slaps forehead ... | 11:51 | |
ogra | oh my ! | 11:51 |
* ogra blushes | 11:51 | |
ogra | indeed | 11:51 |
ogra | asac, ^^^ | 11:51 |
lool | Ah hold on, you actually seek and skip 1024 bytes in UBOOT_BIN | 11:52 |
lool | Where do these 1024 come from? Is this padded? | 11:52 |
ogra | yes, so it needs to be 1024 | 11:52 |
ogra | no | 11:52 |
ogra | could be 512 | 11:52 |
asac | well. | 11:52 |
asac | i am sure i did that | 11:52 |
asac | i even aligned it to cluster sizes | 11:53 |
lool | I don't understand what asac is saying; can I get a sample binary? | 11:53 |
asac | like looking what cluster size the real SD card would have and then see that | 11:53 |
ogra | asac, its not the cluster sizes or anything | 11:53 |
ogra | asac, the uboot partition is smaller than uboot itself | 11:53 |
asac | sure. i aligned by 512 ... using integer match | 11:53 |
asac | e.g. so the size was bigger | 11:54 |
asac | but i wont remove the hope. so give it a try ;) | 11:54 |
asac | math | 11:54 |
lool | 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 |
asac | its padded | 11:54 |
asac | and i had a working uboot image with that ... just tat that partitioning was manually done on the SD before | 11:55 |
asac | i seriously dont know exactly why its there, but it clearly worked here | 11:55 |
ogra | we dont add any extra padding during package build | 11:55 |
ogra | so it should be unpadded | 11:56 |
asac | right. but the .bin itself has probably a MBR at the beginning or something | 11:56 |
lool | So if it's padded, you need to remove 1024 to uboot_size when creating the partition | 11:56 |
ogra | it shouldnt | 11:56 |
asac | feel free to put the full .bin onto it | 11:56 |
lool | What do you use as input? | 11:56 |
asac | lool: remove size? why would a too big partition cause any issues? | 11:56 |
ogra | lool, input ? | 11:56 |
lool | ogra: as input uboot .bin | 11:57 |
lool | asac: It wouldn't be the issue, but it's still wrong | 11:57 |
asac | the uboot-imx51 package | 11:57 |
ogra | the to3.bin from the current uboot-imx51 package | 11:57 |
asac | yeah. | 11:57 |
ogra | and we dont pad it during build, i dont think it gets padded upstream, so there should be no padding at all | 11:57 |
asac | ogra: can you pload the DEBUG build? | 11:58 |
asac | or want to wait f you find something here? | 11:58 |
ogra | gimme some time, i will upoload it with the rest of the default config changes later today | 11:58 |
lool | I checked and it's padded with 0x400 bytes | 11:58 |
ogra | if we get the image going i'd like to add all changes in one go | 11:58 |
asac | yes, so skipping 1024 makes sense | 11:59 |
lool | Yes | 11:59 |
ogra | +ok, thats 1024 | 11:59 |
ogra | -+ | 11:59 |
lool | Unless the first 4 bytes are a jump or something 'b601 00ea' not sure | 11:59 |
lool | Certainly the next 1020 bytes are zeroes, so I'm tempted to think it's padded | 11:59 |
ogra | intresting, that must come from upistream then | 12:00 |
asac | most likely for if you load it into flash or something | 12:00 |
lool | Stupid openid prevents me from using my editor on the paste stuff | 12:00 |
asac | yes | 12:01 |
asac | thats annoying | 12:01 |
asac | i want openid to go away for past.ubnutu.com | 12:01 |
asac | you cannot even wget the "download " link anymore | 12:01 |
lool | asac: Exactly | 12:01 |
lool | Not even with w3m which I think might actually process javascript; you hit a Continue button | 12:01 |
asac | i complained now | 12:02 |
ogra | just FYI, clementine needs a powercycle | 12:02 |
ogra | dmart, ^^^ the builder hangs | 12:02 |
lool | Is the script kept in bzr somewhere? | 12:02 |
ogra | lool, not yet | 12:02 |
lool | Can I patch it in place and send you the new version? | 12:02 |
ogra | we're in very early stages | 12:02 |
asac | ogra was too lazy for that ... so we used pastebin ;) | 12:02 |
ogra | yeah | 12:02 |
asac | sorry | 12:02 |
ogra | me ?!? | 12:02 |
ogra | bah | 12:02 |
* ogra throws a snowball at asac | 12:02 | |
asac | yes, you are the owner, so you are supposed to do that in bzr :) | 12:02 |
lool | I don't know whom | 12:02 |
asac | i am just the peer poking you | 12:03 |
ogra | pfft | 12:03 |
dmart | 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:04 |
dmart | It has nothing to do with any notional block size on the device AFAUK | 12:05 |
dmart | (afaik) | 12:05 |
lool | dmart: Agreed; we're just trying to get the math right | 12:05 |
lool | We're not writing the full image to disk as it would erase the partition table | 12:05 |
ogra | 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:05 |
lool | ogra: God | 12:06 |
dmart | Dunno there. The U-Boot build process may add it. | 12:06 |
lool | You copied the PART1_ID_OFFSET="$(hex2dec 0x1c2)" | 12:06 |
lool | That's probably the issue | 12:06 |
asac | it must be something before uboot | 12:06 |
lool | Oh no that's always correct | 12:06 |
lool | Nevermind :) | 12:06 |
ogra | right | 12:06 |
ogra | i checked that manually | 12:06 |
asac | ogra: i found a bug in that | 12:06 |
lool | I thought it was the offset of the data, not in the partition table | 12:06 |
asac | but that didnt change a thing | 12:07 |
asac | ogra: with sh the data fs partition string dding breaks | 12:07 |
asac | you have to wrap it with bash -c "..." | 12:07 |
asac | otherwise that printf outputs 3 bytes | 12:07 |
ogra | not here | 12:07 |
asac | and you end up with this odd E.. FS partitoin | 12:07 |
asac | ogra: ppost what you have for fdisk -l | 12:07 |
asac | first partitoin isnt Non-FS data iirc for you | 12:08 |
asac | thats the bug | 12:08 |
ogra | ogra@osiris:~/Desktop/uboot$ fdisk -l test.img |grep test.img1 | 12:08 |
ogra | test.img1 1 1 139+ da Nicht-DS-Daten | 12:08 |
ogra | looks like it should | 12:08 |
asac | strange | 12:09 |
asac | then i dont know whats going on with my dash ;) | 12:09 |
asac | it definitly is broke here | 12:09 |
ogra | its your vanilla kernel breaking it :P | 12:09 |
asac | bah | 12:10 |
lool | I had a check for the size of the partition and there is none here | 12:11 |
asac | none? | 12:11 |
lool | ogra, asac: Do you have a run with debug output of the script? | 12:11 |
asac | what did you try? | 12:12 |
asac | i dont even know which version of the script you are using | 12:12 |
asac | ogra: can you push whatever you currently have to some bzr branch so we have the same baseline ;)? | 12:12 |
lool | asac: I'm not using any; I'm changing the one ogra pinged me with earlier here | 12:12 |
lool | I will give you an updated one fixing the issues I listed | 12:12 |
asac | lool: so ogra gave you a script | 12:12 |
ogra | asac, waiting for what lool will send me and put that in bzr | 12:13 |
asac | ok. getting cigarettes ... hope its there after that | 12:13 |
asac | want to give it a try ;) | 12:14 |
asac | now that the bbg2 works | 12:14 |
ogra | lool, adding the 512 to UBOOT_SIZE doesnt change a thing here | 12:17 |
asac | shenki: anything you needed from me? | 12:18 |
ogra | BBG U-Boot > fatload mmc 0:2 0x90008000 /uimage | 12:18 |
ogra | reading /uimage | 12:18 |
ogra | still hangs there | 12:18 |
* asac out for cigarettes for real now ;) | 12:18 | |
* lool pushes lp:~lool/+junk/uboot-image-script | 12:20 | |
lool | 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:21 |
ogra | ok | 12:22 |
ogra | UBOOT_SIZE=$(($(stat -c %s "$UBOOT_BIN") - 1024)) ?? | 12:22 |
ogra | why do you subtract the padding ? | 12:22 |
ogra | ./uboot-image-script: 67: arithmetic expression: expecting primary: ""62914560" / 1024" | 12:24 |
* ogra checks | 12:24 | |
lool | I pushed sanity checks | 12:29 |
lool | ogra: Looks like parted output is bofus | 12:29 |
ogra | ah | 12:30 |
lool | 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 | |
ogra | will do | 12:30 |
lool | I will add further checks at the end of the script | 12:30 |
ogra | hmm, seems that trashed the uboot binary | 12:31 |
ogra | doesnt get to a prompt | 12:31 |
ogra | lool, http://paste.ubuntu.com/354994/ | 12:35 |
ogra | the uboot binary is definately truncated in this version though | 12:36 |
asac | 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:36 |
ogra | hmm, we should pass [start] [size+start] | 12:37 |
asac | yes | 12:37 |
* ogra will try that but needs some food too now | 12:38 | |
asac | ok repushed lp:~ubuntu-armel/+junk/uboot-image-script | 12:50 |
JamieBennett | asac: Did you talk to lutin about the EFL stuff? | 12:54 |
asac | the inclusion thing? i told him to think about it | 12:56 |
asac | but he didnt like it. | 12:56 |
asac | havent got a final decision yet | 12:56 |
JamieBennett | asac: ah, OK | 12:57 |
dmart | ogra: Just looking at the script... | 13:00 |
dmart | 39: UBOOT_SIZE=$(($(stat -c %s "$UBOOT_BIN") - 1024)) | 13:01 |
asac | pushed a few fixes so it works oob here | 13:01 |
dmart | 40: log_run parted -s "$IMAGE" mkpart primary fat32 "512B" "$(($UBOOT_SIZE - 1))B" | 13:01 |
dmart | That makes the partition size = UBOOT_SIZE - 512 | 13:01 |
dmart | This is `stat -c %s "$UBOOT_BIN"` - 1536... is the U-Boot binary getting truncated by the fs partition? | 13:01 |
dmart | On line 40, maybe you want UBOOT_SIZE + 512 - 1. | 13:01 |
asac | dmart: pull again | 13:01 |
asac | lp:~ubuntu-armel/+junk/uboot-image-script | 13:01 |
asac | i already ensured that last parameter is END now rather than size | 13:02 |
dmart | Ah, that should work :) | 13:02 |
dmart | (I think) | 13:02 |
ogra | doesnt work here | 13:07 |
ogra | i still end up with a truncated uboot | 13:07 |
asac | tried my branch? | 13:07 |
ogra | yes | 13:08 |
ogra | just zeroed my Sd to make sure its actually using the proper image | 13:08 |
asac | ogra i get uboot promot ;) | 13:09 |
ogra | i dont | 13:09 |
ogra | In: serial | 13:09 |
ogra | Out: serial | 13:09 |
ogra | Err: serial | 13:09 |
ogra | Net: FEC0 [PRIME] | 13:09 |
ogra | thats it | 13:09 |
ogra | hangs there forever | 13:09 |
asac | In: serial | 13:09 |
asac | Out: serial | 13:09 |
asac | Err: serial | 13:09 |
asac | Net: FEC0 [PRIME] | 13:09 |
asac | Hit any key to stop autoboot: 0 | 13:09 |
asac | BBG U-Boot > mmcinfo | 13:09 |
ogra | even powering off the board doesnt change it | 13:10 |
ogra | whats the imagezize you give on the cmdline ? | 13:10 |
asac | ./uboot-image-script ../out.img ../data/vmlinuz-2.6.31-601-imx51 ../data/uboot-imx51_to3.bin 90M | 13:10 |
ogra | oh, you give it in M | 13:11 |
asac | yes | 13:11 |
asac | 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 | |
asac | are you sure it ever worked? | 13:11 |
asac | ogra: can you create the partitions manually and see if that really helps still? | 13:12 |
ogra | oh damned !!!! | 13:12 |
asac | just want to be sure we are not running after a bad horse | 13:12 |
* ogra durses chromium | 13:12 | |
asac | what? | 13:12 |
ogra | *curses even | 13:12 |
asac | heh | 13:12 |
asac | crashed? | 13:12 |
ogra | it created a ton of scripts on my desktop | 13:12 |
ogra | enumerating them | 13:12 |
ogra | instead of overwriting when i download a new version | 13:13 |
ogra | so i copied the same all the time into my workdir :P | 13:13 |
asac | yes | 13:13 |
asac | ogra: use bzr branch ;) | 13:13 |
asac | bzr ftw | 13:13 |
* asac schedules a bzr brain-wash session for sprint | 13:14 | |
ogra | heh | 13:14 |
ogra | still not reading uImage though | 13:15 |
asac | yes | 13:15 |
asac | ogra: we need the DEBUG build asap | 13:15 |
asac | we are moving in circles ;) | 13:15 |
asac | maybe we just see whats going on there | 13:15 |
* asac hopes | 13:15 | |
ogra | 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 |
asac | 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 |
ogra | nah | 13:16 |
ogra | then i'd rather use fdisk scripts | 13:16 |
asac | i want to see details | 13:16 |
asac | we dont see anything atm | 13:16 |
ogra | we do | 13:16 |
ogra | just wait about 20min | 13:17 |
ogra | uboot will restart | 13:17 |
asac | what does that tell you? | 13:17 |
ogra | and will exec the commands over again ... then it shows a bad CRC for the image | 13:17 |
asac | so are you 100% sure that the current .bin works right if you do the part table manually? | 13:18 |
ogra | it worked before, yes | 13:19 |
ogra | i'm still using the one from friday which worked fine | 13:19 |
asac | what partition sizes did you use there? | 13:19 |
ogra | hmm, doesnt seem like uboot for imx has any debug config options at all | 13:24 |
asac | but fat.c etc. | 13:26 |
asac | they want -DDEBUG | 13:26 |
ogra | Number Start End Size Type File system Flags | 13:26 |
ogra | 1 1024B 143359B 142336B primary | 13:26 |
ogra | 2 143360B 63058431B 62915072B primary fat32 lba | 13:26 |
ogra | the first partition is to small | 13:26 |
ogra | ogra@osiris:~/Desktop/uboot$ ls -l uboot-imx51_to3.bin | 13:27 |
ogra | -rwxr-xr-x 1 ogra ogra 142952 2010-01-07 17:20 uboot-imx51_to3.bin | 13:27 |
ogra | 616 bytes to small | 13:27 |
ogra | how did we get there ? | 13:27 |
ogra | err | 13:28 |
ogra | uboot_start=1024 ??? | 13:28 |
ogra | why 1024 ? | 13:28 |
lool | ogra: So the /boot partition is miscomputed | 13:28 |
asac | otherwise the script will bail out below | 13:29 |
lool | log_run parted -s "$IMAGE" mkpart primary fat32 "$((${PART1_END_B%B} + 1))B" "${BOOT_SIZE}B" | 13:29 |
asac | maybe that was a bug in first place | 13:29 |
lool | That should be PART1_END + 1 + BOOT_SIZE as second arg | 13:29 |
lool | (end) | 13:29 |
lool | Instead of size | 13:29 |
ogra | yes | 13:29 |
ogra | we use that for redboot though | 13:29 |
asac | lool: is that in latest? | 13:29 |
lool | Also, it's inclusive, so you can substract one | 13:29 |
ogra | i wonder why it doesnt break there | 13:29 |
lool | asac: Dunno, I'm working of my branch | 13:29 |
asac | i thought i made it use end everywhere now | 13:29 |
ogra | asac, 1024 is way to much offset for the start | 13:30 |
asac | the ~ubuntu-armel branch | 13:30 |
asac | i fixed | 13:30 |
lool | Oh | 13:30 |
ogra | asac, 512 for the MBR ... | 13:30 |
* lool merges | 13:30 | |
asac | i fixed a bunch ;) | 13:30 |
lool | ogra: 512 for MBR, 512 for part table? | 13:30 |
ogra | err, yes | 13:30 |
asac | mbr has part table included | 13:30 |
ogra | well, 512 for offset :) | 13:30 |
ogra | 1024 leaves a gap | 13:31 |
asac | die "UBoot partition starts at $PART1_START_B but needs to start at 1024B for the ROM to find the bootloader" | 13:32 |
asac | thats why we needed it | 13:32 |
lool | Hmm actually 512B is enough for both | 13:32 |
ogra | thats nonsense | 13:32 |
asac | so either we need to adjust that or 1024 is ok | 13:32 |
ogra | where did you get that from ? | 13:32 |
asac | good | 13:32 |
lool | asac: Why do you start the partition at 1024B instead of 512B?> | 13:32 |
asac | lets use uboot_start there | 13:32 |
asac | and use that in both places ;) | 13:32 |
* asac commits | 13:32 | |
lool | asac: I merged though, you might have to merge now | 13:33 |
ogra | /me branches this time | 13:33 |
ogra | silly chromium | 13:33 |
asac | done | 13:33 |
lool | -log_run parted -s "$IMAGE" mkpart primary fat32 "512B" "$(($UBOOT_SIZE - 1))B" | 13:33 |
lool | +log_run parted -s "$IMAGE" mkpart primary fat32 "${uboot_start}B" "$(($UBOOT_SIZE - 1 + $uboot_start))B" | 13:33 |
lool | That doesn't make any sense to me | 13:33 |
asac | err. thats bad habit ;) | 13:33 |
asac | anyway | 13:33 |
asac | merging | 13:33 |
lool | asac: Why did you add uboot_start? | 13:34 |
asac | so we can just flit one var now ;) | 13:34 |
lool | asac: Yes but it used to start at 512B, right? | 13:34 |
asac | lool: you added the die check so i fixed the start ... and made a variable out of it | 13:35 |
asac | so now we go back to 512 | 13:35 |
asac | ok merge mess finished | 13:35 |
lool | Gah | 13:37 |
lool | uboot_start doesn't mean the same thing now | 13:37 |
lool | UBOOT_SIZE is wrong now | 13:38 |
asac | yes. thats an oversight | 13:39 |
asac | should use the same | 13:39 |
asac | well | 13:39 |
asac | not | 13:39 |
asac | UBOOT_SIZE 1024 is the padding | 13:39 |
asac | the uboot_start is the partition start | 13:39 |
asac | the dd is wrong a bit yes. | 13:40 |
asac | no. no idea what you meant by the die test | 13:41 |
lool | Ok fixed now | 13:41 |
asac | i definitly used thie uboot_start only for partition bits | 13:41 |
lool | I renamed to PART1_START and added a real UBOOT_START if you prefer that | 13:41 |
asac | ok | 13:42 |
asac | whatever works ;) | 13:42 |
asac | lool: thats not good | 13:42 |
asac | "136376 - "1024"" | 13:42 |
asac | ./uboot-image-script: 44: arithmetic expression: expecting primary: "136376 - "1024"" | 13:42 |
* asac fixes | 13:42 | |
asac | done | 13:43 |
ogra | + 1 - 1 ? | 13:44 |
ogra | why dont you just drop +1 | 13:44 |
lool | ogra: To avoid someone adding +1 again :) there wasn't any in the first version AFAIR | 13:45 |
lool | That's odd, I didn't know $(()) wasn't doing expansion | 13:45 |
ogra | uboot-image-script/uboot-image-script: 44: arithmetic expression: expecting primary: "142952 - "1024"" | 13:45 |
ogra | doesnt change a thing for me | 13:45 |
asac | odd. on bbg2 reset powers off | 13:46 |
asac | ;) | 13:46 |
lool | Yup | 13:46 |
ogra | old bug | 13:46 |
asac | yes. wasnt sure that uboot reset command has same effect | 13:47 |
asac | ericm_: cooloney: hi | 13:47 |
asac | ericm_: cooloney: any update on kernel upload? | 13:47 |
ogra | he mailed the kernel list with a pull request | 13:50 |
ogra | i guess its up to apw to pull and roll now | 13:50 |
asac | ogra: btw, replacing ../out.img with /dev/mmblk0 ... it doesnt help ... isnt that the way you did it? | 13:50 |
asac | cool | 13:50 |
ericm_ | asac, marvell patch rebase finished but seems there are many issues with recent lucid | 13:50 |
ogra | not atm, no | 13:50 |
ericm_ | asac, will check with NCommander for that | 13:51 |
asac | ogra: how did you create the good partition table? | 13:51 |
ogra | asac, i roll an image and dd it currently ... | 13:51 |
ericm_ | asac, I've already sent the status report but would like to hold on for a while til those issues are solved | 13:51 |
ogra | i dont have a good part table atm ... | 13:51 |
asac | ogra: but how did you do it when you had that | 13:51 |
asac | ;) | 13:51 |
asac | ericm_: what issues are those? | 13:51 |
asac | do we have bugs tracking the progress? | 13:51 |
ogra | before i used lool's way of creating an empty image with a 512 byte blocksize and used that value for fdisk -C | 13:52 |
ericm_ | asac, gdm or gnome-panel respawned again and again | 13:52 |
ericm_ | asac, and X constantly freezes up | 13:53 |
ogra | you should be able to do the same by: fdisk -C $(($(stat -c %s $imagename) / 512)) $imagename | 13:53 |
ogra | or some such | 13:53 |
ericm_ | asac, have already checked with Marvell on those issues and no solution yet - I'll ping them more frequently on these | 13:54 |
lool | ogra, asac: Could you test the latest version? | 13:55 |
asac | sure | 13:55 |
* ogra pulls | 13:55 | |
* asac dds | 13:56 | |
* ogra too | 13:56 | |
apw | ogra, what are you waiting for me to do? | 13:56 |
asac | apw: upload imx51 | 13:56 |
asac | kernel | 13:57 |
ogra | apw, [Lucid] Git pull request for fsl-imx51 branch upload | 13:57 |
ogra | apw, from kernel-team@ | 13:57 |
apw | you are desiring it be the a-2 kernel? willing to take the pain? | 13:57 |
ogra | apw, we*re waiting for an upload | 13:57 |
ogra | apw, right | 13:57 |
ogra | it has been tested on friday by a bunch of us | 13:57 |
ogra | as long as aufs isnt meesed up it should be a fine kernel for A2 | 13:58 |
asac | lool: same issue. hanging on loading uimage | 13:58 |
lool | asac: So this is on B2.0? Could you paste full boot output? | 13:58 |
ogra | same on 2.5 here | 13:58 |
=== ericm_ is now known as ericm-Zzzz | ||
lool | asac, ogra: I added one more sanity check to verify that the partition is sufficiently big; please repull and rerun (no need to dd to SD card) | 13:59 |
apw | ogra, as you tested it on friday you know its good yes | 13:59 |
asac | lool: http://paste.ubuntu.com/355017/ | 13:59 |
asac | seems the sso was removed!!! | 13:59 |
apw | and if its not you can live with it | 13:59 |
ogra | apw, under the assumption that cooloney didnt change anything :) | 13:59 |
lool | asac: SSO? | 13:59 |
asac | signle sign on | 13:59 |
asac | on paste.u.c | 13:59 |
lool | asac: Oh nice | 13:59 |
asac | i ad to add my nick again ;) | 13:59 |
lool | asac: Can you fatls without hanging? | 13:59 |
ogra | lool, http://paste.ubuntu.com/355018/ | 14:00 |
ogra | same for me | 14:00 |
asac | lool: yes | 14:00 |
asac | we always could do that | 14:00 |
ogra | right | 14:00 |
asac | which is why i would like to have a uboot DEBUG build | 14:00 |
ogra | only loading doesnt work | 14:00 |
asac | to see whats going on ;) | 14:00 |
lool | Are you guys sure of your load address? It's not overwriting some important area? | 14:00 |
asac | we had it working | 14:00 |
asac | with good partition table | 14:00 |
asac | but i had a different uboot.bin ... so i rely on ogra saying that his image is good too for that | 14:01 |
lool | Did one of you two re-run the latest version with the check? | 14:01 |
ogra | not yet | 14:01 |
asac | BBG U-Boot > fatls mmc 0:2 3062220 uimage | 14:02 |
asac | 1 file(s), 0 dir(s) | 14:02 |
asac | lool: which version? | 14:02 |
lool | r19 | 14:02 |
asac | you mean the script or the uboot.bin? | 14:02 |
lool | script | 14:02 |
asac | yes | 14:02 |
asac | thats what i am trying | 14:02 |
lool | So the test passes? | 14:02 |
asac | hangs on uimage loading | 14:02 |
asac | it didnt fail ;) | 14:02 |
asac | let me double check | 14:02 |
ogra | neither here | 14:02 |
lool | Ok good | 14:02 |
asac | http://paste.ubuntu.com/355025/ | 14:03 |
asac | lool: ^ | 14:03 |
lool | Well what you guys could do is take your SD, copy the uImage to your PC, re-do the mkfs by hand on the second partition, copy uImage back | 14:03 |
lool | That would rule out mcopy | 14:03 |
ogra | right | 14:03 |
* asac does that | 14:04 | |
asac | well i have the uImage here in CWD | 14:04 |
asac | PWD | 14:04 |
asac | so i will just copy that after mounting the SD | 14:04 |
lool | asac: I added code to rm it in the latest version | 14:04 |
asac | heh you remove the uImage now ;) | 14:04 |
asac | sabotage | 14:05 |
* asac recreates | 14:05 | |
ogra | hangs here | 14:05 |
ogra | oh, wait, i used the wrong uimage :P | 14:05 |
asac | hangs too | 14:05 |
lool | So I think we need to find a working image again and replace the uboot.bin and the uimage | 14:06 |
asac | i used the right one | 14:06 |
asac | let me check if i really wiped mine | 14:06 |
ogra | hamgs | 14:07 |
ogra | *hangs | 14:07 |
asac | yes | 14:07 |
asac | i have it ;) | 14:07 |
asac | here | 14:07 |
ogra | one sec | 14:07 |
asac | we can dd off the partition table ;) | 14:07 |
ogra | i have a FSL binary | 14:07 |
asac | it works | 14:08 |
asac | http://paste.ubuntu.com/355027/ | 14:08 |
asac | but that doesnt use the .bin by ogra | 14:08 |
asac | i had my own in december | 14:08 |
asac | which i used to create that | 14:08 |
lool | I added code to use tempfiles properly | 14:09 |
asac | ok | 14:09 |
lool | asac: Let's replace the .bin then | 14:09 |
ogra | http://people.canonical.com/~ogra/uImage | 14:09 |
asac | lool: then i dont even have that image anymore :) | 14:09 |
lool | asac: ? | 14:10 |
asac | i have it on a SD card only | 14:10 |
lool | I mean copy the working .bin in the non-working image (if it's smaller than ogra's .bin) | 14:10 |
asac | let me see if i can dd it | 14:10 |
asac | i dont have that .bin anymore :( | 14:10 |
asac | it died with the USB harddrive | 14:10 |
ogra | lool, the uboot.bin wors fine | 14:10 |
asac | and i dont know the size anymore | 14:10 |
lool | asac: You could hack our script to have a very large UBOOT partition to be able to dd some MBs of data from your SD to that one | 14:10 |
lool | ogra: Did you ever boot a kernel with the uboot.bin? | 14:11 |
ogra | several | 14:11 |
asac | yes | 14:11 |
ogra | BBG U-Boot > fatload mmc 0:2 0x90008000 /uimage | 14:11 |
ogra | reading /uimage | 14:11 |
ogra | 2211052 bytes read | 14:11 |
asac | we.. i never saw the current .bin working. but i will now manually create the part table etc. and see | 14:11 |
ogra | thats with the fslk uimage | 14:11 |
asac | ogra: so how do you create that part table | 14:11 |
ogra | *FSL | 14:11 |
lool | asac: Add UBOOT_SIZE=$((12 * 1024 * 1024)) after UBOOT_SIZE= in the script and dd 10 MBs of your SD | 14:11 |
asac | can you post that script please | 14:11 |
asac | lool: yes. let me check | 14:11 |
ogra | asac, i used the script | 14:11 |
asac | ogra: so all is fine? | 14:12 |
ogra | no | 14:12 |
ogra | let me try something, one sec | 14:12 |
asac | why did it work for you then? | 14:12 |
ogra | asac, did you use the uImage i just posted ? | 14:12 |
asac | no. i used mine | 14:12 |
asac | e.g. the one created by the script | 14:12 |
asac | a few minutes ago | 14:12 |
lool | I added copyright to the script, since we all work for Canonical, right? ;) | 14:13 |
asac | you want me to test that? | 14:13 |
lool | (I picked a BSD style header) | 14:13 |
asac | we are supposed to use GPLv3 (not later) ;) | 14:13 |
ogra | ok | 14:14 |
asac | personally fine ;) | 14:14 |
ogra | so | 14:14 |
* asac waits for ogra | 14:14 | |
ogra | i create the image which i dd with the script | 14:14 |
ogra | then mount the second partition (leaving nautilus do that) | 14:14 |
ogra | and then just cp the other uImage in place | 14:14 |
asac | ok | 14:14 |
ogra | that seems to work | 14:14 |
asac | odd | 14:15 |
lool | So it would be the uImage? | 14:15 |
asac | how did you produce that? | 14:15 |
lool | lets check the mkimage args | 14:15 |
asac | ogra: ? | 14:15 |
ogra | what ? | 14:15 |
asac | how you produce the uImage that works | 14:15 |
ogra | i dont | 14:16 |
ogra | its a binary FSL offers | 14:16 |
ogra | 2.6.28 | 14:16 |
ogra | old kernel | 14:16 |
asac | ok | 14:16 |
ogra | thats why i made us look at mkimage for two days last week | 14:16 |
lool | So with uboot-image-script + FSL uImage, it works? | 14:16 |
ogra | oh, wait ! | 14:16 |
ogra | now it hangs | 14:16 |
ogra | lool, no, it doesnt | 14:17 |
ogra | i missed a reformat in the above descriptopn | 14:17 |
asac | ogra: doesnt help | 14:17 |
asac | BBG U-Boot > fatload mmc 0:2 0x90008000 uimage1 | 14:17 |
asac | reading uimage1 | 14:17 |
asac | hangs | 14:17 |
ogra | i forgot i had run one mkfs.vfat when you asked | 14:17 |
ogra | to rule out mcopy :P | 14:17 |
lool | So uboot-image-script + mkfs + FSL uImage works? | 14:18 |
ogra | right | 14:18 |
lool | What about uboot-image-script + mkfs + our uImage? | 14:18 |
ogra | without mkfs it doesnt | 14:18 |
lool | asac: Could you confirm? | 14:18 |
asac | what mkfs should i run? | 14:18 |
lool | I guess mkdosfs -F32 /dev/sdcard2 | 14:18 |
asac | trying | 14:19 |
lool | then write our uImage and FSL uImage and see what you get | 14:19 |
asac | sure | 14:19 |
ogra | ogra@osiris:~/Desktop/uboot$ sudo mkfs.vfat /dev/mmcblk0p2 | 14:19 |
ogra | mkfs.vfat 3.0.3 (18 May 2009) | 14:19 |
ogra | ogra@osiris:~/Desktop/uboot$ cp ../uImage /media/37B5-7516/ | 14:19 |
asac | got that | 14:19 |
ogra | thats what i do here | 14:19 |
lool | ogra: You used mkfs.vfat? Could you try mkdosfs -F32 instead? | 14:19 |
lool | So that we can rule out various things in the script | 14:19 |
ogra | will try | 14:19 |
ogra | but the above works definately | 14:20 |
asac | kernel in bad state. thinks its mounted | 14:20 |
ogra | poor you | 14:20 |
ogra | get better HW :) | 14:20 |
asac | sudo mkdosfs /dev/mmcblk0p2 | 14:20 |
asac | mkdosfs 3.0.3 (18 May 2009) | 14:20 |
asac | mkdosfs: /dev/mmcblk0p2 contains a mounted file system. | 14:20 |
lool | Probably because of the hang | 14:20 |
lool | asac: dd zero to it first | 14:20 |
asac | ok let me check | 14:20 |
lool | asac: It's a mkdosfs bug I guess | 14:20 |
* asac puts fresh img on sd | 14:21 | |
asac | ogra: so what mkdosfs are you running? without F32? | 14:21 |
lool | Right, rewriting the image is enough as well | 14:21 |
asac | didnt help | 14:21 |
ogra | aha ! | 14:21 |
asac | its really bad kernel | 14:21 |
asac | rebooting | 14:21 |
lool | That's odd | 14:22 |
ogra | mkdosfs -F32 makes it hang | 14:22 |
asac | ogra: does the trick help withour uimage? | 14:22 |
lool | Cool | 14:22 |
lool | ogra: Try -F16 | 14:22 |
* asac checks that | 14:22 | |
lool | It's small enough to be FAT16 | 14:22 |
lool | I'm pretty sure mkfs.vfat might pick FAT 16 if it's small enough | 14:22 |
lool | If nothing is specified, mkdosfs will automatically select between 12, 16 and 32 bit. | 14:22 |
lool | From the mkfs.vfat man page | 14:22 |
asac | lool the script is busted | 14:22 |
lool | asac: How so? | 14:23 |
asac | http://paste.ubuntu.com/355033/ | 14:23 |
asac | probably your tmp stuff ;) | 14:23 |
ogra | BBG U-Boot > fatload mmc 0:2 0x90008000 /uimage | 14:23 |
ogra | reading /uimage | 14:23 |
ogra | 2211052 bytes read | 14:23 |
ogra | YAY ! | 14:23 |
ogra | -F16 FTW | 14:23 |
lool | asac: thanks | 14:23 |
ogra | oh my | 14:23 |
lool | asac: Apparently can;t put the X where I like | 14:23 |
ogra | that costed so much time for nothing | 14:23 |
asac | having double " | 14:23 |
asac | ? | 14:23 |
asac | ogra: we started with F16 not working ;) | 14:24 |
lool | asac: that's fine | 14:24 |
lool | asac: see the mktemp error | 14:24 |
ogra | well, it works | 14:24 |
asac | yeah | 14:24 |
* asac backs it out locally to get something going | 14:24 | |
* ogra tries our uImage now | 14:24 | |
lool | asac: Fixed and fixed 16 bits too | 14:25 |
asac | good | 14:25 |
lool | And moved the set -e so that mktemp fails the script | 14:25 |
asac | right | 14:25 |
ogra | hmm | 14:25 |
ogra | hangs | 14:25 |
lool | So uImage is next I guess? | 14:26 |
ogra | yeah | 14:26 |
ogra | ogra@osiris:~/Desktop/uboot$ mkimage -l ../uImage | 14:26 |
ogra | Image Name: Linux-2.6.31-170-ga88b882 | 14:26 |
ogra | Created: Sun Dec 6 23:57:01 2009 | 14:26 |
ogra | Image Type: ARM Linux Kernel Image (uncompressed) | 14:26 |
ogra | Data Size: 2210988 Bytes = 2159.17 kB = 2.11 MB | 14:26 |
ogra | Load Address: 0x90008000 | 14:26 |
ogra | Entry Point: 0x90008000 | 14:26 |
lool | ogra: You could change UIMAGE to point to FSL uImage in the script and remove the mkimage, that should allow testing the full script with FSL image | 14:26 |
ogra | ogra@osiris:~/Desktop/uboot$ mkimage -l uimage | 14:26 |
ogra | Image Name: LinuxRocks | 14:26 |
ogra | Created: Mon Jan 11 15:07:33 2010 | 14:26 |
ogra | Image Type: ARM Linux Kernel Image (uncompressed) | 14:26 |
ogra | Data Size: 3062156 Bytes = 2990.39 kB = 2.92 MB | 14:26 |
ogra | Load Address: 0x90800000 | 14:26 |
ogra | Entry Point: 0x90800000 | 14:26 |
ogra | oh | 14:26 |
ogra | the adresses differ | 14:26 |
lool | Not the same kernel though | 14:26 |
asac | on my other image it doesnt matter | 14:27 |
asac | what you put on the load address etc. | 14:27 |
lool | Tss someone got the address wrong ;) | 14:27 |
asac | its all the fatload | 14:27 |
lool | asac: What do you mean? | 14:27 |
lool | asac: if the address is wrong or the kernel differ, you might erase important memory or use a different code path in uboot | 14:27 |
asac | the uImage works perfect on my SD that has my hadcrafted stuff | 14:27 |
lool | e.g. if the kernel is bigger or the address different, it could erase other memory | 14:28 |
lool | Also the kernel boot stuff might have changed across the versions | 14:28 |
asac | i am saying that exactly the uImage we are now producing works on my SD card :) | 14:28 |
lool | asac: With which uboot? | 14:28 |
asac | and i can boot it | 14:28 |
asac | the same version | 14:28 |
ogra | hmm, still hangs with our image | 14:28 |
asac | could be its the previous code drop | 14:28 |
lool | Ok so our uboot + out uImage work? | 14:28 |
asac | from FSL | 14:28 |
asac | my uboot works with our uImage | 14:29 |
asac | out uboot doesnt work even with the F32 dropped | 14:29 |
lool | But our uboot doens't work with our uimage? | 14:29 |
asac | so i will check the Load Address now | 14:29 |
lool | Ok | 14:29 |
asac | yes | 14:29 |
asac | my uboot works with everything | 14:29 |
lool | Even the load address? | 14:29 |
asac | the Load Address is completely irrelevant | 14:29 |
ogra | but you dont use mkimage from the archive | 14:29 |
lool | Yeah it's overruled | 14:29 |
asac | you specify the load address on the fatload promt | 14:29 |
asac | prompt | 14:29 |
lool | Yeah | 14:29 |
asac | and thats what is used | 14:29 |
asac | right | 14:29 |
lool | The entry point might matter though | 14:30 |
asac | anyway. let me still try ;) | 14:30 |
lool | It's wrong too | 14:30 |
asac | doesnt matter for my other image | 14:30 |
asac | well. atr least that one works ;) | 14:30 |
asac | let me check | 14:30 |
asac | using 0x90008000 for both now | 14:30 |
ogra | lool, i'm testing with the same avlues FSL uses and it doesnt work | 14:30 |
asac | right. | 14:31 |
ogra | asac, so which mkimage do you have installed atm ? | 14:31 |
asac | karmic | 14:32 |
ogra | the one from the archive or the one from source | 14:32 |
asac | karmic archive | 14:32 |
asac | maybe its oosync? | 14:32 |
ogra | shouldnt be | 14:32 |
asac | did you update the archive? | 14:32 |
ogra | no, i dont touch mkimage | 14:32 |
asac | yeah | 14:32 |
asac | but i dont think its mkimage | 14:32 |
ogra | i uploaded a fresh uboot bin today though | 14:32 |
asac | whatever i do it works with the other uboot thing i had | 14:32 |
ogra | but that should only just have built now | 14:32 |
asac | ok | 14:33 |
ogra | there were a bunch of new patches | 14:33 |
ogra | we migh want to try that binary | 14:33 |
asac | yeah | 14:33 |
asac | not sure what changed though ;) | 14:33 |
ogra | 0064-ENGR00119505-MX51-BBG-Change-DDR2-settings looks intresting | 14:34 |
ogra | 0065-ENGR00119526-MX25-Fix-mmc-read-write-failure-on-mmc too | 14:34 |
ogra | the others are rather generic or other mx platforms | 14:34 |
asac | ok so the fsl image really works | 14:35 |
asac | which is strange ;) | 14:35 |
ogra | yes | 14:35 |
ogra | and the worst is, there is no documentation to find anywhere how it was produced | 14:35 |
ogra | mkimage -l is all i can get | 14:35 |
ogra | which is how i found my load address and entry point defaults for initial testing | 14:36 |
asac | i really think its just the size difference | 14:36 |
ogra | i doubt that | 14:36 |
asac | at that stage uboot doesnt do much with it | 14:36 |
asac | just parse header and load to mem | 14:36 |
ogra | i managed to boot your uImage too last week, remember ? | 14:36 |
asac | the uImage we produce works fine on my other SD card | 14:37 |
ogra | with a fully manually created SD | 14:37 |
asac | yes. but my uboot from december works for everything | 14:37 |
asac | you cannot break it | 14:37 |
asac | ;) | 14:37 |
ogra | do you remember which config you used to build it ? | 14:37 |
* ogra guesses the oine thats gone from the tree in the last two uboot drops | 14:37 | |
asac | i used mx51 ... it was the last code drop | 14:37 |
asac | (e.g. the first uboot 2009.08 we had) | 14:38 |
asac | ogra: no. it was the new config | 14:38 |
ogra | ah, yeah, the config was redone afterwards | 14:38 |
asac | just not the same code drop we are using now | 14:38 |
ogra | hmm | 14:38 |
asac | the one before | 14:38 |
asac | and i build it in karmic | 14:38 |
ogra | right, i use the same | 14:38 |
ogra | but from the package | 14:38 |
asac | those are the different parameters | 14:38 |
asac | karmic + old code drop | 14:38 |
ogra | built in lucid on a babbage | 14:38 |
ogra | smae code drop | 14:38 |
asac | ogra: the package is the december code drop, isnt it? | 14:39 |
ogra | but from the package | 14:39 |
ogra | was | 14:39 |
ogra | until today | 14:39 |
asac | yes. but i used the one before that | 14:39 |
ogra | the one i use is the same as yours | 14:39 |
asac | you went back? | 14:39 |
asac | to Nov? | 14:39 |
ogra | we had no .08 drop before that | 14:39 |
asac | odd | 14:39 |
asac | my image was produced on Dec 07 | 14:39 |
asac | maybe the last karmic code drop already had that? | 14:39 |
ogra | the dec. drop i uploaded right before my holidays has the forst 2009.08 | 14:40 |
asac | yes, but thats after 07 Dec | 14:40 |
ogra | and was the first code drop i ever published | 14:40 |
asac | so it means there was a 08 code drop before | 14:40 |
ogra | where did you get that ? | 14:40 |
asac | ogra: you uploaded the one from before somewhere | 14:40 |
asac | and i took that | 14:40 |
ogra | hmm | 14:40 |
asac | let me check if i still have it | 14:40 |
* ogra looks at chinstrap | 14:41 | |
asac | deleted it :( | 14:41 |
ogra | well, its nothing we can use anyway | 14:41 |
ogra | and i think its more a prob of karmic vs lucid building | 14:42 |
lool | asac: Try using our kernel in FSL image? | 14:42 |
ogra | which remonds me, we likely dont have a dove lucid build either | 14:42 |
lool | mkimage it with FSL args and put it on a copy of the FSL image? | 14:42 |
ogra | ## Booting kernel from Legacy Image at 90800000 ... | 14:44 |
ogra | Image Name: LinuxRocks | 14:44 |
ogra | Image Type: ARM Linux Kernel Image (uncompressed) | 14:44 |
ogra | Data Size: 3062156 Bytes = 2.9 MB | 14:44 |
ogra | Load Address: 90008000 | 14:44 |
ogra | Entry Point: 90008000 | 14:44 |
ogra | Verifying Checksum ... Bad Data CRC | 14:44 |
ogra | ERROR: can't get kernel image! | 14:44 |
ogra | aha | 14:44 |
asac | let me build a .bin in karmic chroot | 14:45 |
lool | ogra, asac: I updated the script to drop explicit rms since cleanup() will take care of that; I think you guys need to figure out the contents now, the script itself seems ok except perhaps for the mkimage call | 14:46 |
lool | Can't help you much more without hardware I'm afraid | 14:47 |
ogra | yeah, thanks so much | 14:47 |
asac | thats ok ;) | 14:47 |
* ogra hugs lool | 14:47 | |
asac | thanks a lot | 14:47 |
lool | np | 14:47 |
* ogra has david call in 10 ... | 14:47 | |
ogra | asac, so resetting the board with a configured uboot gets me the above with our uimage | 14:48 |
ogra | Bad Data CRC seems the prob here | 14:48 |
asac | yes. we need debug in fat and so on | 14:48 |
asac | i am sure that there must be issues during loading things | 14:48 |
* ogra tries the new uboot.bin | 14:49 | |
asac | new? | 14:49 |
ogra | todays | 14:49 |
asac | ah | 14:50 |
asac | so on karmic we build with -marm | 14:50 |
asac | is that the case for lucid too? | 14:50 |
ogra | yes, its upstream in 2009.08 | 14:51 |
asac | kk | 14:51 |
ogra | i dropped the patch today | 14:51 |
ogra | you said you didnt have to patch the inline functions for your build | 14:52 |
asac | no clue. it was the code drop we dont have anymore. i applied all the upstream patches and made a build without packaging | 14:52 |
asac | so yeah. most likely | 14:53 |
asac | upstream==fsl | 14:53 |
ogra | hmm, i wonder why gcc didnt choke on the inline functions | 14:53 |
ogra | are you sure you used gcc 4.4 ? | 14:54 |
ogra | 4.4 will definately not accept them | 14:54 |
* ogra needs coffee for the call | 14:54 | |
asac | ogra: yes. i did the same i remember now (looking at the patch) | 14:56 |
asac | or i used static inline | 14:56 |
ogra | ok | 14:58 |
* ogra is our for 1h | 15:42 | |
asac | apw: so i think we didnt come to a conclusion on the kernel upload. will that just happen tomorrow? | 16:17 |
apw | asac, sorry? | 16:17 |
apw | should i not be uploading? | 16:17 |
asac | nono ... it _should_ | 16:19 |
plars | what happened with the livecd builds over the weekend? | 16:22 |
armin76 | asac broke them | 16:22 |
lool | plars: clementine needs a reboot | 16:27 |
lool | plars: IS is aware | 16:27 |
apw | asac, ok well it'll happen as soon as i can get the damn thing to build correctly ... its resisting | 16:34 |
asac | hmm | 17:02 |
asac | ok | 17:02 |
apw | asac, its on the buildd | 17:05 |
asac | apw: rock!!! | 17:05 |
apw | you get to keep both pieces :) | 17:06 |
asac | heh | 17:06 |
asac | ogra: did you enable ext2 in latest .bin already? | 17:14 |
ogra | asac, no, should i ? | 17:29 |
ogra | asac, in my testing it didnt change a thing, loading hung with etx2 was well as with vfat | 17:33 |
ogra | apw, "* drop a number of modules no longer built" what are these ? is there a list ? | 17:34 |
dmart | disconnect | 17:45 |
dmart | ...er... | 17:45 |
ameya | Hi everyone! | 21:06 |
ameya | Has anyone tried building lucid rootfs (ubuntu-minimal) with rootstock? | 21:07 |
rcn-ee | ameya, the lucid change hasn't landed in rootstock yet, however i'm using this for the moment: https://code.launchpad.net/~beagleboard-kernel/+junk/project-rootstock-lucid | 21:07 |
ameya | I am using the same | 21:09 |
ameya | I received "ubuntu-minimal: Depends: ureadahead but it is not going to be installed" | 21:10 |
ameya | and finally Kernel panic - not syncing: Attempted to kill init! | 21:10 |
ameya | I: Killed ... | 21:10 |
rcn-ee | weird... my daily test build worked this morning: http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log | 21:11 |
rcn-ee | actually my "xfce4 image" worked after the 'ubuntu-minimal' kernel panic'd... I'd give it another try, lots of changes going on... | 21:13 |
ameya | I am using: project-rootstock/lucid-support : 33 | 21:13 |
ameya | I checked at packages.ubuntu.com that ureadahead for lucid is only available for amd64 and i386 | 21:17 |
ameya | if ubuntu-minimal depends on ureadahead then won't it create a problem? | 21:17 |
rcn-ee | packages.ubuntu.com doesn't list arm, it's here: http://ports.ubuntu.com/pool/main/u/ureadahead/ | 21:18 |
ameya | ohhh! thanks :) | 21:18 |
ameya | can you tell me your command for building lucid? | 21:19 |
ameya | I will try again | 21:19 |
rcn-ee | ameya, i would just try it again, packages for lucid are updated daily, so something was weird at your time of running it.. Nothing special: sudo ./rootstock --fqdn beagleboard --login ubuntu --password temppwd --imagesize 2G --seed nano,linux-firmware,wireless-tools,usbutils --dist lucid | 21:21 |
ameya | hmm | 21:21 |
lool | ameya: ubuntu-minimal wont depend on ureadahead on an arch if it's not available | 21:22 |
lool | (germinate does check that) | 21:22 |
ameya | lool, Thanks! | 21:23 |
plars | trying alternate on dove and seeing a debootstrap error configuring required packages, anyone tried alternate recently and seen that? | 22:01 |
plars | NCommander maybe? ^ | 22:01 |
plars | odd, seems to still be making progress in the background even though I didn't tell it to continue yet | 22:01 |
NCommander | plars, ugh .... | 22:33 |
NCommander | plars, can you check the imx51 alternate as well? | 22:33 |
plars | NCommander: not at the moment | 22:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!