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