[08:22] <lag> What flavours are supported on Panda/Beagle?
[08:22] <lag> Is Panda just Maverick?
[08:23] <lag> And Beagle? Both?
[08:24] <cooloney> lag: beagle is omap3 which is a flavour in our master branch of Maverick
[08:24] <cooloney> lag: panda is omap4 which is a separated topic branch from master, it is ti-omap4 branch
[08:25] <cooloney> but in the future, when all the omap4 patches are merged into mainline, we don't need the ti-omap4 branch anymore
[08:26] <amitk> lag: omap3 is branch in lucid (ti-omap), part of master in maverick. omap4 is maverick-only (ti-omap4 branch)
[08:29] <cooloney> amitk: do you know what's the difference between x-loader and u-boot?
[08:29] <cooloney> amitk: i just clone the x-loader for omap4, it looks like u-boot.
[08:30] <lag> Isn't x-loader == MLO
[08:31] <sebjan> cooloney: x-loader is a stripped version of u-boot. So same code base but minimal size.
[08:32] <cooloney> sebjan: thanks, man. and is x-loader required for omap4 board booting?
[08:32] <sebjan> cooloney: today yes. We shall be able to get rid of it in a near future.
[08:34] <cooloney> sebjan: ok, so in the near future, u-boot is good enough for booting the system, right?
[08:34] <sebjan> cooloney: yes, that's it :)
[08:34] <hrw> morning
[08:34] <cooloney> hrw: morning
[08:35] <cooloney> sebjan: back to lag's question, x-loader == MLO? what's MLO?
[08:35] <cooloney> sebjan: or it's a secret name
[08:35] <hrw> MLO is X-Loader
[08:36] <lag> I though MLO was for cards
[08:36] <cooloney> hrw: just another name of x-loader?
[08:36] <lag> MLO == x-loader for MMC
[08:36] <lag> Not a secret
[08:36] <sebjan> MLO just has an additional header added to the x-loader binary
[08:38] <DanaG> omap4 "panda"? That's new.
[08:38] <DanaG> I wanna' see a pic of that.
[08:40] <hrw> DanaG: I want hw to take a pic
[08:41] <DanaG> It seems to be so brand-spanking-new, the only google results are the kernel commits.
[08:42] <hrw> DanaG: iirc release in fall
[08:42] <DanaG> http://marcin.juszkiewicz.com.pl/2010/05/14/uds-continues/
[08:43] <DanaG> I still say: I don't call 3D useful until it can do compiz. Open or closed, doesn't matter too much.
[08:43] <DanaG> Well, as long as the closed thing actually builds -- TI PowerVR build script fails miserably.
[08:44] <DanaG> A username and password are being requested by http://www.pandaboard.org. The site says: " pandaboard.org is coming soon.  Please check back later.  "
[08:45] <DanaG> I also think it really sucks that there's an x86 Flash, an x86_64 flash (though not anymore), an ARM-based Android flash... yet no simple ARM flash!
[08:45] <DanaG> Same for dropbox.
[08:46] <DanaG> All it takes is copying files, installing headers, and running "make" (at least, that's what my own software required).  Is that too much to ask?
[08:46] <amitk> DanaG: all it takes is someone to give Adobe a six-figure cheque for that
[08:47] <amitk> if you have spare change lying around, perhaps you want to become the hero of the OSS community? ;)
[08:47] <DanaG> I mean, Android would have taken MORE effort than just plain ARM!
[08:47] <DanaG> That makes no sense.
[08:47] <hrw> DanaG: there is one company behind android... forgot?
[08:48] <DanaG> Yeah, I know Google does Android, but the fact that they have Android means they probably have ARM hardware.... and thus there's no excuse for not doing a mere "make" on the existing Flash code.
[08:48] <DanaG> On ARM.
[08:48] <hrw> money is a reason
[08:49] <DanaG> What money does it take to do "scp" and "ssh" and "make"?
[08:49] <amitk> each of them gave Adobe cheques. A much larger cheque is required to free it all. OTOH, perhaps effort is wasted there and everyone should help with gnash instead?
[08:49] <hrw> if you can get money from Google, Nokia, others when why release basic one?
[08:49] <DanaG> And same is true of Dropbox.
[08:49] <hrw> never used
[08:50]  * amitk neither
[08:50] <DanaG> And unfortunately, ubuntuone rather completely devours my CPU.
[08:50] <cooloney> DanaG: dropbox is blocked in China, although some people are using it
[08:50] <DanaG> 100% of one core.
[08:51] <amitk> probably a bug
[08:51] <DanaG> My use case is having Pidgin logs in it.
[08:51] <DanaG> Thousands of files.
[08:52] <DanaG> In fact, the transition from 32-bit to 64-bit x86 has more changes, at least in my experience, than the transition from 32-bit x86 to 32-bit ARM.
[08:53] <amitk> more changes in what sense?
[08:53] <DanaG> Oh yeah, are any of you in positions to talk directly to those companies (Dropbox or Adobe)?
[08:54] <DanaG> In terms of things like pointer size, and "cast from pointer to uint32_t loses precision" (or such).
[08:55] <DanaG> http://laptopmemo.com/2010/06/22/adobe-leaks-out-all-android-handsets-that-get-the-upgrade-to-2-2-froyo/
[08:55] <DanaG> Say, does "meego" use Xorg?
[08:56] <sshekar> yes, Meego uses X
[08:56] <DanaG> ah, then this means they will be making an ARM-based X-based Flash.
[08:57] <DanaG> Sweet.
[08:57] <sshekar> not sure abt that
[08:57] <DanaG> I'd find it particularly awesome to have an Ubuntu phone.
[08:57] <amitk> that would require significant amounts of new UI work
[08:58] <DanaG> Or even just something that I could do "ssh -X" from would be enough.
[08:58] <DanaG> Android doesn't satisfy that.  Then again, there are probably VNC clients for Android.
[09:00] <hrw> DanaG: maemo has flash too
[09:01] <DanaG> har, I go to get.adobe.com/flashplayer in chromium... it gives me x86 version.
[09:01] <DanaG> ah, must just not bother trying to detect.
[09:01] <hrw> DanaG: dig a bit there, fake useragent so maybe you will get android
[09:01] <DanaG> http://get.adobe.com/flashplayer/otherversions/ -- nothing ARM there.
[09:03] <DanaG> ah, looks like it's just not available yet.
[09:04] <amitk> DanaG: ARM versions are Adobe's cash cows at the moment, since they give away the x86 ones for free
[09:04] <amitk> they're getting lots of money from each of the mobile vendors, so why make it easily downloadable?
[09:05] <DanaG> Aah, that's the best explanation anyone's ever given me.
[09:05] <DanaG> Oh, the generic ARM one wouldn't work on Android...
[09:05] <DanaG> Perhaps once they make it for one of the Xorg-running embedded ones, it'll be hackable.
[09:06] <amitk> perhaps Steve Jobs is right and we should all abandon Flash completely and concentrate on HTML5
[09:06] <DanaG> Yeah, I'd agree with that.
[09:06] <DanaG> Flash sucks everywhere.
[09:07] <DanaG> Dropbox, though, remains as a target for ARM.  Perhaps we just need market prevalence with ARM netbooks.
[09:08] <DanaG> That Toshiba one that's really new looks nice -- though could use an extended-battery option.
[09:09] <DanaG> http://www.liliputing.com/2010/06/toshiba-ac100-10-inch-netbook-with-android-nvidia-tegra.html
[09:11] <DanaG> It'd be awesome to be able to get all-day (as in 12-hour, not 8-hour) battery life.
[09:13] <DanaG> http://www.liliputing.com/2010/06/lenovo-ideapad-u1-hybrid-skylight-arent-dead-yet.html
[09:13] <DanaG> Would be awesome with Ubuntu.
[09:14] <hrw> DanaG: my x86-64 laptop does 8-10h on one charge
[09:15] <DanaG> yeah, that's what I mean... why bother going to ARM for just 8 hours battery life?
[09:16] <DanaG> Something ARM should have way longer battery life to be worthwhile.
[09:16] <DanaG> Well, they can be lighter, I'll grant that.... but some people would rather have slightly heavier for way longer battery.
[09:17] <kai> I'd love to see a mixed arch system, not sure if that's really possible, but it'd be dandy
[09:17] <DanaG> You'd have to have Universal Binaries (like what Apple did with PPC and x86 / x86_64).
[09:17] <hrw> I want 1GB RAM, at least 16GB of storage, bt, wifi, 12-13" screen with 1280x800/1366x768, good keyboard and fast enough to run kde4 desktop
[09:18] <DanaG> My killer-app any system I buy must be able to run: Compiz.
[09:18] <hrw> kai: arm cpu + x86-64 one?
[09:18] <kai> a low power chip for all the hard-core idling a usual desktop system is doing, and then a beefy multi-core that'll kick in when I start a copile or number-crunch job
[09:18] <hrw> DanaG: I prefer kwin
[09:18] <DanaG> Or that.
[09:18] <hrw> kai: omap4 you mean?
[09:18] <kai> I don't actually care about the arch
[09:18] <DanaG> But the key is texture_from_pixmap support.
[09:18] <DanaG> Even an old Radeon 7500 can do that.
[09:19]  * ogra wonders about all the flash babbling ... there *is* and adobe flash for ARM, but you have to sign contracts with adobe to get it 
[09:19] <kai> I just know that compiling samba on my beagle takes two hours, compiling it on my desktop takes two minutes
[09:20] <hrw> ogra: I plan to check maemo flash on beagle running ubuntu
[09:20] <ogra> yeah, thats the one
[09:20] <kai> and I'd like to have the low power consumption of my beagle, _unless_ I actually need the power
[09:20] <hrw> kai: stack few beagles?
[09:21] <DanaG> Ah, they could just say that, on their page...
[09:21] <DanaG> instead of pretending it doesn't exist, say "go to meego or android or whatever"... or such.
[09:21] <ogra> well, if you are $big_company you likely know where to ask at adobe :)
[09:21] <ogra> i dont think they want to make it available to the public in general
[09:22] <DanaG> Damn.
[09:22] <DanaG> If I were to get an ARM netbook, I'd want Ubuntu, quite specifically.
[09:28]  * zyga wants to throw a few cents
[09:29] <DanaG> grreat, and youtube.com also tells me "I need to upgrade my flash player!!!!1one!"
[09:29] <zyga> I worked with one version of flash for arm several years ago
[09:29] <zyga> they had this nice porting layer you'd have to write
[09:29] <zyga> at least at that time flash didn't even care about X existing
[09:30] <zyga> we could plug our own rendering code
[09:30] <zyga> and a/v sink
[09:30] <DanaG> ah, had to "leave html5 beta" and then "join html5 beta".
[09:30] <zyga> and it would more less 'just work'
[09:30] <ogra> DanaG, HTML5 FTW :)
[09:30] <ogra> (ah, you found it already)
[09:31] <DanaG> hmm, it's being dog-slow... but that may partly be due to me running it over ssh. =þ
[09:31] <DanaG> Browser is Chromium.
[09:31] <DanaG> And even scrolling, with no videos, is dog-slow.
[09:32] <DanaG> And even closing tabs is slow.
[09:32] <ogra> you likely need hardware optimization in ffmpeg
[09:33] <DanaG> WebM is also slow on my 64-bit host system, both with fglrx on Linux and with binary driver on Windows.
[09:33] <DanaG> No hardware accel, for now.
[09:34] <hrw> update-initramfs: Generating /boot/initrd.img-2.6.34-3-omap
[09:34] <hrw> Cannot find mtd partition 'Kernel'
[09:34] <hrw> root@beagle:~# cat /proc/mtd
[09:34] <hrw> dev:    size   erasesize  name
[09:34] <hrw> root@beagle:~#
[09:34] <hrw> auch
[09:36] <hrw> which module do I need to load?
[09:37] <DanaG> I'm going to try firefox on ARM.
[09:40] <hrw> ogra: who maintains xserver-xorg-video-omap3? it needs rebuild for newer xserver
[09:42] <kai> hrw: I'd probably have to stack a lot of beagles.
[09:42] <DanaG> Silly hack: http://hackaday.com/2009/02/22/x11-on-android/
[09:42] <ogra> hrw, anyone who likes to touch it :)
[09:42] <DanaG> They used VNC to localhost?
[09:42] <DanaG> Why not just use fbdev?
[09:42] <DanaG> =þ
[09:42] <ogra> hrw, given that i touched it last i'm probably in charge :P
[09:48] <hrw> ogra: any hints for kernel update problem?
[09:49] <DanaG> https://wiki.ubuntu.com/Specs/M/ARMGraphicsStackOnX
[09:49] <DanaG> woot
[09:52]  * DanaG wishes his uefi weren't broken.
[09:54] <DanaG> Specifically, it claims GraphicsOutputProtocol support, but then claims the framebuffer address is zero.
[10:46] <ogra> asac, for CHS i needed to add -D to the sfdisk call to enforce DOS compatibility, that solved all probs
[10:47] <ogra> that apparentlxy leaves a slightly bigger gap at the beginning of the partition to add the bootloader binary
[10:48] <asac> ogra: good.
[10:49] <asac> have you tried on a tiny and big SD card?
[10:49] <hrw> ogra: I said long time ago - check OE script...
[10:49] <hrw> {
[10:49] <hrw> echo ,9,0x0C,*
[10:49] <hrw> echo ,,,-
[10:49] <hrw> } | sfdisk -D -H 255 -S 63 -C $CYLINDERS $DRIVE
[10:50] <ogra> hrw, doesnt help for that use case, but thanks
[10:50] <ogra> this is about repartitioning on the fly with changed CHS values
[10:52] <ogra> (we're using the OE script as a base for building the images, the repartitioning is a lot harder)
[10:53] <hrw> ok
[10:53] <ogra> for example the vfat is trashed afterwards and needs to be reformatted
[10:54] <ogra> intrestingly that doesnt seem to affect any linux partitions, only vfat/fat
[10:58] <asac> i still believe this is not all worth it ;)
[10:58] <asac> write a great media creation script/app -> done ;)
[10:58] <ogra> to late
[10:58] <asac> i know
[10:58] <ogra> its all done and in the infrastructure now
[10:59] <asac> heh
[10:59] <ogra> only flash-kernel changes are pending and a udev rule to hide the boot partition
[10:59] <asac> ogra: is it possible to disable this resizing feature?
[10:59] <ogra> then we should have preinstalled dailies
[10:59] <asac> e.g. can i just use jasper to get the default configs?
[11:00] <ogra> asac, if you have root=UUID=... on the cmdline it wont run
[11:00] <asac> ogra: hmm
[11:00] <asac> ogra: and the settings?
[11:00] <ogra> the settings look for /root/etc/flash-kernel.conf
[11:00] <asac> and oem config etc. thats done outside?
[11:00] <ogra> if that does exist they'll skipp configuration
[11:01] <ogra> oem-config is run after boot
[11:01] <ogra> jasper is run during boot
[11:01] <ogra> they are distinct but jasper depends on oem-config so it gets removed automatically after oem-config was run
[11:01] <asac> what settings are done in jasper? what settings are done in oee-config?
[11:02] <asac> is jasper just doing this resizing?
[11:02] <ogra> nearly all settings are done in oem-config, jasper only enables oem-config and creates the initial fstab ... and to make sure X comes up it sets up loopback networking
[11:02] <ogra> and i'm pondering to add the udev rule for hidint the vfat from jasper_setup
[11:03] <ogra> jasper_growroot is doing the resizing in local-premount, jasper_setup is doing the setup from local-bottom
[11:06] <asac> ogra: i assume jasper also finds the root partition like casper?
[11:06] <asac> or did you hardcode that ;)?
[11:07] <ogra> it only looks at root=
[11:07] <ogra> asac, feel free to look at the code :) there is a MIR pending ;)
[11:08] <asac> ogra: anyone from your team that could help out on MIRs ;)?
[11:08] <ogra> currently its totally bound to the way we build the images
[11:08] <ogra> i'm the only core dev in the team
[11:08] <ogra> and i really cant MIR my own packages :)
[11:09] <asac> its not about jasper, but about the huge backlog
[11:14] <asac> ogra: wow. you used functions in your sh script ;)
[11:14] <ogra> pfft
[11:14] <asac> j/k
[11:15] <ogra> i even plan to add a jasper_functions file to source common functions across the scripts :P
[11:15] <ogra> i.e. i want the root device detection in both scripts ...
[11:15] <ogra> though with the recent kernel changes i shouldnt even need a function for finding root= anymore
[11:16] <ogra> (new kernels will just export cmdline entries completely to initramfs so they are in env vars)
[11:16] <asac> ogra: did you also fix flash-kernel to flash if available and otherwise update first vfat partition?
[11:16] <asac> (for OMAP)
[11:16] <ogra> not yet, thats next on my list
[11:17] <asac> ogra: that cmdline to env stuff was already there in lucid, wasnt it?
[11:17] <ogra> it will check for UBOOT_PART
[11:17] <asac> at least i remember that i could access them there
[11:17] <ogra> no, it wasnt
[11:17] <asac> but could be it was after initram
[11:17] <asac> or was that in casper done manually?
[11:18] <ogra> * [Config] enable passing all kernel command line to init
[11:18] <ogra>     - LP: #586386
[11:18] <ogra>  linux 2.6.35-5.6#
[11:18] <ogra> casper works differently (though a lot of stuff could be dropped with the new kernel feature)
[11:18] <ogra> it exports all that stuff var by var
[11:19] <asac> right. so casper does that on its own. thats what i remember
[11:19] <ogra> (which costs extra time)
[11:19] <ogra> all the cmdline parsing can be dropped with the latest kernel
[11:19] <ogra> which will also help hrw with the automatic serial console setup
[11:19] <asac> ogra: so oem-config is running flash-kernel-installer?
[11:19] <asac> or when is that done?
[11:20] <ogra> upadet-initramfs is running flash-kernel --supported
[11:20] <ogra> if that returns true it runs flash-kernel
[11:20] <ogra> jasper has a trigger to rebuild the initramfs on deinstallation
[11:20] <asac> ah ok and that is at end of removal
[11:20] <asac> kk
[11:20] <ogra> oem-config removes itself and tears jasper out
[11:20] <ogra> since jasper has a hard dep on it
[11:21] <asac> yeah got that
[11:21] <ogra> flash-kernel-*installer* isnt used at all in this setup
[11:21] <ogra> jasper_setup does that part
[11:22] <ogra> (generating an initial boot.scr and creating flash-kernel.conf with the UBOOT_PART variable in it)
[11:23] <ogra> flash-kernel will check if UBOOT_PART is set (it sources flash-kernel.conf by default if it exists) and will then write to NAND or to patition based on that value
[11:23] <ogra> so that the old style is still supported for lucid installs
[11:28] <asac> ogra: i am a bit unhappy with the logic about how uboot images are created and how the boot.scr etc. are done are spread around in the archive
[11:28] <asac> assuming we will do uboot in future ... isnt there some potential to factor that out ?
[11:28] <ogra> uboot images ? in jasper ?
[11:28] <asac> ogra: well you create the boot.scr there ;)
[11:29] <ogra> well, i could just replace root=UUID...
[11:29] <asac> that logic is also in the image builders
[11:29] <asac> yeah. why do you change the UUID?
[11:29] <ogra> effectively i do the same flash-kernel-installer does
[11:29] <ogra> because i want a plain ubuntu install
[11:29] <ogra> ubuntu uses UUIDs
[11:30] <asac> ogra: you could set the UUID in the .img, couldnt you?
[11:30] <ogra> no
[11:30] <asac> why not?
[11:30] <ogra> then every install on the planet would have the same UUID
[11:30] <asac> thats a problem? i dont think so ;)
[11:30] <ogra> it is according to cjwatson
[11:30] <ogra> he asked me to generate a unique one
[11:31] <ogra> which is why i run tune2fs to create a new one and set that in the respective places
[11:31] <ogra> the .img.bz2 doesnt use UUIDs at all
[11:32] <ogra> it just uses root=/dev/mmcblk0p2 on the cmdline
[11:32] <ogra> (which we need to change as soon as we support other setups than omap but thats not part of the current implementation)
[11:33] <ogra> (though the code is ready to be changed if needed)
[11:33] <ogra> (on cdimage.u.c)
[11:35] <ogra> i need to create the boot.scr because i might have to use different load addresses for omap4 and because i want to detect the EDID at some point for setting the best resolution on the cmdline
[11:55] <asac> ogra: so can we do somethning about the une-launcher spec
[11:56] <ogra> asac, not sure yet, currently the user needs to select a different session in gdm
[11:56] <asac> from what i can tell in linaor we could just screw this as we could produce "just" ubiquity ... and "just" efl images
[11:56] <asac> ogra: is that good enough?
[11:56] <ogra> not really
[11:56] <asac> how about the jockey parts?
[11:56] <ogra> i want autodetection
[11:57] <ogra> i havent looked at jockey yet and until all preinstalled SD image parts are implemented i wont have time
[11:57] <ogra> i dont like the idea of chaning ~/.dmrc though
[11:57] <ogra> (/me is generally against fiddling with files in users homedirs)
[11:59] <ogra> oh, i see you targeted lightweight panel for A2 in your spec
[11:59] <ogra> that wont work :)
[11:59] <ogra> we wont get anything from DX before A2
[11:59] <ogra> (which is why lightweight panel is A3)
[15:56] <GrueMaster> ogra: update on yesterday's image testing.  Seemed to work fine on my 16G class 4 card.  Some issues on my 8G class 4 card though.  It didn't actually resize, and instead dumped me down to busybox.
[15:56] <ogra> ugh
[15:56] <ogra> did you save the log ?
[15:57] <GrueMaster> It had the root filesystem mounted under /root, which was odd, and instead of a jasper.log, I had /dev/.initramfs/jasper-tmp/ directory with no logs.
[15:57] <ogra> /dev/.initramfs/jasper-tmp/ is fine
[15:57] <ogra>  /root is the default dir where the rootfs gets mounted in initramfs
[15:58] <ogra> the log should be saved on /root/var/log in this case
[15:58] <GrueMaster> Ok, well it failed shortly after that.
[15:58] <ogra> jasper_setup moves it now
[15:58] <GrueMaster> I will retest today and look.
[15:58] <ogra> great, thanks
[16:00] <GrueMaster> I'm looking at my 8G SD card now (on the desktop) and not seeing a jasper.log.  Will run find.
[16:00] <GrueMaster> nothing.
[16:01] <ogra> weird
[16:02] <GrueMaster> Found one on my 16G device, so it is at least attempting to copy.
[16:02] <ogra> right, thats the default
[16:05] <GrueMaster> As soon as I get setup again here at home, I'll retest some more (coffee first).
[16:07] <ogra> yeah, no hurry
[16:08] <ogra> all bits apart from flash-kernel are ready btw, the only thing we miss is the MIR for jasper
[16:10] <hrw> flash-kernel...
[16:10] <hrw> my bb is unable to update kernel
[16:11] <ogra> hrw, why is that ?
[16:15] <hrw> 10:34 < hrw> update-initramfs: Generating /boot/initrd.img-2.6.34-3-omap
[16:15] <hrw> 10:34 < hrw> Cannot find mtd partition 'Kernel'
[16:15] <hrw> 10:34 < hrw> root@beagle:~# cat /proc/mtd
[16:15] <hrw> 10:34 < hrw> dev:    size   erasesize  name
[16:16] <hrw> no mtd kernel modules loaded
[16:16] <hrw> so flash not deteced
[16:17] <ogra> not an ubuntu kernel
[16:17] <ogra> :P
[16:17] <hrw> it is one of maverick kernels
[16:17] <ogra> its a leftover from lucid ... archive mess
[16:17] <ogra> the omap3 kernel in maverick is a .35 one
[16:18] <ogra> the metapackage was only fixed today to depend on the right kernel
[16:38] <DanaG> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/594382
[16:38] <ubot2> Launchpad bug 594382 in linux (Ubuntu Maverick) (and 1 other project) "Wake up daisy chain activation failed on omap3 (affects: 1) (heat: 8)" [Critical,Fix committed]
[17:06] <amitk> ogra: does Touchbook work with Lucid now?
[17:07] <ogra> amitk, nope
[17:07] <amitk> ogra: kernel features missing?
[17:07] <ogra> amitk, it kind of works with my hand rolled 2.6.32 kernel
[17:07] <ogra> lots
[17:07] <ogra> that "kind of" is, its not charging the battery
[17:08] <amitk> ogra: ok, are there bugs for it?
[17:08] <ogra> and there is no sound support, everything else with that kernel works
[17:08] <ogra> only one
[17:08] <ogra> amitk, and i really doubt we want to break the rest of omap3 for supporting touchbook
[17:08] <ogra> Bug 581771
[17:08] <ubot2> Launchpad bug 581771 in linux-ti-omap (Ubuntu) "omap3 dss2 touchbook patch missing in lucid kernel (affects: 1) (heat: 97)" [Undecided,New] https://launchpad.net/bugs/581771
[17:09] <amitk> ogra: agreed, I'm checking with you to see if it would be feasible to support it in maverick
[17:09] <ogra> there are a lot more patches missing, some of them are very intrusive and will likely break other omap3 HW
[17:09] <amitk> but it looks like it will require non-mainlined patches to be applied
[17:09] <ogra> right
[17:10] <ogra> and even outdated ones
[17:10] <ogra> i dont think anything has been ported to anything beyond .33 or .34
[17:10] <amitk> ok, thanks
[17:11] <ogra> amitk, if we could get the DSS2 patch in without breaking anything that would surely help a bit so people can debug etc without having to solder
[17:12] <rsavoye> I thought the Touchbook was a repackaged Beagle board
[17:12] <ogra> it roughly is
[17:12] <amitk> ogra: hopefully mpoirier, cooloney or lag will get to that bug 581771
[17:12] <ubot2> Launchpad bug 581771 in linux-ti-omap (Ubuntu) "omap3 dss2 touchbook patch missing in lucid kernel (affects: 1) (heat: 97)" [Undecided,New] https://launchpad.net/bugs/581771
[17:12] <ogra> emphasis on roughly :)
[17:13] <ogra> rsavoye, its a newly layed out SoC *based* on the beagle
[17:14] <rsavoye> I was looking at one also... so it'd be nice if it worked :-)
[17:14] <ogra> well, most of the important patches arent upstreamed
[17:14] <rsavoye> are they in maverick though ? That's what I'd be running on it
[17:15] <ogra> they arent
[17:15] <ogra> maverick uses mainline 2.6.35 for omap3
[17:15] <rsavoye> hum... bummer
[17:15] <ogra> the touchbook patches are a) older and b) not mainlined
[17:15] <ogra> the generic defconfig is in and the basic support but you wont i.e. have any display support
[17:16] <ogra> (which means you need to solder an RS232 port for it since it doesnt have one)
[17:16] <rsavoye> been there, done that... :-)
[17:16] <rsavoye> but sounds useless for any development
[17:16] <ogra> right, but thats not really the ubuntu philosopy :)
[17:17] <ogra> it should just work :)
[17:17] <ogra> if i find the time i'll provide hand-rolled images with a handmade custom kernel for maverick
[17:17] <ogra> since i want to use it too ...
[17:17] <rsavoye> I assume the Beagle board is the standard for ubuntu development then
[17:18] <ogra> beagle or the upcoming panda
[17:18] <rsavoye> ah, so if I did buy one, there'd be some support ? :-)
[17:18] <rsavoye> I thought the Panda wasn't shipping yet
[17:18] <prpplague> it isn't
[17:18] <ogra> its not but ubuntu will run on it once it is :)
[17:19]  * ogra will provide the first manually rolled panda images tomorrow btw 
[17:19] <ogra> in case anyone is intrested, watch this space :)
[17:19] <prpplague> ogra: dandy
[17:21] <rsavoye> so even with your patches, there is no working display with the touchbook ?
[17:36] <ogra> rsavoye, the kernel i rolled myself from the touchbook tgz for 2.6.32 has nearly everything working but battery charging ...
[17:36] <ogra> and sound
[17:37] <rsavoye> I can live without sound, but I think charging the battery is a good idea...
[17:37] <ojn> just buy a new one
[17:39] <ogra> rsavoye, http://dl.free.fr/getfile.pl?file=/0mYeCOWC is the download link for their tgz
[17:40] <ogra> if you have the official angstrom image from their site you can charge under angstrom, then replace the SD and reboot to ubuntu, it actually survives 10h on one charge
[17:41] <ogra> its just that you have to reboot and replace the SD every time to charge
[17:41] <rsavoye> 10h ? nice!
[17:41] <rsavoye> although swapping SD cards isn't too bad for the time being
[17:41] <ogra> well, the SD is inside the case :)
[17:42] <rsavoye> oh, ouch...
[17:42] <ogra> you have to rip it apart every time
[17:42] <ogra> its not to hard to take apart (no screws or anything) but its annoying
[17:44] <rsavoye> sounds like it'd be good to keep it plugged in :-)
[17:44] <ogra> well, doesnt help
[17:44] <rsavoye> it doesn't run on AC ?
[17:44] <ogra> it always pulls power through the battery
[17:45] <ogra> at least it seem like, it might work on AC if the driver for the power regulating chip works
[17:46] <ogra> if you use their shipped image it should be fine though, but you are stuck at 2.6.29 with that and they have a very very weird image setup (everything is a squashfs/aufs, no idea why)
[17:46] <DanaG> Too bad the standard beagleboard didn't have the connectors in place already, for batteries.
[17:47] <rsavoye> ogra: so it runs 10,04 but with an older kernel ?
[17:47] <ogra> no
[17:47] <ogra> unless you build your own kernel it will miss features
[17:47] <rsavoye> ah...
[17:47] <ogra> their image is based on 9.10
[17:48] <ogra> i didnt manage to boot 10.04 with their kernel, upstart needs some features that entered after .29
[17:48] <ogra> i wish they would properly upstream their patches, then it wouldnt be any prob
[17:50] <ogra> anyway, out for today ...
[17:51]  * ogra has to do his national duty and watch a soccer game on tv tonight ... and i'm out of beer !
[18:07] <prpplague> ogra: out of beer? what kind of human are you? that is just plain disgusting
[18:08] <GrueMaster> ogra: I'll fie a bug and assign you ownership.
[18:08] <GrueMaster> s/fie/file
[18:12] <DanaG> say, anyone know when there'll be pics of this "Panda"?
[18:12] <DanaG> Or at least a list of specs?
[18:20] <asac> ogra: did you ever get your alwaysinnovation touchsmartbook thing enabled?
[18:43] <ogra_cmpc> asac, see backlog :P
[18:43] <ogra_cmpc> asac, we talked about it for 1h
[18:44] <ogra_cmpc> prpplague, fixed :)
[18:45] <GrueMaster> ogra_cmpc: any idea on how to debug this issue I am seeing?  I have the 8G SD booting, jasper appears to work fine (found the log), but the system stops after mounting mmc0p2 on /root.
[18:45] <prpplague> ogra_cmpc: what is fixed?
[18:45] <ogra_cmpc> prpplague, the out of beer issue
[18:45] <prpplague> DanaG: http://fc01.deviantart.net/fs31/f/2008/201/1/5/Panda_Board_by_elanamullaly.jpg
[18:45] <prpplague> ogra_cmpc: ahh
[18:46] <ogra_cmpc> GrueMaster, not really, so it resizes properly and also creates fstab etc ?
[18:46] <GrueMaster> Yes
[18:46] <ogra_cmpc> hmm
[18:47] <ogra_cmpc> it should just move on, is it possible thats the MMC issue from before ?
[18:47] <ogra_cmpc> (note that my images still use the .34 kernel)
[18:47] <GrueMaster> No, the mmc issue would appear in dmesg, and the filesystem would be corrupt.
[18:47] <GrueMaster> I'm aware of that.
[18:48] <ogra_cmpc> no idea from the top of my head
[18:48] <GrueMaster> Lian is building me a new .35 kernel with the daisy chain fix.
[18:48] <ogra_cmpc> if /root is mounted and fstab is created in /root/etc/ there is no reason it should stop
[18:49] <ogra_cmpc> yeah, i know
[18:49] <GrueMaster> It doesn't happen on my 16G SD card.  Both are Kingston, class 4 SDHC cards.
[18:49] <ogra_cmpc> that kernel isnt there yet though, i'll switch the image once its available
[18:49] <ogra_cmpc> i only have kingston microSD 4G ones, i'll test with one tomorrowq
[18:49] <GrueMaster> No, i meant lian is building me a test kernel now.  It will be uploaded to the pool on Friday.
[18:50] <ogra_cmpc> ah
[18:52] <GrueMaster> I'll continue smacking it around here.  Have to regenerate the boot.scr & add serial console output and some other modifications.
[18:52] <ogra_cmpc> heh, prpplague thats a cute panda
[18:52] <ogra_cmpc> GrueMaster, then oem-config will break
[18:53] <prpplague> ogra_cmpc: actually i have no clue the site is blocked from inside TI, i think avr500 posted that
[18:53] <GrueMaster> It has worked fine when I add console=ttyS2,115200 console=tty1
[18:53] <ogra_cmpc> GrueMaster, input doesnt work iirc
[18:53] <prpplague> DanaG: seriously though. i don't think are going to release specs and pics for a few more months
[18:53] <GrueMaster> it does when you list a local console as well.
[18:53] <ogra_cmpc> oh, i thought you wanted to run it completely on serial
[18:54] <GrueMaster> besides, I am not even getting that far yet.  It dumps me at a busybox shell.
[18:55] <ogra_cmpc> drop quiet from the cmdline
[18:55] <ogra_cmpc> hmm, did i even set that ?
[18:55] <GrueMaster> No it isn't set.
[18:55] <ogra_cmpc> right
[18:56] <ogra_cmpc> and it spills no error to the console ?
[18:56] <ogra_cmpc> i think you can set some debug value on the cmdline that will spit out more info from the initramfs scripts
[18:56] <GrueMaster> No errors (yet).
[18:56] <GrueMaster> brb
[18:57] <ogra_cmpc> i'll also add more logging to jasper_setup, currently the second script doesnt log at all
[18:57]  * ogra_cmpc will do that tomorrow first thing
[19:01] <GrueMaster> second script?
[19:01] <ogra_cmpc> jasper_serup
[19:01] <ogra_cmpc> *setup
[19:02] <ogra_cmpc> first script is jasper_growroot living in scripts/local-premount
[19:02] <ogra_cmpc> second script is jasper_setup living in scripts/local-bottom
[19:02] <GrueMaster> found it.  I'll tear it apart and see if it is havng issues.
[19:03] <ogra_cmpc> would be weird if it had and wouldnt have on the other SD
[19:03] <ogra_cmpc> i could understand if the first script had issues because of different cards but the second one that only moves data around and creates files
[19:04] <GrueMaster> I'm wondering if the remount line is actually working.
[19:05] <ogra_cmpc> it works here
[19:05] <GrueMaster> no, that isn't it.
[19:05] <ogra_cmpc> (and apparently on your other card)
[19:05] <GrueMaster> Thinking out loud.
[19:05] <ogra_cmpc> yeah, good thing
[19:05] <ogra_cmpc> but if the remount wouldnt work you would still boot
[19:05] <ogra_cmpc> the stuff done by the second script isnt essential for moving on
[19:07] <ogra_cmpc> only for rebooting (boot.scr) but it should still move without fstab and /etc/network/interfaces
[19:14] <asac> ogra_cmpc: cheers (/me goes for lagavulin for the game ;))
[19:14] <ogra_cmpc> heh
[19:16] <GrueMaster> very odd.  Rebooting now brings up oem-config.  Something is not going through in the first boot.  Will continue investigating.  Enjoy the game & beer.
[19:16] <ogra_cmpc> will do (starts in 15)
[19:17] <ogra_cmpc> US and england already made it today
[19:47] <armin76> asac: vuvuzela!
[19:48] <DanaG> latest xkcd is fun.
[23:54] <GrueMaster> mpoirier: ping
[23:55] <mpoirier> yes.
[23:55] <mpoirier> GrueMaster: ping
[23:55] <GrueMaster> have you tested the kernel after making the daidy chain fix?
[23:56] <mpoirier> the temporary fix, yes.
[23:56] <GrueMaster> Did you get video out?
[23:56] <mpoirier> ha....
[23:56] <mpoirier> that is another issue.
[23:56] <GrueMaster> I'm getting the following errors on boot:[    2.054840] omapfb omapfb: no displays
[23:56] <GrueMaster> [    2.058654] omapfb omapfb: failed to setup omapfb
[23:56] <GrueMaster> [    2.063476] omapfb: probe of omapfb failed with error -22
[23:56] <mpoirier> plymouth core dumps...
[23:56] <mpoirier> yes indeed.
[23:57] <GrueMaster> No, they should be unrelated.  I get those on .34 as well.
[23:57] <mpoirier> not related to daisy chain - was there since I joined the company.
[23:57] <GrueMaster> Understood.
[23:57] <mpoirier> yes, indeed.