[08:23] <eggonlea> hi guys, I just noticed that lots of device nodes in /dev dir has "+" attribute. Could anybody point me to any doc/wiki about ACL implementation in Ubuntu? E.g. which CONFIG_XXX_ACL should be enabled in kernel and which user space utilities are using ACL to fine control FS or other stuffs. Thanks!
[08:24]  * eggonlea is reading https://help.ubuntu.com/community/FilePermissions and https://wiki.ubuntu.com/ACL-OnByDefault.
[08:25] <eggonlea> But these two doc seem not provide a whole view of ACL in Ubuntu.
[08:37] <lool> eggonlea: + attribute?
[08:37] <lool> how do you see that?
[08:38] <eggonlea> lool, just with "ls -l"
[08:39] <eggonlea> e.g.
[08:39] <eggonlea> lli5@sh-dt-4513:/vobs/ubuntu$ ls -al /dev/snd
[08:39] <eggonlea> total 0
[08:39] <eggonlea> drwxr-xr-x   3 root root      240 2010-03-24 11:18 .
[08:39] <eggonlea> drwxr-xr-x  15 root root     4100 2010-04-02 18:48 ..
[08:39] <eggonlea> drwxr-xr-x   2 root root       60 2010-03-24 11:18 by-path
[08:39] <eggonlea> crw-rw----+  1 root audio 116, 10 2010-03-24 11:18 controlC0
[08:39] <eggonlea> crw-rw----+  1 root audio 116,  9 2010-03-30 18:12 pcmC0D0c
[08:39] <eggonlea> crw-rw----+  1 root audio 116,  8 2010-04-09 15:43 pcmC0D0p
[08:39] <eggonlea> crw-rw----+  1 root audio 116,  7 2010-03-24 11:18 pcmC0D1c
[08:39] <eggonlea> crw-rw----+  1 root audio 116,  6 2010-03-24 11:18 pcmC0D2c
[08:39] <eggonlea> crw-rw----+  1 root audio 116,  5 2010-03-24 11:18 pcmC0D3c
[08:39] <eggonlea> crw-rw----+  1 root audio 116,  4 2010-03-24 11:18 pcmC0D4p
[08:39] <eggonlea> crw-rw----+  1 root audio 116,  3 2010-03-24 11:18 seq
[08:39] <eggonlea> crw-rw----+  1 root audio 116,  2 2010-03-24 11:18 timer
[08:43] <lool> eggonlea: Hmm indeed
[08:44] <eggonlea> This troubled us because we didn't enable ACL in kernel by default. :)
[08:44] <eggonlea> Any doc to describe this?
[08:45] <eggonlea> I'm wondering if we have to enabled all ACL configuration in kernel.
[08:46] <lool> I wonder whether it's an ACL
[08:49] <eggonlea> Er, so, what's this?
[08:51] <lool> stracing ls and getfacl, it appears to query ACL indeed
[08:51] <lool> getxattr("/dev/video0", "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x02\x00\x06\x00\xe8\x03\x00\x00\x04\x00\x06\x00\xff\xff\xff\xff\x10\x00\x06\x00\xff\xff\xff\xff \x00\x00\x00\xff\xff\xff\xff", 132) = 44
[08:51] <ogra> the + usually notates an ACL
[08:51] <lool> Yes; I checked the info page from ls and it says + is for ACL other than SELINUX
[08:51] <ogra> and we definately support ACL in ubuntu
[08:52] <ogra> not sure why its set on audio devices though
[08:52] <lool> When I actually query acls, I do see that there's an ACL in place, but I wonder where it comes from
[08:52] <ogra> i was under the impression while we support them, we dont set up any ACL's by defualt
[08:52] <lool> e.g. getfacl /dev/video0 gives http://paste.ubuntu.com/411491/
[08:52] <ogra> well, i would start looking at udev rules
[08:53] <eggonlea> So we need to know who's using ACL and what's the requirement to kernel.
[08:53] <lool> It's clear that plain owner + group differ from the ACL, but what I don't understand is why an ACL is needed at all
[08:53] <lool> eggonlea: So the device noces are created by udev
[08:53] <eggonlea> lool, it should be.
[08:54] <lool> eggonlea: /lib/udev/rules.d/70-acl.rules
[08:54] <lool> So it seems that's for consolekit integration, misc devices get an ACL on top
[08:55] <lool> It seems that this is to allow access to the devices depending on who's logged in
[08:56] <ogra> eggonlea, for the kernel just enable CONFIG_GENERIC_ACL and the _POSIX_ACL functions for each filesystem
[08:56] <eggonlea> lool: Wow, it seems so.
[08:56] <lool> it kind of makes sense, but it's a bit scary at the same time
[08:56] <eggonlea> ogra: I did not see any "acl" keyword in /etc/fstab
[08:57] <eggonlea> do you think FS_ACL is needed?
[08:57] <ogra> well, its enabled in all ubuntu kernels
[08:57] <ogra> so to prevent later issues i would just try to build my kernel config as close to ubuntu as possible
[08:58] <eggonlea> You are right. I'll check if there's any drawback or impact.
[08:58] <ogra> as i said above, i dont think we use ACL by default, the devices might be an exception because of console/policykit
[08:59] <lool> eggonlea: In practice, things might work via groups, but it's best not to rely on that
[08:59] <lool> My user isn't in the audio group for instance
[09:00] <eggonlea> Yes, that's why we have to add ubuntu user to audio group with non-ubuntu kernel.
[09:00] <eggonlea> We'll enable it if nothing get impacted. Thanks!
[09:01] <DanaG> hmmm, I hope the omap kernel will have all the usb-gadget device-type drivers enabled.
[09:01] <ogra> i think though that the audio group will persist for some releases still ... people still tend to remove pules which then forces you to use the group
[09:02] <ogra> *pulse
[09:02] <DanaG> MUSB_HDRC (or whatever it is) needs to =y, but all the g_ether and g_audio shouldn't need that.
[09:13] <amitk> DanaG: do you have a point to a known working USB (peripherals + OTG) on Beagleboard?
[09:13] <DanaG> A point?  Not sure I get the question.
[09:13] <DanaG> I'm using rcn-ee's images, for now, anyway.
[09:13] <DanaG> I'm using ehci as host and otg as peripheral.
[09:13] <amitk> ogra: does the config on bug 541030 work for you? It doesn't give me keyboard/mouse yet
[09:14] <ubot4`> Launchpad bug 541030 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "omap kernel musb/ehci ports not enabled on beagleboard (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/541030
[09:14] <amitk> DanaG: sorry, pointer
[09:14] <amitk> I was looking for known working configs on 2.6.33
[09:15] <ogra> amitk, i only tried it on sunday, i think you updated the patch inbetween, the sunday build didnt work at all for me (USB wise)
[09:15] <amitk> I've got my USB hub on ehci, and that isn't working
[09:16] <DanaG> I have weird behavior with my asix adapter: doesn't work if plugged in during boot -- has to be unplugged and replugged.
[09:16] <ogra> amitk, i tried both, HUB and direct connection
[09:18] <amitk> ogra: direct connection won't work, the ehci port only support high speed usb, not full speed (keyboard/mice)
[09:18] <amitk> http://elinux.org/BeagleBoard#USB
[09:19] <ogra> oh, thanks
[09:19] <ogra> i didnt know that
[09:23] <amitk> OTG port supports both, but I don't have a mini-mini (whatever it is called) USB cable
[09:24] <ogra> i have a mini to normal adapter here
[09:26] <ogra> hmm, i wonder how risky it is to bump compcache to 50% for all armel arches
[09:27] <ogra> we have no subarch concept at packaging level
[09:27] <amitk> http://trisoft.de/pics/ZHost.JPG <-- this is what I need
[09:27] <ogra> so if i do it in the casper package it would happen for all
[09:27] <ogra> amitk, isnt that the one with two shortened pins ?
[09:28] <ogra> my adapter looks the same but doesnt have pin shortening
[09:28] <ogra> or is that only necessary for nokia ?
[09:28] <ogra> (that adapter works with the revB board i have)
[09:29] <amitk> ogra: yeah, there are two kinds.
[09:29] <ogra> ah, good
[09:29] <amitk> you need the pins shortened
[09:29] <ogra> hrm
[09:29] <ogra> not so good thenm
[09:29] <amitk> you could do it on the board as described in the wiki
[09:29] <amitk> just short the J6 pad
[09:29] <ogra> i definately dont want to solder on HW i'm relying on for getting the image done :)
[09:31] <amitk> ogra: you will have to to get working keyboard/mouse through the OTG board, AFAIK
[09:31] <amitk> DanaG: ^^
[09:32] <ogra> why ? i have a powered hub i can attach to the normal USB port
[09:32] <ogra> and also several unpowered ones
[09:32] <amitk> ogra: ok, try out the kernel on people and see if that works for you
[09:32] <DanaG> oh, "shortened"... I thought you meant "less long"
[09:32] <amitk> ogra: this enabled rcn-ee's 'good' config
[09:32] <ogra> is USB compiled in so i can test it with the server image ?
[09:32] <DanaG> "shortED".
[09:33] <amitk> ogra: yes
[09:33] <ogra> yeah, seems so ...
[09:33]  * ogra just had to dig out the patch :)
[09:39] <ogra> amitk, no go with unpowered hub
[09:40]  * ogra digs for the powered one
[09:42] <ogra> amitk, nor with powered ... tried both ports (OTG and normal)
[09:45] <amitk> ogra: and did you verify that the config is identical to what rcn-ee recommended in the bug?
[09:45] <ogra> amitk, i just took your kernel and replaced the uImage on the SD
[09:45] <ogra> if its compiled in it should just work
[09:46]  * ogra switches back to serial console to check dmesg
[09:46] <amitk> ogra: please confirm the config. So I'm not crazy for not uploading the 'simple' fix
[09:46] <amitk> I wonder if any other long-time beagleboard users have any inputs here...
[09:47] <amitk> lrg: ^
[09:48] <ogra> amitk, no mentioning in dmesg and no plug events (i see its a codesourcery kernel so i'm sure its yours)
[09:48]  * ogra checks the config 
[09:49] <amitk> ogra: try "modprobe ehci-hcd"
[09:49] <ogra> amitk, i cant, its a server image
[09:49] <ogra> thats why i asked if everything is compiled in
[09:49]  * amitk prepares another kernel with ehci-hcd compiled in
[09:49] <ogra> let me try with a live image first
[09:49] <ogra> it just takes endless to boot compared to server
[09:50] <ogra> and i have no SD ready with one, takes a while
[09:53] <amitk> ogra: good idea, I'll switch to a server image too
[09:54] <ogra> note that only works if you dont need any modules
[09:54] <lrg> hey amitk,  ogra
[09:54] <ogra> yo lrg
[10:05] <amitk> ogra: people now has a kernel with ehci compiled in
[10:06] <ogra> ok
[10:11] <ogra> i see ehci in dmesg now, but the kbd doesnt get powered on
[10:11] <ogra> i guess hci stuff is modules
[10:12]  * ogra tries live
[10:13] <amitk> hci?
[10:13] <ogra> well, input drivers
[10:16] <amitk> aah, HID
[10:17] <ogra> amitk, live works
[10:17] <ogra> tell me what you will do with HID since i need to include the udeb in d-i if it stays modular
[10:18] <ogra> hey, even my moschip USB->ETH works out of the box now
[10:19]  * ogra fires up firefox to see if it survives with 25% compcache
[10:20] <NCommander> eggonlea: ping?
[10:20] <ogra> www.ubuntu.com works \o/
[10:20]  * ogra tries something havier
[10:21] <amitk> ogra: so EHCI needs to be compiled in for now... I plan to keep HID modular
[10:21] <ogra> bah, hello OOM
[10:23] <eggonlea> NCommander: ack
[10:27] <ogra> the framebuffer definately has some issues with plymouth
[10:53] <ogra> ok, compcache with 50% doesnt let firefox OOM anymore
[10:54] <amitk> and confirmed that ehci is reqd to be compiled in
[10:54] <amitk> will finalise the patches and prep for upload
[10:54] <ogra> amitk, what about sound ?
[10:54] <ogra> i dont seem to have any sound device atm
[10:55] <hrw> morning
[10:57] <hrw> are there plans to keep kernel+initrd in nand on omap platform?
[10:57] <amitk> ogra: do you care about sound ATM?
[10:57] <hrw> as you want to have rootfs on usb stick then this would drop requirement of sd card for boot
[10:57] <ogra> amitk, well, if we can have it it would be great, not essential though
[10:58] <ogra> amitk, what breaks it ? USB ?
[10:58] <ogra> hrw, probably later, for 10.04 not
[10:58] <hrw> ok
[10:58] <ogra> way to much to do to even make the installer work in the next 7 days
[10:59] <lool> ogra: Hey do you know if the OMAP daily images work somewhat already?
[10:59] <ogra> lool, they dont, we're waiting for a kernel
[10:59] <ogra> lool, no USB support atm
[10:59] <lool> ogra: Do they boot without USB?
[10:59] <lool> e.g. if I write them to SD, will they show some UI?
[10:59] <ogra> lool, yes, but you dont have input devices and no target to install to
[11:00] <ogra> lool, you get all the way to the live desktop
[11:00] <lool> ogra: Ok thanks; What about the netboot ones?
[11:00] <ogra> lool, i havent tested them for a while, they might work ... server definately does to a certain point if you modify boot.scr for serial
[11:01] <ogra> (and the preseed file, i havent rebuilt since i changed debian-cd)
[11:01] <ogra> live has a to low compcache value for installing atm
[11:01] <lool> ogra: Do you intend to build a SD image for d-i images?
[11:02] <ogra> i'm pondering to use only-ubiquity
[11:02] <ogra> lool, no, time is to short, i'll try to get server and live working ... in case there is time left i'll look into netinst d-i images like we have for imx51
[11:02] <ogra> but its unlikely
[11:03] <ogra> lool, getting partman and flash-kernel hacked up to do what we need will be time consuming
[11:04] <lool> oh we disabled alternate desktop images for armel
[11:04] <ogra> lool, thats what i was talking about yesterday :)#
[11:04] <ogra> lool, server is your best bet
[11:04] <lool> ogra: It's disabled or simply broken?
[11:04] <ogra> unless you want a live image
[11:04] <lool> ogra: Did you push the fix I suggested?
[11:05] <ogra> lool, disabled, we dont support desktop on armel anymore
[11:05] <ogra> lool, yup
[11:05] <ogra> thanks for that suggestion again :)
[11:05] <lool> no xubuntu image anymore either hmm
[11:05] <ogra> nope
[11:06] <ogra> only netbook
[11:06] <ogra> and server
[11:06] <amitk> ogra: compiling a final kernel for test with all changes after reworking... once that is verified, I'll ask for an upload
[11:06] <lool> ogra, asac: Can you guys confirm that the subarch name we've been using for omap is "armel+omap"?
[11:06] <ogra> we have massively cut down on images
[11:06] <lool> I see https://wiki.ubuntu.com/LucidLynx/ReleaseManifest mentions armel+OMAP3, and would like to write armel+omap there
[11:06] <ogra> lool, confirmed
[11:06] <ogra> amitk, yay
[11:11] <ogra> lool, i think davidm added the 3 to indicate that we will only support omap3 by release (probably note it in brackets or something)
[11:15] <lool> ogra: added, thanks
[11:17] <ogra> amitk, i see weird errors in dmesg if ubiquity tries to start partman
[11:17] <amitk> ogra: if you'll confirm the kernel on people, we're good to upload
[11:17] <amitk> ogra: pastebin?
[11:19]  * ogra weaits for ubuntu-paste to return the prompt
[11:20] <ogra> grrr, paste.ubuntu.com is broken again
[11:20] <ogra> amitk, http://pastebin.com/khbv1c5i
[11:20] <ogra> amitk, see the parted messages at the bottom
[11:26] <amitk> ogra: something not using setrlimit(RLIMIT_CORE, ...) correctly?
[11:26] <ogra> might be
[11:27] <amitk> man 5 core
[11:30] <amitk> ogra: it is a warning message printed by do_coredump() inside the kernel
[11:30] <amitk> 		if (cprm.limit == 0) {
[11:30] <amitk> 			/*
[11:30] <amitk> 			 * Normally core limits are irrelevant to pipes, since
[11:30] <amitk> 			 * we're not writing to the file system, but we use
[11:30] <amitk> 			 * cprm.limit of 0 here as a speacial value. Any
[11:30] <amitk> 			 * non-zero limit gets set to RLIM_INFINITY below, but
[11:30] <ogra> yeah, RTLIMIT_CORE being 0 is wanted cjwatson tells me
[11:30] <amitk> 			 * a limit of 0 skips the dump.  This is a consistent
[11:30] <amitk> 			 * way to catch recursive crashes.  We can still crash
[11:30] <amitk> 			 * if the core_pattern binary sets RLIM_CORE =  !0
[11:30] <amitk> 			 * but it runs as root, and can do lots of stupid things
[11:30] <amitk> 			 * Note that we use task_tgid_vnr here to grab the pid
[11:30] <amitk> 			 * of the process group leader.  That way we get the
[11:30] <amitk> 			 * right pid if a thread in a multi-threaded
[11:30] <amitk> 			 * core_pattern process dies.
[11:30] <amitk> 			 */
[11:31] <amitk> 			printk(KERN_WARNING
[11:31] <amitk> 				"Process %d(%s) has RLIMIT_CORE set to 0\n",
[11:31] <amitk> 				task_tgid_vnr(current), current->comm);
[11:31] <amitk> 			printk(KERN_WARNING "Aborting core\n");
[11:31] <amitk> 			goto fail_unlock;
[11:31] <amitk> cool
[11:31] <amitk> in that case, please give the ack for the latest kernel on people
[11:31] <amitk> ogra: ^
[11:31] <ogra> i'll test it, one sec
[11:32] <amitk> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/498525
[11:32] <ubot4`> Launchpad bug 498525 in linux (Ubuntu Lucid) (and 1 other project) "[lucid] breaks apport: core dumps get aborted even if core_pattern is a pipe (affects: 2) (heat: 16)" [High,Fix released]
[11:34] <ogra> amitk, so that fix is missing from the omap kernel ?
[11:34] <amitk> apw: this bug above ^^
[11:34] <amitk> ogra: I think so
[11:34] <amitk> apw: I guess the patch you created should be applied to all flavours?
[11:35] <apw> amitk, it is allplied to all flavours based on .32
[11:35] <apw> its that .33 was not taken from leaans rebase means you didn't get it
[11:35] <amitk> apw: I'm going to try cherry-picking it into omap
[11:35] <apw> amitk, ok
[11:35] <apw> we likely need to put that on the release sprint agenda too
[11:35] <apw> deciding what to do about .33
[11:36] <ogra> apw, we have no committed support for omap at all
[11:36] <apw> personally i think it should be synced with leaans pass though .33 version.  she was said to have kept it
[11:37] <ogra> apw, https://wiki.ubuntu.com/LucidLynx/ReleaseManifest
[11:38] <apw> i wonder what N/A means in that context
[11:38] <ogra> apw, its pretty much "get something out that runs and install roughly and dont care anymore"
[11:38] <apw> but regardless of what you say we will be expected to do secirity on it
[11:38] <apw> which means it doesn't want to be an unmaintainable mess
[11:38] <ogra> we need to have an installable image by release but dont do any further stuff with it
[11:39] <apw> i will believe that when we get to M without updating it
[11:49] <amitk> ogra: feedback?
[11:52] <ogra> amitk, installing ...
[11:55] <ogra> crap, OOmed when trying to install it on the running system
[12:03] <NCommander> ogra: 364MiB is the lower bound. How much are you running with omap?
[12:03] <NCommander> ogra: ^we ever successed ran with on Dove
[12:04] <ogra> NCommander, i know the minimal values
[12:04] <ogra> 256M plus 50% compcahce atm
[12:04] <NCommander> ogra: hrm, that should push you just enough to complete installation. Doesn't ubiquity activate swap space like d-i does?
[12:23] <lool> 1
[12:23] <lool> Ups
[12:27] <ogra> sigh, only-ubiquity dies too in ubi-partman
[12:38] <NCommander> ogra: OOM got it?
[12:38] <NCommander> or something else?
[12:43] <ogra> ubi-partman
[12:43] <ogra> no OOM
[12:44] <NCommander> ogra: oh. I though ubi-partman was dying due to OOM before
[12:46] <ogra> no, it does with "error 10"
[12:47] <ogra> i suspect its caused by udisks-part-id failing
[12:48] <NCommander> ogra: why is that failing
[12:48] <ogra> no idea yet
[12:48]  * NCommander decides this is a good time to fix apport
[12:48] <ogra> apport works fine for me
[12:49] <NCommander> ogra: the retracer been down for two weeks, chroot broke
[12:49] <ogra> i just filed bug 559144 with it
[12:49] <ubot4`> Launchpad bug 559144 in udisks (Ubuntu Lucid) (and 1 other project) "udisks-part-id crashed with signal 7 in memcpy() (affects: 1)" [High,New] https://launchpad.net/bugs/559144
[12:49] <NCommander> and I couldn't rebuild the chroot on jocote
[12:49]  * NCommander points to apport stauts in the topic
[12:52] <ogra> err
[12:52]  * ogra glares at the bugreport
[12:52] <ogra> ProcCmdLine: quiet splash vram=12M omapfb.mode=dvi:1280x720MR-16@60 file=/cdrom/preseed/hostname.seed -- boot=casper
[12:52] <ogra> wtf
[12:53] <NCommander> hostname.seed?
[13:04] <ogra> must be something that parses the line its surely not in the actual cmdline
[13:08] <OlivierP> msg ndechesne comment ca va?
[13:08] <ogra> heh
[13:08]  * ogra hands OlivierP a /
[13:14] <lool> ogra: Just checking lucid-netbook-armel+omap.img, apparently it doesn't follow the chs expectations for beagleboard?
[13:14] <lool> Partition 1 has different physical/logical endings: phys=(1023, 3, 32) logical=(8283, 2, 1)
[13:15] <ogra> it woprks so who cares
[13:15] <ogra> it just uses the dove scripts in slightly modified ways, CHS is only relevant if you use MLO on the image which we dont do
[13:16] <lool> ogra: Do you have u-boot on the image?
[13:16] <ogra> lool, nopüe
[13:16] <XorA> erks, I have no MLO on any of my boards
[13:16] <ogra> the expectation is that x-loader and u-boot sit in NAND
[13:16] <lool> ogra: So the image only works if people have a working x-loader and u-boot in NAND with proper config?
[13:16] <lool> Ok
[13:16] <ogra> right
[13:16] <ogra> for 10.04 thats the most minimal
[13:17] <lool> I thought you were trying to change the image scripts to use proper partitions
[13:17] <ogra> for later we'll come up with something better
[13:17] <ogra> lool, i will, but not for 10.04
[13:17] <ogra> we're way to late, my target is to have something installable at all by release going the path of least resistance
[13:19] <XorA> you guys do have the script to make correct partitions?
[13:21] <lool> XorA: No; only the public (manual) instructions
[13:21] <lool> XorA: unfortunately, our scripts are usually based on parted which has a rigid view of what values one should use for chs addressing
[13:21] <XorA> lool: http://git.openembedded.net/cgit.cgi/openembedded/tree/contrib/angstrom/omap3-mkcard.sh
[13:22] <XorA> lool: for reference
[13:23] <lool> XorA: Thanks; we considered using other disk utilities such as fdisk or sfdisk or others, but that's an helpful example
[13:23] <XorA> lool: I still get 50 odd downloads of that a day from new beagleboard owners
[13:23] <ogra> lool, i'll need to have partman-uboot, flash-kernel etc changes before final freeze (and whatever else bugs we find during next week) thats work enough given we only have a usable kernel today
[13:23]  * ogra sighs about reconnects
[13:24] <ogra> i'll dd the working live image off my Sd and upload it to people.u.c so others can play as well
[13:24] <lool> XorA: it might make sense to round the size down to the nearest cylinder boundary before dd-ing zeroes
[13:24] <XorA> lool: that makes sense
[13:25] <lool> XorA: For our particular case, I wish we wouldn't need root (we currently don't have root on the image build server)
[13:25] <lool> XorA: Also, I'm afraid the scripts relies on using real hardware of type MMC to create the image?!
[13:25] <lool> It seems to rely on a /dev/foop2 device for instance
[13:26] <ogra> could you repost the script ? i was disconnected
[13:26] <XorA> you can do it be prepping a blank image in a file once, then writing your FS on top of that
[13:26] <XorA> http://git.openembedded.net/cgit.cgi/openembedded/tree/contrib/angstrom/omap3-mkcard.sh
[13:26] <lool> That only exists for real devices (unless you ask kpartx) and not for USB attached MMC drives
[13:26] <ogra> thanks :)
[13:27] <ogra> ah, yeah, i had a similar approach using sfdisk
[13:30]  * ogra uploads http://people.canonical.com/~ogra/lucid-netbook-armel+omap.img
[13:30] <ogra> that uses 50% compcache and has working USB
[13:31] <XorA> awesome
[13:31] <ogra> 40min to go
[13:31] <NCommander> ogra: on what?
[13:31] <ogra> NCommander, ??
[13:31]  * NCommander does his first likewise-open build
[13:31] <NCommander> ogra: 40 mins to go on what?
[13:31] <lool> ECC Failed, page 0x00080000
[13:31] <lool> gah
[13:31] <ogra> NCommander, the upload
[13:32] <ogra> lool, wait for the image above
[13:32] <ogra> lool, the cdimage images all have the broken kernel
[13:32] <NCommander> ogra: ugh, your upload bandwidth supassing mine in spades; with my up, that would take about 4 hours
[13:32] <ogra> NCommander, SDSL 2Mbit
[13:32] <NCommander> ogra: I have 15 down burst up to 50Mbit, with 1Mbit up
[13:32] <ogra> while it sucks wrt downloading i have a guranteed 2M upload all the time
[13:32] <NCommander> ;.;
[13:33] <NCommander> and the 1 is questionable
[13:33] <NCommander> ogra: I'll trade :-P
[13:33] <ogra> NCommander, costs a fortune though
[13:33]  * XorA has that ADSL where I can request to boost my upload at cost of download
[13:33] <NCommander> ogra: can't be as bad as what I'm paying to get 1 Mbit up versus 264k
[13:33] <NCommander> XorA: I envy you
[13:33] <ogra> XorA, germany doesnt have such offers sadly
[13:34] <XorA> ogra: its rare in the UK, I think this ISP is the only one
[13:34] <NCommander> XorA: nor do most ISPs int he states
[13:34] <XorA> I havent here, but my office does have it boosted
[13:36] <lool> ogra: This is before the kernel
[13:36] <ogra> lool, urgh
[13:36] <ogra> bad u-boot ?
[13:37] <XorA> wrote u-boot with the wrong mixed up sw/hw ecc settings I would guess
[13:38] <ogra> XorA, yeah, lool doesnt trust me so he doesnt use my packages :P
[13:38] <ogra> we have MLO and u-boot.bin in the archive :)
[13:38]  * XorA hasnt ubuntud any of his beagles yet
[13:38] <lool> ogra: I'm using MLO and u-boot.bin from the archive...
[13:38] <ogra> lool, aw, C4 ?
[13:38] <lool> qemu-maemo-system-arm
[13:39] <ogra> ah
[13:39] <ogra> phew
[13:39] <ogra> i tested it on C4
[13:42] <ogra> lool, qemu-maemo-system-arm might emulate a different revision in which case you probably need a different MLO
[13:43]  * ogra considers to be brave and try what the live image does on his B6
[13:45] <lool> ogra: I just managed to load our u-boot, but can't break into it
[13:45] <NCommander> ogra: er, doesn't your B6 only have 128M?
[13:45] <ogra> NCommander, thus "brave" :)
[13:46] <NCommander> ogra: ah. Ping me when its done booting sometime after final freeze ;-)
[13:46] <ogra> seems though our DSS2 already fails on it i get no graphical output
[13:46] <ogra> its stuck on the u-boot splash
[13:46] <lool> Is there anyway to break the start of our u-boot?
[13:47] <NCommander> lool: it should break on any key
[13:47] <ogra> lool, only hitting a key
[13:47] <ogra> while the countdown runs
[13:47] <lool> I don't see any coundtown
[13:47] <ogra> are you sure its our u-boot ?
[13:47] <lool> Note that it uses the default environment; I don't have any default binary environment
[13:48] <lool> U-Boot 2010.03-rc1 (Mar 24 2010 - 15:50:56)
[13:48] <ogra> it definately defaults to a 10 sec countdown
[13:48] <lool> ogra: I don't see which other one it could possibly be
[13:48] <NCommander> wow
[13:48] <NCommander> its up ot date
[13:48]  * NCommander is sad being on u-boot 1.4.3 ;.;
[13:48] <lool> what I get is http://paste.ubuntu.com/411595/
[13:48] <ogra> NCommander, yes, i pulled the very latest upstream that upstream recommended to me
[13:49] <NCommander> ogra: Dove's u-boot is a dinosaur. Although its not as bad as things still shipping u-boot 1.1, and Marvell has added some nice features
[13:49] <ogra> lool, seems it'S stuck, the countdown appears after that
[13:49] <NCommander> like mounting NFS in u-boot :-)
[13:49] <ogra> lool, http://paste.ubuntu.com/411596/
[13:50] <rcn-ee> ah yes, ran into that in real hardware, if you us angstrom's u-boot 2010.03-rc1 you have to use the new 1.4.4ss x-loader...
[13:50] <NCommander> Start in 49 minutes (5000000) - wow, buildds are getting slammed this morning
[13:51]  * ogra hopes thats not the omap kernel
[13:51] <lool> ogra: that assumes you have some delay
[13:51] <lool> rcn-ee: Ah
[13:51] <NCommander> ogra: no, that's compiz
[13:51] <lool> rcn-ee: Do you have a binary x-loader I could try out to confirm?
[13:51] <ogra> ah, k
[13:51] <lool> rcn-ee: Preferably signed
[13:51] <rcn-ee> yeap..
[13:51] <NCommander> ogra: ti kernel is building, I set it so high that it was picked up as soon as a buildd freed up
[13:52] <ogra> NCommander, yup, i see it
[13:52] <rcn-ee> lool, they are uploaded here http://rcn-ee.net/deb/tools/
[13:52] <amitk> ogra: why are you hoping it isn't the kernel?
[13:52]  * NCommander watchs his racing OOo builds
[13:52] <ogra> amitk, ??
[13:52] <ogra> amitk, i said i suspect it *is* the kernel
[13:52] <amitk> 15:51  * ogra hopes thats not the omap kernel
[13:53] <NCommander> amitk: he was worried that the 50 minute build delay was for the kernel
[13:53] <ogra> ah
[13:53] <ogra> i was referring to the 49min delay
[13:53]  * NCommander looks at the build queue to shuffle things around
[13:53] <ogra> amitk, i thoght you referred to the SIGBUS errors
[13:53] <NCommander> Got to love crunch time
[13:53] <rcn-ee> so heads up, that'll be in the FAQ's.. on boards with an older x-loader (1.4.2 is on C4's) when you upgrade u-boot to 2010.03, you need to flash the new 1.4.4ss X-loader... (or hold the user botton down on reset with the MLO on the sd card)
[13:54] <rcn-ee> otherwise it'll just stall at u-boot load....
[13:54]  * ogra twiddles thumbs ... 
[13:54] <lool> rcn-ee: Your x-loader is unhappy with my qemu
[13:54] <lool> Reading boot sector
[13:54] <lool> Error: reading boot sector
[13:54] <lool> u-boot.bin not found or blank nand contents - attempting serial boot . . .
[13:54] <ogra> another 15min until the image is uploaded
[13:54] <lool> Texas Instruments X-Loader 1.4.4ss (Apr  1 2010 - 07:01:03)
[13:54] <lool> Beagle xM Rev A
[13:54] <lool> rcn-ee: it waits for an u-boot over kermit
[13:54] <ogra> XM ?
[13:55]  * amitk starts debugging OTG and kernel boot on XM now
[13:55] <rcn-ee> ah crap... it's build directly in angstrom...
[13:55]  * ogra really doubts qemu can emulate XM already
[13:56] <ogra> amitk, kernel doesnt boot on revB
[13:56] <ogra> :)
[13:56] <ogra> (not that i expected it to work)
[13:56] <rcn-ee> lool, the last version that worked before the 1.4.4ss change, was 2009.11 (in the same directory)
[13:57] <amitk> ogra: I don't have a revB. Only C4 and XM
[13:57] <ogra> amitk, lucky you ... revB is crap
[13:57] <ogra> 128M simply dont cut it :)
[13:58] <lool> rcn-ee: Wee!
[13:58] <rcn-ee> laughs, it's sad I use Rev b's for all my testing because my C's and Xm's are doing all the real grunt work on the server.. ;)
[13:58] <lool> rcn-ee: So I understand that we effectively packaged conflicting x-loader + u-boot in Ubuntu?
[13:58] <amitk> it is still good for lots of things, like running a server, but I'll need someone else to debug the problem
[13:58] <ogra> lool, huh ?
[13:59] <ogra> lool, we packaged what sarkoman recommended
[13:59]  * NCommander pedals faster
[13:59] <ogra> lool, for revC boards
[13:59] <amitk> rcn-ee: want to see what is preventing the lastest kernel upload from booting on revB?
[13:59] <lool> ogra: our x-loader + our u-boot == fail, our x-loader + rcn-ee's older u-boot == work
[13:59] <rcn-ee> lool, no the x-loader and u-boot in ubuntu has all the XM tweaks, i think qemu might be missing one of the new changes...
[13:59] <ogra> lool, in qemu
[13:59] <lool> rcn-ee: Ok
[13:59] <ogra> rcn-ee, it doesnt
[14:00] <rcn-ee> amitk, will do, i took half of today off, so starting noon (central) i'm free for regression stuff.
[14:00] <ogra> rcn-ee, XM support landed after my checkout, i asked sarkoman explicitly for the best combo for revC
[14:00] <lool> at least I can get qemu as far as loading the kernel and uncompressing it
[14:00] <ogra> amitk, even if the kernel boots it wont be usable anyway
[14:00] <lool> I'm afraid nothing happens afterward
[14:01] <amitk> rcn-ee: thanks! people.canonical.com:~/amitk/ti/ has the .deb if you don't want to wait for the official builds
[14:01] <rcn-ee> ogra, i guess i haven't looked too closely at which checkout ubuntu pulled...
[14:01] <amitk> ogra: why can't you pull an update of xloader and uboot?
[14:02] <ogra> amitk, because i'm busy debugging your kernel and the SIGBUS ?
[14:02] <ogra> amitk, i can pull an update on the weekend
[14:02] <amitk> aah, I thought there was some more sinister reason
[14:02] <ogra> amitk, but since we wont support XM for 10.04 thats moot, i dont want to break Cx support
[14:04] <rcn-ee> are you guys planning a 10.04.1 arm rebuild? (i'm hoping to sneak some xm patches for that.. with amitk's blessing of course. ;))
[14:04] <ogra> rcn-ee, nope
[14:04] <ogra> 10.04 will be a one shot omap3 revC image
[14:04] <amitk> rcn-ee: we can always do PPA if these mean devs don't let us push stuff into the archive ;)
[14:05] <ogra> right, PPA is fine
[14:05] <lool> rcn-ee: Do feel free to push as many interesting patches on launchpad
[14:05] <rcn-ee> okay good to know...  and i can always write a script to tweak the image.... ;)
[14:05] <ogra> for 10.04 the plan is to have *something*
[14:05] <ogra> which we are still far away from
[14:06] <rcn-ee> it's good ground work for 10.10... More of the omap stuff should be upstream by then, including the multi omap stuff..
[14:06] <amitk> rcn-ee: I'm curious though if you were using your EHCI port for the USB bug? Or do you plug in your hub into the OTG port?
[14:07] <rcn-ee> For that bug testing, I'm just using a Bx board. so only OTG (otg to usbA adapter and hub..)
[14:08] <NCommander> WOOO, OOO EXPLODED!
[14:08] <NCommander> yay
[14:08] <NCommander> (I think)
[14:09] <amitk> rcn-ee: aah, the revBs have no EHCI port soldered onto the pad, I believe...
[14:09] <amitk> (broken ehci implementation and all that)
[14:09] <ogra> EVERYONE: http://people.canonical.com/~ogra/lucid-netbook-armel+omap.img ********* please help debugging this image !!! **************
[14:10] <ogra> should properly work on Cx boards
[14:10] <NCommander> ogra: do we have a guide for doing omap on QEMU?
[14:10] <rcn-ee> Correct...  however the EHCI still pops up in lsusb, it's just not soldered to anything, since that port was snafu on the omap35x. the Cx boards route to a different pin..
[14:10] <ogra> NCommander, ask lool, he does the qemu-maemo playing atm
[14:10]  * XorA grabs ogras image
[14:10] <ogra> :D
[14:10] <XorA> does it have zippy patches?
[14:11] <ogra> you'll get into a live session properly
[14:11] <ogra> it has whatever will end up in the archive tonight
[14:11] <ogra> plus using 50% compcache to prevent OOM
[14:11] <rcn-ee> XorA, last i tried you have to be careful with the zippy patches, as it causes boards to lock up post 2.6.29... (but i haven't testd my zippy2 witk Koen's new u-boot that reads the i2c)
[14:12] <ogra> i.e. you can run firefosx in the live session without running out of ram
[14:12] <rcn-ee> (zippy2 patch kernel + board with no zippy2 = lockup)
[14:12] <ogra> i dont think amitk added zippy patches
[14:12] <XorA> bang goes me network :-)
[14:12] <amitk> XorA: no zippy patches
[14:13] <rcn-ee> XorA, do you have a zippy1 or zippy2? I have pre-build lucid chroot *.deb on rcn-ee.net for zippy2..
[14:13] <ogra> my USB->ETH adapter works fine though
[14:13] <XorA> rcn-ee: zippy1, zippy2 wasnt public when I met prpplague
[14:15] <rcn-ee> *heads off to work..
[14:16] <amitk> nosse1: you could test out the above image too; I've disabled sound on the EVM boards for now. So if you can tell me if this allows you to boot, that would be great.
[14:26] <dmart> Does anyone know how the apport retracing service works?  Currently it doesn't generate useful output because gdb needs debug symbols in order to make a reasonable attempt at the backtrace.
[14:28] <lool> dmart: We should be providing these debug symbols in the form of -dbgsym packages
[14:29] <ogra> wohooo !!!
[14:29] <ogra> my zoom2 arrived
[14:29] <dmart> lool: yes, but retracing service doesn't seem to have them installed when it generates backtraces
[14:30] <dmart> ogra: very 80s look
[14:30] <XorA> ogra: zoom2 or 3?
[14:30] <dmart> lots of black plastic
[14:30] <dmart> ;)
[14:30] <ogra> XorA, zoom2 with upgrade kit
[14:30] <XorA> ogra: bah
[14:31] <ogra> dmart, giant blackberry
[14:31] <XorA> ogra: Ive been waiting weeks for mine
[14:32] <lool> dmart: I think you can try replicating the apport behavior locally with apport-retrace
[14:32] <lool> dmart: the ddebs should be fetched from ddebs.ubuntu.cim
[14:33] <dmart> Is apport-retrace supposed to do that automatically?
[14:33] <lool> Yes
[14:33] <lool> I think :)
[14:34] <dmart> Also, I find the name of the debug package is unpredictable, because some package generate their own -dbg in the main archive, others generate -dbgsym on ddebs.ubuntu.com, and there seems not always to be a 1:1 relationship between binary packages and debug packages
[14:34] <dmart> Is there an easy way to guess the correct debug packages?
[14:36] <persia> Unfortunately not.
[14:36] <lool> dmart: Ignore -dbg packages
[14:36] <lool> dmart: We only care about -dbgsym ones which should be generated almost all the time
[14:36] <lool> dmart: We just inherit -dbg from Debian
[14:37] <persia> Um, not quite.  We have some -dbg native to Ubuntu, and packages with nostrip don't generate -dbgsyms
[14:38] <lool> persia: I'm not sure what you mean
[14:39] <persia> 1) There exist packages in the Ubuntu archive that have -dbg packages that do not have -dbg packages in Debian.  2) Packages that don't call dh_strip in the usual fashion don't get dbgsyms: this is not uncommon for packages that also have -dbg variants.
[14:39] <NCommander> dmart: it does
[14:40] <NCommander> dmart: the retracer isn't very happy this morning, and the image may have had stale debs installed
[14:40] <persia> apport-re
[14:40] <dmart> When the apport retracing service appends backtraces to bug reports they tend to look like this: http://pastebin.ubuntu.com/411615/
[14:40] <dmart> I was hoping we might be able to improve it...
[14:41] <NCommander> dmart: I'm aware, but if the dbgsym's are out of date/newer than what is available, the retrace explodes. Also some kernel bugs can cause crappy retraces
[14:41] <NCommander> dmart: I'm working on the broken OOo segfault, I think we're looking at a toolchain regression, bisecting now
[14:41] <lool> Well I can't go past Uncompressing Linux... with any kernel I try, hmm
[14:45] <dmart> Do we not keep old debug packages on the servers for a bit?
[14:45] <lool> dmart: Not too much I'm afraid
[14:47] <lool> persia: Concerning -dbg which we add in Ubuntu, we still have -dbgsym for them; we only provide -dbg for end-users, not apport, right?  and concerning packages not using dh_strip and not having -dbgsym as a result, these are bugs/limitations, but the apport model still relies on -dbgsym AFAIK
[14:47] <NCommander> dmart: /win 31
[14:47] <NCommander> er
[14:47] <lool> The vast majority of packages with ELF binaries have -dbgsym packages and that's the main use case I believe
[14:48] <lool> NCommander: /win 42 to you too
[14:49] <NCommander> lool: heh, I've jumped from x-chat to irssi
[14:49] <persia> lool: I'll agree with you that apport relies on -dbgsym.  I just want to make sure everyone understands that it's not quite perfect yet.
[14:50] <dmart> lool: sure, but many key projects have their own -dbg packages instread, so it's hard to automate fetching the debug packages.
[14:51] <lool> dmart: As I said, the machine-usable service is based around -dbgsym packages -- not -dbg; we can fix these if they are missing for this or that package/architecture
[14:51] <dmart> Forcibly pulling in libc6-dbg might help
[14:51] <lool> dmart: or what do you mean with "key projects"?
[14:52] <dmart> Things like eglibc, firefox etc.
[14:52] <lool> dmart: Well you typically want libc6-dbgsym_2.11.1-0ubuntu5_armel.ddeb
[14:52] <dmart> hmmm
[14:52]  * dmart wonders why he failed to find that in the past...
[14:53] <lool> dmart: You need to add the ddeb repo to your sources.list and then call apport-retrace I think
[14:53] <lool> (and apt-get update inbetween)
[14:53] <lool> dmart: -dbg are not meant for apport, but for end-user or specific use cases (e.g. valgrind)
[14:53] <dmart> Does apport-retrace pull in the debug packages for the whole library stack?  This is the other problem we get: the backtrace will tend to die whenever it reached a frame with no debug info.
[14:53] <lool> or to help Debian-style debugging
[14:53] <lool> dmart: In theory it should do something ensuring it gets the proper -dbgsym packages installed
[14:55] <dmart> Do you know whether old debug packages are mirrored / backed up somewhere?  Maybe there is a problem with them often having disappeared by the time a bug gets reported.
[14:55] <lool> dmart: there's an apport-retracer chroot creation script which comes at least in the apport source
[14:55] <dmart> Hmmm, I'll try and have a play with that at some point
[14:55] <lool> dmart: Yes, that's common indeed; I'm afraid we don't keep them for too long as this is huge; pitti might have some details there
[14:57] <dmart> I think some work is being done to improve gdb's backracing, but I don't think it's all merged yet, unfortunately...
[14:57] <lool> dmart: ack; -dbgsym are meant exactly for what you need in the mean time I guess
[14:57] <dmart> ok, I'll try to persevere with that
[14:58] <dmart> NCommander: it sounds like you might need to grab some dbgsyms if you want a better backtrace for the bash segfault in the OOo build
[14:58] <lool> dmart: Basically, we divert dh_strip during package builds and take a copy of the debug symbols just before calling the real dh_strip
[14:58] <lool> because it's made automatically for all build, it covers almost all packages
[14:59] <dmart> Maybe the difficulties I had previously were to do with disappeared package versions.  It was a while ago now.
[15:05] <dmart> NCommander: Am I understanding the OOo build issue correctly?  It looks to me like a bash crash in the build and not something directly connected with the OOo sources?
[15:09] <NCommander> dmart: its not a bash crash
[15:12] <dmart> Is this bug 555977?
[15:12] <ubot4`> Launchpad bug 555977 in openoffice.org (Ubuntu Lucid) (and 1 other project) "openoffice.org FTBFS on armel (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/555977
[15:13] <NCommander> dmart: thats it
[15:13] <ogra> ndechesne, http://people.canonical.com/~ogra/lucid-netbook-armel+omap.img and http://people.canonical.com/~ogra/live-initrd-roller.sh (note that your kernel needs squashfs and aufs at least)
[15:13] <NCommander> dmart: I'm confirming if we're looking at regression in gcc. If it is, at least its a lot less of a nightmare to debug it
[15:14] <dmart> What's the nature of the problem exactly?  I thought it was a build failure:
[15:14] <dmart>  /bin/bash: line 1: 24891 Segmentation fault
[15:14] <NCommander> dmart: it is, due to saxparser segfaulting, which appears to be a regression caused by a toolchain update
[15:15] <dmart> Oh, right--- my confusion
[15:15]  * NCommander pedals faster
[15:56] <asac> bug 559295, bug 559301 and bug 559297 for omap issues
[15:56] <ubot4`> Launchpad bug 559295 in flash-kernel (Ubuntu Lucid) (and 1 other project) "flash-kernel-installer needs to learn to handle omap (affects: 1)" [High,New] https://launchpad.net/bugs/559295
[15:56] <ubot4`> Launchpad bug 559301 in partman-uboot (Ubuntu Lucid) (and 1 other project) "partman-uboot needs to handle omap installs (affects: 1)" [High,New] https://launchpad.net/bugs/559301
[15:56] <ubot4`> Launchpad bug 559297 in flash-kernel (Ubuntu Lucid) (and 1 other project) "flash-kernel needs to learn to handle omap (affects: 1)" [High,New] https://launchpad.net/bugs/559297
[15:58] <asac> bug 559144
[15:58] <ubot4`> Launchpad bug 559144 in udisks (Ubuntu Lucid) (and 1 other project) "[armel] udisks-part-id crashed with signal 7 in memcpy() (affects: 1) (heat: 12)" [High,New] https://launchpad.net/bugs/559144
[16:03] <asac> bug 541399
[16:03] <ubot4`> Launchpad bug 541399 in debian-installer (Ubuntu) "netboot image fails to boot. (affects: 1) (heat: 8)" [Medium,Fix committed] https://launchpad.net/bugs/541399
[16:10] <ndechesne> ogra: thanks. will try this.
[16:12] <asac> ndechesne: i asked cpearson something in pmsg ;)
[16:12] <asac> NCommander: can you poke him to look at his client ;)
[16:12] <asac> ndechesne: oh sorry
[16:12] <asac> ndechesne: figured that you are not on the same continent ;)
[16:12] <asac> nev3rmind
[16:14] <ogra> hahaha
[16:14] <ogra> ndechesne, just stretch your arm !
[16:16] <plars> asac: bug #541030 is omap related for your list, and just went to fix committed
[16:16] <ubot4`> Launchpad bug 541030 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "omap kernel musb/ehci ports not enabled on beagleboard (affects: 1) (heat: 14)" [High,Fix committed] https://launchpad.net/bugs/541030
[16:17] <asac> plars: hmm ogra said thats fixed ... so didnt mention it at all
[16:17] <asac> let me add
[16:17] <plars> asac: also, bug #542041 was dropped, unless it becomes reproducible again (it was from before we had images)
[16:17] <ubot4`> Launchpad bug 542041 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "ext4 support broken on omap kernel (affects: 2)" [High,Invalid] https://launchpad.net/bugs/542041
[16:17] <plars> asac: hmm... he probably knows better than I, I didn't go look to see if it had already been uploaded.  If it's not fixed, then it's *just* about to be
[16:18] <ogra> plars, it was also a different kernel
[16:18] <plars> right
[16:18] <ogra> leave the ext4 one out for now
[16:18] <asac> plars: yeah. now its fix committed in the report ;)
[16:18] <asac> ogra: so we should untarget the ext4 bug
[16:18] <asac> ogra: #
[16:18] <asac> 559295: flash-kernel-installer needs to learn to handle omap
[16:18] <asac> #
[16:18] <asac> 559297: flash-kernel needs to learn to handle omap
[16:18] <asac> shouldnt that be one bug ;)?
[16:18] <plars> done
[16:18] <ogra> no, its two apps
[16:19] <plars> the untarget that is
[16:19] <asac> ok
[16:19] <ogra> i want the two implementation details distinct
[16:19] <asac> thanks plars
[16:19] <ogra> its the same package though
[16:19] <asac> ogra: then its one bug ;)
[16:19] <asac> sourc epackage needs to learn ompap
[16:19] <asac> but ok
[16:19] <asac> we will survive i am sure
[16:20] <ogra> well, one part affects the installer only, the other the general upgradeability
[16:20] <ogra> their possibility of impact is different
[16:20] <ogra> and i will neeed FFe bugs for both features i guess
[16:26] <asac> bug 541399
[16:26] <ubot4`> Launchpad bug 541399 in debian-installer (Ubuntu) "netboot image fails to boot. (affects: 1) (heat: 8)" [Medium,Fix committed] https://launchpad.net/bugs/541399
[16:26] <prpplague> ogra: ping
[16:26] <ogra> prpplague, yep
[17:21] <nosse1> amtik, I'm testing the image now. However, I don't think support for the specific LCD panel of the EVM has been compiled into the kernel, so the panel doesn't work.
[17:22] <nosse1> Is there a boot parameter for making the installer run solely in text mode (against console) ?
[17:23] <ogra_cmpc> nosse1, no, its a live image
[17:23] <ogra_cmpc> identical to UNR on i386
[17:24] <amitk> nosse1: remove "quiet splash" to atleast be able to see the kernel bootup. And add "console=.... serialtty=ttyS2" to enable serial console in your boot.cmd
[17:24] <nosse1> ogra_cmpc, ok. Is it possible to run the _live image_ without a gfx scereen?
[17:24] <amitk> and then compile it to a uboot script format
[17:24] <nosse1> amitk, done that. The last thing the console displays is:
[17:24] <ogra_cmpc> no, you can have a serial login though
[17:26] <nosse1> Here's the output I got: http://pastebin.com/Lii2QqZx
[17:28] <ogra_cmpc> you are missing serialtty=ttyS2 in your cmdline
[17:29] <nosse1> ogra_cmpc, No, I didn't. But I did initially. Thats why there are two lines with setenv bootargs
[17:30] <ogra_cmpc> note serialtty != console
[17:30] <nosse1> ah, sorry
[17:30]  * nosse1 retrying
[17:30] <ogra_cmpc> you need serialtty=ttyS2 additionally
[17:30] <ogra_cmpc> that will tell casper to spawn a login shell on the serial tty oyu defined
[17:33] <ogra_cmpc> amitk, hmm, i guess with adding the DSS2 stuff the kernel doesnt work on zoom anymore
[17:33] <ogra_cmpc> i dont get it to uncompress
[17:34] <nosse1> Sorry, It stops at the same place as the pastebin above.
[17:36] <ogra_cmpc> can you pastebin it again ?
[17:36] <nosse1> I should note that I have not been able to run Ubuntu yet on target, even with rootstock images
[17:36] <nosse1> Yes, sure. Hold on
[17:37] <nosse1> http://pastebin.com/WK9CNB2M
[17:38] <ogra_cmpc> and disk access stops at that point ?
[17:39] <amitk> ogra_cmpc: uncompressin almost never has anything to do with drivers
[17:40] <nosse1> Yes it seems so. I don't really know, as there's no led on the sdcard activity.
[17:40] <nosse1> I *could* bring out my scope
[17:40] <ogra_cmpc> amitk, hmm, it saw it booting with the old archive kenrel in nice
[17:43] <nosse1> amtik, How long time does it take to until the new omap kernel makes it to ports.ubuntu.com ?
[17:43] <ogra_cmpc> https://edge.launchpad.net/ubuntu/+source/linux-ti-omap/2.6.33-500.5/+build/1684225
[17:43] <ogra_cmpc> still building
[17:44] <nosse1> excellent
[17:44] <ogra_cmpc> once thats done an archive admin needs to approve it to move it out of the NEW queue
[17:44] <nosse1> When its done, I'll give it another go on the AM3517 EVM
[17:44] <ogra_cmpc> then apw needs to upload a new meta
[17:45] <ogra_cmpc> nosse1, the kernel just building is identical to the one in the image you just tried
[17:45] <apw> ogra_cmpc, shouldn't need a meta for ti-omap, no abi-bump
[17:45] <ogra_cmpc> apw, ah, sweet
[17:45] <ogra_cmpc> hmm, no abi bump should also mean no NEWing
[17:46] <apw> once you have a good kernel which boots in an image, then we'll bump so you keep that
[17:46] <apw> ogra_cmpc, indeed it should
[17:46] <Martyn> I just re-installed the Dove board, and the tegra2, and the smooth-stone prototype board, and the versatile express 2 with the latest lucid build .. looks good
[17:46] <ogra_cmpc> sweet
[17:46] <nosse1> ogra_cmpc, Ah, so I can take the uImage and extract the kernel/modules from the rootfs. I'll try
[17:46] <Martyn> tasksel server takes FOR-frigging-ever to run on the versatile express 2
[17:46] <apw> ogra_cmpc, in theory its a no-watch situation, of course pkgmgler will core dump and we'll have to put it back
[17:46] <ogra_cmpc> Martyn, so you like the new themes ? :P
[17:46] <Martyn> ogra : I'm ... ambivalent
[17:47] <Martyn> ogra : I've gotten _so_ used to the old brown theme, that the new theme is .. disturbing
[17:47]  * ogra_cmpc likes it
[17:47] <ogra_cmpc> the brown got tiring
[17:47] <ogra_cmpc> and i have seem whats ahead the road for M :)
[17:48] <ogra_cmpc> changing the color is only the first step towards revolution :)
[17:48] <Martyn> right now though, I'm less worried about THEME as getting server -stable- on lucid
[17:48] <ogra_cmpc> whats unstable about it ?
[17:48] <Martyn> we're missing some mission-critical libraries, and there's nothing that can be done for Lucid
[17:49] <Martyn> there will be no way to compile hiphop on the ARM platform until libtbb2 is ported and tested
[17:49] <Martyn> memcached is unstable, but useable
[17:49] <ogra_cmpc> ah, yeah, armel PPAs would really be a good thing
[17:49] <Martyn> latest mysql runs, but has performance issues even when the proccessor is quad core and there are 4MB of L2 cache.   No idea where the slowness is coming from, but doing the streams benchmark is giving me an idea
[17:49] <ogra_cmpc> so you could easily build your own stuff on top of the distro
[17:50] <Martyn> ogra : Yeah .. well .. you know my goal is to make M //the// distribution for server
[17:50] <Martyn> on armel
[17:50] <ogra_cmpc> Martyn, indeed you filed a huge pile of bugs for all these issues :)
[17:50] <Martyn> ogra : no, I //will// be filing them for M
[17:50] <Martyn> L wasn't the right plaef
[17:50] <Martyn> place rather
[17:50] <ogra_cmpc> then stop moaning :P
[17:50] <Martyn> besides, I didn't get server-class hardware until two weeks ago
[17:51] <Martyn> Oh, I'm not moaning... in fact I just got my tickets for Brussels
[17:51] <Martyn> I wish the hotel was cheaper though...
[17:51] <ogra_cmpc> cool
[17:51] <Martyn> 130euro a night, and 150euro on weekends
[17:51] <ogra_cmpc> there is a discount pointed out onm the wiki
[17:51] <Martyn> that's WITH the discount
[17:51] <ogra_cmpc> wow
[17:51] <Martyn> ogra : Yeah, makes me wish I had an apartment in Brussels
[17:52] <ogra_cmpc> you should move to a place with a decent currency ;)
[17:52] <Martyn> for 1600 euros.. I could rent a REALLY nice place for a month
[17:52] <ogra_cmpc> then it hurts less
[17:52] <Martyn> has nothing to do with the currency .. it's the venue, taking advantage that there are three conferences in Brussels all at once, and one of them is UN related
[17:52] <ogra_cmpc> ah
[17:52] <Martyn> ogra : Canonical pays for you, Smooth-Stone pays for me :)  I'
[17:53] <Martyn> I'm just ... frugal ...
[17:53] <ogra_cmpc> the good thing is that the hotel is in the middle of nowhere
[17:53] <Martyn> and anything I don't have to pay for hotel, could be used for more entertaining purposes
[17:53] <ogra_cmpc> so you cant spend money running around in the city
[17:53] <Martyn> BAH, humbug
[17:53] <Martyn> like the one they picked for Dallas.
[17:54] <ogra_cmpc> that was relatively close to the city
[17:54] <armin76> thats what happens when you go to ubuntu stuff :P
[17:54] <ogra_cmpc> we had worse hotels
[17:54] <ogra_cmpc> the paris one was 40km away ... next to the airport
[17:55] <ogra_cmpc> and a beer at the hotel bar was 9euro
[17:57] <armin76> in some conf they made our distro build the stand :D
[18:03] <ndechesne> ogra: what are the bootargs you use on the live image for omap?
[18:04] <lool> ndechesne: quiet splash vram=12M omapfb.mode=dvi:1280x720MR-16@60 + seed + -- boot=casper
[18:04] <lool> for live images
[18:04] <ogra_cmpc> quiet splash vram=12M omapfb.mode=dvi:1280x720MR-16@60 file=/cdrom/preseed/ubuntu.seed -- boot=casper
[18:04] <ndechesne> lool: you were faster ;-)
[18:04] <lool> schnipschnap
[18:04] <ogra_cmpc> ubuntu.seed is wrong btw
[18:04] <ndechesne> lool, ogra: thanks
[18:04] <armin76> fail
[18:05] <ogra_cmpc> tomorrows image will have the right seed name
[18:05] <lool> ndechesne: Do you have a reference of SYS_BOOT information passing between ROM and x-loader?
[18:05] <lool> ndechesne: Is this in some public doc somewhere?
[18:05] <ndechesne> ogra: basically, what bootargs should I use to try to boot the image on the Zoom2/3
[18:05] <ogra_cmpc> ndechesne, i havent succeeded yet to boot it on the zoom
[18:05] <ndechesne> lool: i think it should be in the OMAP3 TRM
[18:06] <ogra_cmpc> i suspect i use the wrong load adresses for initrd and uimage
[18:06] <ndechesne> ogra: up to where are you going?
[18:06] <lool> ndechesne: ok thanks
[18:06] <ogra_cmpc> i tried the defaults that were in the nand
[18:06] <ogra_cmpc> 0x8c100000 for uImage and a guessed 0x82000000 for uInitrd
[18:07] <ogra_cmpc> but the kernel doesnt uncompress
[18:11] <ogra_cmpc> i suspect i'm overwriting something somewhere
[18:12] <Martyn> omap4 kernel, omap4 hardware not working with the current build
[18:12] <Martyn> upstart is failing
[18:12] <ndechesne> ogra: where did you get these addresses? it's been a while since i haven't used my zoom
[18:12] <ndechesne> martyn: omap4? which kernel are you using?
[18:12] <Martyn> I'm going to recreate the rootfs, and try again
[18:13] <Martyn> ndechesne: Same as the standard ubuntu kernel, but patched with omap4 support.  It worked last week, so something changed
[18:13] <Martyn> I can single mode, so it's not the kernel
[18:13] <ogra_cmpc> ndechesne, the 0x81c00000 was the default load address in uboot in nand
[18:13] <ogra_cmpc> the 0x8200000 is just a guess
[18:14] <ndechesne> ogra: but you need to put the uImage and initrd in DDR, not NAND, right?
[18:14] <ndechesne> martyn: where did you get the OMAP4 patches? I am asking because there are many places ;-)
[18:15] <ndechesne> martyn: I have 10.04 latest + UNE running on OMAP4. I built root fs with rootstock (e.g. it's not a live image), and I am based of TI OMAP4 kernel: http://dev.omapzoom.org/?p=integration/kernel-omap4.git
[18:16] <ogra_cmpc> ndechesne, i fatload them
[18:16] <Martyn> Yeah, I've been skipping some of the kernel-omap4.git patches, because they start forking from mainline too far
[18:16] <Martyn> and that means I can't get other patches to work, like the OpenVZ patch set
[18:17] <ndechesne> ogra: ok, so dst address need to be in DDR range, and 0x82000000 is not
[18:17] <ogra_cmpc> well, even if i omit uInitrd and only load to 81c00000 it doesnt uncompress
[18:19] <ndechesne> ogra: i usually put the uImage at 80300000 or 80200000
[18:19] <ogra_cmpc> http://paste.ubuntu.com/411706/
[18:20]  * ogra_cmpc tries 80200000
[18:21] <ndechesne> ogra: oops I forgot you are on Zoom3. Zoom3 has a different CPU than beagle (3630 vs 3430). I am not sure your current kernel has full support for 3630. can you try on zoom2?
[18:21] <ogra_cmpc> yeah, need to replace the CPU though
[18:26] <ogra_cmpc> ah, only 256M
[18:26] <ogra_cmpc> *sniff*
[18:27] <ndechesne> ogra: just tried on my Zoom2, and the kernel boots at @80200000
[18:27] <ndechesne> ogra: yes 256Mb ;-(
[18:28] <ogra_cmpc> nope
[18:29] <ogra_cmpc> fatload mmc 0:1 0x80200000 /casper/uImage
[18:29] <ogra_cmpc> bootm 0x80200000
[18:29] <ogra_cmpc> ...
[18:29] <ogra_cmpc> Starting kernel ...
[18:29] <ogra_cmpc> nothing ...
[18:29] <ndechesne> ogra: on zoom2 or zoom3
[18:29] <ogra_cmpc> zoom2
[18:30] <ndechesne> on my side, kernel boots until it tries to mount the root fs
[18:30] <ogra_cmpc> i just changed the SOM back to the one that was in the device
[18:30] <ndechesne> hum, it could be your uboot/mlo
[18:30] <ogra_cmpc> NAND OMAP34XX ZOOM2 #
[18:30] <ogra_cmpc> in any case 34xx
[18:30] <ogra_cmpc> if i can trust the installed uboot
[18:31] <ogra_cmpc> U-Boot 1.1.4-dirty (Mar 27 2009 - 11:27:11)
[18:31] <ndechesne> U-Boot 1.1.4 (Jun  5 2009 - 15:00:50)
[18:31] <ogra_cmpc> x-loader doesnt generate any output
[18:31] <ogra_cmpc> hmm
[18:32] <ndechesne> so I just need to fatload uImage, and initrd? and use the bootargs you gave me, right?
[18:32] <ogra_cmpc> right
[18:32] <ogra_cmpc> and indeed buse both load addresses with bootm
[18:33] <ogra_cmpc> so it switches to the initrd
[18:33] <ogra_cmpc> (there is a boot.scr in the image toplevel dir)
[18:33] <ndechesne> what do you mean? can you give your commands?
[18:34] <ogra_cmpc>         fatload mmc 0:1 0x80000000 /casper/uImage
[18:34] <ogra_cmpc>         fatload mmc 0:1 0x81600000 /casper/uInitrd
[18:34] <ogra_cmpc>         setenv bootargs quiet splash vram=12M omapfb.mode=dvi:1280x720MR-16@60 file=/cdrom/preseed/ubuntu.seed -- boot=casper
[18:34] <ogra_cmpc>         bootm 0x80000000 0x81600000
[18:34] <ogra_cmpc> thats the default boot.scr on the image
[18:34] <nosse1> ogra_cmpc, how does the kernel where to find the root image? Or is the initrd all that's needed? I mean how can the system know that it needs to access the /casper/filesystem.squashfs on /dev/mmc0p1...
[18:35] <ogra_cmpc> the initrd scans all devices it finds for that file
[18:35] <ogra_cmpc> if you set boot=casper on the cmdline the casper script is executed... casper is the tool that sets up the live environment and mounts the squashfs in an aufs mount
[18:36] <nosse1> ogra_cmpc, Would it be possible for you to post a console output of a working target?
[18:36] <ogra_cmpc> not atm, the zoom doesnt boot and i dont have any other target around
[18:36] <nosse1> :D sure, np
[18:37] <ogra_cmpc> nosse1, but your paste clearly shows you end up in the initrd
[18:37] <nosse1> or :( is perhaps more correct
[18:37] <ogra_cmpc> Loading, please wait...
[18:37] <ogra_cmpc> thats the first line the initramfs writes
[18:37] <ogra_cmpc> try booting with break=top
[18:37] <ogra_cmpc> and see if you end up in a busybox shell
[18:38] <nosse1> Yes, clearly initrd, however I doubt is has completed and ready to pass over to rootfs
[18:38] <nosse1> I'll try, thanksw
[18:38] <ogra_cmpc> nosse1, also how long did you wait for a console
[18:38] <ogra_cmpc> it might be very slow on 256M
[18:39] <ogra_cmpc> (its relatively decent on beagle though)
[18:40] <Martyn> AARRRRGGGGHHHH!
[18:40] <Martyn> omap4 didn't boot because one of the NAND chips has a bit error on it
[18:40] <Martyn> and that error is in the first block.  Fuck
[18:41] <ogra_cmpc> ndechesne, you really need to update to a decent uboot that 1.4.x series is just annoying (hush shell support rules)
[18:42] <ndechesne> ogra: this is weird, if i set bootargs, then my kernel does not boot. if I run bootm without setting the bootargs it does boot....
[18:42] <ogra_cmpc> try dropping the video stuff
[18:42] <ogra_cmpc> thats clearly for beagle
[18:42] <ndechesne> ogra: i know... the problem when you don't stick to mainline, is that the more you wait the more painful it is to catch up ;-)
[18:42] <ogra_cmpc> yeah
[18:43] <nosse1> I didn't get any output from kernel until I added console= (and ogra later told to add serialtty=)
[18:43] <ogra_cmpc> serialtty is really only for getting a login prompt
[18:44] <ogra_cmpc> https://edge.launchpad.net/ubuntu/+source/linux-ti-omap/2.6.33-500.5/+build/1684225
[18:44] <ogra_cmpc> sweet ... kernel finished
[18:45] <nosse1> Argh. The break=top had no effect
[18:45] <nosse1> "Loading please wait..." is the last lifesign from the board
[18:45] <ogra_cmpc> you cond get the ramzswap stuff anymore >
[18:46] <ogra_cmpc> ?
[18:46] <ogra_cmpc> *dont
[18:46] <nosse1> Dont
[18:46] <ogra_cmpc> sigh, that cmpc knbd is so small
[18:46] <ogra_cmpc> *kbd
[18:48] <nosse1> BTW: How can I force a module to load during boot? I thought editing /etc/modules would, but looking in the initrd, there's no conf/modules file present
[18:49] <ogra_cmpc> there is a special /etc/initramfs-tools/modules you can use
[18:49] <ogra_cmpc> but you need to rebuild the initrd
[18:49] <nosse1> sure, thanks
[18:51] <nosse1> What is the real difference between update-initramfs's -c (create) and -u (update)?
[18:53] <ogra_cmpc> u updates and creates a backup of the old one
[18:54] <ndechesne> ogra: still something weird on my board. if I don't set the bootargs and load uimage and uinitrd, i can get the initramfs prompt
[18:55] <ogra_cmpc> what bootargs do you use now ?
[18:56] <ndechesne> nevermind... it's too late ;-) i forgot the console stuff.
[18:56] <ogra_cmpc> ndechesne, the only arg thats actually necessary is boot=casper
[18:57] <ogra_cmpc> you shouldnt need console if you have any external display you can drive
[18:57] <ndechesne> with setenv bootargs 'console=ttyS3,115200n8 mem=256M splash file=/cdrom/preseed/ubuntu.seed -- boot=casper', kernel boots, but omapfb fails, so there is no display.
[18:57] <ogra_cmpc> yeah
[18:58] <ogra_cmpc> try adding serialtty=ttyS3
[18:58] <ndechesne> what does it bring?
[18:58] <ogra_cmpc> should spawn a getty on ttyS3
[18:58] <ogra_cmpc> so you get a serial login
[18:58] <ndechesne> ok
[18:59] <ndechesne> with the normal bootargs, on zoom2, kernel crashes with some usb problems.. but I am using the old .img from 2 days ago....
[19:00] <ogra_cmpc> oh
[19:00] <ndechesne> yup ... ;-)
[19:00] <ogra_cmpc> yeah, use the img from my people.canonical.com page
[19:00] <ogra_cmpc> that has a kernel with fixed USb
[19:01] <ndechesne> i need to go now... i will try the new image on monday ... but I think that the new image will not resolve the omapfb issue. i will look into that on monday.
[19:02] <ogra_cmpc> yeah, unliklely that omapfb works on anything but beagle i guess
[19:02] <nosse1> ndechesne, you say Zoom2, is that the beagle you're talking about?
[19:02] <ogra_cmpc> nosse1, nope thats the zoom
[19:02] <ogra_cmpc> http://omapzoom.org/
[19:03] <nosse1> What CPU? Because this kit (AM3517-EVM) is also a Zoom kit (IMHO)
[19:03] <ndechesne> nosse1: zoom2 has 3430, zoom3 has 3630.
[19:03] <ndechesne> ogra: is that the one: http://people.canonical.com/~ogra/lucid-netbook-armel+omap.img
[19:03] <ogra_cmpc> right
[19:04] <ndechesne> ok. i will start download now, and leave, bye.
[19:04] <ogra_cmpc> you should have usb
[19:04] <ogra_cmpc> have a nice weekend
[19:04] <nosse1> http://www.logicpd.com/products/development-kits/zoom-am3517-evm-development-kit
[19:04]  * ogra_cmpc also calls it beer'o clock now
[19:05] <nosse1> Yeah! for good product (re)naming....
[19:13]  * ogra_cmpc slaps forehead
[19:13] <ogra_cmpc> oh my
[19:13] <ogra_cmpc> console=/dev/ttyS3,115200n8
[19:13] <ogra_cmpc> indeed that cant boot
[19:14]  * ogra_cmpc wonders how that got in the default env
[19:17] <plars> heh
[19:18] <ogra_cmpc> sweet, it seems to boot
[19:20] <ogra_cmpc> hmm, no, boot ends at squashfs
[19:20] <ogra_cmpc> oh, its just slow
[19:21]  * ogra_cmpc twiddles thumbs 
[19:21] <ogra_cmpc> wohoo
[19:22] <ogra_cmpc> nosse1, so on the zoom2 i get a boot but it takes about 2 min
[19:22] <ogra_cmpc> ubuntu@ubuntu:~$ cat /proc/cpuinfo |grep Hard
[19:22] <ogra_cmpc> Hardware        : OMAP Zoom2 board
[19:23] <ogra_cmpc> setenv bootargs console=ttyS3,115200n8 serialtty=ttyS3 file=/cdrom/preseed/ubuntu-netbook.seed -- boot=casper
[19:23] <ogra_cmpc> mmcinit
[19:23] <ogra_cmpc> fatload mmc 0:1 0x80200000 /casper/uImage
[19:23] <ogra_cmpc> fatload mmc 0:1 0x81000000 /casper/uInitrd
[19:23] <ogra_cmpc> bootm 0x80200000 0x81000000
[19:23] <ogra_cmpc> that gets it going for me
[19:25]  * ogra_cmpc goes to try 3630 now
[19:25] <nosse1> It gets going for me as well, except it stops somewhere down the line
[19:25] <ogra_cmpc> well, its takes quite long
[19:26] <ogra_cmpc> 2-3 min
[19:26] <nosse1> On my other test (trying to run roostocked lucid), it stops in the initrd on "+ wait-for-root /dev/mmcblk0p1 30"
[19:26] <nosse1> BTW: Why do you explicitly specify mem=xxM ?
[19:26] <ogra_cmpc> i dont ?
[19:26] <nosse1> well you don't, but I've seen it around here
[19:27] <nosse1> it was a general q
[19:27] <ogra_cmpc> you normally dont need to
[19:27] <ogra_cmpc> the kernel handles that fine
[19:30]  * nosse1 is giving it yet another go. Stopwatch on
[19:31] <nosse1> How many minutes until declared dead?
[19:33] <ogra_cmpc> max 5 i'd say
[19:33] <ogra_cmpc> amitk, any chance we can have 3630 together with 34xx in our kernel ?
[19:34] <nosse1> Do you guys use any JTAG tools in case of deep crash, or do you rely solely on SW mechanisms? In case which tools do you use?
[19:35]  * ogra_cmpc didnt have to debug such deep crashes yet 
[19:35] <ogra_cmpc> and all targets we support are usually unbrickable
[19:35] <ogra_cmpc> i.e. they support getting the bootloader from SD
[19:36] <prpplague> nosse1: i personally recommend the flyswatter and openocd, but i'm biased
[19:36]  * XorA recomands flyswatter as well
[19:36] <nosse1> Ah. Point is we are bringing forth new HW based on the OMAP, so for the custom driver development we need JTAG for observability. I was curious what other linux devlp. are using
[19:36] <prpplague> XorA: hehe thanks
[19:37]  * ogra_cmpc is a glue guy ... my work usually starts above kernel and with already existing bootloader sources 
[19:37] <prpplague> nosse1: openocd is not as robust as something like a BDI or lauterbach, but it generally works well enough to debug most issues with driver development
[19:38] <nosse1> I had a demo one of lauterbach with extremely smoooth kernel & userspace integration, however my boss wont agree on the pricetag :D
[19:38] <nosse1> s/one/once/
[19:41] <amitk> ogra_cmpc: yes, you can have 3630 support in the same kernel
[19:43] <nosse1> 13 mins passed. I think it's dead.
[19:43]  * nosse1 would be happy if he had a JTAG tool to see if target is really dead
[19:44] <amitk> nosse1: I've used lauterbach in my previous job, I've just acquired the tincan tools jtag, haven't tried it yet
[19:45] <nosse1> A local company is making a new tool named ZY1000: http://www.zylin.com/zy1000.html
[19:46] <nosse1> ...oh forgot - we've switched to A8 - which isn't listed yet
[19:49] <nosse1> Since the boot hangs on "+ wait-for-root /dev/mmcblk0p1 30", how can I modify Ubuntu for NFS root?
[19:49] <nosse1> Edit /etc/fstab, put up the NIC driver in /etc/initramfs/modules. More?
[19:52]  * nosse1 will try https://help.ubuntu.com/community/DisklessUbuntuHowto
[19:53] <prpplague> nosse1: openocd is free, and the flyswatter retails for $49.00
[19:54] <nosse1> prpplague, yeah, I saw that. Cheap!
[19:54] <prpplague> nosse1: i prefer inexpensive!
[19:55] <nosse1> prpplague, hehe we don't have that distinction in my language... Anyway they ship to Europe I hope
[19:56] <prpplague> nosse1: we do
[19:56] <XorA> heh, defineately not cheap
[19:56] <prpplague> nosse1: the USPS service is the cheapest shipping
[19:56] <nosse1> _we_?
[19:57] <rcn-ee> amitk, just tested your 500.4 link from this morning, the ehci port looks good on my C4 board.  Found all the random assorment of usb based devices...
[19:58] <prpplague> nosse1: i said i was biased
[19:58]  * prpplague designed the flyswatter
[19:58] <nosse1> lol
[20:00] <nosse1> prplague, I'd like to talk more about the flyswatter. However I haven't got the time now. Can I PM you later on this?
[20:01] <prpplague> nosse1: you can feel free to message me over in #edev to discuss it at any time
[20:01] <prpplague> nosse1: or pm me
[20:01] <nosse1> Thanks
[20:13] <nosse1> YYYEEESSS!!!!! I finally got Ubuntu up and running on target!
[20:13]  * nosse1 VERY HAPPY!
[20:13] <ogra_cmpc> what was it ?
[20:14] <ogra_cmpc> just slowness ?
[20:14] <nosse1> it's the kernel. I have compiled a new kernel using a newer one from TI
[20:14] <ogra_cmpc> ah
[20:15] <nosse1> And I'm running NFS root. The MMC is probably not working on the vanilla omap target
[20:15] <ogra_cmpc> works on the beagle and zoom
[20:16] <cpearson> @ogra: how is the Zoom coming along?
[20:16] <ogra_cmpc> cpearson, well, the 34xx version boots slower than the beagle, the 36xx one doewsnt work with our kernel
[20:17] <cpearson> same issue as with the XM?
[20:17] <ogra_cmpc> it just doesnt have 36xx support built in
[20:17] <ogra_cmpc> but amitk just said its possible
[20:17] <ogra_cmpc> so if we can we will enable it
[20:19] <ogra_cmpc> beyond that, our current image is indeed targeted for beagle so the framebuffer etc have issues
[20:31] <amitk> rcn-ee: \o/
[20:31] <amitk> ogra_cmpc: is 36xx support a priority over OTG/PM/ etc.?
[20:32] <rcn-ee> amitk, is there anything else on your check list?  I'm downloading ogra's latest *img file..
[20:32] <rcn-ee> making up a sd card for the xm to see how bad it is. ;)
[20:32] <amitk> rcn-ee: XM is on my wishlist next
[20:32] <amitk> but I need to do some family time (it being friday evening and all that)
[20:34] <rcn-ee> of course family first ;) My goal is to get this XM booted and benched against it's older boards this weekend (inbetween beer and golf)..
[20:35] <amitk> beer, great idea.
[20:36] <rcn-ee> and someone broke gcc trunk...  i think i need 2-3 more beagles for faster bisecting..
[20:37] <JaMa> isn't trunk expected to be broken a bit sometimes, now after branching 4.5?
[20:38] <rcn-ee> yeah.. it's perfectly fine at this stage.. ;)
[20:38] <nosse1> OK. I got lucid running, but only with custom kernel (based on non-ubuntu source).
[20:39] <nosse1> The last kernel ti-omap   -5 does not work on AM3517, see http://pastebin.com/RdiMijNL
[20:39] <rcn-ee> hey nosse1, which kernel repo did you use again?
[20:39] <nosse1> For the one that works, I'm using TI's git repo
[20:40] <nosse1> So, I'm ready to conclude that the official kernel wont work for my target.
[20:40] <rcn-ee> actually that's not bad...  nosse1 does the console ever come up with 500.4?
[20:40] <nosse1> But it's not tragic, because we will have custom HW (hence kernel) anyways
[20:41] <nosse1> The cheering from me was for running Ubuntu userspace!
[20:42] <rcn-ee> nosse1, is that their psb/bsp repo?  I'm going to steal/browow some xm stuff
[20:44] <nosse1> rcn-ee: It's this repo: git://arago-project.org/git/people/sriram/ti-psp-omap.git   I know TI has two repos: This one and the one on the official kernel server
[20:45] <nosse1> According to the other developers here the former is the most updated one, while the last is for what is pushed upstream
[20:45] <rcn-ee> Thanks nosse1, wasn't 100% where it was, I normally pull from tmlind's tree and after 2.6.31 i kinda was off in the woods doing my own thing.. ;)
[20:46] <nosse1> I haven't a full understanding of the difference between those two repos.
[20:47] <nosse1> We need to base our HW branch from one of them, but I'm not sure which yet
[20:47] <rcn-ee> talking with my buddies at TI it's their new, more upstream kernel policy then years past, 'plan'..
[20:49] <nosse1> I spent some considerable time to ubuntuize the kernel config for the ti-kernel
[20:50] <rcn-ee> It's kind of a challlenge, in years past you've allways had one specific config for one specific board, but now for distrutors, you need one config for all..
[20:51] <nosse1> Now we are ready to evaluate _if_ we are going to run Ubuntu at all on the device...
[20:51] <prpplague> ogra: ping
[20:52] <rcn-ee> i can give you one hint... it's faster then debian.. ;)
[20:52] <nosse1> Thanks, that answers one ;)
[20:53] <nosse1> I need to get the SVX-stuff and Qt on top (either fb or X11) to eval the end user GUI
[20:54] <rcn-ee> the sgx modules are pretty easy to build, i have a couple scripts in my bzr repo... Haven't messed around with the QT-SGX setup thou...
[20:55] <nosse1> bzr repo?
[20:56] <rcn-ee> sorry: https://launchpad.net/~beagleboard-kernel  in the 2.6-stable and 2.6-dev tree's theirs a build_sgx_modules.sh script...
[20:58] <nosse1> Can one cross-compile apps for Ubuntu target?
[20:59] <nosse1> Some of our developers are worried about having to compile Qt on target for the target, while we have a rather large build farm
[21:00] <rcn-ee> Yeah, it's not always 100%, but it's fast for a quick test, i usually build on either a qemu based chroot or native chroot...
[21:00] <rsalveti> nosse1: qt is going to be very slow if you compile it inside qemu
[21:00] <rsalveti> nosse1: cool to see that you finally made to boot ubuntu :-)
[21:00] <nosse1> Oh yes! Tried it!
[21:00] <nosse1> rsalveti, hi yes. I got it to boot only an half hour ago! Finally!
[21:01] <rsalveti> nice :-)
[21:02] <rsalveti> nosse1: you could probably use your build farm inside qemu, but you have to setup the cross compiler correctly
[21:02] <rsalveti> and depends on what system you're currently using
[21:03] <nosse1> Yes. I'm running qemu/chroot to update and prepare packages from target, and that work fine (however slowly)
[21:03] <rsalveti> at least with sbox I already saw it working with icecream
[21:04] <rsalveti> c++ sucks even when you build it at your native invironment
[21:04] <rsalveti> *environment
[21:04] <nosse1> Should I use serialtty=ttyS2 on installed Ubuntu as well?
[21:05] <nosse1> (I solved this by adding my own /etc/init/ttyS2.conf instead)
[21:14] <nosse1> Try telling the app developers that C++ sucks....
[21:17] <nosse1> Interesting: https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-stable, clicking on a revision like this: http://bazaar.launchpad.net/~beagleboard-kernel/+junk/2.6-stable/revision/64 then I get internal server error
[21:20] <rcn-ee> yeah noticed that too.. something wrong with launchpad.. click reload works for me...
[21:26] <nosse1> rcn-ee, how do you experience Ubuntu against say Arago/OE or any other cross compiled into-one-large-image distro?
[21:27] <nosse1> size is obvious, but we've got nearly 1G available for entire system, so that's handled
[21:27] <rcn-ee> well, from my experience (pre lucid) Angstrom has always been the fastest and most polished, mostly due to many arm developers working on it for many years...
[21:28] <rcn-ee> other then the 'feel' i haven't run any numbers for load comparisons yet...
[21:32] <rcn-ee> one interesting side note, i do have a touchbook running both Angstrom and ubuntu Karmic...  Although Karmic is slower, more things do work out of the box, vs some of hte applications in the Angstrom image..
[21:33] <nosse1> Yes, that another point. I expect customer upgrade/maintenance/security fixed to be easy with Ubuntu. I have no idea what that would imply on Ångström
[21:34] <rcn-ee> They use a tool called ipkg very similar to dpkg, but i haven't figured it out 100%.. Long term maintance is ubuntu/debian's strong point...
[21:35] <nosse1> Yeah. If we can stick with vanilla Ubuntu arm, and then our own custom kernel + our app, then I'd be /very/ happy
[21:38] <nosse1> Theres one product requirement though. Boottime from off until GUI is shown must be minimized, so perhaps some customization to the boot process must be added as well
[21:39] <rcn-ee> there is the 10second wait in most u-boot that's easy to remove...
[21:43] <nosse1> Timing it now, it takes 21 secs from u-boot bootm to login is shown (i.e. kernel and initrd loading is not included).  This is with NFS root and all so I'm very optimistic about shaving off seconds.
[21:44] <rcn-ee> console login or gui?
[21:45] <nosse1> console. I have no gui as of now
[21:45] <rcn-ee> okay, i had a user report that "console-setup-mini" shaved some more seconds in the lucid alpha releases...
[21:46] <nosse1> rcn-ee, perhaps you know what is needed to get the display up and running (I have the AM3517-EVM)?
[21:47] <rcn-ee> i'm comparing the ti-psp-omap repo with ubuntu's. to figure out xm stuff ;) what git checkout did it work in ti-psp's?
[21:48] <nosse1> Uhm. /me git newbie: How to check?
[21:49] <rcn-ee> ti does things like OMAPSP_03.00.00.04/etc.. which will get us in the ball park...
[21:49] <nosse1> No, I've pulled their working git repo for the kernel
[21:51] <rcn-ee> well they have about 12-15 more commits vs ubuntu's... your using the LCD panel?
[21:53] <nosse1> I'm about to...
[21:54] <rcn-ee> I'm going to try to merge them in..
[21:55] <nosse1> I can give you my head git revision if I just knew how to get it
[21:56] <rcn-ee> git log (top one sha) is the easist that i know off
[21:57] <nosse1> This one 7b8926aa626
[22:03] <rcn-ee> okay it's going to take quite a bit more cherry picks, but i think i got the lcd, it'll take about 5mins to finsih building..
[22:04] <rcn-ee> yeah, it's going to take more... it doesn't like the board-am3517evm at all... it's just too new with very little upstream...
[22:07] <nosse1> Yeah, I think I have logged over 50 hrs on this thing now. But part of that is to get oneself up to speed on Ubuntu booting internals
[22:07] <nosse1> So the positive result this evening is most welcome :D
[22:08] <rcn-ee> it's very possible and doable, both tree's are based off 2.6.33, but ti has about 100 new patches....
[22:09] <rcn-ee> i really hope they merge some of that inthe next cycle...
[22:22]  * nosse1 is trying xserver-xorg-video-omap3
[22:29] <nosse1> Adam want long in Eden: [ 5577.017395] BUG: soft lockup - CPU#0 stuck for 61s! [dpkg:681]
[22:29] <nosse1> *wasn't
[22:54]  * NCommander isn't doing good.
[23:08] <crimsun> does dave martin frequent this channel?
[23:08] <crimsun> (I need someone to look at some gutsy v7 asm)
[23:53] <nosse1> I see I get a lot of unresolved packages when I try to get "ubuntu-netbook".
[23:53] <nosse1> What's a good target for the standard gnome desktop?