[04:08] <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.
[08:31] <lool> gregoiregentil: Thanks; I had not tested it, will look at fixing the patch to use MOUNTPOINT
[11:11] <ogra> fresh uboot-imx is uploaded with the lastest patchset ...
[11:18] <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:19] <ogra> you probably see something obvious we both dont find
[11:21] <dmart> Hi there... does anyone know why there were no armel daily-live images for the last couple of days?
[11:22] <dmart> 20100108 seems to work well, but the more recent images seem to have no armel variants.
[11:23] <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:24] <dmart> Is that expected, or did something go wrong?
[11:25] <dmart> http://cdimages.ubuntu.com/ports/daily-live/ has 20100110 and 20100111, but they only seem to have ia64 and powerpc
[11:26] <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:28] <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:29] <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:30] <dmart> Strange
[11:30] <ogra_> right, as i said, no attempt
[11:30] <ogra_> x86 built though ... so the builds were not disabled
[11:32] <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:33] <ogra_> great to hear
[11:38] <ADcomp> Can I add this board to "ARM/DeviceSupport" on ubuntu wiki  ?
[11:39] <lool> [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:40] <ogra> i pinged lamont already
[11:41] <lool> ADcomp: Which kernel tree supports the board?
[11:41] <lool> ADcomp: Does linux-omap support it?  linux?
[11:42] <ADcomp> lool: 2.6.31
[11:43] <lool> ADcomp: You mean naked linux 2.6.31 will support this board?
[11:46] <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:47] <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:48] <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:49] <lool> ogra: The first partition seems too small to me
[11:50] <ogra> 142848B
[11:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[12:00] <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:01] <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:02] <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:03] <asac> i am just the peer poking you
[12:03] <ogra> pfft
[12:04] <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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <asac> bah
[12:11] <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:12] <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:13] <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:14] <asac> want to give it a try ;)
[12:14] <asac> now that the bbg2 works
[12:17] <ogra> lool, adding the 512 to UBOOT_SIZE doesnt change a thing here
[12:18] <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:20]  * lool pushes lp:~lool/+junk/uboot-image-script
[12:21] <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:22] <ogra> ok
[12:22] <ogra> UBOOT_SIZE=$(($(stat -c %s "$UBOOT_BIN") - 1024)) ??
[12:22] <ogra> why do you subtract the padding ?
[12:24] <ogra> ./uboot-image-script: 67: arithmetic expression: expecting primary: ""62914560" / 1024"
[12:24]  * ogra checks
[12:29] <lool> I pushed sanity checks
[12:29] <lool> ogra: Looks like parted output is bofus
[12:30] <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:31] <ogra> hmm, seems that trashed the uboot binary
[12:31] <ogra> doesnt get to a prompt
[12:35] <ogra> lool, http://paste.ubuntu.com/354994/
[12:36] <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:37] <ogra> hmm, we should pass [start] [size+start]
[12:37] <asac> yes
[12:38]  * ogra will try that but needs some food too now 
[12:50] <asac> ok repushed lp:~ubuntu-armel/+junk/uboot-image-script
[12:54] <JamieBennett> asac: Did you talk to lutin about the EFL stuff?
[12:56] <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:57] <JamieBennett> asac: ah, OK
[13:00] <dmart> ogra: Just looking at the script...
[13:01] <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:02] <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:07] <ogra> doesnt work here
[13:07] <ogra> i still end up with a truncated uboot
[13:07] <asac> tried my branch?
[13:08] <ogra> yes
[13:08] <ogra> just zeroed my Sd to make sure its actually using the proper image
[13:09] <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:10] <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:11] <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:12] <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:13] <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:14]  * asac schedules a bzr brain-wash session for sprint
[13:14] <ogra> heh
[13:15] <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:16] <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:17] <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:18] <asac> so are you 100% sure that the current .bin works right if you do the part table manually?
[13:19] <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:24] <ogra> hmm, doesnt seem like uboot for imx has any debug config options at all
[13:26] <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:27] <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:28] <ogra> err
[13:28] <ogra> uboot_start=1024 ???
[13:28] <ogra> why 1024 ?
[13:28] <lool> ogra: So the /boot partition is miscomputed
[13:29] <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:30] <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:31] <ogra> 1024 leaves a gap
[13:32] <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:33] <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:34] <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:35] <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:37] <lool> Gah
[13:37] <lool> uboot_start doesn't mean the same thing now
[13:38] <lool> UBOOT_SIZE is wrong now
[13:39] <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:40] <asac> the dd is wrong a bit yes.
[13:41] <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:42] <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:43] <asac> done
[13:44] <ogra>  + 1 - 1 ?
[13:44] <ogra> why dont you just drop +1
[13:45] <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:46] <asac> odd. on bbg2 reset powers off
[13:46] <asac> ;)
[13:46] <lool> Yup
[13:46] <ogra> old bug
[13:47] <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:50] <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:51] <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:52] <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:53] <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:54] <ericm_> asac, have already checked with Marvell on those issues and no solution yet - I'll ping them more frequently on these
[13:55] <lool> ogra, asac: Could you test the latest version?
[13:55] <asac> sure
[13:55]  * ogra pulls
[13:56]  * 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:57] <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:58] <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:59] <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?
[14:00] <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:01] <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:02] <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:03] <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:04]  * 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:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21]  * 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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <asac> right.
[14:31] <ogra> asac, so which mkimage do you have installed atm  ?
[14:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41]  * ogra looks at chinstrap
[14:41] <asac> deleted it :(
[14:41] <ogra> well, its nothing we can use anyway
[14:42] <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:44] <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:45] <asac> let me build a .bin in karmic chroot
[14:46] <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:47] <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:48] <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:49]  * ogra tries the new uboot.bin
[14:49] <asac> new?
[14:49] <ogra> todays
[14:50] <asac> ah
[14:50] <asac> so on karmic we build with -marm
[14:50] <asac> is that the case for lucid too?
[14:51] <ogra> yes, its upstream in 2009.08
[14:51] <asac> kk
[14:51] <ogra> i dropped the patch today
[14:52] <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:53] <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:54] <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:56] <asac> ogra: yes. i did the same i remember now (looking at the patch)
[14:56] <asac> or i used static inline
[14:58] <ogra> ok
[15:42]  * ogra is our for 1h
[16:17] <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:19] <asac> nono ... it _should_
[16:22] <plars> what happened with the livecd builds over the weekend?
[16:22] <armin76> asac broke them
[16:27] <lool> plars: clementine needs a reboot
[16:27] <lool> plars: IS is aware
[16:34] <apw> asac, ok well it'll happen as soon as i can get the damn thing to build correctly ... its resisting
[17:02] <asac> hmm
[17:02] <asac> ok
[17:05] <apw> asac, its on the buildd
[17:05] <asac> apw: rock!!!
[17:06] <apw> you get to keep both pieces :)
[17:06] <asac> heh
[17:14] <asac> ogra: did you enable ext2 in latest .bin already?
[17:29] <ogra> asac, no, should i ?
[17:33] <ogra> asac, in my testing it didnt change a thing, loading hung with etx2 was well as with vfat
[17:34] <ogra> apw, "* drop a number of modules no longer built" what are these ? is there a list ?
[17:45] <dmart> disconnect
[17:45] <dmart> ...er...
[21:06] <ameya> Hi everyone!
[21:07] <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:09] <ameya> I am using the same
[21:10] <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:11] <rcn-ee> weird...  my daily test build worked this morning: http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log
[21:13] <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:17] <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:18] <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:19] <ameya> can you tell me your command for building lucid?
[21:19] <ameya> I will try again
[21:21] <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:22] <lool> ameya: ubuntu-minimal wont depend on ureadahead on an arch if it's not available
[21:22] <lool> (germinate does check that)
[21:23] <ameya> lool, Thanks!
[22:01] <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:33] <NCommander> plars, ugh ....
[22:33] <NCommander> plars, can you check the imx51 alternate as well?
[22:38] <plars> NCommander: not at the moment