[01:43] <Baybal> like arm v7 cortex a5 is faster arm 1136
[01:44] <rcn-ee> an a5? it would need a lot of clockspeed...
[01:51] <ojn> I haven't seen any performance comparisons. Has anyone announced A5-based SoCs yet?
[01:53] <rcn-ee> one of the marvell ARMADA cores is.. and ti has one.. Haven't seen any numbers, but it should be slower then a8/a9..
[01:53] <ojn> rcn-ee: really? I thought marvell designed their own cores. And which TI part has an A5? I've completely missed that announcement
[01:56] <ojn> Seems like A5 has better DMIPS/MHz than 1136, but that doesn't mean that real-world performance is better.
[01:57] <rcn-ee> well yeah Marvell does that in the end... but they say it's a5 compatable...
[01:58] <ojn> A5 compatible means A8 compatible. I don't see the point in that statement.
[01:58] <ojn> bzzt.
[02:02] <rcn-ee> well, A5 is an 8 stage vs A8's 13 stage pipeline, but since Marvel designs it anyways, who knows what the difference is.. ;)
[02:05] <rcn-ee> yeah sorry about that ti doesn't have a a5, i was getting their new Sitara 500Mha A8..
[02:05] <rcn-ee> confused..
[02:09] <ojn> rcn-ee: Yeah, you seem to be very confused. :)
[02:10] <rcn-ee> and i think i'm going nutz, right now i'm 1/2 defconfig changes between a beagle and igep2 both working with ubuntu 500.2 kernel..
[02:11] <rcn-ee> (dss2 omapfb stuff)
[02:30] <cooloney> plars: hi, paul, did you test the daily build of UNE for fsl-imx51
[02:30] <cooloney> plars: i can not enter X, just got a black screen, even beta1 release
[02:30] <cooloney> plars: mine is bb2.5
[02:31] <persia`> cooloney: Any interesting output on console?
[02:36] <cooloney> persia: i can switch to console vt1
[02:36] <cooloney> persia: and login with reentering a new password
[02:37] <cooloney> persia: although i just need my console works firstly
[02:37] <persia> What is the output of `date -u` ?
[02:47] <plars> cooloney: yes, I tried it, worked fine for me
[02:47] <plars> cooloney: I am on babbage 3 though, haven't tried on 2.5
[02:51] <cooloney> plars: so weird
[02:52] <cooloney> plars: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/
[02:52] <cooloney> i installed this one
[02:52] <cooloney> persia: Tue Mar 23 02:51:10 UTC 2010
[02:54] <persia> OK, so that's not the date bug.
[02:54] <persia> Does /var/log/Xorg.log have anything useful?
[03:12] <cooloney> persia: i failed to find that. but live image works fine
[03:12] <cooloney> just after installation, i boot from my hd, no X only black screen
[03:13] <persia> And you can log in at a console.  Hrm.
[03:13] <persia> And there's really no X log?
[03:13] <persia> Does startx work?
[03:20] <cooloney> i tried that, startx said X Server is running
[03:20] <cooloney> persia: let me check the whole X log
[03:20] <cooloney> i think X is running, but there is nothing on the screen, only a black one
[03:22] <persia> Try launching an xterm from the console :)
[03:23] <persia> `DISPLAY=:0.0 xterm &`
[03:29] <cooloney> persia: xterm Xt error: Can't open display: 0.0
[03:30] <persia> Try with sudo, just in case.
[03:30] <persia> If that also doesn't work, try restarting gdm.
[03:30] <persia> If that also doesn't work, the issue should really be in /var/log/Xorg.log
[03:31] <persia> If you don't have that file, X didn't really start (although something may be wedged)
[03:38] <cooloney> persia: i got the Xorg.log, but did not find any error
[03:38] <persia> pastebin it?
[03:40] <cooloney> persia: no problem,
[03:46] <cooloney> persia: here it is http://pastebin.ubuntu.com/399667/
[03:50] <persia> cooloney: And restarting gdm does nothing for you?
[03:51] <persia> plars: Does that look like your output?
[03:54] <cooloney> persia: yeah, nothing for me
[03:55] <persia> I'm stuck.  Sorry.
[03:56] <cooloney> persia: thanks anyway, I was stuck by the black screen since yesterday
[03:56] <cooloney> no idea what happened to my board
[03:56] <cooloney> persia: do you have bb2.5?
[03:57] <persia> I don't have anything that can boot in direct comparison to what you have.
[03:57] <cooloney> persia: i am apt-get upgrading, see if it will help somehow
[04:11] <Baybal> hello
[04:11] <Baybal> can you do startx
[04:12] <Baybal> what is your display resolution?
[04:18] <cooloney> Baybal: hi, i tried startx
[04:19] <cooloney> but it said x is running
[04:19] <Baybal> what is your display resolution?
[04:19] <cooloney> and my display supports 1920x1080
[04:19] <Baybal> lsmod please
[04:22] <cooloney> http://pastebin.ubuntu.com/399678/
[04:24]  * cooloney need some food. heads out for lunch
[04:26] <Baybal> I suspect that concurrent db driver is running
[04:26] <Baybal> you need to set video:
[06:54] <cooloney> persia: so weird, after i did apt-get dist-upgrade, x works fine now
[06:54] <cooloney> persia: thanks for taking a look
[06:54] <cooloney> plars: thanks
[08:36] <lool> persia: Did you understand the suggestion of infinity in the openbios-sparc bug?  I wonder how he meant we should build automatically with multiple sources -- I don't think it would be automatical and I'm not sure of the benefit of multiple sources
[08:41] <lool> Hmm oo.o FTBFSed on armel
[08:41] <lool> And I can't make any sense of its build log
[09:05] <ogra> lool, i only see it failing on ia64
[09:06] <ogra> oh, the ftbfs page is wrong :(
[09:11] <wgrant> ogra: Wrong, or slightly out of date?
[09:11] <ogra> wgrant, out of date i think, it only failed 1h ago
[09:12] <wgrant> ogra: It should have rerun about 2 hours ago, but LP broke.
[09:12] <ogra> ah, k
[09:13]  * wgrant cranks the frequency up until LP people complain.
[09:13] <ogra> hehe
[09:13] <ogra> ++
[09:15] <ogra> lool, do you know anything about versatile2 ? is it in mainline already ?
[09:16]  * ogra wonders if it wouldnt make more sense to use a real cortex-a* kernel implementation instead of faking one 
[09:18] <lool> ogra: versatile 2?
[09:18] <lool> ogra: You mean versatile express?
[09:19] <ogra> lool, no, 2 ... the arch that Martyn uses
[09:19] <lool> ogra: Well try it out, I researched moving to realview versatile, but it didn't work
[09:19] <ogra> cortex-a9 actually
[09:19] <lool> qemu / upstream mismatch in features
[09:20] <ogra> oh, verstile2 (V2) is actually express
[09:20] <lool> See
[09:20] <lool> and this is part of realview
[09:21] <ogra> ah
[09:21] <ogra> silly marketing departments ... too many names :P
[09:22] <ogra> hmm, realview is only: ARM1136JF-S, ARM1176JZF-S, ARM1156T2F-S and Cortex-R4F
[09:23] <lool> Not really
[09:23] <lool> There are various boards and replaceable tiles
[09:24] <lool> There's a cortex-a9 one
[09:24] <ogra> ok
[09:24] <ogra> just referring to the arm website here
[09:25] <lool> You might be looking at the first realview board, but then they declined it in many variations
[09:25] <ogra> ah
[09:26] <lool> ogra: http://www.arm.com/community/software-enablement/linux.php?tab=Linux+OS+Downloads
[09:26] <ogra> i also wonder where the beagleboard support for qemu went
[09:27] <lool> I think one can build support for all of these in a single kernel, but only with a certain CPU level, so in practice some combinations wont work
[09:27] <ogra> there was a GSoC project one or two years ago (i presented it at the berlin sprint)
[09:27] <lool> hehe you presented it and you lost it?  :-)
[09:27] <ogra> no, it was a hack back then
[09:27] <lool> ogra: Don't present your keys!
[09:27] <ogra> i know where on goodle it loves but i wonder if it ever was finished upstream
[09:27] <ogra> *google
[09:28] <ogra> *lives
[09:28] <lool> goodle love baby
[09:28] <ogra> oh my
[09:28]  * ogra glares at his fingers and wonders if they want to tell him something
[09:38]  * NCommander waves to ogra and lool 
[10:09] <lool> NCommander: Hmm didn't you send pselect6/ppoll support to upstream QEMU?
[10:09] <NCommander> lool: I did; it got committed
[10:12] <lool> NCommander: Odd, I don't see support for pselect6() in linux-user/arm/syscall_nr.h o ntip
[10:14] <NCommander> lool: *blink*
[10:15] <NCommander> lool: http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01067.html
[10:15] <NCommander> lool: not sure what happened, they were supposed to land
[10:17] <lool> NCommander: I think these are staged in suihkulokki's tree
[10:17] <NCommander> lool: I guess suihkulokki's tree didn't land in the mainline git yet. I didn't follow up on the patch inclusion beyond suihkulokki's comment
[10:20] <persia> lool: I did understand infinity's comment.  NCommander tried that approach several months ago in a PPA.  We need to modify Soyuz to make it work.
[10:21] <NCommander> lool: persia: it mostly means touching build-dispatcher and archiveuploader, its fairly straightforward where changes need to be made
[10:21] <lool> persia: I tried it as well and confirmed it's still an issue -- attached upload log to the bug
[10:21] <persia> bigjools suggested we set X-Arch-Indep-Build-Arch in the .dsc, and have Soyuz parse that properly.
[10:22] <persia> Which means adding XS-X-Arch-Indep-Build-Arch to debian/control, I think.
[10:23] <persia> I'm unsure if there would also be benefit to adding it to the .changes file: needs investigation of the potential implentation.
[10:25] <lool> I had the same intuition (adding an XS field)
[10:25] <lool> I wish we'd discuss this on debian-policy@ though
[10:32] <persia> lool: Doesn't affect Debian though: it's a Soyuz-specific issue.
[10:33] <persia> Simply because the first upload in Debian must be source+binaries, the maintainer can force indep build affinity by selecting a build to sign an upload.
[10:33] <lool> persia: Really?  How do you express this constraint in Debian source packages?
[10:33] <persia> One just has to put a note in debian/README.source
[10:33] <lool> I disagree, I think the Debian approach of uploading binaries is wrong as it requires access to specific hardware to upload the package
[10:33] <lool> And it requires a by hand upload
[10:34] <lool> The security team would be pained to upload an update for instance
[10:34] <persia> I happen to agree with you, mostly because of all the arch:all packages that FTBFS.
[10:34] <lool> And currently there's nothing indicating that this *can't* build on !specific-arch
[10:34] <persia> Even after all these years, we're *still* commonly fixing issues with Java packages that can't build.
[10:34] <lool> I actually discovered that the *two* packages fail to build on their respective arches!!
[10:35] <persia> Hrm!
[10:35] <persia> So the packages FTBFS in Debian as well?
[10:36] <lool> I suspect openbios-sparc FTBFSes in Debian and openhackware might FTBFS if SSP is the default
[10:38] <persia> openhackware built for me in Ubuntu about 9 months ago.  I haven't tried since.
[10:38] <persia> I don't have hardware to test-build openbios-sparc.
[10:39] <lool> persia: openhackware required -fno-stack-protector to build for me
[10:39] <lool> I'm surprized you weren't hit by this even 9 months ago
[10:40] <persia> All I did was apt-get source, sbuild.  I didn't examine the logs.
[10:40] <persia> Or maybe it was a different package
[10:40]  * persia looks
[10:41] <persia> I may be misremembering, and I may have tried to build openbios-ppc
[11:01] <lool> NCommander: Did you see oo.o ftbfsed?
[11:01] <NCommander> lool: ugh
[11:01]  * NCommander cries
[11:02] <NCommander> lool: I think the buildd went weee *splat*
[11:02] <NCommander> lool: probably worth smashing retry
[11:06] <NCommander> lool: unless you have a better idea, I'm going to hit retry and see if it happens again
[11:07] <lool> NCommander: Hmm ok
[11:07] <lool> The build log didn't make sense to me, but then I'm not an oo.o dev really
[11:09] <NCommander> lool: it seems to me the buildd just went plunk. They sometimes blow up on OOo due the sheer size
[13:06] <lool> suihkulokki: Is there some ML where you folks coordinate qemu-maemo stuff?
[13:52] <lool> amitk: Is there a beagleboard vmlinuz from linux-ti-omap somewhere out there?
[13:57] <ogra> lool, http://people.canonical.com/~amitk/ti/ (the versioning is wrong afaik, its 500.2)
[13:59] <lool> thanks
[14:00] <amitk> lool: use this one to be sure: http://people.canonical.com/~apw/ti-omap-lucid/
[14:00] <ogra> lool, oh, wait http://people.canonical.com/~apw/ti-omap-lucid/
[14:00] <ogra> is the right one
[14:00] <ogra> bah, snap
[14:00] <ogra> lool, i can give you an initramfs too if you want one (or uImage/uInitrd)
[14:01] <ogra> and a boot.scr
[14:04] <dmart> asac, I do get the firefox problem over ssh to a non-Babbage board
[14:04]  * dmart waiting for babbage to reboot
[14:04] <asac> dmart: i see it here on bbg through ss
[14:04] <asac> h
[14:04] <asac> and dove i am checkin gnow
[14:04] <asac> its just that ubuntu.com doesnt show the problem
[14:05] <dmart> I'm wondering whether it's some weird rounding issue where firefox rounds the size of images down and then adds scroll bars to compensate
[14:05] <dmart> Google maps is the best example I've found so far...
[14:06] <asac> feels like
[14:06] <asac> dmart: did you see the chromium bug on dove? it feels like a rounding issue too ;)
[14:06] <dmart> I don't have dove to look at :(
[14:06] <asac> but lets focus on this one
[14:06] <asac> dmart: join #developers on irc.mozilla.org
[14:11] <NCommander> dmart: I get the FF problem on Dove
[14:13] <lool> amitk: Did you already use beagle kernels directly in qemu?
[14:14] <amitk> lool: nope
[14:17] <asac> dmart: so lets wait a bit there and ping again in a couple of hours
[14:18] <asac> vlad is the guy that usually knows about arm
[14:19] <ogra> lool, http://code.google.com/p/qemu-omap3/
[14:20] <ogra> that was the one i had in berlin
[14:23] <lool> ogra: Yeah, is there a way to run it like we run the versatile stuff?
[14:23] <lool> Or does one has to create the nand flash stuff in all cases?
[14:23] <ogra> it only runs from NAND
[14:23] <ogra> no disk or MMC support :/
[14:23] <lool> Also, what's the canonical upstream for the bb_nandflash.sh and bb_nandflash_ecc.c stuff?
[14:23] <ogra> no idea
[14:23] <ogra> it wasnt ready back then, so i didnt follow it deeply
[14:24] <ogra> (and we had no omap support)
[14:42] <dmart> lool: re your bug post that OOo ftbfs again on armel, it looks like https://launchpad.net/ubuntu/+source/openoffice.org/1:3.2.0-4ubuntu1 is still building for armel.  Is this a retry or a different version?
[14:43] <ogra> dmart, retry
[14:43] <dmart> Is the log from the failed build around somewhere?  What went wrong?
[14:45] <lool> dmart: It's a retry
[14:45] <lool> dmart: Apparently some obscure error like the shell failing; it seems this happens regularly on babbage 3
[14:45] <dmart> I see a bash SEGV in the eglibc ftbfs
[14:45] <dmart> I'm doing a build to see if I can reproduce that
[14:46] <ogra> lool, s/babbage 3/pegatron/
[14:47] <ogra> babbage3 is stable
[14:51] <dmart> oh, args
[14:52] <dmart>  /argh
[14:52] <dmart> I'll leave that build running anyway... you never know.
[15:00] <asac> dmart: will be a few minutes late to call :( ... sorry, lost my time
[15:01] <dmart> The call is in 1 hour?
[15:01] <lool> .c
[15:01] <ogra> .sh
[15:06] <asac> dmart: according to my calendar now
[15:06] <asac> but noone is there
[15:07] <asac> dmart: ?
[15:07] <asac> dmart: ping us if the cfall i snow
[15:08] <asac> otherwise talk to you in 50
[15:33] <asac> dmart: http://launchpadlibrarian.net/39762270/klibc-thumb.patch ... is that armv5 compatible?
[15:33] <asac> also armv4t?
[15:38] <suihkulokki> lool: I guess the normal qemu-devel would do
[15:38] <dmart> asac: Is all the affected code inside #ifdef __thumb__ or similar?  We might want to avoid bx when building in ARM for older architectures (to avoid making builds fail for other people)
[15:39] <asac> dmart: armv4t and above should do bx, right?
[15:39] <dmart> Yes
[15:39] <asac> its not guarded by anything
[15:39] <dmart> Otherwise, your changes look sensible
[15:39] <asac> we just wonder if we should really care for older stuf
[15:39] <asac> i thought we said we dont care for anything before armv4t
[15:40] <dmart> If it's inside #ifdef __thumb__ you're OK, but otherwise you might want checks similar to what we've already done in other packages.
[15:40] <asac> dmart: bx is only __thumb__ ?
[15:40] <asac> or do we need to match: armv4t armv5 armv6 armv7 ?
[15:41] <ogra> why would you ?
[15:41] <ogra> we only build v7
[15:41] <asac> upstream
[15:41] <asac> i wouldnt ask all this if it was about us
[15:41] <ogra> well, upstream wants to be run in debian too i guess
[15:41] <lool> suihkulokki: Ok; got my email?
[15:41] <dmart> For: #ifdef __thumb__  ... bx ... #else ... bx ... #endif
[15:42] <dmart> The second bx might need some protection if we want to be compatible with pre-armv4t processors.  But as asac says, maybe we don't care about that.
[15:42] <asac> i will try to get that upstreamed without any protection
[15:42] <asac> unless you shout
[15:42] <asac> if they say they want to support older stuff we can clean it up
[15:43] <dmart> ok ... either is should not cause a problem or it will ftbfs for someone (which is relatively easy to fix)
[15:43] <dmart> "no problem" is the more likely
[15:44] <dmart> asac: Just before you post, can you check where the value we bx to comes from?  It is just the return address passed to the function?  If it's computed or something, we might have to worry about interworking.
[15:51] <asac> dmart: i think we checked that when we made the patch
[15:52] <dmart> OK, I don't recall the details now.  Sounds plausible.
[15:53] <asac> dmart: oh klibc is build with -mno-thumb-interwork   -Os -march=armv4 -mtune=strongarm
[15:53] <asac> so atm it complains about target cpu not supporting thumb instructions ;)
[15:53] <dmart> When is klibc used?
[15:53] <dmart> Interworking is mandatory for EABI iirc
[15:58] <dmart> ... so it may be wrong to use these build options if klibc is supposed to interoperate with "normal" binaries
[16:34] <asac> dmart: its used by initramfs
[16:37] <asac> -mabi=aapcs-linux
[16:37] <asac> -mabi=apcs-gnu
[16:37] <asac> dmart: ... any clue what those mean?
[16:37] <asac> either of that i used on arm for klibc
[16:49] <prpplague> davidm: you still in the DFW area?
[16:54] <lool> Does someone have a mtdblock .bin file for beagle which does something useful I could test qemu with?
[17:07] <dmart> asac: -mapi=apcs-gnu is the legacy ABI (as used by the Debian "arm" port).  Not sure about -mabi=aapcs-linux
[17:07] <dmart> Do you know what klibc is used for?
[17:07] <asac> dmart: just in initramfs where there is no libc available
[17:07] <asac> for more details we need to check with cjwaston on -devel
[17:07] <dmart> What gets built against it?  If they mess with the ABI then everything would need to be built with the same options...
[17:08] <asac> we can figure that
[17:08] <suihkulokki> lool: pushed fixed version to gitorious
[17:08] <asac> dmart: for main checkout http://archive.ubuntu.com/ubuntu/dists/lucid/main/source/Sources.gz and search for klibc-dev
[17:08] <dmart> What's not clear to me is why a weird ABI is used for this at all... maybe it is just for historical reasons.  If so we should consider bring it up to the lucid defaults.
[17:09] <dmart> asac: I'll take a look
[17:09] <asac> dmart: so dmraid
[17:09] <asac> and rootskel
[17:09] <asac> for universe in http://archive.ubuntu.com/ubuntu/dists/lucid/universe/source/Sources.gz
[17:09] <ogra> klibc is only shipped in initramfs, its not used
[17:09] <ogra> we ship glibc as well
[17:10] <asac> ogra: why do we ship it then?
[17:10] <ogra> asac, no idea
[17:10] <asac> dmart: cowdancer
[17:10] <lool> suihkulokki: thanks
[17:10] <ogra> cjwatson might know
[17:10] <asac> is the one in universe using it
[17:10] <asac> ogra: the packages from above build depend on it
[17:10] <asac> so i guess they also use it?
[17:10] <lool> suihkulokki: are you rebasing this regularly?
[17:10] <lool> I guess you are, that's fine, just would like to know
[17:10] <ogra> lool, do you have an idea ?
[17:11] <ogra> (why we ship klibc in initramfs even though everything is linked against glibc)
[17:11] <asac> ogra: what about dmraid, rootskel and cowdancer?
[17:11] <suihkulokki> lets see how much time Ḯ'll have
[17:11] <asac> why do those build depend on it?
[17:12] <ogra> asac, hmm, these might probably use it (though its pontless, they could as well use glibc since thats already there anyway)
[17:12] <lool> suihkulokki: I mean rebasing versus merging
[17:13] <suihkulokki> that branch should be rebased rather than merged
[17:13] <lool> ok
[17:14] <dmart> Is a special build of glibc used for the initramfs?
[17:14] <asac> ogra: ?
[17:14] <ogra> asac, there is no reason for them to build-dep on klibc in ubuntu
[17:15] <ogra> it might be something we inherit from debian
[17:15] <ogra> not sure
[17:15] <ogra> but effectively klibc is pointless in our setup
[17:15] <dmart> The problem I see is that building klibc with the build options currently used makes no sense because then any binary needs to be specially built for use in the initramfs --- due to the incompatibility with the lucid compiler defaults.
[17:15] <ogra> right
[17:16] <ogra> and we have glibc anyway in the initramfs in ubuntu
[17:16] <asac> ok
[17:16] <asac> dmart: so we should try to just build without any special options?
[17:16] <asac> let me do that ;)
[17:16] <dmart> Might be worth trying.  Should we ping cjwatson for more understanding of why klibc is in there?
[17:17] <ogra> probably
[17:17] <ogra> though he might also only have second hand knowledge ... initially all the initramfs infrastructure was designed by jeff bailey who isnt ubuntu dev anymore
[17:22] <asac> dmart: so seems we need to fix it or leave it ;)
[17:23] <asac> dmart: http://paste.ubuntu.com/400080/
[17:23] <asac> what should i drop on top ;)?
[17:31] <lool> PPAs are so backlogged
[17:32] <lool> suihkulokki: New branch looks all good; thanks!
[17:32] <asac> lool: please call cr3 at home
[17:32] <lool> asac: Eh
[17:32] <asac> its probably a script failure again, that dont reinject the 10 more oppa builders we have
[17:32] <asac> we had that in the past ... thought it was fixed, but it seems not
[17:32] <lool> asac: My builds are showing 6 hours delays
[17:33] <lool> asac: is that normal?
[17:35] <asac> lool: native or virtual ppa?
[17:35] <asac> lool: its normal that if QA pulls out their builders and forgets to put them back that the queue grows infinitely
[17:35] <asac> and you can even have 24h or more backlog
[17:35] <asac> its QA treating us bad ... i always thought there was sense in this, but after discussing i found that the builders should never be away longer than 2h ;)
[17:36] <asac> so everytime we have 5 instead of 15 for longer than a few hours, QA forgot about us ;)
[17:36] <lool> asac: virtual
[17:36] <asac> yeah. thats QA forgetting to put back the builders (or really doing long running test which is unlikely)
[17:36] <asac> oh ... but now we have 9 again
[17:36] <asac> so i think they are back (maybe not all)
[17:37] <asac> the queue should recover in a day or so
[17:38] <lool> a day, ugh
[17:42] <asac> yeah. there are 600 builds waiting ;) ... what do you expect?
[17:42] <asac> you can bribe a buildd admin and get your build score bumped
[17:42] <asac> but we all have to suffer ;)
[17:44] <ogra> lool, just send IS your beagles ;)
[17:45] <lool> I only have one, and one I actually *cought*!
[17:45] <lool> her *bought*
[17:45] <lool> *Er
[17:45] <lool> I'm tired
[17:45] <ogra> heh
[17:45] <lool> asac: It's ok, I'll sit on it
[17:45] <lool> I pushed a qemu-maemo upload and am eager to share it, it's good stuff
[17:45] <lool> But it doesn't help the glib test failure
[17:46] <lool> ogra: I'd try it with your installation issue
[17:46]  * ogra would love if it would help the rootstock hang
[17:46] <lool> ogra: did you try with cache=writeback?
[17:46] <ogra> not yet
[17:46] <ogra> omap kept me busy
[17:46] <asac> lool: qemu-maemo? what platforms get adde there?
[17:46] <ogra> i havent touched rootstock since last wed
[17:46] <ogra> asac, omap
[17:46] <suihkulokki> lool did you try it with ubuntu ?
[17:46] <asac> cool
[17:47] <lool> suihkulokki: What do you mean with ubuntu?
[17:48] <lool> suihkulokki: it boots our versatile kernels just fine
[17:48] <lool> and our userspace
[17:48] <dmart> asac: re klibc, we might need to look at it more carefully... they are quite specific about ABI options etc., so I'm wondering whether there may be more assembler which makes assumptions which may break if we change things.
[17:48] <suihkulokki> lool: i understood you now have a omap3 kernel?
[17:48] <lool> so I tried both under ubuntu and running ubuntu
[17:48] <lool> suihkulokki: No that's what I wanted to do
[17:48] <ogra> suihkulokki, you wish ... its stuck in NEW
[17:48] <dmart> asac: we should probably discuss klibc further tomorrow
[17:48] <lool> suihkulokki: But I don't know how to try it
[17:49] <lool> suihkulokki: I grabbed the sample files from the qemu-omap3 project and their scripts to create a mtdblock.bin, but I'd rather point qemu-maemo straight to xloader, or uboot or kernel + rootfs, and I don't know how to do this
[17:49] <lool> I think I should look at the available -boot options
[17:49] <suihkulokki> lool: if you have a bootable beagleboard sd, just -m beagle and -sd /dev/sdcard
[17:50] <lool> suihkulokki: that didn't work for me
[17:50] <lool> let me try again
[17:50] <suihkulokki> or a file image of the sd
[17:50] <lool> suihkulokki: qemu-maemo-system-arm -M beagle -sd lucid.img
[17:50] <lool> qemu: hardware error: no boot device found
[17:50] <lool> Hmm what I'm trying can't work
[17:51] <lool> suihkulokki: What does it expect on the SD?  vfat + MLC / u-boot.bin?
[17:51] <suihkulokki> and lucid.img includes the uboot part?
[17:51] <lool> No
[17:51] <lool> I need to build something suitable, but I don't know what it is
[17:53] <lool> suihkulokki: What I just tried is a 100M vfat with the u-boot.bin + MLC (x-loader.ift) + uImage from the qemu-omap page
[17:53] <lool> suihkulokki: But same error
[17:54] <lool> The only thing which progressed a bit was -mtdblock somenand.bin which I created using the qemu-omap3 tools
[17:54] <ogra> did you try using -hda instead ?
[17:55] <lool>     if (!dmtd && !dsd) {
[17:55] <lool>         hw_error("%s: SD or NAND image required", __FUNCTION__);
[17:55] <lool> Weird, I don't even get that message
[17:57] <lool> err so I should call it MLO, not MLC
[17:57] <lool> Gah, forgot to create an actual partition table
[17:57] <ogra> MLO needs to be copied first into the vfat !
[17:57] <ogra> it needs to sit at the first blocks
[18:02] <lool> Ok so now I have a real image with a single vfat partition with a MLO and it still fails
[18:02] <ogra> lool, might be that the size matters
[18:02]  * ogra digs up the reciepe he used to get his beagles up
[18:03]  * prpplague reads the scroll back
[18:03] <ogra> lool, http://paste.ubuntu.com/397188/
[18:03] <ogra> that definately boots on all my beagles here
[18:05] <prpplague> you also need to make sure that your xloader/mlo file has been signed with gpsign
[18:05] <prpplague> basicaly just adds a header with the size and location to load the file
[18:05] <ogra> prpplague, the one from the ubuntu package is definately signed
[18:06] <prpplague> ogra: ahh part of the build?
[18:06]  * lool just took an image of his SD card
[18:06] <ogra> yep :)
[18:06] <prpplague> dandy
[18:06] <lool> Still no luck
[18:08]  * lool goes a for a debug build
[18:08] <lool> actually I had that multi SD card patch disabled in my version, perhaps that's it
[18:08] <ogra> ah
[18:09] <ogra> well, a working MLO should at least get you some console output
[18:18] <lool> Gah I rebuilt with #define OMAP3_BOOT_DEBUG and I see nothing
[19:27] <abdalla> Hello, Anyone here from Canconical Company..Please I want to ask a question?..Thanks in Advance
[20:46] <Gopal> Hello, I used linux-image-2.6.32.10-zippy2.x12_1.0karmic_armel.deb to build he beagle board ubuntu
[20:47] <Gopal> but my keyboard is not working and no usb devices attached is working, can some tell me what is going on here
[21:14] <lool> Gopal: I'm afraid this kernel isn't from Ubuntu
[21:14] <lool> Gopal: Check with whom you got it from
[21:18] <Gopal> lool: OK thanks
[21:32] <Gentooer> Hi, I keep seeing stuff about Ubuntu on Marvell Dove and Freescale Babbage boards. Where do you guys actually get these boards? Are they for sale to the public?
[22:29] <NCommander> Gentooer: they aren't sadly
[23:00] <armin76> heh
[23:00] <armin76> Gentooer: funny you being a gentooer and being in here :P