=== pcacjr_ is now known as pcacjr === lilstevie|ZNC is now known as lilstevie [02:25] http://www.slashgear.com/pandaboard-offers-ti-cortex-a9-omap4-to-imaginative-devs-04105681/ [02:25] Spiffy. [02:25] So the Pandaboard is really close. [02:28] Though, it looks like form-factor may be just different enough to make it incompatible with Beagle expansion boards. [02:28] http://pandaboard.org/ is already taking developer applications... [02:29] Is the "retail availability" date still NDA? [02:30] No idea :) [02:30] As a result, I believe the answer is probably "Yes", because otherwise I would expect to have heard something. [02:37] That's a good answer. === asac_ is now known as asac === JaMa|Zzzz is now known as JaMa === amitk-afk is now known as amitk === hrw|gone is now known as hrw [08:30] moin === vstehle_ is now known as vstehle-laptop [10:22] ogra: hey! [10:22] so release is up, finally! [10:28] :D [10:29] Are you please with it ndec? [10:29] celebreate! [10:29] lag: well extremely! [10:29] ndec: I'm pleased you're pleased :) [10:29] lag: it's been a really cool project to work with! [10:29] ndec: So what's next? [10:29] For sure [10:29] lag: natty ;-) [10:29] I've enjoyed it [10:29] Whoooooooo :) [10:29] lag: well, next step is to release our public PPA [10:30] For sure [10:31] Are we going to be supporting any more boards? [10:32] not that I know of [10:32] zumbi_: celebrate! [10:32] then you can support another distro :D [10:33] armin76: :-o [10:33] There's only need for one distro :) [10:34] yeah, and 640k ought to be enough for anyone ;) [10:35] armin76: ;-) [10:36] :) === lilstevie is now known as lilstevie|ZNC === ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | wanna cross build ? see http://idlethread.blogspot.com/2010/09/cross-compilation-redux.html | Maverick is out ! http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/ [10:59] :) [11:00] Why point at cdimage rather than releases? [11:01] persia, because thats where our release lives ? [11:01] show me the url on r.u.c and i'll point to it [11:02] You're right. [11:02] That's a regression. [11:03] We were on releases.ubuntu.com for karmic and lucid [11:04] * ogra doesnt see it as a regression, butu yeah [11:04] Well, it indicates we weren't considered part of the release. Maybe just a social thing. [11:05] * hrw agrees with persia [11:05] armel looks like 3rdparty in ubunt [11:05] u [11:05] Anyway, something to target to be fixed in Natty. [11:05] hrw, It's most certainly nothing like 3rd party. [11:05] but totally outside of official archive [11:06] No. Just not blessed with release. [11:06] persia: but also ports.ubuntu.com for last few years instead of merging to archive.ubuntu.com [11:07] * hrw hugs apt-cacher-ng [11:07] That's mostly blocked by some technical limitations of our mirror software, sadly. [11:07] hmm, https://wiki.ubuntu.com/MaverickMeerkat/ReleaseManifest agrees with you [11:07] i dont think there is code in place to put them on releases.u.c :( [11:07] Yep. Go complain to skaet. [11:08] There is code to move from ports/daily{,-live} but maybe not daily-preinstalled. [11:08] right [11:09] though i really wouldnt mind keeping them on cdimage [11:10] simply because it's super confusing having them in the same page with all the other images [11:10] (and their install instructions) [11:12] ogra, See, the way to solve that is to make them have the *same* installation instructions :) [11:12] thats not possible [11:12] * persia grumbles at git for being painfully slow and bloated (why download 1GB of stuff for 80MB of data?) [11:12] Yes it is. Just requires more work, and more time. [11:12] then the install isntructions get confusing [11:13] you just move the problem around [11:13] I believe the only remaining obstacles are 1) getting everyone to accept a common first-stage bootloader (e.g. UEFI), 2) porting grub2, and 3) ensuring there is *some* flash on every board to hold a vendor-installed first-stage bootloader. [11:14] This is much better than we were two years ago. I predict we'll be done in only 5 or 6 more. [11:14] you are making weird assumptions about HW manufacturers [11:14] Why? For x86/powerpc the vendors all meet those requirements already. It's kinda expected for consumer-level general-purpose devices. [11:15] there is no flash on any of the publically available boards we support except the beagle C4 which is underpowered for these images [11:15] So? [11:15] That's deficient HW. [11:15] there is neither grub but a properly usable u-boot [11:15] Right, hence point 2) above. [11:15] which i disagree with [11:15] why? [11:16] as well as with the other points [11:16] we have a properly unified bootloader with u-boot [11:16] its just missing framebuffer support [11:16] Do you not think it makes sense to have first-stage bootloaders managed by folks to do boards (for board-bring-up), and second-stage bootloaders managed by folks that do OSs (for OS bring up)? [11:16] Everyone else is doing it. [11:17] i do ... but thats what we have effectively with x-loader and u-boot [11:17] Why be different ? Multiple code paths are harder to maintain. [11:17] we dont have to maintain them [11:17] If you like x-loader, fine, but x-loader/grub2 is more cleanly aligned. [11:17] no, its not [11:18] Plus, I think it's easier to use the existing ARM port of UEFI than to port x-loader to everything else. [11:18] simply because everyone working with these boards has u-boot experience [11:18] the only missing bit is framebuffer support so the general enduser could get a menu [11:18] So? Training is easy. [11:18] * suihkulokki thinks u-boot has way more momentum than uefi [11:19] ++ [11:19] or grub porting (which hasnt even started) [11:19] and making the boards more expensive by adding NAND doesnt look like a good solution either [11:20] suihkulokki, Could be: I've seen ports to about the same number of architectures for u-boot and UEFI. I don't really care which is selected, but would prefer there to be one-true-first-stage-bootloader [11:20] I think that arm boards should go for one simple setup: vendorbootloader + osbootloader. thats done on x86(-64) and works on arm so far with targets which we support [11:20] forget about grub/arm [11:20] hrw, Precisely. [11:20] Huh? Which osbootloader then? Why not use the same as everyone else? [11:20] persia: we do have it with omap34 - xloader + uboot [11:21] u8500/linaro also goes that way: something-from-stericsson + uboot [11:21] atmel at91 (armv5): at91bootstrap + uboot [11:22] at9200rm: simple-in-cpu-flash-bootloader + uboot [11:23] bleh! Standardising on uboot would be fine. Standardising on it as a *second-stage* bootloader just seems like madness, when it can do first-stage just fine, and it can't do useful device-selection. [11:23] persia: *if* uboot can be 1st stage then let it be. on *rest* let it be 2nd [11:24] persia: atmel at91bootstrap fits inside of cpu flash. you cant get uboot there [11:24] uboot needs a fair bit of work from what I've seen to allow user selection of boot devices, etc. [11:24] hrw, That's a HW bug :) [11:25] u-boot is to big for fitting in the ram you have available at that stage of boot [11:25] you *need* a smaller first stage [11:25] indeed it could be derived from the u-boot code [11:26] (as x-loader already is) [11:26] And has been in several cases. [11:26] So sure, maybe I don't actually care that much about standardisation for hwbootloader. [11:26] i agree that this should be fixed [11:26] and i know linaro is working on that at least for omap [11:26] I still want the *same* osbootloader for every architecture, and think having a single shared hwbootloader would lead to economies of scale. [11:27] persia: so port uboot for basic x86 [11:27] you wont get that without the vendors agreeing [11:27] persia: most of PC are fine with legacy bios + grub. you cant get grub outside of x86 anyway [11:27] hrw, It's been done for a while. [11:27] and you cant get PC users with uboot [11:28] Hrm? grub2/powerpc is reputed to work. [11:28] o.. did not know [11:28] And u-boot claims to support PPC, ARM, AVR32, x86, M68k, ... [11:28] * hrw moved to coreboot on one machine at home [11:28] persia: sure. very few x86 chipsets probably [11:29] Oh, I'm sure. probably mostly VIA ones, for that matter. [11:29] and they do not boot windows anymore? [11:29] I still maintain there is scope for economies of scale to have one true hwbootloader, and one true osbootloader. [11:29] I wouldn't expect it for the lower-end VIA embedded x86 cores. [11:30] persia: 5 years and EFI will be x86 desktop standard maybe [11:30] Most of them can't run current Ubuntu (insufficient instruction support) [11:30] * hrw hugs alix.1c with its 2.098s to get init booted from power on [11:35] persia, oh, btw, i fail to see how that bootloader discussion solves the initial problem of having different methods to write differnt install media [11:35] ogra, Identical OSbootloader means one can use identical procedures cross-arch. [11:35] i still need to write to different media with different tools [11:35] As a result the means by which I make bootable SD for armel is the *same* as for bootable SD for i386. [11:36] Which means the same instructions, etc. [11:36] so you run brasero to create an SD card ? [11:36] No. I use usb-creator. [11:36] (or at least I did last time I tried that for amd64) [11:36] persia: does any of your pc boots stright from SD? [11:37] right, on armel you cant even start it :P [11:37] hrw, At least two of them can. I thikn a third, but haven't tested it. [11:37] its not installable due to its dep on syslinux [11:37] persia: and by default you need to press some key during reboot to invoke boot menu and select "this SD please" in it [11:37] ogra, Right. See, that's a bug in usb-creator: should use grub2: see discussion with superm1 and Bugabundo in -devel whilst you were sleeping. [11:38] i wasnt sleeping :) [11:38] and i followed it roughly while my ac100 kernels were building [11:38] hrw, Actually, no, on one of them it tries SD by default (as I discovered when forgetting to remove the SD when trying to reboot, and being confused why it failed) [11:41] ogra, Ah, excellent! Still, like I said, we're years away. Even if everyone in the world attempted to start achieving it right now, I don't think it's *possible* to have clean alignment in less than 3 years because of chip layout planning timeframes. [11:42] yup [11:43] and given that work on devicetree is already going on in kernel and u-boot i expect that to arrive earlier as a unified arm solution [11:43] persia: my desktop can boot from sata/pata/usb/cf/sd/sm/ms/xd but for non-sata I need to go to bootmenu, for pata even to bios [11:43] ogra: 11.10 not earlier [11:43] hrw, That's just a side-effect of your hwbootloader. If there was the alignment and consensus on a single hwbootloader like I'm advocating, we'd be having a comparable experience. [11:44] ogra: for Linaro 11.05 DeviceTree will not be ready yet [11:44] hrw, i dont exepct d-t in less than a year [11:45] buut thats still quicker than persias estimated 3 years for grub [11:46] 3 years isn't for grub. It's to fix on-chip ROM codes to not be braindead about what to use to boot hwbootloaders. [11:46] And 3 years is a lower-bound estimate, really. [11:47] (as in, if someone decided to start fixing this today, it would take 3 years for the *first* SoC that wasn't broken to be released) [11:59] Assuming I don't have kernel issues, are there issues expected with do-release-upgrade from jaunty->karmic->lucid->maverick for armel? [12:05] win go #linaro [12:05] win go #linaro [12:13] I can feel a new Bootloader coming ... Supports all architectures, all bios', all OS': persia-boot [12:18] lag, That is a frightening concept. The moreso since I tend to write most stuff in make, which is probably not an ideal language for bootloader development. [12:19] persia: :) [12:19] persia: I can teach you C - it's a small language [12:23] thanks, but I've been taught C a few times: I just haven't used it professionally in something like 15 years, amd my hobby C has all been small patches. === zyga is now known as zyga-lunch [12:33] * ogra sighs ... [12:34] 3800 mails done, 1400 mails to go [12:35] releases are fun :) [12:36] ogra: Are you back home? [12:36] lag, yes [12:36] wading through my mail since two days [12:37] I spoke with ndec this morning - he sounded happy with the release :) [12:37] on the road i only read what was directly affecting the current work [12:37] lag, yes, he told me already [12:37] lag, we still need to solve the sound issue and i need to get the tablet going [12:37] thats the twoi last bits on my TODO for maverick [12:38] Sounds == userspace (last I heard) [12:38] oh, and bug 657732 is an intresting one ... i could reproduce it on the tegra [12:38] Launchpad bug 657732 in xaos (Ubuntu) "xaos has artefacts on first frame with -threads (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/657732 [12:38] sound* [12:38] lag, not clear yet [12:39] lag, there seem to be initialization bits missing but its not clear where [12:39] to me it looks like the driver needs the init after the mixers were set [12:39] which would be a clear driver issue [12:39] Quite [12:40] but it could as well be a race in alsa userspace [12:40] thats why its so hard to pin down [12:40] I believe Mathieu has been liaising with various kernel and TI people to have this issue solved [12:41] rama from TI (the omap4 ASoC driver dev) was working directly with lrg on the issue but there was no outcome yet [12:41] Well if they can't fix it, then we have an issue [12:42] they still try i belive [12:42] lrg wrote most of ASoC [12:42] i know [12:42] He would be 'the one' AFAIC [12:42] and rama most of the omap4 driver ... and he worked on the HW too [12:42] Then we have the best people 'on it' [12:43] no [12:43] ? [12:43] because nobody seems to have deep insight in the ubuntu specifics of alsa [12:43] What if we lent diwic to them? [12:43] as i understand it alsactl restore is supposed to do the same as alsactl init for example [12:44] but that either doesnt happen or happens in the wrong order for the device [12:44] lag, how much does he know about the userspace ? [12:44] He is Ubuntu's Audio guy [12:44] the prob with alsa is that the line between kernel and userspace is really blurry in ubuntu [12:45] I think that is the case with ALSA generally [12:45] there are many bits expected by the driver that imho should be in userspace [12:45] but alsa generally doesnt depend on i.e. pulse to set all mixers :) [12:45] at least in the rest of the world === zyga-lunch is now known as zyga [12:45] diwic is afk, but I'll hassle him later [12:45] hi [12:46] lag, ok, i'll try to get rama on IRC (dont know his nick, i need to find out if TX gets up) [12:46] Where is lrg? [12:47] TX? [12:47] lag: UK [12:47] BANG! [12:47] no idea, i know he uses to live in the UK [12:47] Hello Liam [12:47] ogra: my panda is very ill [12:47] heh [12:47] hey [12:47] lrg, still ? :( [12:47] sh*t [12:47] ogra: hw issue :( [12:47] so I'm using SDP now [12:47] Hey Lag [12:47] should be fine as well [12:48] Where in the UK are you? [12:48] lrg, any idea about the issue ? [12:48] lag: just north of Edinburgh [12:48] Just over the bridge? [12:48] ogra: afaict the USB hub is a bit broken [12:48] :) [12:48] lag: yes [12:48] lrg, i meant the sound issue with the SDP4430.conf :) [12:50] That's a nice area [12:50] ogra: ah, I'm just starting to look now that I have 10.10 running on the SDP, although ubiquity kept crashing for me so I had to do some manual hacks to setup a user account etc [12:50] Do you know Queen's Ferry? [12:50] Do you know Queensferry? [12:50] lag: that would either North or South, there is no such town named on its own [12:50] lrg, kept crashing ? how ? [12:50] lag: Yes, very close :) === XorA|gone is now known as XorA [12:51] That's a scary little place if you're not a 'local' :) [12:51] lag: Im going to assume from your IP your in Bristol or South Gloucestershire :-) [12:52] Bristol [12:52] ogra: it would crash after 30secs in the help pages [12:52] hrm [12:52] with the final release ? [12:52] Where are you XorA? [12:52] no, a few days ago [12:52] i know it works for TI Nice who have tested it [12:52] ah [12:52] lag: Edinburgh, but I used to work in Aztech West many years ago [12:52] @ST? [12:52] lag: yes [12:53] I have a few friends there [12:53] 1999-2000 [12:53] They didn't work there then :) [12:53] ogra, lag: going for lunch now - will be back shortly [12:53] k [12:53] worked on the disastrous project for ST GFX card [12:53] Sure [12:54] I believe they've had a couple [13:12] ogra: It looks like diwic specialises in userspace :) [13:13] awesome [13:13] I will speak to the chain and see if we can free him up [13:16] Hi diwic [13:16] Thanks for joining [13:16] np [13:16] ogra: ping [13:16] yes, i'm here :) [13:17] diwic: We have some rather taxing issues with regards to audio on the Panda [13:17] We have two kernel audio experts on the case [13:17] But we are lacking in userspace knowledge [13:18] okay [13:18] Can we set up some kind of brain storming session when lrg is back and rama is available [13:19] ogra: diwic: ? [13:19] Would you be up for that? [13:19] sure, at what time approx? [13:20] That would depend [13:20] ogra: Where in the world is rama? [13:20] TX [13:20] So it would be afternoon [13:20] yeah [13:20] lrg is at lunch currently [13:20] My work day is up in ~ 3 hours [13:20] and i need to get him to IRC first :) [13:20] Sure [13:21] If we can't do it today, I'll set a meeting up and we'll do it later in the week (perhaps tomorrow) [13:22] ogra: Do you have his contact details? [13:22] no [13:22] Okay, we'll hunt those down [13:22] Then speak to lrg [13:22] right [13:22] diwic: I'll let you know more as soon as I do [13:22] diwic: Thanks for your time [13:22] he knows them for sure [13:22] We'll get them one way or other [13:23] robclark will probably know them too [13:23] lag, okay. For today I can't be online when my work day is up, but tuesday or wednesday might work better, if time zones are a problem [13:23] diwic: No problem - we'll work something out [13:26] hello, when porting linux to arm, I add printascii("bara bara\n"); in start_kernel. It print other string, and then trap into abort. What wrong? [13:33] cjjnjust: When you say it prints another string, what do you mean? [13:35] i mean it print the other strings. the string is define in other place. [13:35] You mean it prints out other strings successfully? [13:35] It's just yours that it does not? [13:36] lag, the string is in other function, it seems like address error [13:36] That's probably what it is then [13:37] Check in: arch/arm/kernel/head.S [13:37] yes, I have check it again and again... [13:38] once call a function with args, it will trap into abort mode. [13:39] but it can run to start_kernel, when printk("%s",linux_banner); it go to abort mode. [13:43] cjjnjust: Which kernel are you using? And which Arm chip are you trying to use? [13:44] lag,2.6.35 s3c2410 [13:46] The s3c2410 is already supported [13:48] arch/arm/configs/s3c2410_defconfig [13:48] I know that . [13:48] Then why port it? [13:49] lag: ogra: can you please invite me to your audio brainstorming too? [13:49] berco: Of course [13:49] I just want to add some driver on it . [13:50] use the default config can't work. [13:50] You can use it as a base [13:51] Then edit it [13:51] All of the bring-up and debugging (including earlyprintk) code as already been implemented [13:52] All of the addressing setup code too [13:53] In fact, I just do what you say. [13:54] * ogra_ac dances ... [13:54] got an ubuntuized kernel for the ac100 [13:54] cjjnjust: Failing that, take a look at this: http://stackoverflow.com/questions/1359919/arm-data-abort-error-exception-debugging [13:55] Will enable you to dump the stack and see where it's going wrong [13:55] ogra_ac: Congrats ... booting? [13:55] lag, sure, its the toshiba source but with ubuntu config [13:56] (still 2.6.29 indeed) [13:56] but all the android crap is gone, i have swp and all modules i can imagine [13:56] So long as you're enjoying yourself :) [13:56] i|ll test later what mavericks udev thinks about it :) [13:57] s/swp/swap [13:57] I knew what you meant [13:57] lag, well, i have a netbook on which i can do ubuntu arm development, what more would a human need :) [13:57] thanks [13:58] lag, compiling the omap4 kernel package takes just 2h here [13:58] (on external USB disk) [13:58] cjjnjust: No problem - best of luck [13:59] ogra: Here being? [13:59] on the ac100 [13:59] It only takes me 15mins :) [13:59] thats a third of what the buildds take [14:00] and 30min less than on the panda [14:00] quite impressive imho [14:04] wow, hows that? tegra and panda should be same speed, no? [14:05] similar [14:05] but 30mins is a lot [14:17] ogra_ac: you should be fine with udev: http://paste.ubuntu.com/510877/ [14:17] minimum is 2.6.27 [14:17] ogra_ac: with usb on omap4 it takes less than 2 hours [14:18] something around 1:50 minutes [14:18] with the new mem speed ? [14:18] but this I got when testing with 1gb [14:19] ogra_ac: on panda with usb disk, I built kernel (just running 'make uImage') in ~35 min.. [14:19] ogra_ac: I have the timing with new mem speed, just need to boot my board [14:19] robclark, ubuntu package ... [14:19] ahh.. I didn't try that [14:19] robclark: so, how is it going with usb disk? [14:19] robclark, i build zImage for the tegra in about the same time [14:20] but on MMC card it was ~1hr.. and with USB disk ~35min (for make uImage) [14:20] * rsalveti is setting up all the boards again [15:00] bug 657281 [15:00] Launchpad bug 657281 in ubuntu "Kubuntu Maverick on Omap3 & Omap4: screen goes black and never comes back (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/657281 [15:11] lag, any news on the brainstorming meeting? I'll have to go in an hour. [15:11] No sorry [15:11] lrg: Are you around? [15:11] diwic: I can't see it happening today [15:12] I'll try and sort something out for another day [15:12] XorA: Are you in the same place as lrg? [15:13] lrg, isn't that Liam? I think he knows ALSA userspace better than I :-) [15:13] lag: he is the wrong side of the river [15:13] Ah, do you both work from home? [15:14] diwic, but not the ubuntu specifics about it i guess [15:14] i think our setup has a lot of specialities [15:15] lag: I'm here, diwic lets do this tomorrow as I'm seeing some funny things with our mixers that could cause config to fail [15:15] \o/ [15:15] someone with a clue [15:15] YAY ! [15:15] lrg, aren't you the one designing the use case manager? [15:15] I need to get the mixer thing sorted out and then I should have a better idea whats going on with the config [15:16] diwic: yes, ucm is in perex ucm branch - he's made some changes and I need him to push to master..... [15:17] lrg, so then you probably know alsa userspace as well as I, but I don't mind participating in a brainstorming, if not lrg's mixer fixes is what we need. [15:18] lrg: Do you have Rama's contact details? [15:18] lrg: Is it worth pulling him in? [15:20] lag: yes, rsrimushnam@ti.com [15:20] Okay, I'll send out an email [15:20] lag: Rama is in Dallas so he's probably around atm [15:20] How does 15:00 UTC grab everyone? [15:20] Tomorrow [15:20] and he does have a working pandaboard [15:20] Or Wednesday [15:21] lag: most times are fine for me, Rama has more meetings though [15:21] best find a time suitable for Rama andI'll join [15:21] I'll email him and try to get him on here [15:21] works for me, but 14:00 UTC would be even better. [15:22] is this day a some kind of a holiday in North America? [15:23]