=== dl9pf_ is now known as dl9pf === JaMa|Zzzz is now known as JaMa === rtp_ is now known as rtp === ynezz_ is now known as ynezz === hrw|gone is now known as hrw === jamie_ is now known as JamieBennett === the_eye_ is now known as dimitris === JaMa is now known as JaMa|Off === hrw is now known as hrw|gone [18:44] asac: whats the status of db-4.8 failure with thumb2? [18:44] did you fix it? [20:30] hello [20:34] armin76: it appears to be fixed [20:37] What is the best approach for debugging Ubuntu startup issues? upstart starts, but hangs somewhere during boot. "--verbose" doesn't reveal anything [20:38] I suspect some missing kernel feature. The kernel is cross compiled because I don't have a running target system running yet. [20:38] nosse1: what SoC? [20:38] AM3517 [20:39] * prpplague wants to play with AM3517 [20:39] I am capable of injecting "init=/bin/bash" and thus start upstart manually from the prompt, but it doesn't help [20:46] How do you guys do the initial bringup of Ubuntu on some target? [20:46] JTAG debugger? [20:47] Martyn: got audio working on the tegra? [20:47] nosse1: what do you mean initial? boot loader? kernel? [20:48] I've got boot loader and I've got a (cross compiled) kernel, so that's fine. [20:48] The thing is I've created a rootstock image which I'm trying to boot on (or perhaps more correctly "root" on) [20:49] cool, so I guess that you can work to the other steps just booting the kernel and debugging by uart connection [20:49] armin76 : No, since it's not relevant to using ARM as a server [20:49] But I can't build a kernel natively for the target as I don't have a target system running with Ubuntu [20:49] I'm even working on disabling video, and getting back the 64MB that steals [20:49] nosse1: so, are you able to mount the filesystem and start the init stuff? [20:49] armin76 : What Im dissapointed in, though, is that the tegra2 PCIe suffers from a deadlock [20:49] Yes. It hangs sometime after upstart and before terminal login [20:49] armin76 : So I can't use the PCIe interface [20:50] nosse1: oh, ok, so you basically need to debug the upstart scripts [20:50] Martyn: why as a server? don't like it for tablet/smartbook? [20:50] nosse1: are you able to fully boot and get the terminal, at least once? [20:51] rsalveti: Yes. And I've tried to use "init=/sbin/init --verbose" in the kernel params. But it doesn't reveal anything useful [20:52] rsalveti: Using "init=/bin/bash" gives me a working console, yes [20:52] armin76 : Smooth-stone is making a Server-on-Chip out of the arm cortex A9 .. we use other C-C9 based platforms to test our theories before our own chip tapes out [20:52] nosse1: oh, so you can try the initscripts by hand, until you identify what's actually breaking your system [20:53] maybe running upstart with strace [20:53] if you have it available [20:53] I can get strace. Because qemu lets med download any app to my system using apt-get [20:54] with strace you can see easily what initscript is breaking your system [20:54] then you can try to remove it and move on, until you can get a working environment to be able to debug it further [20:55] let me check if you can debug upstart in a different way, since verbose is not helping you [20:57] I do have a suspicion that its some feature missing from the kernel, since the kernel is not build natively in ubuntu-land. But I do need to get the system up and running natively before I can build native packages :D [20:57] yeah, verbose shows almost nothing :-) [20:58] I'll certainly try the strace [20:58] nosse1: sure :-) you can try to use qemu or scratchbox [20:58] but scratchbox is more a scarebox than anything else [20:59] well, I did. qemu crashes on lucid and the network is somewhat broken, #548353 [20:59] nosse1: if you have a cross compiler set up on your host, you can try to build the kernel with most of the features as built-int, then you'll probably be able to boot it fine [20:59] nosse1: are you able to mount the rootfs without any problem? [21:00] Yes. Both via SD or NFS. Both are viable and stable [21:00] oh, so yeah, probably a bug when trying to set something at your hardware [21:00] as it's hanging [21:00] let me check the bug [21:01] I had a really hard afternoon not understanding why I couldn't get ssh login to my qemu target system [21:02] My strategy has been to make a rootstock ubuntu-minimal, and then use qemu to access apt-get for everything else I need for my physical target [21:03] qemu does work, it's just that I'm stuck with 80x24 console [21:04] I hoped I could use qemu to compile the native kernel for the real target, but gcc dies with internal compiler error, so I didn't feel the urge to go down that road. [21:05] nosse1: hm, it seems to be really a bug in qemu itself [21:05] ouch, internal compiler error :-) [21:05] Yeah, I didn't know where to stick the bug rootstock or qemu. ogra wanted me to post it on rootstock so there it is [21:05] nosse1: you could try to use qemu with this rootfs but getting inside it using chroot [21:06] How do I do that? I mean, I am now using a ext2 image file which is passed to qemu [21:07] nosse1: you could mount that as a loop device [21:07] register the arm emulator using binfmt [21:07] and get inside using chroot [21:07] When mounting the real target I use loop device, and then mount it using NFS [21:08] nosse1: similar with scratchbox and what we did with mamona (openembedded based distro) [21:08] that was our sdk, basically [21:08] But when i start qemu i do get the lucid image as root. I'm sorry I don't see why I need chroot, that's all [21:09] nosse1: oh, chroot is basically to get inside the lucid enviroment and use the native binaries, that will then be emulated by qemu [21:09] it's not a full emulation solution [21:09] you'll just emulate what you execute inside chroot [21:09] so once you get inside chroot, you can use the native arm compiler, if needed [21:09] the chroot is just to limit the compiler and linker enviroment, so it can find the arm libraries and so on [21:10] Ah. You are not running a full system emulator; only a bin-per-bin emulation. This is new to me. Do you have any links to how-tos? [21:10] different from a full emulation solution, you can get inside the distro with chroot instead of ssh [21:10] sure, let me try some links with what we worked on at mamona [21:11] excellent! [21:11] can change the scripts and post something regarding this later when I get home :-) [21:11] What timezone are you in? [21:11] nosse1: brazil, utc-3 [21:12] Ah. Because it's getting late PM here, so I'll have to leave for the evening. I will go at it tomorrow morning [21:13] this is the script we created to get inside the chroot enviroment: http://dev.openbossa.org/mamona/gitweb?p=tools.git;a=blob;f=mamona-installer/scripts/mamona-chroot.in [21:13] Eh. Norway, CET-1 i forgot [21:13] basically it mounts the proc, dev and pts, if needed [21:13] nosse1: oh, ok, so you can check it tomorrow [21:13] just ping me, will test it later [21:13] http://dev.openbossa.org/mamona/gitweb?p=tools.git;a=blob;f=mamona-installer/scripts/mamona-stdcheck.in [21:13] thanks, really appreciate it [21:14] this is the one that has most of the interesting functions [21:14] the binfmt_register is the one that we register inside the kernel that we want it to use the qemu in case you're running an arm binary [21:15] nosse1: will change it to fit in a more generic way so we can easily use it in any rootfs [21:15] hopefully qemu will work fine with gcc and so on [21:15] and you're then able to built whatever you need [21:16] The ultimate goal it to make the real target work :D [21:16] nosse1: yeah, sure :-) [21:16] nosse1: what board are you trying to use with ubuntu? [21:17] Well now we're using the TI AM3517-EVM kit [21:17] But we're developing some products that will have the same SoC [21:17] oh, cool [21:17] And I'm exploring the possibility to use Ubuntu behind the scenes [21:18] It's going to be a end-user product, where the user will never see Ubuntu directly [21:18] nice, for sure ubuntu seems to be a good target as the os for this board [21:18] But I hoped Ubuntu could ease up the system maintenance part of this project. [21:19] nosse1: oh, got it [21:19] So that we can focus on our Qt based app [21:19] nosse1: so you basically need the platform up and running and then you'll customize the UI stack [21:19] Yes [21:19] nosse1: are you runnint Qt with X11? or directly at the framebuffer? [21:19] And if lucid fits (mostly) out of the box, then I'd be very happy [21:20] nice, too bad it's so hard to get development kits here in brazil :-( [21:20] We are exploring if X11 or fb gives the best perforamce. TI has Open GL accel on both [21:20] nosse1: sure, and I guess that the X11 omapfb driver is running quite well [21:20] I think it's supporting EXA, DRI2 and etc [21:21] I would say that X11 is better, if you have all these hardware acceleration implemented as a video driver [21:21] I does have issues on some kinds of objects, but we're evaluating as we speak [21:21] nosse1: the opengl is always a problem :-( [21:22] the n900 is always facing many many issues with the opengl stack [21:22] by imagination [21:22] Well. gfx acceleration is critical for the app. The product is solely a 5.7" screen with touch, nothing more [21:23] nosse1: oh, got it, it's just one single application as the window manager and composite manager? [21:23] nosse1: qt does that very well if you use the opengles backend [21:23] and nokia is improving the support a lot, to use it for the next devices [21:23] one single app. Or more precise: we can make it that way [21:24] cool [21:24] Yes, and since "Trolltech" is here in norway, support isnt far away [21:25] nosse1: oh, true :-) I know a couple of people from the new qt-software, they are very accessible [21:25] qt will be the future for new UI concepts and products [21:26] Yes, I agree. With SoC CPUs being as powerful as they are, Qt has become very available [21:27] Ah. But this has been a productive conversation. Unfortunately I have to leave for the evening. I'll leave my irc open in case you want to post any more urls. [21:27] I'll be back in the morning. Thank you very much [21:27] nosse1: sure, np :-) [21:27] talk to you tomorrow [21:28] nosse1: sorry, I had to go AFK, but you usually need a proper initramfs to boot an ubuntu based system as of lucid [21:29] now, that interesting. Because the rootstock image does not have a initramfs installed. And it is no problem to start qemu-system-arm without one [21:30] guess you don't need it if you're just builting everything in [21:30] nosse1: I can't say for sure, but things break if you don't have one [21:30] NCommander : Heh .. I do pretty good without one :) [21:30] rsalveti: not due to kernel modules [21:30] Unless, there's a initramfs inside the zImage referenced from https://wiki.ubuntu.com/ARM/RootfsFromScratch [21:31] NCommander : But then again, I've gotten used to creating non-initramfs based dists for testing @ Smooth-Stone ... since I'm only using base + server [21:31] Martyn: that's probably it, since desktop now is trying to use plymouth and mountall voodoo [21:31] NCommander : The trick is to have -everything- you need compiled into the kernel at boot too. [21:31] yeah, but if you build a kernel without any module, you're free to go without initramfs [21:31] rsalveti: No, you're not [21:31] rsalveti : On desktop -- there are /scripts/ running in the initramfs that you can't get away with. [21:32] rsalveti: They need to be copied out of initramfs and put in the main rootFS if you want to do away with the initramfs [21:32] How come the rootstock image works without a kernel nor initrd image installed? [21:32] Martyn: even with the server, you *really* should be using an initramfs [21:32] oh, sure, because of the desktop scripts [21:32] NCommander : Can't .. not enough RAM [21:32] Martyn: how little RAM are we talking?!, we used an initramfs on NSLU2 [21:33] NCommander : Not with LUCID you didn't :) [21:33] you try to get lucid working on lslu2 .. go on :) [21:33] Martyn: *cough*, ok, when we supportred NSLU [21:33] Martyn: I just need a new SoC and a steady hand :-) [21:33] NCommander : <512MB ram at this point, means lucid initramfs won't work [21:33] Martyn: should work just fine [21:33] you simply won't get enough ramdisk [21:33] Martyn: Dove Y0 only booted with 364MiB [21:34] Martyn: and I know we've managed to boot as far down as 128MiB before [21:34] NCommander : I've tried booting desktop (twice) on a non-published multicore A9 platform with only 256M .. failure [21:34] I haven't tried limiting the tegra2 to 384M though .. would be worth an experiment. [21:34] Since the rootstock image works without the initrd image, I'd bet that given a kernel with enough statically built resources, that you don't need the initrd for the initial bootup. [21:35] ubuntu failure? :D [21:35] nosse1 : Under karmic, sure. [21:35] Martyn: tegra2? Damn, you get fun hardware [21:35] NCommander : I always get fun hardware, you know that. [21:35] yeah, I wish I had one of those in my hands [21:35] and the tegra2 250 is a nice chip :) [21:35] it's the second chip we've gotten in-house that even comes CLOSE to what our server chip will finally be like [21:35] Martyn: without neon :) [21:36] Martyn: But lucid rootstock image _does_ work without. I'm using it here... [21:36] and the second one to clock >GHz [21:36] Martyn: I do have a 1Ghz snapdragon (in my phone) [21:36] NCommander : Not multicore though, and that's the big difference [21:36] Martyn: wait, multicore >Ghz?!?!@?!?!?!@#$ [21:36] ... [21:36] linux gets -really- snappy when you have a second core to offload tasks on [21:36] * NCommander stares [21:37] NCommander : What did you think the tegra2 is? It's DUAL core, 1.0->1.2 GHz [21:37] Martyn: I thought tegra was single core SoC; I've never seen one in person [21:37] and (unpublished chip under NDA) is TRI core, 1.2 GHz :) [21:37] tegra was .. tegra2 is dual [21:37] Martyn: *drooooooooooooool* [21:37] yeah, it's a increadible hardware, missing just neon [21:37] rsalveti: we don't have any plans to use NEON in Ubuntu ATM [21:38] Pretty much the Cortex A8/A9 are the only chips that suppor tNEON and ARMv7 [21:38] ( Small paste-flood ) [21:38] AND thumb2 [21:38] Processor : ARMv7 Processor rev 0 (v7l) [21:38] processor : 0 [21:38] BogoMIPS : 1998.84 [21:38] processor : 1 [21:38] BogoMIPS : 1998.84 [21:38] Martyn: O_O;;;;;;;;;; [21:38] NCommander: oh, ok [21:38] Martyn: I want some to put in our datacenter [21:38] it could be useful for multimedia, but yeah, not all hardware supports it [21:38] Features : swp half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 neon [21:38] NCommander: I HAVE ONE! [21:38] and no, I'm not telling who produced that chio :) [21:39] man hahaha [21:39] Martyn: I will tell you BogoMIPS aren't 100% accurate [21:39] but that last entry makes ALL the difference to science apps :) [21:39] Martyn: hows that you have neon? [21:39] Martyn: my Dove board reportds 400 BogoMIPS, but its 600/800Mhz core [21:39] NCommander : this is definitely hardware clocked at 1.1 GHz :) I checked with a scope :) [21:39] Martyn: indeed, I need to poke Marvell and ask [21:39] armin76 : That's not a tegra or tegra2 [21:40] My AM3517 (500MHz) shows 500 BogoMIPS [21:40] * NCommander thinks we're running at 800Mhz, but isn't 100% sure [21:40] armin76 : Thats (unpublishable manufacturer) making a chip for (some device coming out in December) with three cores [21:40] Martyn: ah... [21:40] the tegra2 reports : [21:40] Features : swp half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 [21:40] CPU implementer : 0x41 [21:40] CPU architecture: 7 [21:40] Hostname: tegra200 - OS: Linux 2.6.29-arm2/armv7l - Distro: Gentoo 1.12.13 - CPU: ARMv7 rev 0 (v7l) - Processes: 73 - Uptime: 15h 3m - Users: 1 - Load Average: 0.00 - Memory Usage: 30.18MB/629.16MB (4.80%) - Disk Usage: 1.57GB/7.66GB (20.46%) [21:40] *g* [21:41] * armin76 laughs at NCommander [21:41] *g* [21:41] armin76: I've been 0wned [21:41] Linux tegra2 2.6.29-arm2 #1 SMP PREEMPT Fri Mar 26 15:33:45 CDT 2010 armv7l GNU/Linux [21:41] yey [21:41] armin76: I'll come back and surpass you soon [21:41] Linux tegra200 2.6.29-arm2 #4 SMP PREEMPT Sat Mar 27 10:46:32 GMT 2010 armv7l ARMv7 Processor rev 0 (v7l) Tegra generic GNU/Linux [21:41] * NCommander has seem some amazing hardware in the pipe [21:42] NCommander: from who? [21:42] NCommander : But you'll never TOUCH what I've got in the pipe :) [21:42] NCommander : At least, not until and unless you get better connections that direct-from-ARM :) [21:42] * nosse1 thinks ARM soon catches up with IA CPUs [21:42] nosse1 : No, I think IA32 will still be ahead in raw performance for a while [21:42] Martyn: how much ram do you have? [21:43] Martyn: As well as the Atom product line? [21:43] nosse1 : Getting 28nm foundries is one thing, and also there's a long way to go before arm supports things like 40 bit memory space, a /good/ floating point unit, and there are a lot of changes needed to get close to some of the base performance the IA32 gets with it's CISC architecture for some kinds of math [21:44] binutils took 9m to build, vs 4m on a dual core atom 330 [21:44] armin76 : On tegra2 -- 1GB, 128 megs of which is taken by video and there are other issues : MemTotal: 644024 kB [21:44] compared to the 30m it took on the efika mx [21:44] We considered atom in our product, but the hw cost and complexity is much higher than any ARM system [21:44] Martyn: same as me then :) [21:45] armin76: On ( unpublished platform ) we have 3196 MB of ram available, and a full 2M of L2 cache [21:45] Martyn: the difference is that i run a better distro than you *g* [21:45] j/k [21:45] it's much more powerful [21:45] and it uses DDR3 ram [21:45] sounds fun, thats the server thing? [21:45] armin76 : I'm on lucid half the time, karmic the other half... [21:46] armin76 : That's our chip (smooth-stone) which will probably be available at the end of the year [21:46] what will be it useful for? [21:46] man, you got so much ram! [21:46] armin76: Data center .. it's a -server- chip, not a tablet chip [21:46] armin76 : It's meant to bring ARM to the server market, where people are huring for power [21:47] you can stick 10 of our chips in a cluster where you can only run one core2quad [21:47] Martyn: cool, didn't think that arm would head to server side so quickly :-) [21:47] so with our chip, you get 40 cores for the same power as one quad-core intel chip [21:47] I'm coming here with my newly aquired Audi (which I'm proud of), and then you guys are swining Ferraris and Bugatties... *sigh* I can't compete [21:48] :D [21:48] hahaha, same feeling [21:48] although generation 1 chips from us will suffer from a memory limitation (only 3.5 GB of accesible memory per chip .. that's a limitation of the Cortex A9) [21:48] rsalveti: i got 3G on a marvell board! :) [21:48] but that won't matter ... [21:48] Martyn: but that server, what would it be used for, for example? webpages? [21:49] armin76: cool :-) [21:49] rsalveti: Hostname: ganesha - OS: Linux 2.6.31-01335-g86d7101/armv5tel - Distro: Gentoo 2.0.1 - CPU: Feroceon rev 0 (v5l) - Processes: 78 - Uptime: 158d 19h 19m - Users: 2 - Load Average: 1.25 - Memory Usage: 286.34MB/3042.39MB (9.41%) - Disk Usage: 5.40GB/20.73GB (26.06%) [21:49] :) [21:50] argh! haha :-) [21:50] I just have a sheevaplug! and that's a very old hardware comparing to these [21:51] armin76 : Think .. hadoop cluster with 8196 cores, 8 TB of RAM, 64TB of SSD storage.... [21:51] but at work I can play with a more interesting board, the ste u8500 :-) [21:51] All in .. say .. half a rack? [21:51] Martyn: hahaha, man, that's something :D [21:51] maybe a full rack if you want it to run nice and cool? [21:52] Yeah .. that's what we're after, and we're at least a full year ahead of anyone else. [21:55] i see === JaMa|Off is now known as JaMa [22:36] lool or NCommander - incase you didn't see my message in #ubuntu-x i fixed up xserver-xorg-video-dove to work with xserver 1.7+ and brought in all the fbdev changes since it was forked incase its useful: http://sarvatt.com/downloads/patches/xserver-xorg-video-dove.diff [23:07] hello, can I load xfce on the beagle did someone tried it ? === JaMa is now known as JaMa|Zzzz [23:47] samuel_Sayag, yes.. and it's more responsive then gnome..