=== suihkulo1ki is now known as suihkulokki
[09:19] <janimo> marvin24, so did you try rebasing on the l4t-r15 nvidia branch?
[09:22] <ppisati> ogra_: willing to test an omap3 kernel on your xm?
[09:23] <ogra_> ppisati, sure, but i have to check if i have a working install, i think i trashed the last one with a broken netinst
[09:23] <ogra_> (so it might take a little to roll a new one)
[09:24] <ppisati> ack
[09:24] <ppisati> i'll prepare the kernel, put it somewhere and point you to it
[09:24] <ppisati> ogra_: ^
[09:25] <ogra_> k
[09:25] <ogra_> oh wow, this is neat ! http://www.arm.com/community/partners/display_product/rw/ProductId/6951/
[09:26] <ogra_> "OpenBlocks AX3", " SO-DIMM (4 GbE ports model, up to 2 GB can be added), " ... "1 SATA port and 1 eSATA port" .... "dual core Marvell(R) 1.33 GHz (based on ARM v7 instruction set architecture)"
[09:26] <marvin24> janimo: yes
[09:27] <marvin24> but usb fails to resume now :-(
[09:27] <ogra_> http://openblocks.plathome.com/products/obs_a/   ...  "Only Available in Japan "
[09:27] <ogra_> *sniff*
[09:27] <infinity> ogra_: If our Armada kernel will boot that out of the box, I'll take two.
[09:27] <janimo> marvin24, you mean any usb device
[09:28] <ogra_> infinity, that would need some emmiting *gg*
[09:28] <marvin24> no, only devices connected to ehci2 (wifi)
[09:28] <marvin24> janimo: should be fixable though
[09:29] <infinity> ogra_: The slightly beefier version there, if I could get a decent WiFi PCIe card for it, and an antenna that doesn't suck, would handily replace my G3 tower for my core router at home.
[09:29] <infinity> ogra_: Well, the 4-port version would.
[09:30] <ogra_> you would do builds on a router ? or use a router as buildserver ?
[09:30] <janimo> marvin24, I'll check out that kernel. The one we have now in Ubuntu is based on same nvidia but without your latest patches since the last ubuntu package
[09:30] <janimo> and this one causes X to not come back well after resume
[09:30] <infinity> ogra_: No, I'd use it as a router. :P
[09:30] <marvin24> janimo: oh, bad
[09:30] <ogra_> heh, what a waste
[09:31] <ogra_> it could replace all your pandas in one go
[09:31] <infinity> ogra_: Nah, it's not THAT fast.
[09:31] <infinity> ogra_: (Though, the expandable RAM is a huge win)
[09:31] <ogra_> sata as well
[09:32] <ogra_> that togetzher will make it as fast as the armada board
[09:32] <infinity> I have an mx53 and mx6 with SATA, that's less exciting.
[09:32] <ogra_> oh, you have an mx6 ?
[09:32] <infinity> But man, I'd love some RAM.
[09:32] <ogra_> *envy*
[09:32] <infinity> Not much to envy, since it seems like the Freescale Landing Team has all but disappeared.
[09:32] <infinity> I need to hunt down WTF is going on there.
[09:33] <ogra_> oh, bad
[09:33] <ogra_> infinity, btw, do you have an idea why ubuntu-server daily doesnt build armhf+omap4 ?
[09:33] <ogra_> according to default-arches it should
[09:33] <infinity> I wasn't aware that it didn't.  Haven't you taken over ownership of images this cycle, so I can pretend I don't care? :)
[09:34] <ogra_> (works awesome now, i fiddled with it over the weekend)
[09:34] <ogra_> infinity, i did, but you know cdimage as well and i cant find the cause ...
[09:35] <infinity> ogra_: Are you talking daily-preinstalled (which hasn't built since June...) or some new-fangled thing?
[09:35] <ogra_> alternate ubuntu-server for arm
[09:35] <ogra_> ubuntu-server daily
[09:36] <ogra_> +ubuntu-server           *                       *                       amd64 amd64+mac i386 powerpc armhf+omap4
[09:36] <ogra_> (since last week)
[09:36] <ogra_> but there is also:
[09:36] <ogra_> ubuntu-server           daily-preinstalled      quantal                 armhf+omap armhf+omap4
[09:37] <ogra_> ogra@anubis:~/Devel/branches/nusakan/cdimage-deployment$ CDIMAGE_ROOT=. ALL_DISTS="quantal precise" bin/default-arches ubuntu-server daily quantal
[09:37] <ogra_> amd64 amd64+mac i386 powerpc armhf+omap4
[09:38] <ogra_> ogra@anubis:~/Devel/branches/nusakan/cdimage-deployment$ CDIMAGE_ROOT=. ALL_DISTS="quantal precise" bin/default-arches ubuntu-server daily-preinstalled quantal
[09:38] <ogra_> armhf+omap armhf+omap4
[09:38] <ogra_> but ubuntu-server armhf+omap4 is never attempted
[09:38] <ogra_> (for daily)
[09:39] <ogra_> building it manually with ARCHES= set works fine
[09:39] <ogra_> (and only takes 10 min !)
[09:40] <infinity> Can we actually install meaningfully from altrenateish media now?  Keen.
[09:41] <ogra_> yep, works flawless
[09:41] <ogra_> and i started shipping a boot.scr-serial file that you can just cp in place if you want serial enabled
[09:45] <infinity> ogra_: Was there much point in dropping the server preinstalled in favour of alternates, if server will (some day) change format again anyway?
[09:45] <ogra_> it wont chanage format
[09:45] <infinity> ?
[09:45] <infinity> Has Daviey given up on that?
[09:45] <ogra_> the install is still d-i usinf live-installer to copy a squashfs in place as i understood that
[09:46] <infinity> Well, yes.  Which is a format change. :P
[09:46] <ogra_> well, i want arm images to be in sync with what x86 does
[09:46] <ogra_> i would have to do that in any case
[09:47] <ogra_> if i do it before or after the switch doesnt matter
[09:47] <infinity> Fair enough.
[09:48] <ogra_> i doubt colin will invent a new imagetype for it but just change "daily"
[09:48] <ogra_> (he implements it in his spare time as i understood)
[09:52] <infinity> ogra_: Alright, well.  I fixed the default-arches syntax (and committed).
[09:52]  * ogra_ pulls and takes a look
[09:52] <infinity> ogra_: If that doesn't make it magically happy, I'm not sure what the breakage might be.
[09:53] <infinity> I'm also not sure how bin/default-arches was "working" with the previous copy...
[09:53] <ogra_> well, see above
[09:53] <infinity> Yes, I see it working.  I'm not sure why. :P
[09:53] <ogra_> it even gave me the expected output
[09:55] <ogra_> ah, drat ...
[09:55] <ogra_> so just removing the dash would have been enough
[09:55] <ogra_> (form precise-)
[09:56] <ogra_> infinity, thanks so much !
[09:57] <infinity> ogra_: Well, I make no promises that it's working until you test it. :P
[09:57] <infinity> ogra_: But it should.
[10:00]  * ogra_ moves on to finbally fix netboot images
[10:01] <LetoThe2nd> ogra_: \o/
[10:01] <ogra_> sorry that it took so long to get there, the alternates were more broken than i thought
[10:02] <LetoThe2nd> ogra_: np, i'm just glad you find time now :)
[10:02] <ogra_> :)
[10:42] <LetoThe2nd> bug #721147
[10:42] <ubot2> Launchpad bug 721147 in flash-kernel "flash-kernel subarch check fails with Linaro OMAP kernels" [Undecided,Fix committed] https://launchpad.net/bugs/721147
[10:42] <LetoThe2nd> ogra_: is ping from #pandaboard above bug?
[10:48] <ogra_> LetoThe2nd, yep, though in your case the bug is in the way you packaged it i think
[10:49] <LetoThe2nd> ogra_: seems like nop-ing check_subarch() in /ust/sbin/flash-kernel does the trick....
[10:49] <ogra_> (even the linaro kernels use the subarch in tehir name)
[10:53] <LetoThe2nd> ok, it *did* claim to flash this time, but it still boots the old kernel
[11:00] <janimo> lilstevie, do you know what the 'kinteractiveup task blocked for more than 120 seconds' could be caused by? Most references on the net are in pastebins
[11:00] <LetoThe2nd> even changing the inird.img and vmlinuz links in /boot does not seem to effect the selected kernel :(
[11:09] <lilstevie> janimo: interactive task scheduler literally grepping 'kinteractiveup' would have shown you that
[11:10] <janimo> lilstevie, right I see that but I don't know what the actual bug is
[11:10] <janimo> I saw your fix is disabling that config option
[11:11] <lilstevie> yep, no need for interactive scheduling IMO
[11:21] <sveinse> How is the uboot files updated in precise? I't cant find how mkimage is run on the kernel and the initramfs in precise. It seems the method have been changed...
[11:28] <sveinse> I think I found it. I missed calling /etc/kernel/* hooks from my kernel pre/postinst scripts.
=== zyga_ is now known as zyga
[12:22] <ppisati> ogra_: 600$ for that thing?!?! (i mean the openblock embedded board)
[12:22] <ogra_> yeah, its not a cheapo, but its pretty powerful
[12:22] <ogra_> should shorten your builds a lot
[12:22] <ppisati> ogra_: ok, but with 600$ you can buy an i7 maybe
[12:22] <ogra_> well, not yours, wont indeed be as fast as cross
[12:23] <ogra_> burt ofr everything that cant use cross it would be great
[12:23] <ogra_> *for
[12:23] <ppisati> ogra_: bryan is looking after a marvell(?!?!) board quad-core + sata
[12:24] <ogra_> yeah, next gen
[12:25]  * ogra_ needs to reboot, brb
=== shadeslayer is now known as shadeslayer_
=== shadeslayer_ is now known as shadeslayer
[12:35] <sveinse> I observe that update-initramfs is being called twice when installing a new kernel. The first time with the -c option (which does not run any hooks) and the second with -u that does. Is this expected behaviour?
[12:45] <ppisati> ogra_: when you want to test omap3, here it is: http://people.canonical.com/~ppisati/linux-image-3.5.0-6-omap_3.5.0-6.6~next_armhf.deb
=== shadeslayer is now known as shadeslayer_
=== shadeslayer_ is now known as shadeslayer
=== ogra is now known as ogra_
=== cmagina-lunch is now known as cmagina
=== zyga is now known as zyga-brb
=== zyga-brb is now known as zyga-afk
[16:50] <janimo> infinity, are the cdv packages icky?
[16:50] <janimo> cedarview
[16:51] <infinity> janimo: Probably.  I haven't had the time to delve deeply into them. :/
[16:52] <janimo> np, thanks
=== zyga-afk is now known as zyga
[18:39] <prpplague> just fyi, if anyone has some wish list items for an omap5 community board, now is the time to discuss them
[18:40] <TypoNAM> please give us the ability to attach a RTC backup battery? ;)
[18:41] <TypoNAM> don't even have to provide a battery holder, just a few pins would be nice
[18:42] <infinity> prpplague: SODIMM slot, SODIMM slot, and SODIMM slot.
[18:42] <prpplague> infinity: ??
[18:43] <infinity> prpplague: The limited RAM on these boards is the one thing that kills their usefulness in many situations.
[18:43] <TypoNAM> they're embedded SoCs, not desktop processors :P
[18:43] <prpplague> infinity: give me an example
[18:43] <infinity> TypoNAM: There's no distinction anymore.
[18:44] <prpplague> infinity: i have never even come close to using all the ram on panda
[18:44] <infinity> prpplague: Then you don't use yours to build software natively.
[18:44] <infinity> prpplague: Many of us do. :P
[18:44] <prpplague> infinity: which makes no sense at all, imho
[18:45] <infinity> You can carry on having that HO, but you're just as "wrong" as I am. :P
[18:45] <TypoNAM> prpplague: I really do like the pandaboard ES PCB layout, but there's been some complaints about the tall audio and USB+ethernet ports though for trying to fit the boards into thin enclosures such as purposing laptop cases, hehe
[18:45] <prpplague> infinity: "that HO" ?
[18:45] <infinity> prpplague: "humble opinion".
[18:46] <prpplague> infinity: there is a place and time for doing native complies, but one that requires massive amount of memory simply implies that it would be better done on a workstation
[18:46] <infinity> prpplague: OMAP5 is the first A15 I'll be able to get my hands on (probably), being able to use it as a solid test bed (and build environment) for Xen and KVM will be lovely.  Limiting the RAM will make it much less useful (as the Pandas are much less useful to me than they could be)
[18:46] <prpplague> TypoNAM: yea got that one down already
[18:47] <infinity> prpplague: Yes, well.  You're not building a distribution on/for them.  I am.  Just sayin'.
[18:47] <prpplague> infinity: and what "amount" of ram would you want?
[18:47] <infinity> Cross-compiling entire distros is actually much more effort than people claim it is, and really not worth it.
[18:47] <TypoNAM> I'll be happy with the 1GByte minimum as we currently have the pandaboard ES :P
[18:48] <prpplague> infinity: and you?
[18:48] <infinity> TypoNAM: Yes, but you also don't build on them, I'm assuming.
[18:48] <TypoNAM> infinity: I'm doing native build with software yes, but not entire distributions
[18:48] <infinity> prpplague: If it must be hard-wired, 4G would be a nice start.
[18:48] <infinity> But heck, even if we discount building, it's a quad-core A15, supports virtualisation, etc.  1G is... not much.
[18:48] <prpplague> infinity: even if the price was much more expensive?
[18:49] <prpplague> infinity: omap5 is dual core
[18:49] <infinity> prpplague: It wouldn't be "much" more expensive, unless someone puts a premium on it to increase margins.  Maybe 20-50$ at the most.
[18:49] <prpplague> infinity: it adds more than you think to the cost
[18:49] <infinity> prpplague: Is it?  Why was I under the impression it was 4?  Anyhow.  The A15 and virt bits stand.  It's not a "slow" CPU.
[18:51] <TypoNAM> I believe the PowerVR graphics is quad-core in OMAP5
[18:51] <prpplague> infinity: don't know why you thought it was quad A15
[18:51] <prpplague> infinity: there are four cores, but only two of them are A15
[18:51] <prpplague> infinity: http://focus.ti.com/en/graphics/wtbu/omap5/OMAP5430-SoC_tn.gif
[18:52]  * suihkulokki would also like a SODIMM but is also a distro builder :P
[18:52] <TypoNAM> http://focus.ti.com/en/graphics/wtbu/omap5/OMAP5430-SoC_large.gif
[18:53] <infinity> prpplague: Yeah, so I see.  No idea where I got the 4 from.  Doesn't much matter.
[18:53] <prpplague> TypoNAM: thanks thats the one i meant to post
[18:54] <infinity> And I suppose using the 5432 part is out of the question? :)
[18:54] <infinity> (Which would make the use of normal laptop RAM much simpler)
[18:55] <TypoNAM> infinity: the board you want will probably cost the same as an iPad 3
[18:55] <prpplague> infinity: well, most "laptop" sodims are designed for a 64-bit data bus. since the OMAP5 is designed around 32-bit operations, you would only get 1/2 of the memory of a general sodimm memory device
[18:56] <infinity> TypoNAM: The 5432 is cheaper than the 5430...
[18:58] <infinity> prpplague: Maybe I'm misreading "dual-channel DDR3" on the larger/cheaper part?  *shrug*
[18:59] <prpplague> infinity: yea you are
[18:59] <infinity> Anyhow.  More RAM, either hardwired or expandable, would make me (and many people I know) a happy camper.  Beyond that, I have no laundry list.
[19:00] <infinity> I assume the board will have a SATA header?  But if not, I can live without it.
[19:01] <prpplague> just asking for input on a possible board right now
[19:03]  * infinity thought the Panda5 already more or less existed, just not in GA production.  Or are you working on a competing product?
[19:04] <scientes> infinity, do you even have specs for the panda 5?
[19:04] <infinity> scientes: Other than hallway conversations with robclark about the one on his desk, no. :P
[19:08] <robclark> prpplague, and building kernel or other big packages is actually a good stability test for the platform.. just fyi
[19:09] <prpplague> robclark: i am not totally against native builds, it has it's place
[19:11] <robclark> true.. but keep in mind ARM is closing the desktop gap..  if it were cost effective SODIMM slot would be nice so people could put in whatever amount of memory..   (that said, going beyond 2GiB we start leaning on LPAE which should make for fun kernel bugs at the beginning)
[19:12] <TypoNAM> infinity: what kind of builds are you doing that uses up all the RAM? are you running parallel builds or something?
[19:12] <robclark> TypoNAM, ever build chromium?
[19:12] <robclark> (to be fair.. that one I've only cross compiled, but it even struggles with the 4GiB on my laptop)
[19:12] <infinity> TypoNAM: Try webkit.
[19:12] <infinity> TypoNAM: Or *anything* C++/boost.
[19:13] <infinity> Or.. Well... Lots of things.
[19:13] <TypoNAM> my projects are C++ with boost libraries, but they're only about 50 .cpp source files though :P
[19:13] <infinity> TypoNAM: When I said "an entire distro", I meant it.  There's no "what kind of builds here", it's "everything in the Debian and Ubuntu archives".
[19:13] <infinity> s/ here"/" here/
[19:13] <TypoNAM> yeah, but it does matter if you're building each package at a time or trying to build multiple of them at once ;)
[19:13] <scientes> robclark, i've compiled chromium on armv5t
[19:14] <robclark> an o5 panda w/ 4+GiB RAM would be worth it's weight in unobtanium for someone who had to build chromium
[19:14] <infinity> TypoNAM: One at a time.
[19:14] <scientes> with 1.5GB ram
[19:14] <scientes> and no swap!
[19:14] <infinity> Don't get me started on the joys of swapping to USB. ;)
[19:14] <scientes> (thats with NaCl disabled)
[19:15] <scientes> robclark, chromium actually built with 1.5GB ram and no swap, so its not insane
[19:15] <scientes> about the same as firefox
[19:15] <robclark> scientes, well, ok.. when I was cross compiling, i had debug syms enabled.
[19:15] <scientes> yes i am unable to build firefox with debug symbols
[19:15] <robclark> I assume there is no dbg package for firefox or chromium on arm
[19:15] <scientes> i don't have enough ram
[19:15] <infinity> webkit generally hits just shy of the 3G-per-process limit when linking.
[19:16] <prpplague> infinity: don't suppose you've picked up one of those odroid-x boards yet?
[19:16] <infinity> Which is a laugh riot when you're swapping 2G of that to disk.
[19:16] <scientes> but actually this built the chromium debug symbols in 1.5gb, but it did have optimization on
[19:16] <scientes> the debug symbols themselves are 500MB
[19:16] <scientes> http://packages.debian.org/sid/chromium-dbg
[19:16] <robclark> hmm, last time I built (r20 or so), the executable w/ debug symbols was itself about 1.5GiB..  and dropped to maybe around 60MiB if you strip debug syms
[19:17] <robclark> so > 1GiB of debug symbols
[19:17] <infinity> prpplague: Nope, though I'd end up with the same complaint (or worse, given the two more cores, and the urge to eat all the RAM twice as fast with -j4 instead of -j2)
[19:17] <robclark> it took a few hours to link on my core i7 laptop w/ 4GB
[19:17] <scientes> robclark, yeah the diff might be that ubuntu+debian dynamically link alot of stuff, instead of statically link
[19:17] <robclark> ahh, yeah, for sure
[19:18] <robclark> default chromium build statically links the world
[19:18] <scientes> however its still a mess how much is statically linked
[19:18] <robclark> yeah, tell me about it
[19:18] <scientes> like chromium makes one incompatible change to protobufs (their own upstream!) which means you can't dynamically link
[19:18] <robclark> heheh, yeah, it's insane