[06:48] <DanaG> http://www.liliputing.com/2010/06/toshiba-ac100-10-inch-netbook-with-android-nvidia-tegra.html
[06:48] <DanaG> Say, why do OEMs stick a smartphone OS on a laptop?  They need Ubuntu!
[06:56] <ojn> 512MB is a bit on the low end for a regular distro
[07:23] <DanaG> ah. So they need to add more RAM!
[07:24] <DanaG> Still can't seem to find Marvell Dove boards anywhere... are they just not out?
[07:25] <DanaG> Retail, I mean.... to where beagleboard is 'retail".
[07:28] <DanaG> http://soltesza.wordpress.com/2010/06/27/toshiba-a100-smartbook-with-android-but-why/
[07:31] <DanaG> I also wonder: why in the world are AMOLED displays always made glossy?  AMOLED is bright enough without gloss... adding gloss just makes it hard to see outside!
[08:34] <hrw> mrnng
[08:44] <ericm_> I remember there's a wiki page describing the switches we are using for ARM on Lucid, anyone has that reference?
[08:44] <ericm_> gcc switches
[08:45] <hrw> -arch=armv7-a -mfpu=vfpv3-d16 like ones?
[08:45] <ericm_> hrw, yeah
[08:45] <ericm_> hrw, like we decided to use thumb2 in lucid for code density
[08:47] <lool> ericm_: Correct
[08:47] <ericm_> lool, you have that reference, cannot find it on wiki.u.c
[08:48] <hrw> -mthumb -mthumb-interwork - first enables Thumb (Thumb2 on arm1156 and cortex), second enables mixing arm and thumb code
[08:48] <hrw> https://wiki.ubuntu.com/ARM/Thumb2 you mean?
[08:48] <ericm_> lool, hrw, and do you know if how we handle ThumbEE in Lucid and Maverick?
[08:49] <hrw> no idea
[08:49] <ericm_> hrw, I think that's the page I was looking for, thanks man
[08:52] <ericm_> hrw, did we use ThumbEE maybe in some libraries?
[08:53] <ericm_> for run-time Java acceleration possibly?
[08:53] <lool> ericm_: I have no idea if we use any thumb EE, openjdk might?
[08:53] <hrw> do not know
[08:53] <lool> ericm_: we don't in the toolchain
[08:53] <lool> ericm_: thumb2 != thumbee though
[08:53] <lool> we use thumb2 all over the place
[08:54] <lool> -mthumb + -march=armv7 implies thumb2
[08:55] <hrw> openjdk has a branch which use java arm extensions/instructions but thats not merged yet iirc
[08:57] <ericm_> lool, ok I see - so toolchain won't automatically generate ThumbEE instructions unless explicitly coded in the assembly file right?
[08:58] <ericm_> hrw, chances are it still could be merged in the future, and you know how we could handle SoC with ThumbEE and SoC without ThumbEE in this case?
[09:02] <hrw> "ThumbEE is a variant of the Thumb-2 instruction set. It is designed as a target for dynamically generated code. This is code compiled on the device either shortly before or during execution from a portable bytecode or other intermediate or native representation. It is particularly suited to languages that employ managed pointers or array types. ThumbEE provides increased code density for the compiled binary compared with the compiled code for th
[09:02] <hrw> and jazelle (java thing) is other stuff
[09:19] <lool> ericm_: I dont think the toolchain uses thumbee indeed
[09:20] <lool> ericm_: usually it's generated by JITs
[09:36] <ericm_> lool, ok
[16:13] <GrueMaster> ogra: any luck on the image build issue?
[16:13] <ogra> the archive is constantly out of sync :(
[16:14] <GrueMaster> Yea, I've known that for several cycles now.
[16:14] <GrueMaster> How about the mke2fs issue?
[16:14] <ogra> i wrote a script that loops until it has one successfull build and then takes an archive snapshot from my package proxy
[16:14] <ogra> thats running since yesterday afternoon without finishing successfull once
[16:15] <ogra> i cant move on with the filesystem issue without having at least for a few hours a stable archive
[16:15] <GrueMaster> I think it is just a matter of finding the right combination of parameters to mke2fs.
[16:15] <ogra> well, we shouldnt need *any* parameters, thats the worrying issue
[16:17] <GrueMaster> I was comparing the dumpe2fs output from the 7/20 image and a test fs that I created.  Major differences.  Today I'll look to see if there is a difference when I use mke2fs on a real partition.
[16:19] <GrueMaster> I also looked at the source for genext2fs.  It has hard coded inode and block sizes that are different than the defaults for mke2fs.
[16:19] <ogra> oh, thats intresting
[16:20] <ogra> but it should just work still ... and it obviously does for a filesystem you create yourself
[16:20] <rsalveti> could be an issue with how the image is created
[16:21] <GrueMaster> In my testing yesterday, I created a blank fs with dd that was 2G, then formatted it with mke2fs using different parameters each time.  I still couldn't copy the 7/20 image contents over without failing.
[16:21] <rsalveti> I mean, you're using dd
[16:21] <rsalveti> for some reason mkfs is not behaving well with it
[16:22] <GrueMaster> Nah.  dd should just be making a blank file full of zeros.
[16:22] <GrueMaster> Other than no chs info, it should be ok.
[16:31] <GrueMaster> ogra: question on the beagleboard lucid>maverick upgrade.  I'm testing it this week, but is it really an option, considering we never officially released lucid for beagleboard?  (I don't see an image on releases.ubuntu.com with the other armel images)
[16:32] <ogra> GrueMaster, http://cdimage.ubuntu.com/ports/releases/lucid/release/
[16:32] <GrueMaster> Hmmm.  It never made it to releases.ubuntu.com.  Not sure why.
[16:33] <ogra> deliberately
[16:33] <ogra> we only added it as new port while its fully supported in maverick
[16:33] <GrueMaster> ok
[16:35] <GrueMaster> Thought I'd check.
[17:53] <asac> rcn-ee: there?
[17:53] <asac> rcn-ee: is there still a ti hosted omap3 kernel tree with all the goodies like powervr module etc.?
[17:55] <asac> rcn-ee: afaiui git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git  is not broken as they do omap4 there
[17:55] <asac> is there a separate omap3 branch?
[19:36] <rcn-ee_work> asac, just read the irc log, you still looking for the powervr goodness?
[19:36] <asac> rcn-ee_work: yes, i wonder where its originating. and whether there is a full omap3 tree still hosted by ti
[19:37] <asac> i would assume the latter would have it applied already
[19:38] <rcn-ee_work> hey asac, nope no tree yet.. ;)  i saw the gpl license in the SDK and just went for it... no one at TI's complained yet and it beats cross compiling them later.. ;)
[19:38] <rcn-ee_work> Patches here: against 2.6.35-rc http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.35-devel/files/head:/patches/sgx/
[19:39] <rcn-ee_work> just wired them into the kernel myself one saturday. so no ryme or reason for the kconfig settings, but it works.. ;)
[19:39] <asac> rcn-ee_work: whats the canonical place for omap3 SDKs? TI folks said there are many SDKs floating around ;)
[19:40] <asac> i got mine from what you mentioned on your site ... still TI didnt know who is owning that etc. if you have info about that i would be happy!
[19:40] <rcn-ee_work> oh no idea... (here i thought you were working for canonical.. ;) )
[19:40] <asac> i am ;)
[19:40] <asac> but even ti doesnt know ;)
[19:40] <rcn-ee_work> i should dump a readme in there... I'm leaving it up to TI to submit (and then get denied by the kernel guys)
[19:40] <XorA> depends on the TI department
[19:41] <XorA> chances of TI submitting SGX modules is probably less than zero
[19:42] <asac> well. chances of those landing as they are now is probably less than zero too ;)
[19:42] <asac> slangasek: 20:38 < rcn-ee_work> Patches here: against 2.6.35-rc http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.35-devel/files/head:/patches/sgx/
[19:42] <rcn-ee_work> exactly, but having them in the tree for ubuntu or for my customers it does help remove an extra recompile step..
[19:42] <asac> those are apparently shipped in the SGX SDK ... which we don't know whats the right place
[19:43] <asac> rcn-ee_work: yes, thats why i am asking. i am pushing for getting them in some linaro tree
[19:43] <asac> and package
[19:43] <rcn-ee_work> I have it synced with the latest, i try not to ship the old sdk for too long..
[19:43] <asac> so we don need to pull your .debs etc. all the time
[19:43] <asac> rcn-ee_work: i hoped there would be a dirty full omap3 tree with all kind of patches that ti hasnt upstreamed ... would be easiest to just package that up. but seems none such thing exist
[19:44] <rcn-ee_work> the sad part, an x86 is still needed for the final sgx binary (libGL stuff) http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6.35-devel/annotate/head:/create_sgx_package.sh
[19:44] <asac> so we need to use our tree and add the patches from gsx there
[19:44] <XorA> GFX modules are a different team than the kernel team
[19:44] <prpplague> XorA: what's cookin?
[19:45] <asac> XorA: still they could land their stuff in their tree rather than shipping patches etc.
[19:45] <XorA> hey prpplague hows the big office in Dallas
[19:45] <prpplague> XorA: still big
[19:45] <XorA> asac: heh, try working for TI :-)
[19:45] <asac> rcn-ee_work: hmm ... isnt OMAP35x_Graphics_SDK_setuplinux_${SGX_VERSION}.bin just a shell unpack installer thing?
[19:45] <asac> or is there really x86 binary code in it that gets run?
[19:45] <rcn-ee_work> yeap... it is.. but the *.bin is x86 code.. ;)
[19:46] <dcordes_> XorA: :D hey. long time no see
[19:46] <XorA> prpplague: post me some BBQ
[19:46] <XorA> prpplague: or new toys :-)
[19:46] <asac> so they wrote the unpack installer code in C? wowo
[19:46] <rcn-ee_work> with a little help qemu on arm probally could do it?
[19:46] <dcordes_> XorA: mmm ti nice
[19:46] <prpplague> XorA: hehe
[19:46] <prpplague> XorA: should have a new round of toys soon
[19:46] <rcn-ee_work> talkign with koen, the next release might be atleast 'wget-able' doubt you could extract it on anything other then x86 thou.
[19:46] <prpplague> XorA: i've been so busy with board bringup i've not had time to work on new products
[19:47] <asac> rcn-ee_work: yeah. i think we shouldnt bother too much on the user space pieces. i think they are working to make packages happen - so lets hold our breath ;)
[19:47] <asac> probably not for omap3 though ... or at least with low prio
[19:47] <asac> ok tanks
[19:47] <XorA> the team is nice is making packages for the driver
[19:47] <XorA> the team is nice is making packages for the drivers
[19:47] <XorA> in Nice
[19:47] <prpplague> XorA: zippy and zippy2 are still selling pretty good, and the trainer is slowly starting to pick up in sales
[19:48] <rcn-ee_work> I know ubuntu has shipped closed blobs before, so as long as the kernel as the gpl parts, the userspace maybe could be downloaded from ubuntu repo? (like nvida/ati/etc stuff) but that would be something between ubuntu and ti...
[19:49] <XorA> prpplague: put zippy support in ubuntu yet?
[19:49] <rcn-ee_work> i thought asac was working on the zippy stuff too.. (he was looking at my tree)
[19:50] <prpplague> XorA: not i
[19:50] <prpplague> zippy2 support might be a better choice for ubuntu
[19:50] <prpplague> since the zippy2 uses the same chipset as the 4430sdp and blaze
[19:50] <rcn-ee_work> the only difference is the spi driver, so it's pretty easy to support both..
[19:51] <prpplague> true
[19:51]  * prpplague wonders if the ubuntu-arm folks have ordered some zippy boards
[19:52] <XorA> prpplague: but you gave me a zippy :-D
[19:52] <prpplague> XorA: indeed
[19:52] <prpplague> XorA: i'll bring some other boards if i can when i come in october
[19:52] <XorA> prpplague: you gouing to ELC-E
[19:53] <rsalveti> prpplague: yep, I got one here
[19:53] <XorA> prpplague: the annoying thing is I think I might end up at UDS which is the same week
[19:53] <rsalveti> didn't have time yet, but I'm planning to push the zippy 2 patches forward
[19:53] <prpplague> XorA: doh
[19:53] <prpplague> rsalveti: ahh
[19:53] <rsalveti> at least to be supported by ubuntu's kernel
[19:53] <prpplague> XorA: http://www.embeddedlinuxconference.com/elc_europe10/sessions.html#Anders
[19:54] <XorA> prpplague: heh
[19:54] <XorA> prpplague: you is famous
[19:54] <prpplague> XorA: hehe, well we will have to see if anyone actually shows up for the presentation
[19:55] <dcordes_> prpplague: that's the elinux.org tux!
[19:55]  * dcordes_ has never been to UK
[19:55] <dcordes_> maybe I will stop by
[19:56] <XorA> dcordes_: well we have the best beers :-)
[19:56] <prpplague> dcordes_: elinux.org is sponsored by CELF
[19:57]  * prpplague is an original founder of elinux.org
[19:57] <dcordes_> cool
[19:57] <dcordes_> I need to add some information about htc-linux.org in elinux.org
[19:58] <XorA> prpplague: you cant be, you dont have a waist length beard, all *linux* guys do
[19:58] <dcordes_> XorA: hm beers are best thing at geek events
[19:58] <dcordes_> XorA: at fosdem in belgium I drank many delirium tremens
[19:58]  * XorA doesnt drink much beer
[19:58] <dcordes_> and other funny beers from strange 0,2l bottles
[19:59] <prpplague> XorA: hehe
[19:59] <dcordes_> XorA: do they also listen to metal ?
[19:59] <prpplague> mmmmmm belgian beers
[19:59] <XorA> dont know, I listen to a lot of metal :-)
[20:01] <prpplague> rsalveti: let me know if you have any questions on the zippy2
[20:01] <prpplague> rsalveti: (and if you need any other specialized accessory boards)
[20:01] <dcordes_> XorA: ^^ you still using HTC phones ?
[20:02] <XorA> dcordes_: got a TouchDiamond2 and a Dell Streak these days
[20:02] <dcordes_> XorA: ahh rhodium
[20:02] <dcordes_> no wait that's htc topaz
[20:02] <XorA> topaz2
[20:02] <dcordes_> rhodium is the touch pro 2
[20:03] <XorA> I see Android is almost 100% on it
[20:03] <dcordes_> yes but the kernel is a total mess
[20:03] <dcordes_> they are stuck at 2.6.29
[20:03] <XorA> pretty much all android devices are
[20:03] <dcordes_> hardcode everything
[20:04] <dcordes_> sorry 2.6.27
[20:04] <XorA> android was written in LARGE crayons as far as I can see from the code quality
[20:04] <dcordes_> but with qualcomm merging msm7 and qsd8 in mainline it will only be a question of time to rebase easily
[20:06] <rsalveti> prpplague: sure, thanks :-)
[20:06] <dcordes_> XorA: mhm I'm not a big fan of android either way
[20:06] <prpplague> rsalveti: if i can ever find the time, i need to finish up with the showdog, which would be a good item for you ubuntu guys
[20:07] <dcordes_> XorA: and regarding kernel I'm trying to keep some order in the chaos at least for the devices I have
[20:07] <dcordes_> XorA: still have the kaiser :) ?
[20:08] <rsalveti> prpplague: hm, that would be a nice toy
[20:08] <XorA> dcordes_: no, swapped the kaiser for part of my car
[20:09] <rsalveti> prpplague: how is it going?
[20:09] <dcordes_> XorA: no reason to keep it when you have same device with better performance
[20:10] <XorA> prpplague: get designing that quad omap4 :-)
[20:10] <dcordes_> XorA: I somehow can't give mine away
[20:10] <XorA> dcordes_: well I wanted a car :-)
[20:10] <dcordes_> XorA: lol. with the leo (htc hd2) I got my first linux device w/o keyboard
[20:12] <dcordes_> never getting used to the on screen keyboard only situation
[20:12] <prpplague> rsalveti: it's pretty much done, i just need to run a few more tests, clean up a few items on the schematic and get the gerbers off to china for pcb production
[20:12] <prpplague> rsalveti: just been too busy with board bringup
[20:12] <dcordes_> XorA: but there were no other qsd8250 devices available when I got it
[20:13] <rcn-ee_work> oh asac, sorry misread one of your questions: TI has told me to always use: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS.html (to get latest)
[20:13] <XorA> prpplague: BTW dude, is there a guide to debugging x-load with JTAG anywhere?
[20:13] <prpplague> XorA: i don't think there is
[20:14] <prpplague> XorA: running into problems?
[20:14] <XorA> omapzoom3 needs external UART support
[20:14] <asac> rcn-ee_work: thanks a bunch
[20:14] <asac> rcn-ee_work: how about adding #linaro to your autojoin list ;) ... you are more than welcome there!
[20:15] <prpplague> XorA: for booting? or output?
[20:15] <XorA> prpplague: so I can see why it is failing to load u-boot :-)
[20:15] <XorA> prpplague: but some form of output would be nice
[20:15] <prpplague> XorA: ahh
[20:15] <rcn-ee_work> asac, i will when i get home tonight, too many pc's took me 5mins to get back into this channel at work. .;)
[20:15] <XorA> prpplague: beagle x-load is verbose :-)
[20:18] <asac> heh
[20:18] <dcordes_> XorA: btw you shouldn't use evil msm7* phone. get one with omap850 :D
[20:42] <XorA> hey robbiew
[20:42] <XorA> hey robclark
[20:44]  * prpplague throws EHCI PHY chips at robclark and XorA  like ninja throwing stars
[20:44] <robbiew> XorA: looking for me or robclark?
[20:44] <XorA> robbiew: robclark, sorry!
[20:44] <robbiew> np ;)
[20:44] <XorA> return to sleep :-D
[20:44] <robclark> hey XorA
[23:05] <prpplague> anyone got dual framebuffers up and running on ubuntu?
[23:06] <prpplague> more accurately dual framebuffers running a desktop
[23:14] <cwillu_at_work> given a zippy that gives me a second dvi port from the lcd headers, I would :D