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