[01:48] <dcordes> GrueMaster, awesome. I didn't know about that option, thanks
[01:49] <dcordes> rsalveti, any news :) ?
[01:52] <rsalveti> dcordes: worked fine :-)
[01:53] <rsalveti> dcordes: installed the ubuntu-minimal on my sd card
[01:53] <rsalveti> with maveric
[01:53] <rsalveti> *maverick
[01:53] <rsalveti> and then just installed the ubuntu-netbook package, with tons of dependencies
[01:53] <rsalveti> mono was included and did work fine
[01:57] <dcordes> rsalveti, oh nooo
[01:58] <dcordes> ^^
[01:58] <dcordes> rsalveti, hm my first thought is something went wrong during my ubuntu-minimal image install
[01:59] <rsalveti> don't know, could be, try it again
[01:59] <dcordes> no I won't
[01:59] <dcordes> it would be the third time
[01:59] <dcordes> and I will see the same error
[01:59] <dcordes> I must do something wrong
[01:59] <dcordes> I will boot the image now and see if I can work around it somehow
[02:01] <rsalveti> try giving strace on the process that got hang
[02:01] <dcordes> apt-get
[02:01] <rsalveti> or running the update by hand, to find the problem
[02:01] <rsalveti> I got the correct line that was giving problem on the bug, let me find it
[02:02] <rsalveti> dcordes: just /usr/bin/mono /usr/lib/mono/2.0/gacutil.exe was enough to generate the error with qemu
[02:02] <rsalveti> see bug 610719
[02:02] <ubot2> Launchpad bug 610719 in mono (Ubuntu) "Mono hangs while running with qemu ARM user emulation (chroot) (dup-of: 530000)" [Undecided,New] https://launchpad.net/bugs/610719
[02:02] <ubot2> Launchpad bug 530000 in qemu-kvm (Ubuntu) "mono assembly installation under qemu-arm-static hangs (affects: 2) (dups: 1) (heat: 30)" [Medium,Won't fix] https://launchpad.net/bugs/530000
[02:03] <rsalveti> I think you're probably getting another bug
[02:03] <dcordes> rsalveti, it is not the same mono bug I see in qemu.
[02:03] <rsalveti> dcordes: what arm machine are you using at your installation?
[02:03] <dcordes> the native mono bug is a different one.
[02:03] <dcordes> rsalveti, cortex-a8 htcleo
[02:04] <dcordes> rsalveti, and host is x86
[02:04] <rsalveti> it did work fine on my beagle, weird
[02:04] <rsalveti> host should not be a problem
[02:04] <rsalveti> ubuntu-minimal is really minimal, quite small image
[02:04] <dcordes> rsalveti, how big is your compressed minimal-image ? could you upload the one you used in the test ?
[02:04] <rsalveti> let me check
[02:05] <dcordes> ok here is the line
[02:05] <dcordes> I ran dpkg --configure -a
[02:05] <dcordes> (cause apt tells me to)
[02:05] <rsalveti> uploading it, will take some minutes
[02:06] <rsalveti> dcordes: do you have the logs?
[02:06] <dcordes> * Installing 2 assemblies from libappindicator0.1-cil into Mono
[02:06] <dcordes> this the same line it froze during the initial 'apt-get install ubuntu-netbook
[02:06] <dcordes> '
[02:06] <dcordes> and I'm almost sure it is the same thing I got when I tried same procedure a week ago
[02:07] <dcordes> all of the installing n assemblies processes fail
[02:08] <dcordes> it is the mono program that freezes
[02:08] <dcordes> now I remember...
[02:08] <dcordes> I debugged it before
[02:08] <dcordes> it eats all cpu
[02:10] <dcordes> is there no 'assume provided' kind of thing for apt ?
[02:11] <dcordes> so mono must be child of apt-get
[02:11] <dcordes> or dpkg in the current case right ?
[02:11] <dcordes> i.e. I should be able to debug it with dbg
[02:11] <rsalveti> yep
[02:11] <rsalveti> there is a command that installs the assemblies
[02:12] <rsalveti> it's on the post install of some mono packages
[02:12] <rsalveti> so you could debug it directly instead of debugging apt
[02:12] <dcordes> can you tell me how to figure the command that's ran ?
[02:15] <rsalveti> I can try to find it here, give me a minute
[02:15] <dcordes> thx
[02:16] <dcordes> rsalveti, maybe my kernel is more similar like qemu :)
[02:19] <dcordes> rsalveti, lol I can't install strace
[02:19] <dcordes> guess why
[02:20] <rsalveti> dcordes: hahah, why?
[02:20] <dcordes> if you answer correct you get a free mono.deb
[02:22] <rsalveti> haha, no idea, and I don't want a free mono.deb :P
[02:22] <rsalveti> thanks
[02:22] <dcordes> dpkg was interrupted. you must manually run 'sudo dpkg --configure -a' to correct the problem.
[02:23] <dcordes> :>
[02:24] <rsalveti> ouch :-)
[02:24] <rsalveti> guess you can still install it by hand, giving dpkg -i
[02:24] <rsalveti> after downloading the package
[02:25] <dcordes> apt-get --download-only install strace to download ?
[02:26] <rsalveti> dcordes: check file /usr/share/cli-common/runtimes.d/mono
[02:26] <rsalveti> it's a perl script that probably installs the assemblies
[02:27] <rsalveti> get's called by /usr/share/cli-common/gac-install
[02:27] <rsalveti> during a post-inst
[02:27] <dcordes> I think I make it a hello world.
[02:28] <dcordes> rsalveti, how to download package with broken apt ?
[02:29] <rsalveti> dcordes: you can download it by hand, with wget :P
[02:29] <rsalveti> generally apt keeps complaining all the time if you canceled a previous run
[02:30] <dcordes> rsalveti, do you have url for the maverick arm debs ?
[02:30] <dcordes> I download it to usb mass storage device on host
[02:30] <dcordes> rsalveti, are you still uploading your minimal ?
[02:31] <rsalveti> dcordes: yep, 98%
[02:31] <dcordes> nice thx
[02:32] <rsalveti> dcordes: http://ports.ubuntu.com/ubuntu-ports/pool/main
[02:33] <rsalveti> dcordes: wget http://rsalveti.net/pub/armel-rootfs-201008021722.tgz
[02:34] <dcordes> rsalveti, something is definetly going wrong with my minimal then
[02:34] <dcordes> rsalveti, mine is t60 meg
[02:35] <dcordes> 60
[02:35] <dcordes> rsalveti, do you specify extra packages with the roostock script ?
[02:37] <rsalveti> dcordes: this is just ubuntu-minimal with kernel and kernel modules
[02:37] <rsalveti> that's why it's probably bigger than yours
[02:37] <dcordes> aha ok
[02:57] <dcordes> rsalveti, ok now I got the strace output on screen
[03:04] <dcordes> rsalveti, and it doesn't give me full enlightenment yet :D
[03:05] <dcordes> I'm still starring
[03:11] <dcordes> rsalveti, how long does such a mono install process take for you ?
[03:12] <dcordes> rsalveti, I made the script do nothing
[03:12] <dcordes> rsalveti, now some installing mono tasks succeed
[03:12] <dcordes> some still run and fail
[03:13] <dcordes> ah it found the renamed original script!
[03:14] <dcordes> evil
[03:14] <dcordes> done!
[03:14] <rsalveti> haha :-)
[03:15] <rsalveti> generally it takes a minute or so
[03:15] <dcordes> maybe I'm to impatient
[03:15] <dcordes> but 20 minutes are pretty much foul
[03:15] <dcordes> methink
[03:16] <dcordes> apt-get install netbook-launcher-efl
[04:04] <rsalveti> GrueMaster: yep, I'm getting the same error lag is facing with his lg monitor
[04:05] <rsalveti> probably this is fixed already with robclark patches
[04:05] <GrueMaster> Interesting.
[04:06] <GrueMaster> I don't have an HDMI monitor, but will test this when I am at the QA sprint in a couple of weeks.
[04:06] <rsalveti> GrueMaster: when are you going to be off for the qa sprint?
[04:07] <GrueMaster> I leave next Friday and will be in Oxford until the 22nd.
[04:07] <rsalveti> GrueMaster: oh, ok :-)
[04:07] <GrueMaster> Food's cooking, gotta run.
[04:07] <rsalveti> see ya
[04:17] <robclark> fyi, for DVI monitors, I pushed a patch: http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commit/37050de250e570d67a435cb36ecfa9763a98e5ff
[04:18] <robclark> it won't make any monitor that wasn't working at all start working.. but it will make some DVI monitors that were defaulting to 640x480 pick a better resolution
[04:18] <robclark> (this at least helps with my DVI monitor at home ;-))
[06:50] <mythripk> lag:ping . do you see it always ?
[06:50] <mythripk> oops : *do you see it always ?
[07:41] <lag> mythripk: Morning
[07:48] <mythripk> morning lag
[07:48] <mythripk> did you see it again ?
[07:48] <mythripk> i tried and could not reproduce
[07:48] <lag> I see different things depending on my cmdline
[07:49] <mythripk> can you send your cmdline ?
[07:49] <lag> omapdss DISPC error: SYNC_LOST_DIGIT
[07:49] <lag> omapdss HDMI error: Failed to lock PLL
[07:49] <lag> quiet splash ro elevator=noop console=ttyO2,115200n8 vram=32M mem=463M fixrtc
[07:49] <mythripk> failed to lock pll is because the first block is 1920 1080 with 138.5Mhz
[07:50] <lag> Okay
[07:50] <mythripk> that will be fixed with the patches i sent you  , which will be part of out L24.9 release
[07:50] <lag> Okay
[07:50] <lag> So they're not out yet?
[07:50] <mythripk> not yet! , will be by this friday
[07:50] <lag> Have they been approved?
[07:50] <mythripk> yes
[07:51] <lag> Excellent, well done
[07:51] <mythripk> that is anyways our internal tree :) though
[07:51] <lag> I guess I'll wait for those before doing anymore
[07:51] <lag> I'll try and get them into our tree asap
[07:52] <mythripk> but this is a strange error you see , it is failing in dispc_set_digit_size which would mean   x and y res are goofed up, in case you see that again a full log with debug enabled would be great
[07:53] <lag> I'm sure I can reproduce
[07:53] <lag> Wait one
[07:57] <lag> mythripk: I don't get the whole log (I guess most of it is printed to the monitor (which isn't working)
[07:57] <lag> http://paste.ubuntu.com/472531/
[07:58] <lag> mythripk: setenv bootargs vram=32M mem=463M console=ttyO2,115200n8 console=tty2 root=/dev/mmcblk0p2 fixrtc
[07:59] <lag> If I remove the console=tty2 it does something different
[08:02] <lag> I correct myself
[08:02] <lag> Its actually this cmdline: setenv bootargs quiet splash ro elevator=noop console=ttyO2,115200n8 vram=32M mem=463M fixrtc
[08:04] <lag> That's more like it
[08:04] <lag> When I remove the console=tty2 I get this:#
[08:05] <lag> http://paste.ubuntu.com/472534/
[08:06] <hrw> alo
[08:17] <lag> ogra: ping
[08:33] <mythripk> lag : I suspect that it is becasue of the wrong x and y timing value. which ideally shouldnt , you are using console = ttyo2 which is ok  , this would be needed to redirect your prints to TV when enabled. Can you wait for the patch set to be pushed ?
[08:34] <lag> ttyO2 won't push the prints to the TV/Monitor, only to the serial console
[08:34] <lag> tty2 will push them to the TV/Monitor
[08:40] <mythripk> lag: my bad . "lag : When I remove the console=tty2 I get this:#" that would when it is trying to redirect the contents  to TV where you get the pll_not locked  state
[08:42] <asac> persia: could you check http://revu.ubuntuwire.com/p/glmark2 for alf`?
[08:43] <lag> mythripk: If you read on you'll find that I was incorrect
[08:43] <lag> mythripk: In fact, the only think that differs when I removed console=tty2 is that I receive more output on the serial
[08:43] <lag> I'll wait for the new patches
[08:46] <mythripk> lag: I shall update you when its pushed to our tree
[08:46] <lag> mythripk: Great thanks
[08:52] <ukleinek> ericm|ubuntu: I would have expected from me to notice the breakage even though it was your patch :-)
[09:16] <ericm|ubuntu> ukleinek, nah - you are fine
[09:17] <amitk> ericm|ubuntu: have you worked with the Freescale guys in Shanghai?
[09:17] <ericm|ubuntu> amitk, a bit
[09:17] <ericm|ubuntu> amitk, but not much
[09:18] <ericm|ubuntu> amitk, knows some guys there as well as cooloney
[09:18] <amitk> ericm|ubuntu: ok, one of them joined Linaro today (just introducing around)
[09:18] <ericm|ubuntu> amitk, in #linaro?
[09:18] <ericm|ubuntu> amitk, I missed that part
[09:18] <amitk> ericm|ubuntu: yes
[09:36] <cooloney> amitk: is he/she based in Shanghai?
[09:36] <amitk> cooloney: yes, come to #linaro to meet him
[09:51] <ukleinek> amitk: I have a mx51evm here and it seems to be broken with CONFIG_FIXED_PHY=y; CONFIG_MDIO_BITBANG=y; CONFIG_MDIO_GPIO=y
[09:52] <ukleinek> amitk: Did you see this already, too?
[09:53] <cooloney> ukleinek: hi, how's broken?
[09:53] <amitk> ukleinek: unfortunately no, haven't had a chance to test mx51 for a few -rcs since my board broke. :-/ I just got a new one now so should be able to test.
[09:53] <cooloney> ukleinek: in our ubuntu fsl-imx51, those configs are all off,
[09:54] <ukleinek> amitk: the fec doesn't work so I cannot nfsrootboot
[09:55] <amitk> cooloney: you fixed the fec driver for MDIO support, right? Do you have time to look at this today?
[09:56] <cooloney> ukleinek: yeah, my patch was merged sometime ago and there are some updates in Dave's netdev-next tree
[09:56] <cooloney> amitk: yeah, ^^
[09:56] <cooloney> but too bad, i don't have the hardware now
[09:56] <cooloney> my babbage is broken
[09:56] <cooloney> bricked
[09:58] <amitk> ukleinek: I'll try to look at it as soon as I setup the new board
[09:58] <ukleinek> amitk: this issue is in my way, I can do it myself, too.
[10:00] <amitk> ukleinek: ok, I can't help you right away (so you might consider looking at it)
[10:00]  * ukleinek just wanted to check if it's a known (or even fixed) issue
[10:01] <amitk> ukleinek: no it isn't (we've had HW availability issues). Thanks for the report
[10:04] <ukleinek> CONFIG_FIXED_PHY=y is the trigger
[10:06] <ogra> lag, yes ?
[10:07] <lag> ogra: Do you have a uboot which omits the memory error on XM?
[10:08] <ogra> i have an yet untested patch http://cgit.openembedded.org/cgit.cgi/openembedded/diff/?id=b4c5ef7e0e06890b1369bfbd5c767820024adb21&id2=b738634ead43d9ebcc8f8a4840366528ec91045a
[10:10] <cooloney> ukleinek: pls take a look at this http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commitdiff;h=0e5e6e2a981eeab61dcc184d51ab769a33af6589
[10:10] <cooloney> ukleinek: and this http://bugs.launchpad.net/bugs/457878
[10:10] <ubot2> Ubuntu bug 457878 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "imx51 on board ethernet plug/unplug events not detected (affects: 2) (heat: 15)" [Medium,Fix released]
[10:11] <ukleinek> cooloney: is this a fix or a work around?
[10:12] <cooloney> ukleinek: i simply turned that off.
[10:13] <ukleinek> cooloney: the plug/unplug event thing is fixed upstream
[10:14] <cooloney> ukleinek: CONFIG_FIXED_PHY will cause a sysfs conflict when I was trying to add phylib support in fec driver
[10:41] <lag> ogra: What SD card are you using for your XM?
[10:50] <ogra> lag, traxdata 4G currently
[10:51] <lag> ogra: Have you seen the "mmc0: USB HID whilst initialising SD card" issue?
[10:53] <lag> ogra: Is the Traxdata a High Capacity (SDHC) card?
[11:02] <cwillu_at_work> hands out free samples of his slc 4gb flash crack :)
[11:14] <lag> cwillu_at_work: ?
[11:14] <cwillu_at_work> lag, I buy silly sd cards
[11:15] <cwillu_at_work> they don't break when you pull power from them mid-write
[11:15] <lag> cwillu_at_work: The XM's kernel doesn't like my SanDisk Micro SDHC card :(
[11:16] <cwillu_at_work> !info ttf-larabie-straight
[11:16] <ubot2> cwillu_at_work: ttf-larabie-straight (source: ttf-larabie): Straight fonts from www.larabiefonts.com. In component multiverse, is optional. Version 1:20011216-1.1 (lucid), package size 3462 kB, installed size 7860 kB
[11:17] <cwillu_at_work> that doesn't want to install on arm
[11:17] <cwillu_at_work> reports that it's a virtual package
[11:17] <cwillu_at_work> makes me want to cry
[11:18] <cwillu_at_work> ... or I just don't have multiverse enabled....
[11:19] <cwillu_at_work> if I give you ssh to my server, can you call my cell if the build breaks again?
[11:19] <cwillu_at_work> I need to go for a walk :/
[12:26] <lag> ogra: Am I correct in assuming you have fully booting XM and Panda boards?
[12:30] <ogra> lag, no, XM doesnt
[12:31] <ogra> i see some mmc issues but have lost the dmesg data for it before i could look
[12:31] <ogra> it finds the mmc though, but the device is readonly
[12:31] <ogra> (sfdisk complains it cant open the device for writing)
[12:33] <lag> Okay
[12:33] <lag> I'm just compiling a kernel which should eradicate my -110 error
[12:33] <lag> Once that's gone, I'll look into any other errors
[12:33] <lag> Can you send me the kernel logs you have?
[12:34] <lag> For XM and Panda would be helpful
[12:35] <ogra> will do after the next image test (i just triggered a build)
[12:36] <ogra> the XM is totally trashed atm
[12:36] <lag> Kernel error, or userspace?
[12:36] <ogra> the filesystem dissolved itself at some point after i did reset the system several times
[12:37] <ogra> i think the root cause is a kernel or bootloader issue with the SD bus though
[12:38] <lag> Well if you can get me some logs, I can try to do something about it
[12:41] <rcn-ee> ogra.. just fixed the ro bit last night.. http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.35-devel/annotate/head:/patches/rcn/xm-wp-testing.diff
[12:41] <rcn-ee> verified by another user, i'll clean up the patch a little.
[12:42] <ogra> lag, ^^^
[12:42] <ogra> can i has that ? pleeeease
[12:42] <rcn-ee> basicly, the xm schematic has no wp, the current kernel defaults to a bx or cx non-existent wp line on the beagle.. (bad)
[12:43] <ogra> hrm, yeah
[12:44] <rcn-ee> but there's another weird bug in 2.6.35 i'm going after.. on both my Bx and Cx boards, the mmc card is defaulting to 'ro' on boot.  Have you guys seen that too on your kernel?
[12:45] <ogra> yes, thats what i described above
[12:46] <ogra> it appears like its locked
[12:46] <rcn-ee> yeap, well that patch fixes the xm..  the Bx and Cx have a gpio issue, playing around with the write protect lever it seems to be ignored..
[12:48] <rcn-ee> this brings ti back to 2.6.34/2.6.33 behavor in my testing: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.35-devel/annotate/head:/patches/rcn/regression-disable-wp.diff but i think there's bigger issues in the mmc write protect detection as it doesn't register the write protect lever in my testing..
[12:49] <rcn-ee> it's basicly revert ed8303fc111e58530e22bd29b0d7e08dced75999 introduced in 2.6.35-rc1
[13:05] <dyfet> ping: ogra
[13:10] <lag> rcn-ee: Have you seen the -110 error?
[13:10] <lag> rcn-ee: On XM?
[13:15] <rcn-ee> lag, probally.. i see lots of errors on mine.. 'sudo aptitude' opps it for me.. (i really need to get production hardware.. very early proto "P7" full of extra solder wires for traces..)
[13:16] <rcn-ee> i think that's the usb -110 error right?
[13:16] <lag> rcn-ee: "mmc0: USB HID whilst initialising SD card"
[13:16] <lag> You'd know if you had it, because it dies on the way up
[13:16] <lag> It doesn't find the SD card
[13:18] <rcn-ee> that's very weird.. mine finds the SD: (last saved dmesg) http://pastebin.com/4Dtysi8W
[13:19] <lag> It must like your MicroSD card
[13:19] <lag> Which one are you using?
[13:19] <rcn-ee> just generic sandisk..
[13:19] <lag> SDHC?
[13:19] <lag> Or SC?
[13:19] <rcn-ee> 4Gb/2Gb sdhc..
[13:19] <lag> That's interesting
[13:19] <lag> Are you using our kernel?
[13:20] <rcn-ee> but i almost think they are clones.. the adapters don't work and i had to use another one..
[13:20] <rcn-ee> yeap that's mine kernel..
[13:20] <lag> Okay
[13:20] <lag> Our kernel doesn't like SDHC cards
[13:20] <rcn-ee> weird...
[13:20] <lag> We have to turn off preemption to get them to work
[13:21] <rcn-ee> does it also fail with the Bx/Cx's?
[13:21] <rcn-ee> (sdhc)
[13:21] <lag> No idea
[13:21] <lag> I don't have either of those
[13:21] <lag> I haven't heard of it
[13:21] <lag> Only XM
[13:21] <lag> rcn-ee: bug 591941
[13:21] <ubot2> Launchpad bug 591941 in linux (Ubuntu Maverick) (and 1 other project) "SDHC card not recognized (affects: 2) (dups: 1) (heat: 80)" [High,In progress] https://launchpad.net/bugs/591941
[13:23] <rcn-ee> that actually might be 'too' cheap cards......  cat-ing my config, wondering if? # CONFIG_MMC_SDHCI is not set
[13:24] <lag> It's a SanDisk
[13:27] <rcn-ee> you guys don't off hand happen to know where the mmc keeps there error code list.. (looking 110)
[13:28] <lag> Not off hand, sorry
[13:29] <ukleinek> rcn-ee: 110 is usually ETIMEOUT
[13:29] <rcn-ee> i found another reference in the plug computer forums, looked like a bad sandisk card..
[13:30] <rcn-ee> thanks ukleinek
[13:30] <lag> I've seen it happen with others
[13:31] <rcn-ee> which isn't good...  reading the bug report, it's pretty consistent, but is there a specific image i should test with my xm and collection of sd cards?
[13:33] <lag> Please :)
[13:33] <lag> rcn-ee: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
[13:33] <lag> gunzip it and dd it to your MicroSD card
[13:35] <ukleinek> cooloney: CONFIG_FIXED_PHY is enabled in mx51_defconfig
[13:35] <rcn-ee> got it..  i'll pull it down at work in a bit, just getting ready at the moment..  i'll log back in a couple hours with my findings..
[13:35] <lag> rcn-ee: Great, thanks
[13:43] <rsalveti> lag: any news regarding the problem you had yesterday with your lg monitor?
[13:43] <rsalveti> lag: I got the same problem with mine :-)
[13:43] <rsalveti> lag: with panda
[13:44] <lag> What's it doing?
[13:45] <rsalveti> lag: http://paste.ubuntu.com/472128/
[13:45] <cooloney> ukleinek: hmmm, but do we use CONFIG_FIXED_PHY in ARM system
[13:46] <lag> mythripk: ping
[13:46] <lag> rsalveti: Wait one
[13:46] <lag> rsalveti: What monitor are you using?
[13:46] <rsalveti> lag: lg with hdmi
[13:47] <ukleinek> cooloney: mx51 is the only defconfig that has it
[13:47] <mythripk> lag: is this regarding the dump from rsalveti ?
[13:49] <lag> mythripk: Yep
[13:49] <lag> Mine is LG with HDMI too
[13:49] <lag> rsalveti: Which model?
[13:50] <rsalveti> lag: W2253V
[13:51] <cooloney> ukleinek: if we don't need it, we can disable it in mx51
[13:51] <lag> rsalveti: Okay mine is W2261VP
[13:51] <cooloney> ukleinek: it looks like just for x86
[13:51] <ukleinek> cooloney: then it should depend on X86, no?
[13:53] <rsalveti> lag: any news regarding this bug? still didn't look for patches into other trees
[13:54] <cooloney> ukleinek: from the code, 'Fixed MDIO bus (MDIO bus emulation with fixed PHYs)'
[13:54] <cooloney> ukleinek: i am not sure about what is Fixed PHY
[13:54]  * ukleinek isn't either
[13:55] <lag> rsalveti: Ask mythripk
[13:55] <rsalveti> mythripk: were you debugging this lg monitor issue?
[13:58] <mythripk> rsalveti: yes i was and the issue is fixed now but then the patches will be pushed to our tree only by this friday.
[13:59] <rsalveti> mythripk: and where can I find these patches? is it just an internal tree?
[13:59] <mythripk> rsalveti : The issue is because in the lg monitor block 0 has 1080P timing with 138.5Mhz which is not a standard
[13:59] <mythripk> its still in the internal tree
[13:59] <rsalveti> =\
[14:00] <mythripk> oh wait let me check robclark's tree
[14:00] <mythripk> he must have pushed
[14:00] <rsalveti> ok
[14:02] <rsalveti> nice to know that my monitor doesn't follows the standard :-)
[14:02] <mythripk> http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commit/f2fa54fcfe8fa09ad14f104ae64d1bb5c93982bc and this http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commit/5553031b56322a7dbaa2f57b8f773be9ae2baaff
[14:03] <mythripk> rsalveti : other block timings are still ok :)
[14:03] <rsalveti> mythripk: nice, thanks for the links
[14:07] <mythripk> rsalveti : you dont have to give any bootargs with this if you were giving any for HDMI , just try and let me know.
[14:07] <rsalveti> mythripk: sure, will do
[14:07] <rsalveti> thanks
[14:22] <ukleinek> amitk: mx51 doesn't use IMX_IO_ADDRESS.  Do you prefer the mx51's current approach or did this just slip through?
[14:25] <lag> rsalveti: What are you going to do with that patch/
[14:25] <lag> ?
[14:25] <rsalveti> lag: test it? :-)
[14:26] <lag> And then/
[14:26] <lag> ?
[14:26] <rsalveti> lag: will let you all know if it worked or not
[14:26] <lag> Okay
[14:26] <rsalveti> and then we can think if we're going to merge or wait for friday's tree
[14:26] <lag> Those patches should all be coming to us sooner or later anyway
[14:26] <rsalveti> yep
[14:27] <lag> Let me know how you get on and we'll have a chat
[14:27] <ogra> the sooner the better
[14:28] <rsalveti> yep
[14:36] <lag> ogra: It matters not
[14:36] <ogra> lag, it does
[14:36] <ogra> we'Re way behind on the omap arches and need the HW to work
[14:40] <lag> I'm still getting OOM
[14:41] <lag> on XM
[14:41] <lag> I thought this was a HW issue
[14:41] <lag> We can only work with what we've got
[14:49] <mythripk> lag: i guess mdelay is missed in the patch from rob's tree can you please point that out to rsalveti ?
[14:50] <ogra> lag, yes, and there are a ton of patches for XM that surely arent applied to our tree
[14:50] <ogra> some crappier some not
[14:50] <ogra> i know that people in #beagle do some work on booted XMs so we have to be missing a lot
[14:53] <lag> rsalveti: ping
[14:53] <rsalveti> lag: pong
[14:55] <lag> http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=blobdiff;f=drivers/video/omap2/dss/hdmi.c;h=0830bbc6baed30e04afca7b1c1a5b83ec298c890;hp=a8bedb1facd324eb6d2f07767ae6399f7c24ec3a;hb=76dd0768b77f731bbe6ad4df55379734f3a38770;hpb=f6c95ac85cfa087a84cd82564dcaea8ce4a6c867
[14:55] <lag> mythripk says this is missing from robclark's patches
[14:55] <lag> Insure you add it, or your monitor won't work
[14:55] <robclark> yes it is
[14:55] <lag> robclark: Don't shoot the messenger
[14:55] <amitk> ukleinek: MX51_IO_ADDRESS should be replaced with IMX_IO_ADDRESS at some point
[14:55] <lag> ;)
[14:56] <ukleinek> amitk: ok, will do
[14:56] <robclark> you need that one from mythripk's patches :-)
[14:56] <robclark> no shooting involved :-)
[14:56] <robclark> ("yes it is" == "yes it is missing")
[14:56] <robclark> sorry, I noticed my wording wasn't so clear
[14:56] <rsalveti> lag: ok, will apply the patches and test it here, thanks for the link
[14:56] <amitk> ukleinek: thanks
[14:56] <lag> robclark: Ah, lost in translation (from US to English) ;)
[14:57] <robclark> no.. I just haven't had my coffee yet this morning ;-)
[14:57] <ogra> texan vs australian you mean ?
[14:57] <robclark> heheh
[14:57]  * lag kicks ogra in the nether-regions
[14:58] <ogra> ouch
[14:59] <ogra> geez !
[14:59] <lag> :)
[14:59] <ogra> logging out on the panda steals my display
[15:00] <ogra> no signal anymore
[15:00] <ogra> ah, its just slow
[16:28] <GrueMaster> what adds flash-kernel to the /etc/kernel-img.conf file?  It is currently not enabled in the 20100802 image, so updating to the latest kernel doesn't run flash-kernel.
[16:29] <lool> GrueMaster: Usually, it's flash-kernel-installer, but it might be the image generation script
[16:34] <GrueMaster> Thanks. I see it in the changelog as being added in May, but I see nothing in the code now.  Looking at actual diffs.
[16:53] <GrueMaster> lool: It looks like this was heavily discussed in the last few cycles, but never really resolved (that I can see).  See bug 365053.
[16:53] <ubot2> Launchpad bug 365053 in initramfs-tools (Ubuntu) (and 1 other project) "On armel (Babbage platform), kernel image upgrading breaks if Ubiquity is instructed not to install a bootloader (heat: 12)" [Medium,Triaged] https://launchpad.net/bugs/365053
[16:54] <GrueMaster> Of course this bug is moot with preinstalled images as we don't use ubiquity (except for oem-config).
[16:55] <GrueMaster> I would think that it should be up to the flash-kernel-installer.postinst script to ensure that it is added to /etc/kernel-img.conf.
[16:56] <lag> rcn-ee: Hey Robert
[17:27] <ogra_cmpc> GrueMaster, lool, kernel-img.conf isnt used anymore by flash-kernel (debian dropped it) flash-kernel is always run by update-initramfs now
[17:27] <GrueMaster> Hmmm.  It didn't run on this update.
[17:28] <ogra_cmpc> does /etc/flash-kernel.conf exist ?
[17:28] <GrueMaster> yes
[17:29] <ogra_cmpc> then there is nothing that could block it from being executed at least
[17:29] <ogra_cmpc> are you sure you got a new kernel ?
[17:29] <ogra_cmpc> with this update i mean
[17:29] <GrueMaster> I manually ran flash-kernel and it updated the boot partition with the new kernel.  It just didn't run when installing the new kernel.
[17:30] <GrueMaster> Yes.
[17:30] <ogra_cmpc> thats pretty weird since our kernel packages usually run update-initramfs from their postinst
[17:31] <ogra_cmpc> which in turn should run flash-kernel
[17:32] <GrueMaster> the 20100802 image has 2.6.35-13-omap kernel installed.  Updating pulled in 2.6.35-14-omap.
[17:33] <GrueMaster> Flash-kernel should have run, but it didn't.
[17:33] <ogra_cmpc> really the kernel or just meta ?
[17:33] <GrueMaster> kernel.
[17:33] <ogra_cmpc> i didnt actually see a linux upload
[17:33] <GrueMaster> I'm looking at /boot
[17:33] <ogra_cmpc> but there was a meta upload yesterday
[17:34] <ogra_cmpc> thats on a panda ?
[17:34] <GrueMaster> beagle.
[17:34] <ogra_cmpc> ah
[17:34] <GrueMaster> (hence th 2.6.35-14-omap kernel) ;P
[17:34] <ogra_cmpc> if you run update-initramfs, does it run flash-kernel ?
[17:37] <GrueMaster> checking...
[17:38] <GrueMaster> dmesg
[17:38] <GrueMaster> oops
[17:38] <ogra_cmpc> heh
[17:39] <GrueMaster> I didn't see that it ran.  is there a log I can check?
[17:40] <ogra_cmpc> i dont think so
[17:40] <ogra_cmpc> it should tell you it runs, its actually still very noisy
[17:40] <GrueMaster> Nevermind.  timestamp on mmcblk0p1/uInitrd is an hour old.
[17:40] <GrueMaster> So no, it isn't running.
[17:41] <ogra_cmpc> hmm
[17:42] <ogra_cmpc> if you run: sudo flash-kernel --supported; echo $?
[17:42] <GrueMaster> Grrrr.  terminal reset.
[17:42] <ogra_cmpc> whats the return value ?
[17:42] <GrueMaster> running flash-kernel manually works fine.  I already tested that to make sure (and rebooted to verify new kernel loads).
[17:43] <GrueMaster> The return value is 0 (which I assume is good).
[17:43] <ogra_cmpc> yep
[17:43] <ogra_cmpc> means your HW is supported
[17:44] <ogra_cmpc> 		if flash-kernel --supported >/dev/null 2>&1; then
[17:44] <ogra_cmpc> 			flash-kernel
[17:44] <ogra_cmpc> ...
[17:44] <ogra_cmpc> thats what update-initramfs executes
[17:45] <ogra_cmpc> urgh
[17:45] <ogra_cmpc> i think i see the issue
[17:49] <GrueMaster> It doesn't even run that test.
[17:51] <ogra_cmpc> no, because there is still old code lool added once to check for the postinst_script value in kernel-img.conf
[17:51] <ogra_cmpc> i thought i had dropped that when i merged the new flash-kernel
[17:51] <GrueMaster> oops
[17:52] <ogra_cmpc> comitted and pushed
[17:52] <ogra_cmpc> i dont think its critical to upload it now though, we'll get just in the way of other arches ...
[17:54] <GrueMaster> ok.
[17:54] <GrueMaster> As long as it makes beta
[17:54] <ogra_cmpc> as a quick fiox you can just edit update-initramfs
[17:54] <GrueMaster> Planned on it.
[17:54] <ogra_cmpc> jumpo to flash-kernel and remove the outer if statement
[17:55] <ogra_cmpc> the one that checks for kernel-imf.conf contents
[17:58] <GrueMaster> yep, that fixed it.
[17:58] <ogra_cmpc> great
[17:59] <GrueMaster> Should I post a bug against initramfs-tools to track this?
[17:59] <ogra_cmpc> nah
[17:59] <ogra_cmpc> the fix is already in the tree
[18:00] <GrueMaster> It's in the debian git tree.  Will we pull an update prior to Beta?
[18:00] <ogra_cmpc> next image will have an up to date kernel and before the next kernel comes we'll have the update in
[18:00] <GrueMaster> ok
[18:00] <ogra_cmpc> its in the ubuntu bzr branch
[18:00] <GrueMaster> Oh.  Didn't find that.  Only found the debian git tree.
[18:01] <GrueMaster> Didn't look too hard either.
[18:07] <lag> rcn-ee: And now?
[18:14] <ogra_cmpc> GrueMaster, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/initramfs-tools/maverick/revision/210 btw
[18:15] <GrueMaster> Yea, got it.
[18:49] <GrueMaster> ogra_cmpc: Are we supposed to be generating netboot images for dove & imx?
[19:46] <ogra_cmpc> GrueMaster, no, but i wont switch them off unless they cause failures
[19:46] <GrueMaster> Just emails from iso.tracker.
[19:47] <ogra_cmpc> they are built automatically if debian-installer is built
[19:47] <ogra_cmpc> oh, they should be removed
[20:35] <dcordes> hi my friends
[20:38] <rcn-ee_> lag, same mmc bug as your guys xm boards: http://pastebin.com/R0tTmXjE
[20:39] <rcn-ee_> however this sandisk card works fine with my 2.6.35 kernel, so it's got to be a patch/config difference...
[20:40] <dcordes> rcn-ee, did you get the mmc from GrueMaster  ??
[20:41] <rcn-ee_> nope, off amazon. ;)
[20:42] <rcn-ee_> back in april when i realized i should stock up before everyone found out the xm's used micro sd cards. .;)
[20:42] <GrueMaster> What is it?  (class/size)
[20:42] <rcn-ee_> Sandisk 4GB SDHC
[20:43] <GrueMaster> Should work, although you have oops that I haven't seen yet.
[20:44] <rcn-ee_> Yeah, this XM rev P7 (256Mb) isn't 100% anyways.. ;)
[20:44] <rsalveti> rcn-ee: what filesystem are you using by default?
[20:45] <rcn-ee_> oh this was lag's image he wanted me to test this morning.. just a dd of http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
[20:45] <rcn-ee_> normally i rootstock my own over ext4
[20:46] <rcn-ee_> for some reason my kernel 2.6.35-dl12 works fine with these sd cards, but ubuntu's kernel can't load the mmc.. since most of the xm patches are similar we are left with the config...
[20:46] <GrueMaster> There is an updated kernel, but I am not sure how you would install it w/o booting.
[20:46] <rcn-ee_> that's what the bx is for.. ;) give me 5mins..
[20:47] <rsalveti> with a rootstock rootfs you can generate it, with qemu user emulation
[20:47] <rsavoye> rcn-ee: I had to drop using your patched kernel :-(
[20:47] <rsalveti> or just mount the dist, copy qemu-arm-static there and install it with qemu user emulation
[20:47] <rsalveti> *disc
[20:47] <rcn-ee_> yeap.. i read that...
[20:48] <rsavoye> 500Mhz sucks,,,
[20:49] <rcn-ee_> blah.. i've built kernels on a Bx at 400Mhz.. (debian etch 'arm')..
[20:49] <rsavoye> I'm doing a build now, almost to the part that kept causing trouble, so I";ll let you know how it goes
[20:49] <rsavoye> beats my 200Mhz Sharp Zarus...
[20:50] <dcordes> rsalveti, may I ask which zaurus you have ?
[20:51] <rsalveti> rsavoye: ^
[20:51] <rsavoye> me, I've got several, the 3200 clamshell being my favorite
[20:51] <rcn-ee_> crap there goes the upgrading idea, my Bx's musb port isn't coming alive... ;)
[20:51] <dcordes> rsalveti, :)
[20:51] <dcordes> rsavoye, :)
[20:52] <dcordes> rsavoye, the akita is a lovely device
[20:53] <rsavoye> I wound up doing a project a bunch of years ago for NASA, and we used 6000Ls, cause I could install ipsec
[20:54] <rsavoye> I was pumping air traffic data over the network to it for monitor alerts
[21:06] <slangasek> dyfet: are you at DebConf?  They have you on the schedule giving a talk?
[21:18] <dcordes> rsalveti, nice. I love the nasa
[21:20] <dcordes> rsalveti, 6000 are the potrait orientation ones right ?
[21:20] <dcordes> oops
[21:20] <dcordes> rsalveti, sorry that was for the other guy also starting with rs
[21:20] <rsalveti> :-)
[21:53] <rsalveti> mythripk: now I'm finally able to test the patches, but didn't work that well :-(
[21:53] <rsalveti> now I'm able to get something on the screen but the image is really big and distorted
[21:53] <rsalveti> probably still missing some patches from robclark
[21:55] <rsalveti> and I don't have a console because of the oem-config, needs to generate a minimal image
[21:57] <rsalveti> another weird thing is that I need to recreate the first partition every time I need to update uImage or uInitrd
[21:57] <rsalveti> otherwise u-boot doesn't like it
[21:57] <rsalveti> GrueMaster: did you ever make any kernel update with panda?
[21:57] <prpplague> rsalveti: how are you partitioning and mounting the sd card?
[21:58] <rsalveti> this is the pre-installed image generated by ogra
[21:58] <rcn-ee_> that's a little weird..
[21:58] <rcn-ee_> standard fat16/32 partition?
[21:58] <rsalveti> prpplague: mounting without any extra options at my desktop
[21:58] <rsalveti> yep
[21:58] <rsalveti> fat 32
[21:58] <GrueMaster> rsalveti: not yet, but I found a bug in the initramfs-tools.  It won't run flash-kernel unless it is in /etc/kernel-img.conf Fix committed).
[21:58] <rsalveti> if I just copy the new uInitrd or uImage file on top of the older one I'm not able to boot
[21:58] <prpplague> rsalveti: interesting
[21:58] <rsalveti> u-boot will complain about it
[21:59] <rsalveti> ** Unable to read "uImage" from mmc 0:1 **
[21:59] <rsalveti> mmc read: Invalid size
[21:59] <rcn-ee_> after updating..  then rebooting.. is "fatls mmc 0:1" still show a clean fat?
[21:59] <rsalveti> ## Booting image at 80000000 ...
[21:59] <rsalveti> Bad Magic Number
[21:59] <rsalveti> if I create the vfat fs again and copy the files, everything works
[21:59] <GrueMaster> I'll try here.  I thing I pulled an updated kernel during the massive updates I've done today.
[21:59] <prpplague> rsalveti: i normally only see that problem when the FAT index tables are corrupted or it contains data that can't be parsed by u-boot
[22:00] <rsalveti> rcn-ee_: didn't try this yet
[22:00] <rsalveti> prpplague: the weird thing is that once I created it again and try for the second time, I get the same error
[22:00] <rsalveti> so it's not a problem on how ogra is creating it
[22:01] <rcn-ee_> rsalveti, it just seems very weird, i've been doing stuff like: http://pastebin.com/ccM2tDH5 for a good 2 years on my beagle..
[22:01] <prpplague> rsalveti: yea, i suspect that is some bug, i'll see if i can recreate the issue here and have a look
[22:01] <rsalveti> argh, my screen size is totally wrong
[22:02] <rsalveti> rcn-ee_: yep, but I'm doing this on panda, with beagle it works fine
[22:02] <rsalveti> GrueMaster: try updating and running flash-kernel to see how it goes
[22:02] <rcn-ee_> ah sorry...  wrong board.. i still haven't got my panda's usb port to work yet for any upgrade.. ;)
[22:03] <rsalveti> if flash-kernel is not called by default
[22:04] <rsalveti> prpplague: could be something wrong with our u-boot version too
[22:08]  * rsalveti still needs to get the u-boot hash we're using for omap4
[22:12] <prpplague> rsalveti: i suspect there is a minor fat bug in the u-boot we are using
[22:12] <prpplague> rsalveti: it is rather old
[22:13] <rsalveti> prpplague: oh, ok, do you know if we already have the fix somewhere?
[22:13] <prpplague> rsalveti: i've only seen the problem occur a couple of times, and i just assumed i had damaged the partition with my testing
[22:14] <prpplague> rsalveti: so, no, i doubt there is a fix
[22:14] <prpplague> rsalveti: i'll put it on my bug list to see if i can get to the bottom of it
[22:15] <rsalveti> prpplague: do you know where can I find the "upstream" development of the uboot for panda?
[22:16]  * rsalveti is just new regarding panda work
[22:16] <rsalveti> GrueMaster: you may also know it
[22:17] <GrueMaster> Not sure, but it is part of the image, so the packaging tools should know.
[22:20] <rsalveti> GrueMaster: L24.7git20100624
[22:22] <prpplague> rsalveti: sakoman is doing some contracting for TI to upstream all the new support to u-boot
[22:22] <rsalveti> http://git.omapzoom.org/?p=repo/u-boot.git;a=summary
[22:22] <prpplague> rsalveti: negative
[22:23] <prpplague> rsalveti: he has a repo somewhere
[22:23] <rsalveti> prpplague: this link I guess is the one used for our package
[22:23] <prpplague> rsalveti: basically yea
[22:23] <prpplague> rsalveti: one sec, getting you some urls
[22:23] <rsalveti> but I guess I have sakoman's repo too
[22:24] <robclark> rsalveti: you need the patches related to framebuffer supporting resizing
[22:24] <robclark> and you need to plugin monitor before xserver starts..
[22:24] <robclark> (because no KMS yet)
[22:24] <rsalveti> robclark: the patches I got from mythripk made my hdmi work, but with a very wrong size
[22:24] <robclark> 640x480?
[22:24] <rsalveti> robclark: but I'm not even using X11 :-)
[22:25] <robclark> is it a DVI monitor?
[22:25] <rsalveti> robclark: probably something like that
[22:25] <rsalveti> has dvi and hdmi
[22:25] <rsalveti> but I'm using just the hdmi
[22:25] <robclark> so there were a few patches that I think might be interesting to you...  hang on
[22:25] <rsalveti> robclark: the fonts are huge and distorted (from console)
[22:26] <robclark> is the picture scrambled, or just distorted?
[22:26] <prpplague> rsalveti: my core development has been to get the hardware verification done, now that it _is_ done, i'll be looking at getting all the code consoladated
[22:27] <robclark> rsalveti: from here: http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commits/L24.7_panda-hdmi-patches  I think you might want
[22:27] <robclark> "add callback to notify client of resolution change"
[22:27] <prpplague> rsalveti: do you care to get his ppt with slides describing the status, or just the url?
[22:27] <robclark> "register callback to get notified of resolution change"
[22:27] <rsalveti> prpplague: could be the whole thing, np
[22:27] <robclark> that should at least give you an ok picture..
[22:28] <robclark> and then for some monitors that are falling back to 640x480, when a higher resolution would be possible, "better support for DVI monitors"..  although I think that will mainly matter when you plug in over DVI..  it is basically adding support for parsing parts of EDID that HDMI screens don't seem to use
[22:29] <prpplague> rsalveti: you've got spam
[22:30] <rsalveti> prpplague: nice, so the idea is to get most of this support directly on u-boot upstream
[22:30] <rsalveti> prpplague: nice, thanks
[22:31] <rsalveti> robclark: http://www.flickr.com/photos/rsalveti/4857717987/
[22:32] <GrueMaster> rsalveti: Ok, I am finally finished with the updating.  flash-kernel updates the boot partition, but somehow it is getting clobbered.  I think it may be a file order thing.  Will do some more testing.
[22:32] <rsalveti> GrueMaster: ok
[22:32] <prpplague> rsalveti: that's a "feature" for people who have visual handicaps
[22:33] <robclark> rsalveti: I suspect you need the patches related to resizing
[22:33] <rsalveti> for sure :-)
[22:34] <robclark> rsalveti: what you might want to do before spending much time, is just pull my branch and build it.. or send me an email addr and I can send you my uImage..
[22:34] <rsalveti> robclark: will try some of your patches
[22:34] <robclark> just to try and see if that solves
[22:34] <rsalveti> robclark: yep, that's why I'm doing now
[22:34] <rsalveti> *what
[22:34] <robclark> then you can try and merge on top of ubuntu kernel
[22:34] <robclark> ok, cool
[22:35] <robclark> if that still doesn't work, email me the contents or /sys/devices/omapdss/display0/edid
[22:35] <GrueMaster> Interesting.  The fat partition has a date stamp of 1969-12-31 16:00
[22:35] <rsalveti> GrueMaster: ops
[22:35] <GrueMaster> The files are ok and have the correct timestamp.
[22:36] <rsalveti> GrueMaster: when I tested the md5 was ok, but u-boot didn't like it
[22:36] <rsalveti> had to recreate the fs
[22:37] <GrueMaster> Don't tell me we found another mkfs glitch.
[22:39] <rsalveti> u-boot just didn't like it, probably
[22:40] <GrueMaster> What I am seeing is that when I mount the filesystem on my x86, the date of the mount directory becomes 12-31-1969.  That is a glitch somewhere in the filesystem, and I am willing to bet it is during fs creation.
[22:40] <GrueMaster> mount
[22:40] <GrueMaster> gah.
[22:42] <GrueMaster> Nevermind.  I have a new SD that still has the factory format.  same issue there.
[22:43] <rsalveti> yep, the bug happens every time with me
[22:43] <GrueMaster> back to my earlier theory.  It is a location issue on the drive.  testing now.
[22:52] <GrueMaster> rsalveti: I'm thinking it is an issue with the uboot fat code.  I don't think it can read beyond a certain point or something, as flash-kernel renames the existing files and creates new files.  That or uboot can't handle file fragmentation.
[22:53] <rsalveti> GrueMaster: it's also happening when I just copy a new file on top of an older one
[22:53] <rsalveti> but yes, probably on u-boot
[22:53] <rsalveti> still needs more debugging
[22:54] <GrueMaster> Copying a new file over an old one without syncing could be a separate issue.
[22:54] <rsalveti> GrueMaster: so currently if we get a new kernel on a pandaboard the panda is not going to boot anymore :-)
[22:55] <GrueMaster> Yep.  That's what my test currently shows.
[22:56] <GrueMaster> I have another part of the test to run.  Give me a few.
[22:56] <rsalveti> GrueMaster: ok
[22:56] <rsalveti> GrueMaster: would you mind to open a bug later on about this issue?
[22:58] <GrueMaster> will do after this reboot.
[22:58] <rsalveti> nice, thanks :-)
[23:08] <GrueMaster> very interesting.  As a test, I renamed the new kernel & initrd as uI*.old and renamed the old kernel & initrd from uI*.bak to uI* (shortened for explanatory reasons).  It still loaded the new kernel.
[23:10] <rsalveti> interesting
[23:10] <GrueMaster> I'm not even sure what that suggests.  iirc, the fat system should just change the entry in the directory table, not the order or the fat table starting point.
[23:11] <GrueMaster> Ok, filing a bug, then doing more research.
[23:27] <GrueMaster> rsalveti: Bug #613230
[23:27] <ubot2> Launchpad bug 613230 in u-boot-omap4 (Ubuntu) "u-boot fails to load new kernel fromm boot partition after kernel update (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/613230
[23:30] <rsalveti> GrueMaster: interesting, after renaming the old files it's still trying to load the newer ones
[23:30] <GrueMaster> yep
[23:39] <GrueMaster> something is trashing the fat directory tree in uboot.  Try running "mmcinit 0;fatls mmc 0".
[23:39] <GrueMaster> ugly
[23:40] <rsalveti> probably u-boot itself is trashing the fat directory tree