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