[02:37] <andruk> If I use u-boot to configure my beagleboard to use SPI, will the stock Ubuntu kernel pick up on the device?  where will it show up in /sys/?
[03:06] <rcn-ee> andruk, those u-boot spi setting in 2010-03 are still in their infancy..  I'm not even sure if Angstrom's 2.6.32-psp kernel does that either...
[03:17] <andruk> rcn-ee: oh, okay.  so, to adjust the SPI settings in the kernel, I just need to get the source from https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-stable ?  will it be blindingly obvious how to compile a new kernel?
[03:17] <rcn-ee> andruk,  you have a zippy1 right?
[03:18] <andruk> rcn-ee: nope, just a vanilla bb
[03:19] <rcn-ee> ah yes, i remember now, you were just wanting to get "spidev" to work...  this patch works: http://elinux.org/BeagleBoard/SPIPatch-2.6.32
[03:20] <rcn-ee> all you need to do is "bzr branch" the 2.6-stable... add that patch anywhere in the patch dir, then add a "patch -p1 -s < ${DIR..etc" to patch.sh then run build_kernel.sh...  ALl you need is CC defined in system.sh
[03:23] <rcn-ee> something like this: http://pastebin.com/hZd2XLu6  (had it saved in my temp since our last conversation)
[03:25] <rcn-ee> andruk, if it actually works for you and your spi devices work, I'll rework the patch and actually commit it...
[03:55] <andruk> rcn-ee: so, is that a patch for patch.sh?
[03:55] <andruk> rcn-ee: the pastebin link, I mean
[03:55] <rcn-ee> yeah, it's a patch for patch.sh and it adds the SPIPatch-2.6.32.diff file...
[04:07] <andruk> rcn-ee: patch unexpectedly ends in middle of line (\n) patch: **** malformed patch at line 240:
[04:08] <rcn-ee> yeap, noticed that too...  (my cable modem is very slow tonight) fixing as we speak..
[04:14] <rcn-ee> 2nd try the charm: http://pastebin.com/5SDB3ZKC  just do a "bzr diff > remove.diff" "patch -p0 -R < remove.diff" then "patch -p0 < newpastebin"
[04:21] <andruk> so, this is what patch.sh should look like (check near the bottom): http://pastebin.com/YgATCjdJ    and this is what patches/spi/SPIPatch-2.6.32.diff should look like: http://pastebin.com/h2LJgJK3    right?
[04:24] <rcn-ee> it looks like you still have the old one, the source was different around: static void __init omap3_beagle_init(void)
[04:24] <andruk> oh, kay
[04:24] <rcn-ee> and that was what was causing the patch to stop...
[04:29] <andruk> uhoh...same error around line 238 this time
[04:33] <andruk> rcn-ee: ping
[04:33] <rcn-ee> very weird... well i don't want to break 2.6-stable till tomorrow, so i just pushed it to another tree, that change is here: "bzr branch lp:~beagleboard-kernel/+junk/2.6-stable-spi"
[04:35] <andruk> rcn-ee: you are too kind for a faltering noob like me
[04:35] <andruk> :-)
[04:35] <rcn-ee> laughs, we are all noob's here.. wait till i finally figure out git, then force everyone to git clone my tree.. ;)
[04:58] <andruk> rcn-ee: is there anything i need to do for Kconfig?
[04:59] <rcn-ee> no, the mcspi method is on by default...  the only thing you need to worry about for the Kconfig is if your running for lucid or (all the others)  IS_LUCID define in system.sh takes care of that...
[05:02] <andruk> rcn-ee: cool.  thanks.
[05:02] <andruk> fuck...
[05:05] <andruk> rcn-ee: http://pastebin.com/L0HdENxz
[05:05] <rcn-ee> laughs, i think i know the bug you see...  Use this uImage and Modules i built last time: http://rcn-ee.homeip.net:81/dl/testing/spidev/
[05:07] <rcn-ee> heading to bed, i'll dig up why it didn't work in the 2.6-stable tree tomorrow..  the one i posted above was from last week when we were talkign about it, not sure if  i have the whole patch anymore...
[05:08] <andruk> rcn-ee: :-/ okay thanks for you help!
[07:38] <DanaG> hmm, is plymouth going to be used on ARM?  Or rather, present tense, is it used on ARM?
[07:39] <DanaG> On any system with serial console (in addition to local tty0), Plymouth refuses to show the splash screen.
[07:39] <DanaG> http://users.csc.calpoly.edu/~dgoyette/amtterm.log -- this is from my host system.
[07:40] <ogra> plymouth is a dependency of mountall, so yes, its on all ubuntu systems now
[07:41] <DanaG> Bummer it's not usable with serial console. :(
[07:42] <DanaG> 'I would expect to see splash on tty0 and messages on ttyS0.;
[07:43]  * ogra has that here
[07:43] <ogra> with plymouth
[07:45] <DanaG> hmm, maybe I should try putting back "quiet"... but that gets rid of messages on serial console, too.
[07:45] <ogra> amitk-afk, with the new kernel it hangs but without OOPS
[07:45] <DanaG> I'll have to try it with ARM sometime again.
[07:46] <ogra> oh, wait
[07:46] <ogra> if you use console= plymouth wont show a splash at all
[07:46] <DanaG> yeah.
[07:46] <ogra> thats known
[07:46] <DanaG> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/516825
[07:47] <ubot4`> Launchpad bug 516825 in plymouth (Ubuntu) "plymouth doesnt show any splash as soon as a console= commandline option is used on boot (affects: 2)" [Medium,Fix released]
[07:47] <ogra> right
[07:47] <DanaG> it's marked fixed... but I disagree with that.
[07:47] <ogra> amitk, http://paste.ubuntu.com/414122/ :(
[07:48] <ogra> thats what i get after some unsuccessful boots
[07:49] <DanaG> [main.c]                            check_for_consoles:checking if splash screen should be disabled
[07:49] <DanaG> [main.c]                            check_for_consoles:serial console found!
[07:49]  * ogra removes the HUB and attaches the USB key directly
[07:50] <ogra> hmm, hangs too
[07:50] <ogra> no oops
[07:50] <amitk> w/o hub, it won't work
[07:50] <ogra> well, it finds the disk and mounts it
[07:51] <ogra> but hangs right after with no messages
[07:51] <amitk> ogra: line 41 on the paste says you had a ext4 error
[07:51] <amitk> did your FS become corrupt?
[07:52] <ogra> amitk, i doubt ext4 *can* get corrupt that way
[07:52] <ogra> its never mounted RW
[07:52] <ogra> my boot doesnt get that far
[07:52] <amitk> EXT4-fs error (device sda1): __ext4_get_inode_loc: unable to read inode block - inode=267617, block=1049142
[07:52] <ogra> right
[07:53] <amitk> ogra: we've had lots of issues with ext4 corruption, was this tried on a fresh image?
[07:53] <ogra> i know what you think, but my boot never gets to mountall
[07:53] <ogra> (mountall is remounting / RW)
[07:53] <amitk> we are talking about "read" here...
[07:53] <ogra> amitk, thats the USB install from yesterday
[07:53] <ogra> using your newest kernel from people
[07:54] <amitk> so it could be corrupted in the last shutdown
[07:54] <ogra> amitk, i know, but how would the disk get corrupted if itwas never mounted ?
[07:54] <ogra> i mean RW mounted
[07:54] <ogra> hmm, unpowered HUB doesnt work either
[07:54] <ogra> nor does the mini USB port
[07:55] <amitk> what are you using the OTG port for?
[07:55] <ogra> well, i was just trying all options and attached the disk with adapter
[07:55] <ogra> i didnt expect that to work :)
[08:01] <amitk> ogra: so you're saying that the kernel is lying about the ext4 error? :)
[08:01] <ogra> amitk, not sure if it lies or if it has a hiccup
[08:02]  * amitk doubts it
[08:02] <ogra> though i'd guess given the other USB issues i see that its not the FS but the underlying layer
[08:02] <ogra> i havent had any other ext4 errors
[08:03] <ogra> i dont have any other errors at all now, it just gets stuck
[08:03] <ogra> sometimes it managed to print the ureadahed message, sometimes it just gets stuck when leaving the initramfs
[08:03] <ogra> i didnt get further than ureadahead with this kernel
[08:04] <ogra> the archive kernel got a bit further (up to the apparmor messages ) and got stuck then
[08:04] <ogra> and either oopsed or not
[08:05] <ogra> without USB we're a bit screwed :/
[08:06]  * ogra gets more coffee
[08:07] <amitk> ogra: you are seeing errors now!
[08:07] <amitk> [   35.254974] EXT4-fs error (device sda1): __ext4_get_inode_loc: unable to read inode block - inode=267617, block=1049142
[08:07] <amitk> [   35.267272] EXT4-fs error (device sda1): ext4_find_entry: reading directory #2 offset 0
[08:07] <amitk> [   35.277526] Kernel panic - not syncing: Attempted to kill init!
[08:07] <amitk> [   35.283630] [<c003c81c>] (unwind_backtrace+0x0/0xe8) from [<c043e434>] (panic+0x54/0x138)
[08:07] <amitk> [   35.291900] [<c043e434>] (panic+0x54/0x138) from [<c006717c>] (exit_notify+0x0/0x144)
[08:07] <amitk> [   35.299804] [<c006717c>] (exit_notify+0x0/0x144) from [<00000001>] (0x1)
[08:07] <amitk>                                ^^^ that is the beginning of a panic aka oops
[08:10] <ogra> that was in one out of 20 boots
[08:10] <ogra> didnt show up again
[08:10] <ogra> now it just gets stuck
[08:11] <ogra> no oops no error at all, just locks up
[08:11] <ogra> and yes, i mounted the usb key on my desktop inbetween where it doesnt show any issues, i also fsck'ed it already with no errors
[08:13] <ogra> its definately not the filesystem
[08:14] <lool> ogra: did you see my comments on the dove netboot images bug?
[08:14] <ogra> if it wouldnt take ages i'd try another install right now
[08:14] <ogra> lool, havent read my bugmail yet, if you made comments today i didnt see them, i saw your last one yesterday
[08:14]  * ogra looks at evo
[08:15] <lool> ogra: No need for a full install, just loading the images is a good enough test
[08:15] <ogra> lool, ah, well, at least we build the netboot initrd the same way the cdimage one is built now
[08:15] <lool> ogra: So GrueMaster was saying that the initrd has incorrect values
[08:15] <ogra> lool, i cant test dove i dont have the HW
[08:16] <lool> So the bug should probably be reopened, but I dont have the hardware either
[08:16] <ogra> only NCommander GrueMaster or plars can test
[08:16] <ogra> i was just aiming for consistency, the cdrom initrd which is an initramfs obviously worked for GrueMaster
[08:17] <ogra> so we excluded at least one breaking factor here
[08:17] <NCommander> lool: what was the bug number? I can recheck
[08:17] <ogra> Bug 541399
[08:17] <ubot4`> Launchpad bug 541399 in linux-mvl-dove (Ubuntu) (and 1 other project) "netboot image fails to boot. (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/541399
[08:18] <ogra> lool, you shouldnt need ramdisk_size with initramfs
[08:18] <ogra> or /dev/ram0
[08:18] <ogra> what i dont get is why we use a different load address at all
[08:18] <ogra> that seems broken
[08:19] <ogra> building the same setup the cdrom initrd has while keeping the same address should suffice
[08:20] <ogra> ah, sweet, omap netboot has its boot.scr now http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/omap/netboot/omap/
[08:20] <ogra> i wish i had the time to make a dd'able image out of it
[08:21] <ogra> amitk, do you still need my broken USB install ? else i'll start over with a fresh install to see if it changes anything
[08:22]  * ogra wants to try if he can probably get away with a minimal install to SD if running netinst
[08:23] <ogra> thats better than nothing given time runs short
[08:27] <amitk> ogra: please do, I'm interested in a fresh install
[08:28] <amitk> I'm doing that here too
[08:28] <ogra> well, i wont do a USB install
[08:28] <ogra> which is our main issue atm
[08:28] <ogra> though i'm not sure parted can handle installing to the media we run from but netinst makes me hope
[08:35] <ogra> grr, so partman doesnt let me create /boot as fat
[08:35] <ogra> thats a prob
[08:56] <amitk> ogra: I'm still ooming on the new image while installing...
[08:56] <ogra> can you check with free ?
[08:56] <ogra> if swap is actually 128M
[08:57] <amitk> ogra: yes it is
[08:57] <amitk> I checked on serial console
[08:57]  * ogra curses very loudly
[08:57] <amitk> I'm stuck at the keyboard layout dialog
[08:57] <ogra> did you modify anything else than adding serial ?
[08:57] <amitk> new kernel and serial
[08:58]  * ogra wonders why it doesnt OOM for him
[08:58] <amitk> ubuntu@ubuntu:~$ free -m
[08:58] <amitk> [  684.363372] Out of memory: kill process 1743 (gnome-session) score 50392 or a child
[08:58] <amitk> [  684.371276] Killed process 1974 (metacity) vsz:32548kB, anon-rss:1000kB, file-rss:7380kB total       used       free     shared    buffers     cached
[08:58] <amitk> Mem:           240        205         35          0          8         49
[08:58] <ogra> can you change the cmdline and add only-ubiquity to it ?
[08:58] <amitk> -/+ buffers/cache:        146         93
[08:58] <amitk> Swap:          120        118          1
[08:58] <ogra> i guess we'll have to default to that
[08:59] <ogra> it wont start the desktop but go directly into the installer
[08:59] <ogra> indeed the user needs to have a big enough swap in his install
[08:59]  * ogra sees a pile of release notes ahead
[09:01]  * ogra is afk for a moment
[09:01] <amitk> just 1M of swap free, I guess even starting a serial console shell is a step towards oom
[09:01] <ogra> yes
[09:02] <ogra> but lets go the only-ubiquity path ...
[09:02] <ogra> its the best fallback we have
[09:02] <ogra> <- really afk
[09:55] <hrw> morning
[09:56] <amitk> ogra: "The installer encountered an unrecoverable error. A desktop session will now be run so that you may investigate the problem or try installing again"
[09:56] <amitk> hrw: morning
[09:56] <ogra> amitk, at which point ?
[09:56]  * ogra definately sees an issue with update-initramfs atm
[09:56] <amitk> ogra: last I saw it was almost finished with the install
[09:57] <ogra> right, thats likely either the kernel installation or the bootloader step
[09:57] <amitk> ogra: I have the session active in case you want some information to help you debug
[09:57] <amitk> hrw: since you're involved with OE, what kernel version do they ship for beagleboard?
[09:57] <ogra> yeah, file a bug with ubuntu-bug -p ubiquity
[09:59] <hrw> amitk: 2.6.32 based on linux-omap-psp branch
[09:59] <amitk> what is psp?
[10:00] <hrw> TI branch of linux-omap
[10:00] <hrw> never read what makes it special
[10:00] <XorA> Platform Support Package
[10:00] <XorA> TI language for BSP
[10:01] <hrw> said TI OMAP OE expert
[10:01] <XorA> and there is nothing special, about it, everything goes upstream
[10:01] <hrw> XorA: but TI code lands in psp and then migrate to linux-omap - right?
[10:02] <nosse1> ogra, did you resolve the "Unhandled fault: external abort on non-linefetch" issue?
[10:02] <XorA> hrw: yes I beleive thatd the path, but its so damn quick these days
[10:02] <ogra> nosse1, yes, fixed in todays images
[10:02] <hrw> amitk: git://arago-project.org/git/people/sriram/ti-psp-omap.git
[10:02] <nosse1> May I ask what it was? Compile flag issue?
[10:03] <hrw> amitk: OE uses da0c86a8f3bd57fad0ccd05eb1b5e3326d7f36aa revision + 41 patches added
[10:04] <amitk> hrw: where would I find their defconfig?
[10:05] <ogra> nosse1, code in parted that tried to run dmidecode snippets to read BIOS info from /dev/mem
[10:05] <hrw> moment
[10:05] <XorA> amitk: arch/arm/configs
[10:05] <XorA> amitk: if you mean TI defconfig
[10:05] <amitk> ohh, so they use the defconfigs?
[10:05] <ogra> sigh, so we cant install to mmc
[10:05] <XorA> OE has its defconfig in metadata
[10:05] <hrw> amitk: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/beagleboard/defconfig
[10:05] <ogra> initramfs-tools has no support for it
[10:06]  * amitk looks, although a lot has changed in 2.6.33
[10:06] <XorA> so which image should I use on my beagle today?
[10:07] <amitk> ogra: bug 562888
[10:07] <ubot4`> Launchpad bug 562888 in ubiquity (Ubuntu) "omap installation failed with unrecoverable error (affects: 1)" [Medium,New] https://launchpad.net/bugs/562888
[10:08] <ogra> amitk,
[10:08] <ogra> Jan  1 00:48:52 ubuntu python:   File "/usr/share/ubiquity/install.py", line 1664, in configure_bootloader
[10:08] <ogra> Jan  1 00:48:52 ubuntu python:     raise InstallStepError("No bootloader installer found")
[10:08] <ogra> Jan  1 00:48:52 ubuntu python: InstallStepError: No bootloader installer found
[10:09] <ogra> i wonder why it didnt show the correct error msg though
[10:09]  * amitk wonders how ogra managed to install yesterday
[10:09] <ogra> amitk, i used d-i
[10:09] <ogra> thats more flexible
[10:10] <ogra> d-i offers you actually to install without bootloader, in ubiquity thats possible too but a bit hidden
[10:10]  * amitk has wasted 2 hours 
[10:10] <ogra> on the last page you can select "advanced"
[10:10] <ogra> there you can check "dont install bootloader"
[10:11] <ogra> amitk, use netinst and do a minimal install
[10:11] <ogra> its way faster
[10:11] <ogra> http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/omap/netboot/omap/
[10:11] <ogra> as long as your target is USB it will work
[10:11] <ogra> donty try mmc though, initramfs-tools is buggy
[10:12] <amitk> ogra: just copy these to casper/ ?
[10:12] <ogra> amitk, nope, just have a vfat SD card ... copy all three files to /
[10:12] <ogra> if you want to use serial for installing, edit boot.scr
[10:13] <ogra> i'll set up wikipages for all install variants after freeze ... once i have time for that
[10:13] <ogra> amitk, you didnt waste the 2h ... now we are at least sure that only-ubiquity wont OOM, thanks a lot
[10:25]  * XorA guesses he better find out how to install u-boot on a beagle :-)
[10:26] <hrw> XorA: you need to finding it out? I thought that you can do that anytime ;D
[10:26] <XorA> hrw: I have never done it
[10:27] <XorA> hrw: never needed to until now
[10:27] <hrw> XorA: use Koen's instructions on angstrom /demo/beagleboard/README
[10:28] <hrw> XorA: I always used those
[10:32] <nosse1> ogra, the gnome desktop has become very smooth. Even on my 256M system. I think the fix last night really improved my issues
[10:33] <ogra> great
[10:48] <XorA> hrw: thanks, they are nice and easy to follow :-)
[11:10] <XorA> arse I hit the C3 EHCI bug really quick :-(
[11:12] <persia> XorA: On the bright side, that means you managed to get the system up and running really quick :)
[11:12] <bmwiedemann> hello. are you aware that http://www.ubuntu.com/getubuntu/releasenotes/1004 links to a non-existing https://wiki.ubuntu.com/ARM/LucidReleaseNotes page?
[11:13] <XorA> persia: but as you guys dont support the zippy I cant install it, only live disk
[11:14] <persia> bmwiedemann: Feel free to create that page if you like.  I'm not sure anyone has composed the ARM-specific release notes yet (but more help is always welcome)
[11:15] <persia> XorA: What happens when you try to install?  Bugs are welcome, although most of them probably end up being 10.10 candidates.
[11:15] <XorA> persia: my EHCI port shuts down, its a hardware bug on C3 and earlier boards
[11:15] <bmwiedemann> persia: I could drop in a place-holder page. so far I have only used Debian/Lenny on armel (openrd, gumstix, RD-6281-A)
[11:15] <persia> Basically, if a patch is simple and easy to maintain, there's no reason for it not to be there.
[11:15] <persia> Basically, if a patch is simple and easy to maintain, there's no reason for it not to be there.
[11:16] <persia> XorA: Oh, a known hardware issue that can't be worked around in the kernel?  Yeah, not much hope there.
[11:16] <persia> bmwiedemann: That'd be a great start, if you don't mind.  Thanks.
[11:20] <XorA> persia: its what the C4 boards fixed
[11:23] <bmwiedemann> persia: done
[11:24] <XorA> you goes should turn on heartbeat on one of the leds by default
[11:24] <persia> bmwiedemann: Thanks.
[11:25] <persia> XorA: The seeds aren't subarch (let alone board) aware, so there's no easy/safe way to do that.  On the other hand, if you have some code that does that in userspace, it could be in a package (although not for 10.04) that folks are encouraged to install on such a device.
[11:26] <XorA> persia: ok, its quite easy as you in the led class in sysfs
[11:28] <persia> XorA: So one could write a tool that flashed the led if present, and didn't if not, and have it safely present everywhere?
[11:31] <XorA> persia: its literally as easy at echo heartbeat >/sys/class/leds/name/function
[11:31] <XorA> trigger not function, but you see what I mean
[11:32] <persia> We we just need a good way to pick *which* led to flash for heartbeat.
[11:32] <XorA> persia: anyway Im concentrating on just getting the damn thing installed :-)
[11:33] <persia> Unfortunately, it seems there's no direct correlation between /sys/class/leds/* and the leds on my laptop :(  Some of them seem to be known to the kernel, but not exposed, and others are exposed, but unknown to the kernel.
[11:35] <XorA> arse my EHCI port seems to have given up completely
[11:40] <XorA> any of you guys been installing with OTG port?
[11:43] <XorA> not using the zoom2 SD card helps
[12:03] <lool> ogra: 09:18 < ogra> lool, you shouldnt need ramdisk_size with initramfs
[12:03] <lool> ogra: are you sure?
[12:05] <ogra> lool, yes
[12:05] <ogra> i had the same issue with omap
[12:05] <ogra> initrd needed ramdisk_size set, initramfs didnt
[12:05] <ogra> thats why i moved dove to initramfs for netinst
[12:06] <ogra> i'm waiting for feedback from NCommander who wanted to test that hours ago
[12:07] <ogra> lool, i think its a differece of mounting compressed vs fully unpacking
[12:07] <ogra> (though thats just a guess)
[12:08] <ogra> OMAP3 beagleboard.org # ext2load mmc 0 0x80000000 uImage
[12:08] <ogra> Loading file "uImage" from mmc device 0:1 (xxa1)
[12:08] <ogra>  ** ext2fs_devread() read error - block
[12:08] <ogra> ** Unable to read "uImage" from mmc 0:1 **
[12:08] <ogra> ah well, i had to try at least :/
[12:17] <nosse1> Anyone else that have had problems with "BUG: soft lockup - CPU#0 stuck for 61s!"?
[12:17] <ogra> nope
[12:17] <nosse1> I'm getting it when doing heavy disk activity (e.g. dpkg) when using NFS
[12:18] <ogra> though i never use NFS
[12:18] <nosse1> I'm kind of stuck as for some reason my EHCI driver started to give in, so my connection to my USB disk also fails
[12:19] <hrw> XorA: did you upgraded MLO too?
[12:19] <XorA> hrw: yes
[12:19] <XorA> hrw: both from Angstrom
[12:19] <amitk> nosse1: you're not using the Ubuntu kernel though...
[12:19] <nosse1> It's a coincidence that this occurs at the same time that the HW bug is discussed in this channel :(
[12:20] <XorA> nosse1: C3 beagle?
[12:20] <nosse1> amtik, no I'm not
[12:20] <nosse1> XorA, no. The AM3517-EVM. That's why I cannot run the vanilla ti-omap kernel
[12:21] <XorA> nosse1: C3 and earlier beagle there is not enough grunt in the power rail of EHCI and port drops out under heavy load
[12:21] <hrw> and I have C3+C3+B7 ;(
[12:21] <hrw> hope that TI will release XM soon
[12:21]  * XorA has C3 and B6
[12:22] <nosse1> XorA. This might be it. I use a bus powered hub (because of this USB 1.1 vs. 2.0 thing in OMAP) connected to USB disk, kbd and mouse. Perhaps the load of the kbd and mouse is too heavy
[12:22] <hrw> and one of C3 has to work as mediaplayer plugged to TV
[12:23] <XorA> yeah we all need XMs :-D
[12:23] <XorA> otherwise ubuntu work is going to be painful
[12:24] <ogra> ++
[12:24] <ogra> though we're getting closer to at least have *something* for lucid
[12:24] <hrw> XorA: too bad that this time I would rather have to pay for Beagleboard... the ones which I have I got for free
[12:25] <ogra> make your employer pay ;)
[12:26] <hrw> ogra: you mean me myself?
[12:26] <hrw> :D
[12:26] <hrw> ogra: I am self employed
[12:26] <ogra> if you are self employed, reclaim it from taxes ;)
[12:26] <ogra> its a "tool" :)
[12:26] <hrw> I know
[12:26] <rcn-ee> hrw, i'm not planning to stop my experimental builds, so you can always use an external kernel with ubuntu for Bx/Cx's...
[12:27] <hrw> I just bought 42" plasma TV for my work
[12:27] <XorA> ogra: you live disk image looks nice, I just cant actually do anything with it
[12:27] <ogra> thats indeed an important tool to have :)
[12:27] <hrw> rcn-ee: most of my Debian machines use own kernels
[12:27] <ogra> XorA, can you define that ?
[12:27] <XorA> ogra: I have no working usb
[12:27] <ogra> "anything" is a bit broad :)
[12:28] <XorA> ogra: so I can stare at the screen :-)
[12:28] <hrw> XorA: connect BB to TV and boot ubuntu - nothing to stare at ;D
[12:28] <ogra> XorA, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ tried a recent one ?
[12:28] <XorA> ogra: usb in the image works, it appears my port just blew
[12:29] <ogra> it should definately work on the C4 ... not sure about 3
[12:29] <rcn-ee> ogra, i was playing around with a hacked rootstock that installed apt/dpkg -dbgsym's and it still locked up at iso-codecs is there anything i can dump for a useful trace?
[12:29] <hrw> beagleXM with 2xsize and good wifi/bt on board would be nice
[12:29] <ogra> rcn-ee, attach gdb to the hanging apt and get a backtrace
[12:31] <rcn-ee> okay, I'll try that.. it only locked up 50/50, on my two runs, so i'll try that...
[12:31] <ogra> hey, 50/50 is already better than 100% :)
[12:32] <rcn-ee> i know... ;) it almost installed netbook-image last night.. right before it segfaulted in the middle of the last stage of apt-get...
[13:10] <ogra> sigh, i want class 20 SD cards
[13:10] <ogra> i bet the card is worn out once i'm done with install tests
[13:15] <persia> You just need a better FTL on your card.
[13:16]  * persia wishes there was a handy generic interface to hint to FTLs which filesystem one intended to use so it could use the flash optimally.
[13:17] <ogra> ok, finallly i get the right initramfs-tools
[13:17]  * ogra crosses fingers
[13:18] <ogra> WOHOO !
[13:18] <ogra> user setup reached
[13:18] <ogra> and we're in pkgsel
[13:19]  * ogra gets some coffee while d-i does its duty
[13:43] <ogra> amitk, so my SD install seems to have similar issues
[13:44] <ogra> i see no oops though
[13:44] <amitk> ogra: break=premount doesn't give me a shell
[13:44] <ogra> ugh
[13:44] <ogra> it definately shoudl give you busybox
[13:45]  * ogra tries here
[13:45] <ogra> what i see is that the SD read LED is flickering very fast
[13:45] <ogra> but booting stops at
[13:45] <ogra> Begin: Running /scripts/init-bottom ...
[13:45] <ogra> Done.
[13:45] <ogra> init: ureadahead main process (128) terminated with status 5
[13:46] <nosse1> ogra, This one I also get all the time
[13:46] <ogra> (note status 5 means it recognozed flash media it doesnt want to read and exited gracefully)
[13:47] <ogra> nosse1, how did you get stuck with the ubuntu kernel before ? did that look similar ?
[13:47] <nosse1> Yes, it locked up sometime after that message
[13:48] <nosse1> I never actually learned what and where it stopped
[13:48] <ogra> so thats similar then ... and it was fixed for you with a custom kernel but same rootfs/initrd ?
[13:49] <ogra> amitk, break=bottom clearly gets me to busybox
[13:49]  * ogra tries premount
[13:49] <nosse1> ogra, break=bottom worked for me as well
[13:50] <nosse1> Yes, custom kernel. And generate new initrd from that kernel's modules
[13:50] <ogra> but using update-initramfs from ubuntu. right ?
[13:50] <nosse1> yes
[13:51] <ogra> amitk, so i can chroot /root from busybox but dont get to a prompt
[13:51] <nosse1> I inject the kernel into the NFS root tree and use update-initramfs with qemu (in chroot env)
[13:52]  * ogra reboots and checks /dev ... i have a suspicion
[13:52] <ogra> hmm, no, all devices are there, devtmpfs is mounted fine
[13:52] <nosse1> ogra, Speaking of which: In my effort to root out the NFS problem, I now try to run the kernel config from TI.
[13:53] <nosse1> now I have a message during boot saying: mount: mounting none on /dev failed: No such device
[13:53] <nosse1> But I get into login, and /dev has been mounted properly
[13:54] <ogra> thats because you dont have devtmpfs enabled in your kernel
[13:54] <ogra> comes from initramfs' init
[13:54] <ogra> amitk, i wonder if it makes sense to compare our config to nosse1's
[13:56] <nosse1> Could this be related?
[13:56] <amitk> ogra: I'm not getting a shell with break=bottom (I see the panic instead)
[13:56] <amitk> or break=premount
[13:56] <ogra> i do on SD card
[13:56] <nosse1> I mean this error you now describe is the exact reason why I cannot use the ti-omap kernel
[13:56]  * amitk tries break=top
[13:57] <ogra> amitk, which kernel do you use ? my install indeed uses the archive kernel still
[13:57] <amitk> my own kernel
[13:57] <amitk> installed in chroot
[13:57] <ogra> right
[13:58] <ogra> archive kernel definately gets me busybox ... but no boot either
[13:58]  * amitk tries the arhive kernel
[13:58]  * ogra goes and makes all initscripts as noisy as he can
[13:59] <nosse1> I'm sorry guys, I need to leave for kindergarden. I'm unable to be of any further assistance until tomorrow
[14:00] <nosse1> I am very keen on following this discussion though
[14:00]  * ogra didnt know nosse1 was *that* young
[14:00] <nosse1> *lol*
[14:00] <ogra> :)
[14:01] <ogra> amitk, hmm, i added --debug to mountall which should be the next thing running after ureadahead and i dont get anything
[14:01] <amitk> [    0.000000] Kernel command line: console=ttyS2,115200n8 console=tty0 ro root=49b39455-6136-471e-8140-cd5
[14:01] <amitk> 8dbc48900 vram=12M omapfb.mode=dvi:1280x720MR-16@60 break=bottom debug usbcore.blinkenlights=1 initcall_deb
[14:01] <amitk> ug
[14:01] <amitk> ogra: ^ my cmdline, still no busybox shell on break
[14:01] <ogra> so i suspect we get actually stuck in ureadahead
[14:01] <lool> ogra: mountall doesn't output to the console by default
[14:01] <ogra> lool, i added --debug in the initscript
[14:02] <ogra> it should make a lot of noise
[14:02] <lool> ogra: If you want it to do that, add console output, and switch from daemon to verbose
[14:02] <lool> ogra: As I said, it doesn't log to the console by default
[14:02] <hrw> usbcore.blinkenlights=1? what it does?
[14:02] <ogra> --debug turned it on when i debugged with KEybuk recently
[14:03] <ogra> hum
[14:03] <ogra> indeed lool is right once again
[14:03] <ogra> --verbose is the parameter
[14:04] <lool> Right
[14:04] <amitk> hrw: blinken blinks the lighs on the usb hub (useful to tell if usbcore is working fine)
[14:04] <ogra> ok, lets see what --verbose gets us
[14:04] <ogra> no output at all
[14:05] <lool> ogra: do drop --daemon
[14:05] <ogra> lool, i did
[14:05] <lool> ogra: do you have console output in your mountall.conf?
[14:05] <ogra> its only mountall --verbose
[14:05] <ogra> lool, seems to be the default
[14:06] <ogra>  22 # temporary, until we have progress indication
[14:06] <ogra>  23 # and output capture (next week :p)
[14:06] <ogra>  24 console output
[14:06] <ogra> ...
[14:06] <ogra>  31     exec mountall --verbose # --daemon $force_fsck $fsck_fix
[14:06] <ogra> but i get no output at all
[14:06] <ogra> so that somewhat makes me think we get stuck in ureadahead
[14:07] <amitk> ogra: does break have anything to do with splash (i've removed that)
[14:07] <ogra> amitk, not to my knowledge
[14:07] <ogra> but plymouth might have changed the world
[14:07]  * amitk hates it
[14:07] <ogra> sigh, where is Keybuk if i need him
[14:08] <ogra> i wonder if we miss some magical kernel bit for ureadahead
[14:08] <lool> ogra: Does upstart start at all?
[14:08] <lool> ogra: are you past initrd?
[14:08] <ogra> lool, yes
[14:08] <ogra> Begin: Running /scripts/local-bottom ...
[14:08] <ogra> Done.
[14:08] <ogra> Done.
[14:08] <ogra> Begin: Running /scripts/init-bottom ...
[14:08] <ogra> Done.
[14:08] <ogra> init: ureadahead main process (134) terminated with status 5
[14:08] <ogra> lool, ^^^
[14:09] <ogra> thats where we get stuck
[14:09] <ogra> my USB image gets a bit further but hangs then as well
[14:09] <ogra> on the USB install i can actually see the apparmor profiles being set
[14:10] <amitk> apw also seemed to think that bits of userspace is being run and exiting...
[14:10] <ogra> amitk, right, but that a different kernel made it work for nosse1 is suspicious
[14:10] <ogra> so i suspect we miss a kernel setting that some userspace bit requires
[14:11] <ogra> which is why i'd love to consult Keybuk ... who isnt here
[14:14] <ogra> aha
[14:14] <ogra> Begin: Running /scripts/init-bottom ...
[14:14] <ogra> Done.
[14:14] <ogra> init: Failed to spawn ureadahead main process: unable to execute: Permission denied
[14:14] <ogra> moo
[14:15] <ogra> i made ureadahead unexecutable
[14:15] <ogra> and added "echo "moo"" to mountall directly when the script is exece'd
[14:15] <ogra> it doesnt move on though
[14:16] <ogra> the SD LED is flickering very fast again
[14:17] <ogra> amitk, silly question, but what are our console settings ?
[14:18] <ogra> i dont seem to get any tty0 output at all
[14:21] <amitk> ogra: yeah, I don't see anything on tty0 either. Only serial
[14:21] <ogra> right, there is something wonky with text consoles here
[14:23] <ogra> # CONFIG_FRAMEBUFFER_CONSOLE is not set
[14:23] <ogra> ah
[14:24] <ogra> amitk, i guess we need that :)
[14:24] <ogra> imx51 and dove have it
[14:25] <ogra> amitk, and that makes me guess that plymouth might be unhappy and crash or something similar
[14:27] <amitk> ogra: ok, will look, meanwhile I've added some comments to the bug (https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/562343)
[14:27] <ubot4`> Launchpad bug 562343 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "installation to USB device results in a non-booting system with OOPS (affects: 1) (heat: 8)" [High,New]
[14:28] <ogra> amitk, init doesnt exit for me
[14:28] <ogra> and the flashing SD card LED somewhat indicates that something acesses the filesystem
[14:30] <ogra> amitk, hmm, looking at your log you dont even get into initramfs
[14:30] <ogra> (you should have shown me the full log earlier)
[14:31] <ogra> in fact *your* crash is exactly if you enter the initramfs ... is you boot.scr ok ?
[14:31] <amitk> i posted it up there ^^^^
[14:32] <ogra> amitk, only the bottom snippet
[14:32] <ogra> amitk, the full log shows that you are not even entering initramfs
[14:33] <amitk> ogra: i meant my boot.scr
[14:33] <ogra> ah, yeah, the log has it too
[14:33] <ogra> seems ok
[14:34] <ogra> seems your initramfs isnt though
[14:34] <ogra> the udev line is clearly *inside* initramfs ...
[14:34] <ogra> and it dies immediately after firing up udev
[14:35] <ogra> try to regenerate your initramfs
[14:35] <amitk> ogra: yeah, disregard that. I'm currently running the archive kernel with my own initramfs (to debug the break=) problem. Will switch back to my own kernel.
[14:35] <ogra>    Image Type:   ARM Linux RAMDisk Image (uncompressed)
[14:35] <amitk> ogra: kernel with FB almost done
[14:35] <ogra>    Data Size:    2261686 Bytes =  2.2 MB
[14:35] <ogra> way to small
[14:36] <ogra> there are bits missing for sure ... by whatever reason
[14:36] <ogra> hmm, or no ... newer initramfses on my systems are as small ...
[14:43] <ogra> ... more coffee...
[14:45] <amitk> ogra: kernel with FB in on people
[14:45] <amitk> that fixed tty0, but our problem still remains...
[14:47] <ogra> ok
[14:47] <rsalveti> morning
[14:47] <ogra> i'd really love to talk to KEybuk, sigh
[14:47] <ogra> amitk, FB compiled in or module ?
[14:48] <amitk> compiled-in
[14:48] <ogra> ah, then i should be able to just use my initrd
[14:48] <amitk> ogra: but I _still_ don't get a busybox shell
[14:49] <ogra> do you get through initramfs ?
[14:49] <ogra> you should see all the "running scripts init-blah" messages
[14:49] <amitk> nope
[14:50] <ocs_> hi. how much does a Freescale i.MX51 Babbage board pda cost?
[14:50] <ocs_> (about)
[14:51] <ogra> $750
[14:51] <ogra> amitk, re-roll your initramfs something is corrupt there
[14:51] <ocs_> and... which is the cheapest board on which ubuntu-arm has been tested ?
[14:51] <amitk> ogra: doesn't kernel install already do that?
[14:51] <kaouthia> http://store.digi.com/index.cfm?fuseaction=product.display&Product_ID=1711
[14:52] <ogra> amitk, it re-rolls, but did you mkimage etc ?
[14:52] <amitk> ogra: yes, mkimage uImage, uInitrd
[14:52] <kaouthia> http://www.digi.com/products/embeddedsolutions/connectcore-wi-mx51.jsp#overview <-- Click "contact us" for the Linux version
[14:53] <kaouthia> Google is your friend
[14:53] <ogra> amitk, strange ... my boot definately goes through even with your current kernel ...
[14:53] <amitk> ogra: the latest one?
[14:53] <ogra> yup
[14:53] <rsalveti> ogra: did you find why the upstart was stopped during the boot?
[14:53]  * amitk wonder if he should run a apt-get upgrade on the chroot
[14:54] <rsalveti> was following the problem but had to get to work
[14:54] <ogra> amitk, didnt you use your USB installation root ?
[14:54] <rsalveti> I tested yesterday when I was playing with u8500 and had to remove some services to get it to boot, but didn't had time to go and further debug upstart to check who was the culprit
[14:56] <amitk> ogra: I did..
[14:56] <ogra> thats very strange, i havent seen such behavior
[14:56] <hrw> rsalveti: u8500 got some available boards or still ST-E internal only?
[14:56] <ogra> amitk, want a uInitrd on people ?
[14:57] <amitk> ogra: give me the whole package, uImage, boot.scr and uInitrd
[14:57] <ogra> ok
[14:57] <rsalveti> hrw: we've been working with then with other projects and boards, so we got some u8500 to work with when it was released
[14:58] <rsalveti> hrw: but the kernel, boot loader, mali driver and etc are all internal only atm
[14:58] <ocs_> thanks
[14:58] <rsalveti> hrw: they're pushing the kernel upstream, but the support is still very basic
[14:58] <hrw> rsalveti: so same like it was with NDK-15
[14:58] <hrw> but this time they learnt that using few years old kernel is not good
[14:59] <ogra> amitk, btw, no messages on console ... only a blinking cursor ... did you see kernel msgs ?
[14:59] <rsalveti> hrw: sure, currently we're using 2.6.29
[14:59] <amitk> ogra: yes
[14:59] <rsalveti> quite old and the kernel itself is not that stable, but it's working fine
[15:00] <ogra> amitk, http://people.canonical.com/~ogra/beagle/
[15:00] <hrw> rsalveti: when I had ndk-15 it was using 2.6.16.2 which at that time was up to .51 stable update. now I have NHK-15 with 2.6.20 kernel which I do not even want to look at
[15:00] <amitk> ogra: I see the kernel messages
[15:00] <ogra> note i'm fiddling with boot.scr atm
[15:00] <rsalveti> hrw: we got oe and maemo running on top of it as a proof of concept
[15:00] <ogra> you might want to change it for your purpose
[15:00] <hrw> rsalveti: and android
[15:00] <rsalveti> hrw: sure, they are working inside mainly with android
[15:00] <hrw> rsalveti: on SCW'09 ST-E shown android on u8500
[15:01] <rsalveti> now that maemo/meego stuff got more attention
[15:01] <rsalveti> hrw: yeah, the kernel is being developed mainly to support android
[15:02] <ogra> amitk, oh, intresting ... there *are* messages, but the console blanks at the point where i have the hang
[15:02] <ogra> i just switched my monitor over to late
[15:02] <rsalveti> hrw: we also have the basic mali support, but this will be closed source in the end, like sgx stuff
[15:02] <hrw> rsalveti: it it will be redistributable then it will be good
[15:02] <rsalveti> hrw: currently we're developing basic support for X acceleration, like exa, dri2 and xvideo
[15:03] <hrw> rsalveti: we (OH) did that for stn8815 few years ago
[15:03] <rsalveti> hrw: yeah, andrea was talking about it
[15:03] <rsalveti> then oh went for intel and they had to drop the project
[15:03] <hrw> anyway stn8815 is dead
[15:03] <ogra> amitk, whats even more intresting, while i still have the hang, the LDE behavior changed
[15:04] <ogra> *LED
[15:04] <ogra> both SD LEDs are solid green now
[15:04] <hrw> ogra: I have a board which talks after 'system halted'
[15:05] <amitk> ogra: USR0 and USR1?
[15:06] <ogra> amitk, HAHAHAHAHA !!!
[15:06]  * ogra fixes /lib/init/fstab
[15:06]  * amitk prepares to strangle ogra :)
[15:07] <rsalveti> hrw: but I think that with u8500 ste will at least make it full supported upstream
[15:08] <ogra> amitk, so i suspect the "console output" line in mountall.conf tries to write to plymouth ... while fbcon was broken it just got stuck there ... now i see the old "mount time in the future" bug
[15:08] <hrw> rsalveti: I hope too - it makes maintaince much cheaper
[15:09] <rsalveti> hrw: sure, besides making it easier for everyone that wants to used it as a product
[15:09] <rsalveti> the quality is much better when it's upstream
[15:09] <rsalveti> vendor's kernel is always a mess
[15:10] <persia> Lots of that is code-review issues.  Going through that many layers of code review internally could theoretically generate a good vendor kernel, but it's really expensive (and seems odd when one can mainline it for the same effort and lower cost)
[15:10] <amitk> ogra: no change with your initrd and kernel, I'll check my boot.scr now
[15:11] <ogra> amitk, yeah, probably one of your kernel debuig settings prevents initrd from being used
[15:11]  * ogra curses 
[15:11] <rsalveti> persia: yeah, but people seems afraid of mainline developers :-)
[15:11] <ogra> i cant get past fsck !
[15:12] <amitk> ogra: did you fix both fstabs?
[15:12] <ogra> amitk, only /lib/init/fstab that usually suffices
[15:13]  * ogra edits /etc/fstab too
[15:14] <GrueMaster> lool: I tested http://ports.ubuntu.com/dists/lucid/main/installer-armel/20081029ubuntu98/images/dove/netboot/dove/ image yesterday and it now works.  Completed the install with no issues.
[15:14] <ogra> Starting kernel ...
[15:14] <ogra> Uncompressing Linux... done, booting the kernel.
[15:14] <ogra> Ubuntu lucid (development branch) ubuntu ttyS2
[15:14] <ogra> ubuntu login:
[15:14] <ogra> WOHOOOOO !!!!
[15:15] <ogra> amitk, so the console fix is essential :)
[15:15] <ogra> amitk, lets corner Keybuk in brussels ... he owes us beer ... lots of ... i asked him yesterday and he insisted the bug would be 100% fixed in any case
[15:16] <ogra> Linux ubuntu 2.6.33-500-omap #5 Tue Apr 13 11:58:48 EEST 2010 armv7l GNU/Linux
[15:16] <ogra> Ubuntu 10.04 (lucid)
[15:16] <ogra> Welcome to Ubuntu!
[15:16] <ogra> :D
[15:17]  * ogra is happy that he can finally start to work 
[15:18]  * amitk hugs ogra 
[15:19] <amitk> ogra: so fixing both fstabs was reqd?
[15:19] <ogra> amitk, yep
[15:20] <ogra> now the point that counts ...
[15:20]  * ogra tries update-initramfs with vfat /boot
[15:21] <ogra> asac, why dont i have network on my cmdline system ? shouldnt NM sort that ?
[15:21] <ogra> oh, i dont have a driver
[15:22] <ogra> amitk, ergh ... no more USB with your latest kernel from people
[15:31] <lool> GrueMaster: Ok, the uinitrd settings were *not* changed
[15:36] <amitk> ogra: new kernel uploaded to people with OTG settings reverted.
[15:36]  * ogra pulls
[15:40] <prpplague> ogra: greetings
[15:42] <ogra> amitk, urgh and shutdown (sudo halt) results in an oops
[15:44] <amitk> ogra: try with archive kernel first, there are several changes in my kernel that we might not want at such short notice
[15:44] <ogra> hey prpplague (sorry i'm *very* busy ... final freeze is tomorrow)
[15:44] <prpplague> ogra: np, just saying hello
[15:47]  * ogra curses 
[15:48] <ogra> amitk, so while initramfs creation works, linux-image isnt installable on vfat :(
[15:48] <ogra> silly postinst !
[15:58] <amitk> ogra: any luck? (I need a break from this stuff)
[16:03] <ogra> amitk, gimme a min ... just got into a discussion in -kernel
[16:04] <amitk> np
[16:07] <amitk> ogra: so what did you have to change in /lib/init/fstab? Just the 1 -> 0
[16:07] <amitk> ?
[16:07] <ogra> amitk, yep
[16:08] <ogra> crapo i trashed my SD
[16:15] <ogra> amitk, lookd good
[16:15] <ogra> *looks
[16:23] <ogra> amitk, if you upload dont forget to adjust the deps
[16:23] <ogra> we need flash-kernel and uboot-mkimage
[16:26] <amitk> ogra: against linux-image-2.6.33.....?
[16:26] <ogra> yep
[16:29] <amitk> ogra: so usb is working now, right?
[16:30] <ogra> amitk, gimme a sec, it works with the SD install ... i want to make sure root on USB works too
[16:40] <ogra> amitk, root on USB works too now
[16:43] <ogra> amitk, so lool just pointed me to code that cares for uboot-mkimage ... but flash-kernel shoudl be a dep
[16:45]  * ogra wonders why he hasnt gotten flash-kernel installed on omap now
[16:53] <lool> ogra: we might not need flash-kernel as a strong dep for the same reason
[16:53] <lool> ogra: these are usually recommends
[16:53] <ogra> lool, i dont have it at all in my two omap installs
[16:54] <ogra> and iirc we had a reason to make it a dep in imx51
[16:54]  * ogra chacks again
[16:54] <ogra> *checks
[16:54] <amitk> ogra: I don't think it was a dep for imx51
[16:55] <ogra> Recommends: flash-kernel
[16:55] <ogra> linux-image-2.6.31-605-imx51
[16:55] <lool> ogra: You need to update flash-kernel-installer for the same reason
[16:55] <ogra> so right, make it a recommends
[16:55] <ogra> lool, yes, i'm doing that with some really ugly code
[16:55] <lool> ogra: No
[16:55] <amitk> ogra: only flash-kernel?
[16:56] <lool> ogra: see debian/flash-kernel-installer.postinst line 48
[16:56] <ogra> amitk, yes
[16:56] <lool> ogra: the Recommends is optional and just there to "be nice" to people installing an omap kernel by hand
[16:56] <ogra> lool, there was a reason for having the recommends ... iirc it was to enable people who manually roll images
[16:56] <ogra> right
[16:56] <lool> ogra: Yes
[16:56] <ogra> so lets stay nice :)
[16:56] <ogra> and have that recommends in omap too
[16:57] <ogra> no dep though
[16:57] <lool> ogra: not related to the fact you're missing it in your installed image
[16:57] <ogra> i'll handle that in flash-kernel-installer
[16:57] <ogra> yeah, i know
[16:57] <lool> If you used ubiquity / d-i that is
[16:57] <ogra> i did
[16:57] <ogra> well, d-i
[16:57] <ogra> ubiquity needs another image chjange before we can use it
[16:57] <amitk> ogra: I don't think it is even in recommends, in the kernel pkg
[16:57] <ogra> god, i cant type anymore
[16:58] <amitk> it is only in the bootloader section
[16:58] <ogra> amitk, please make it one for people maunally installing kernels
[16:58]  * ogra thinks these flash-kernel-installer changes will forever destroy the bit of reputation his coding style has left 
[16:59] <ogra> fiddling with fstab is really really nasty :/
[17:01] <lool> ogra: So if you used d-i / ubiquity, the problem is in flash-kernel-installer, not in deps
[17:01] <ogra> hmm
[17:01] <lool> I agree we want a recommends or a suggests, but I would personally go for a suggests
[17:01] <ogra> it is in deps
[17:01] <ogra> its just not executed
[17:01] <ogra> since there is no match for the beagle
[17:01] <lool> ogra: Yes, exactly
[17:02] <lool> ogra: that's not related to deps
[17:02] <ogra> lool, so ... i need an opinion
[17:02] <ogra> mdz suggested to create /boot/uboot for the first partition of the mmc (vfat needed for booting)
[17:03] <ogra> the only way i see to create that dir and make sure its mounted under /boot/uboot (for running mkimage) is to add code that adds this stuff to fstab in flash-kernel-installer
[17:03] <ogra> lool, do you have any better idea ?
[17:04] <ogra> i dont think i can invent a new partman module right now some hours before the freeze
[17:04] <lool> ogra: You need to update flash-kernel and flash-kernel-installer for OMAP beagleboard
[17:04] <amitk> lool: we have a debian.ti-omap/control.d/vars.<flavour> where we define the bootloader. The control generation scripts then automatically add that to a Recommmends in the control file.
[17:04] <ogra> lool, yes, i know
[17:04] <ogra> lool, i know what to do there ... please read above ... that fstab fiddling is more important
[17:05] <lool> ogra: Ok; need to finish a call to focus on the questions
[17:06] <lool> amitk: That's nice to have; I would _personally_ to for a suggests instead of recommends
[17:06] <ogra> lool, ok, i'll write some code you can review then
[17:06] <lool> I can argue why, but I'd rather convince ogra so that he agrees with the approach
[17:06] <lool> s/to/go
[17:06] <ogra> well, go with whatever you feel is right :)
[17:06] <ogra> i'm way to focused to finish omap :)
[17:06] <lool> ogra: So recommends make it a bit harder to replace the bootloader
[17:07] <lool> ogra: e.g. to use grub for arm, or mukluk
[17:07] <ogra> well, do you ever expect omap to not use uboot ?
[17:07] <ogra> oh, ok
[17:07] <ogra> thats an argument :)
[17:07] <ogra> amitk, go with a suggests :)
[17:07] <lool> Hmm that was easy  :)
[17:07] <ogra> heh
[17:08] <ogra> lool, i promised you i'D work on it ;)
[17:10] <lool> ogra: I didn't understand that /boot/uboot story; is this for images, for installed system, or both?
[17:11] <ogra> installed
[17:11] <lool> ogra: Also, why do we have this requirement?  is it to have a copy of the installed uboot?
[17:11] <ogra> to get around the hardlinks on /boot
[17:11] <ogra> no its for uImage/uInitrd and boot.scr
[17:11] <lool> ogra: Which hardlinks are these again?
[17:12] <ogra> lool, dpkg ... when replacing vminuz-*
[17:12] <ogra> or System.map-* etc etc
[17:12] <lool> ok, but u-boot is usually in /usr/lib?
[17:12] <ogra> it tries to create backup files using hardlinks
[17:13] <ogra> lool, well, we could call it /boot/bootloaderpartition if that makes it clearer
[17:13] <ogra> i made up /boot/uboot
[17:13] <lool> ogra: Can't we have anything which needs to have hardlinks in /boot and have /boot be in extN?
[17:13] <ogra> the point is that we cant have /boot on vfat ... and that the bootpartition needs to be mmcblk0p1
[17:13] <ogra> lool, nope, omap uboot doesnt support ext2
[17:14] <ogra> we talked about it in nice and thats supposed to be fixed at some point
[17:14] <ogra> but not atm
[17:14] <lool> ogra: Ok; dont we flash the kernel in NAND?
[17:14] <ogra> no
[17:14] <ogra> we use SD for booting
[17:14] <ogra> similar to imx51
[17:15] <ogra> but with a real vfat partition
[17:15] <ogra> so that partition should have an fstab entry
[17:15] <lool> ogra: So the NAND stuff is for post 10.04?
[17:15] <ogra> yeah
[17:15] <lool> ogra: Would I be you, I would find it much more easy and clean to implement the NAND stuff right now
[17:15] <ogra> lool, i have a working kernel since noon today :) i'm trying what i can
[17:16] <lool> I think in terms of coming up with a working design and such, the vfat approach is horrible
[17:16] <ogra> it is
[17:16] <ogra> its quick though
[17:16] <lool> Also, we will dump it after 10.04!
[17:16] <ogra> and i only have a few hours left
[17:16] <ogra> yes
[17:16] <lool> Upgrades will be disastrous
[17:16] <ogra> thats was the plan from the beginning
[17:17] <amitk> lool: ogra: I'm going with what is automatic for all kernel flavours (define it in var.flavour) and let the control-scripts do the rest. I don't like this sort of change 5 minutes before a freeze
[17:17] <ogra> thats handleable
[17:17] <amitk> besides all x86 flavours and fsl-imx51 use it already
[17:17] <lool> amitk: Oh you mean it's not easy to switch from suggests to recommends?
[17:17] <ogra> amitk, yes, all i want is the same imx51 does
[17:17] <lool> amitk: It doesn't matter then
[17:17] <amitk> lool: it is probably easy, I don't know enough about the ramifications...
[17:17] <ogra> lool, i think the other way round
[17:17] <ogra> currently it is a recommends
[17:18] <lool> ogra: I understand, was justan example
[17:18] <ogra> in imx51 at least
[17:18] <lool> amitk: No need to worry about it
[17:18] <ogra> yerah
[17:18] <lool> we can visit Recommends -> suggests later
[17:18] <ogra> just go for it
[17:18] <lool> The main point is: this dep doesn't really matter for us in practice, it's just a nice to have, and on the long term a suggests would make more sense
[17:19] <lool> ogra: So back to your vfat issue
[17:19] <ogra> lool, yeah :)
[17:19] <lool> ogra: flash-kernel was initially meant to flash stuff to NAND
[17:19] <lool> ogra: It's really meant for that
[17:19] <ogra> i know
[17:19] <ogra> but mtd is totally untested with our kernel
[17:19] <lool> ogra: I would find it easier to just implement that instead of this complex SD setup
[17:19] <ogra> SD works
[17:19] <lool> ogra: is it hard to test?
[17:19] <ogra> no idea
[17:20] <ogra> i have not much experience with mtd ...
[17:20] <ogra> and if i trash my board now we're screwed
[17:20] <lool> ogra: I seriously think you'll lose many days to build a decent design for what you're trying to do with vfat on SD and hardlinks in another partitions and that will be a waste post 10.04 and will prevent upgrades
[17:20] <lool> ogra: you can't really trash it
[17:20] <lool> ogra: you can always press user button and boot from SD
[17:20] <amitk> we'd have to setup partitioning to use mtd and something like ubifs?
[17:20] <ogra> i dont have *many days*
[17:20] <lool> amitk: No need for a FS
[17:20] <lool> amitk: it's just for kernel + initrd
[17:20] <ogra> i have a few hours
[17:21] <lool> ogra: Exactly, so would I be you, I would pick the simplest thing being NAND
[17:21] <ogra> the simplest thing is SD for me
[17:21] <ogra> since i have experience with that and dont need to start to learn while implementing
[17:21] <ogra> it just butt ugly
[17:21] <lool> You're in trouble IMO
[17:22] <ogra> i am
[17:22] <ogra> that was supposed to land a week ago
[17:22] <ogra> but i didnt have anything to work with
[17:23] <lool> ogra: So I'll just finish exploring the NAND stuff to have it here for reference: I think flash-kernel currently writes to mtdblock devices; you only get these if the kernel knows which areas of the flash map to each mtdblock device; problem is that IIRC beagleboard doesn't have any partition table for them
[17:23] <lool> ogra: So it would either be absolute addressing from the whole mtdblock device, or making sure we have partitions (perhaps we do have partitions?)
[17:24] <ogra> it should create one device for each partition
[17:24] <ogra> lool, ogra@ubuntu:~$ ls /dev/mt*
[17:24] <ogra> ls: cannot access /dev/mt*: No such file or directory
[17:24] <ogra> no mtd support ...
[17:24] <lool> ogra: For SD; I dont understand enough details of the problem; I suspect it impacts partman which is complex and picky
[17:25] <ogra> lool, it will be a hack in flash-kernel-installer at this point of time
[17:25] <ogra> surely not partman at all
[17:25] <lool> amitk: Do you know why we miss MTDs in the kernel support?  Is this missing drivers, missing config, bug...?
[17:25] <lool> ogra: "lol"
[17:26] <lool> ogra: Ok; so here's what I would propose
[17:26] <lool> ogra: That will make your like easy to some extent
[17:26] <ogra> ok
[17:27] <lool> ogra: a) make sure we create a flash-kernel.conf which explains that we're in a special mode to support beagleboard on sd card in 10.04
[17:27] <ogra> right, i was planning to
[17:27] <ogra> essentially planned to steal from imx where i can ... apart from the fstab stuff
[17:28] <lool> b) flash-kernel should, when this mode is set, look for where the first partition of the SD card (VFAT) is mounted -- or you could have a hardcoded value -- and copy over the /boot/* bits into the mounted partition
[17:28] <lool> I don't really like /boot/uboot, but it could work
[17:28] <ogra> well, another option would be mcopy to the partition file
[17:28] <lool> In reality, it should be /boot but it's too hard to move our files around
[17:28] <lool> ogra: I suspect you're taking risks by using mcopy
[17:29] <ogra> yeah, probably
[17:29] <lool> a) requires to ensure dosfstools is installed, new dep in multiple places
[17:29] <ogra> but it would overcome the fstab issue
[17:29] <lool> b) what happens if the partition is also mounted?
[17:29] <lool> For fstab you have two options
[17:29] <ogra> hmm, right
[17:29] <amitk> lool: missing config. (http://paste.ubuntu.com/414408/). I did this yesterday but then got side tracked by this boot issue today, so reverted it out of my tree.
[17:29] <lool> Either you make sure there's an fstab entry and it's created in the install phase and then you just expect it's mounted at $place
[17:30] <ogra> right, thats the /boot/uboot approach
[17:30] <lool> OR you hardcode the device / UUID where this should be written to, and then you check mounted filesystems to see whether it's mounted or not; if it is, you update this place, if it's not you mount it to $place and unmount it when done
[17:30] <lool> amitk: I think it's desirable, so please include it
[17:31] <amitk> ogra: you'll have another kernel to test and confirm then (for flash support)
[17:32] <ogra> lool, ok thats a bit more code than adding the following to flash-kernel-installer
[17:32] <ogra>         mkdir /target/boot/uboot
[17:32] <ogra>         uuid="$(block-attr --uuid /dev/mmcblk0p1)"
[17:32] <ogra>         echo "$uuid vfat defaults 0 0" >>fstab
[17:32] <lool> amitk: I am not a release manager, but I wouldn't think the feature freeze applies in the same conditions as on the other kernel packages here
[17:32] <ogra> well, /target/etc/fstab ... but essentially that
[17:32] <ogra> lool, it doesnt
[17:33] <ogra> we have a bit more freedom in all places were we dont touch other arches code
[17:34] <lool> ogra: I personaly wouldn't write directly to fstab, if the installer can include/detect the partition that's fine, otherwise I wouldn't hack the contents of fstab
[17:34] <ogra> the above is surely the most minimal, quickest but also hackiest approach
[17:34] <lool> a) you don't actually need an fstab entry b) it's very risky to touch it
[17:34] <lool> ogra: did you check whether the installer actually creates an entry for you already?
[17:34] <ogra> you mean i should better deal through flash-kernel with temporary mounting/unmounting ?
[17:35] <lool> It might be creating entries not mounted by default for other-os partitions
[17:35] <ogra> it doesnt
[17:35] <lool> ogra: yes; but if you do mount/umount, check that the fs isn't mounted somewhere else first
[17:35] <ogra> i added all omap realted code the last two days there isnt anything magic in it yet
[17:35] <ogra> *any
[17:36] <ogra> thats all 10.10 or for the interim
[17:36] <ogra> indeed
[17:37] <lool> ogra: But I really really think that you take less risks by trying the NAND route and you'll save yourself time in the end
[17:37] <ogra> lool, i'm scared to miss the freeze
[17:38] <ogra> and that code touches other arches code
[17:39] <ogra> lool, http://paste.ubuntu.com/414411/
[17:39] <ogra> thats flash-kernel-installer
[17:40]  * ogra needs a break and actually some breakfast ... i havent eaten today
[17:41]  * amitk hands ogra his all-day liquid diet
[18:00] <lool> ogra: a) I suggest you put some flag for the special mode in flash-kernel.conf, e.g. "beagle-board-install-location = sd" or just install-location; b) do the mkdir if the dir doesn't exist just before mounting, that's more robust c) not sure whether boot_uuid= or rootfs= have a meaning in flash-kernel.conf already; make sure it's the same meaning and no new variable are introduced needlessly
[18:00] <lool> ogra: on that note I need to drop off
[18:05] <ogra_cmpc> lool, thanks a lot
[18:05] <ogra_cmpc> root uuid only has a meaning for boot.scr
[18:06] <ogra_cmpc> but i think i'll just create that on the go in flash-kernel-installer
[18:07]  * persia idly notes that not all hardware has NAND
[18:10] <rsalveti> persia: at u8500 u-boot is loading the kernel and initrd from the emmc (bigger and chipier)
[18:10] <rsalveti> Show romanization
[18:10] <rsalveti> cheaper
[18:10] <rsalveti> argh
[18:10] <rsalveti> my logitech mouse is not working as it was before
[18:10] <persia> rsalveti: That's an example, indeed :)
[18:11] <rsalveti> persia: i think it's 8gb
[18:11] <rsalveti> so you can put the whole system there, besides the kernel
[18:11] <rsalveti> much like a desktop
[18:13] <persia> rsalveti: Ought be indistinguishable from any SD boot (e.g. booting my amd64 laptop from SD).
[18:13] <persia> But that depends, of course, on the bootloader :)
[18:13] <rsalveti> yeah, sure
[18:21] <sveinse> ogra, did you discover the kernel/initrd issue?
[18:21]  * sveinse is nosse1@home
[18:21] <amitk> ogra: people has the (hopefully) final kernel. Will upload after confirmation that it works for you.
[18:23] <sveinse> amtik, did you have to change the kernel today? I.e. are we looking at a ti-omap -6 ?
[18:26] <amitk> sveinse: yes, several config changes to make the install process work fine (mtd, framebuffer console, rtc driver, etc.)
[18:26] <sveinse> amtik, then I can try it once more on my EVM tomorrow then
[18:27] <amitk> sveinse: I doubt it will help a lot over -5 since I don't really have any EVM hardware to enable..
[18:28] <amitk> perhaps we'll be able to add more support when we get more boards after release
[18:28] <sveinse> amitk, well I can try at least. It's not the end of the world if doesnt work though
[18:29] <amitk> sveinse: sure :)
[18:29] <sveinse> may I ask the exact nature of the initrd boot issue ogra was working on when I left?
[18:30] <amitk> the boot would stop somewhere in the initramfs
[18:30] <sveinse> Because it is very similar to the symptoms I'm seeing on the AM3517-EVM, you see
[18:30] <rsalveti> I also had this problem yesterday when trying it on u8500
[18:31] <amitk> it turned out to be missing FRAMEBUFFER_CONSOLE support
[18:31] <ogra_cmpc> well, in combination with mountall :)
[18:31] <rsalveti> yeah, probably the issue I had was with mountall
[18:31] <amitk> right, the actual bug was in mountall
[18:32] <amitk> but didn't show up because of lack of FB support :)
[18:32] <ogra_cmpc> cat > /etc/e2fsck.conf << EOF
[18:32] <ogra_cmpc> [options]
[18:32] <ogra_cmpc> broken_system_clock = true
[18:32] <ogra_cmpc> EOF
[18:32] <ogra_cmpc> thatsthe proper fix btw :)
[18:32] <amitk> nice, no /lib/init/fstab hacking then :)
[18:33] <ogra_cmpc> i'll see if we can make that a default on beagle
[18:33] <ogra_cmpc> since we definately wont have a battery
[18:33] <rsalveti> cool, will try it when I get home
[18:34] <ogra_cmpc> its less evil than fstab hacking .... it will still check the filesystem ... but ignore the clock
[18:34] <sveinse> BTW: Is that (the system clock) why when you boot you see the kernel time doing a sudden jump up to a high value?
[18:34] <ogra_cmpc> yep
[18:38] <sveinse> Will the arm release follow the same release schedule (RC then release) as the main release plan?
[18:38] <ogra_cmpc> yes
[18:38] <ogra_cmpc> for now at least
[18:42] <sveinse> and it will be LTS?
[18:44] <ogra_cmpc> no
[18:44] <amitk> sveinse: there isn't anything worth an LTS in here yet :)
[18:47] <sveinse> ok. Point is LTS would fit our project/product schedule very well. If it were LTS, the customer support effort would be much simpler for us.
[18:48] <sveinse> Our product is designed for a market lifetime of 5 yrs (2017) after launch.
[18:52] <persia> sveinse: Even if 10.04 *was* LTS it wouldn't last until 2017.  12.04, if an LTS, would last that long.
[18:53] <sveinse> Yes, yes I know. It's us as mfg responsibility to provide the end user support anyways. During the period it covered by LTS, we will have an easier job keeping it up to date due to the LTS, that's all
[18:53] <persia> sveinse: So if you're actually planning a 2012 launch, and you want a product that runs Ubuntu, my recommendation would be to run current-devel and participate in making Ubuntu work to meet the product needs, so that the 12.04 release was absolutely perfect for you, and so that you had a track record supporting some specific image that could be enough to get LTS approval for it.
[18:54] <rcn-ee>  ogra, is the  "broken_system_clock = true" /etc/e2fsck.conf setting official for going forward now? (lucid -> lucid+1)
[18:54] <sveinse> The customer will not know Ubuntu is running in the scenes in our product. In fact we will try hard not to reveal that fact.
[18:54] <ogra_cmpc> rcn-ee, well, i'm still discussing soemthing like a cmsdline option with Keybuk in -devel
[18:55] <persia> sveinse: Oh, if that's all you're worried about, there will be critical bug support for all of userspace for 5 years anyway: just no special arm-specific work after 18 months (but, frankly, if all the arm-specific stuff isn't ironed out in 18 months, there's not enough user testing to matter for 60 months).
[18:55] <ogra_cmpc> rcn-ee, i guess for 10.04 it will be our best option but we'll discuss a better solution at UDS
[18:55] <sveinse> But we will use Ubuntu for deployment and upgrade. And drive the userspace system as well
[18:55] <rcn-ee> okay, nothing official yet.. ;)  I'll wait before i rewrite the scripts..
[18:55] <persia> sveinse: So you'd just be worried about the kernel.  WIth the current state of the Ubuntu kernels for ARM, you'd probably end up rolling your own kernel anyway (sadly, we're still a ways from truly generic kernels for ARM).
[18:56] <sveinse> persia, not the kernel, no. Because we're running custom HW which mandates custom kernel anyways
[18:56] <ogra_cmpc> rcn-ee, its the most official thing we have
[18:57] <rcn-ee> of course, by 10.10, all the old beagles will be long gone, and everything should have spots for battery hookups. ;)
[18:57] <sveinse> Basically, it's the "PC" idea which is tempting: We worry only about the kernel and the end-user application. The rest is the distro.
[18:57] <ogra_cmpc> amitk, http://paste.ubuntu.com/414443/ (tring to reboot into the new kernel)
[18:57] <sveinse> With Ubuntu, it is now possible to achieve this goal
[18:58]  * ogra_cmpc climbs upstairs to hot the reset buttomn
[18:58] <ogra_cmpc> *hit even
[18:58] <rcn-ee> sveinse, as long as you honor a couple specific config settings, it's pretty easy to use deb-pkg in a arm chroot to roll your own...
[18:58] <persia> sveinse: In that case, it's unlikely to matter that there's only 18 months of support for ARM, because there are 60 months of support for everything else, so most userspace will get critical bugfixes and security uploads.  Just make sure that any outstanding porting issues are hammered out in the first 18 months.
[18:59] <persia> ogra_cmpc: "hot" is probably also correct, although implies a lower level of hardware hackery :)
[18:59] <ogra_cmpc> heh
[18:59] <amitk> ogra_cmpc: this is on bootup?
[18:59] <sveinse> persia: and like you said, we can probably switch/participate on 12.04 as well and follow that when the time is right
[18:59] <persia> sveinse: The only possible issue would be if there was some massive change to the architecture that meant hardware in 2013 *couldn't build* for armel.
[19:00] <ogra_cmpc> amitk, no that was on shutdown
[19:01] <ogra_cmpc> amitk, i'm in the new kernel now seeing mtd[0-9] and mtdblock[0-n]
[19:01]  * ogra_cmpc tries another reboot
[19:01] <sveinse> persia, like the state of the art armel is called Cortex-A42 and not compatible with A8...
[19:01] <persia> sveinse: If you're thinking about switching, I *strongly* recommend that you base on 10.04, get into 10.10 as it is developing, attend the 11.04 UDS to start getting your base stuff implemented, attend the 11.10 UDS to make sure to fix the many significant bugs actual users exposed in that in 11.04, and then chase 12.04 for stabilisation and LTS-worthiness.  If you don't start now, it's unlikely you can get your stuff well-supported for LTS in 12
[19:01] <persia> .04.
[19:01] <ogra_cmpc> amitk, this time it worked, i'll try another reboot if i'm sure dpms kicked in
[19:02] <ogra_cmpc> (like in 10min)
[19:02] <persia> sveinse: Right.  Such a massive change would make 10.04 unsupportable in e.g. 2013, but I think that's unlikely.
[19:04] <sveinse> persia, it is still possible to follow 10.04 and on, because the product release isnt until Q1-2012. I would expect a feature freeze of around Q2/3-2011
[19:05] <ogra_cmpc> apw, kernel looks good so far i dont think its urgent to have the upload in tonights image though
[19:05] <apw> ogra_cmpc, cool then i'll await your 'go/no-go'
[19:05] <sveinse> persia, currently we are evaluating if we are to use Ubuntu. Coming from an purely embedded background (the project that is), it is a large jump into "mainline" distro philosophy -- like the fact that the packages are built natively
[19:06] <persia> sveinse: Hrm.  That gets tricky.  I'm expecting FF for 12.04 in Q4 2011.
[19:06] <ogra_cmpc> apw, i just want to wait for another 10min until dpms kicks in to be sure  http://paste.ubuntu.com/414443/ doesnt show up
[19:07] <persia> sveinse: Yeah, general-purpose-OS is fairly different from embedded.  That said, it offers a lot of flexibility it's hard to get in embedded, at the cost of a larger footprint.
[19:07] <ogra_cmpc> well ...
[19:07] <ogra_cmpc> depends how you will define embedded in five years
[19:08] <sveinse> persia, Yes. And again the far greatest reason for wanting Ubuntu is the upgrade/package system which solves a lot for our part when it comes to deployment
[19:08] <ogra_cmpc> i guess thne you are at the state of a normal low powered laptop of today
[19:09] <sveinse> our system is speced with 512M/1G NAND, so it will work, but not with too great margin (considering the space at least)
[19:09] <ogra_cmpc> rcn-ee, did you manage to capture any backtrace from apt ?
[19:10] <persia> ogra_cmpc: "embedded" means two things to me.  1) computers that are inside other things, and not expected to have any real "interface", so much as just run control software (e.g. the main processor in your keyboad).  2) a softwre building philosophy traditional for such environments, where ideally you want a single monolithic binary, but you may end up breaking it up a bit for ease-of-management: however you know, in advance, everything that it
[19:10] <persia>  needs to do,and the code does that.
[19:10] <persia> sveinse: 1G NAND is tight.  Any chance that could be 2G?
[19:10] <persia> (or emmc works)
[19:11] <rcn-ee> nah, nothing really good/useful yet..  Had some urgent emails this morning, where 1.4.4ss X-loader and 2010-03 seems to be causing issues with 9.10.. ;)
[19:11] <sveinse> persia, perhaps. We landed on 1G because then you can use SLC NAND, which has a high data retention. MLC are poor in that respect
[19:11] <sveinse> Perhaps 2G SLCs are becoming more common now
[19:12] <ogra_cmpc> rcn-ee, pfft 9.10 ... thats so old
[19:12] <persia> sveinse: Worth a look.  We don't recommend installing Ubuntu with less than 2G space.  It's possible to do things like mount / and /usr separately, but that tends to annoy folk when some partition runs out, and there's still free space on the other.
[19:12] <ogra_cmpc> rcn-ee, i just remembered it because i see kirkland in #ubuntu-devel
[19:12] <ogra_cmpc> (he's our qemu maintainer)
[19:12] <persia> (and for general use we really recommend 4G, but 2G works, if necessary)
[19:13] <rcn-ee> I know.. ;)  but since i release images on rcn-ee.net i need to half ass support them before the next release.. ;)
[19:13] <persia> rcn-ee: Only two more weeks :)
[19:13] <ogra_cmpc> persia, well, if i can make it :P
[19:13] <sveinse> persia, yes. Ubuntu's reccomendation is not an issue, because we will strictly control the packages going into the product. Basically it will be ubuntu-minimal + custom QT (running on fbdev) + our app.
[19:14] <rcn-ee> thanks, ogra, i'll watch ubuntu-devel for any hints...
[19:14] <ogra_cmpc> amitk, so i get the same oops after waiting 10min
[19:14] <ogra_cmpc> amitk, i guess there is an issue with dpms
[19:14] <ogra_cmpc> apw, ^^^^
[19:14] <persia> sveinse: How do you strictly control the packages?  Is there no UI available?
[19:15] <persia> sveinse: I'm all for folks using Ubuntu in products, but I worry that we may not be able to meet that requirement.
[19:15] <sveinse> persia, no Ubuntu UI (gnome/kde), only our application.
[19:15] <rcn-ee> persia, can't wait, specially with daily X-loader/U-boot changes happening in Angstrom right now.. ;)
[19:15] <sveinse> persia, is there a problem with that?
[19:15] <persia> (if nothing else, someone can spoof their local DNS, and swap a package name so the automatic updater installed e.g. ubuntu desktop)
[19:15] <ogra_cmpc> rcn-ee, we dont touch uboot/x-loader in 10.04
[19:16] <persia> sveinse: I can work around it in 20 minutes.  If that's acceptable to you, then there's no problem :)
[19:16] <ogra_cmpc> we just rely on them being in NAND
[19:16] <sveinse> persia, we won't associate ubuntu into this. At least not visibly. We must, however due to copyright and source references of course.
[19:17] <persia> sveinse: Understood.  I just want to make sure that you realise that while you can not install stuff by default, and not give the users a UI to install stuff, that if you allow updates over the network, and you're based on Ubuntu, it's trivial for a user to install anything they want.  This may be a hackers-only-manufacturer-unsupported use case, but if you have (e.g. regulatory) reasons why this *cannot* happen, I'm unsure that you've selected the
[19:17] <persia>  right base.
[19:17] <sveinse> persia, I think that's fine. The product we're building is training equipment for emergency medical personel.
[19:18] <rcn-ee> Yeah i saw that...  Sadly I'm going the other way, betting on me finishing XM support at the last minute.. ;)  (need latest x-loader/uboot for xm) here's my nasty script: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/image-builder/annotate/head%3A/tools/setup_sdcard.sh
[19:19] <persia> sveinse: Oh, that's easy.  Just make sure the end-user license specifies that it is no longer guaranteed to comply with X, Y, and Z if there is end-user modification to the base software, so that anyone who hacks it can't complain when it doesn't act like they expect.
[19:19] <sveinse> persia, We don't think the customer will have the compteance or will to do that. However, if someone does, by GPL it's fine that they install ubuntu-netbook on it
[19:19] <sveinse> The only thing we keep to our chest til the business logic
[19:19] <persia> sveinse: Yeah.  Just wanted to make sure.  Some regulatory regimes for some classes of equipment don't allow that, which makes it tricky.
[19:20] <sveinse> We'll have to see. This isn't settled internally yet. But there's the TiVoization monster lurking in the back here as well
[19:23] <persia> Oh, good point.  I always forget about the GPLv3 restrictions.
[19:25] <ogra_cmpc> hmm
[19:25]  * ogra_cmpc wonders how to put initrd into nand on beagle
[19:26] <sveinse> ogra_cmpc, if it's the same as the AM3517-EVM, its a specific region in the NAND
[19:26] <sveinse> ogra_cmpc, http://elinux.org/BeagleBoardNAND
[19:27] <ogra_cmpc> sveinse, thats what i'm reading atm
[19:27] <ogra_cmpc> but it diesnt have an explicid initrd partition
[19:27] <sveinse> ogra_cmpc, ummm.. it doesn't mention initrd, no
[19:27] <ogra_cmpc> i guess i need to use the filesystem one
[19:28] <sveinse> Hold on, I'll dig up the descr for the AM3517
[19:29] <rcn-ee> ogra, just need to carve another section: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/board-omap3beagle.c;h=962d377970e9bb198d410abf1ac1b418d0658341;hb=HEAD ;)
[19:29]  * sveinse is wondering if the partition table is hardcoded into u-boot...
[19:30] <ogra_cmpc> rcn-ee, no way ... amitk would kill me if i requested any change now
[19:30] <rcn-ee> i know.. ;)  I'm keeping my mouth shut too..
[19:31] <ogra_cmpc> heh
[19:32] <persia> sveinse: It's not.
[19:33] <rcn-ee> did you guys decide on a mount name for the vfat /dev/mmcblk0p1 partition?  If so, I'll make it consistent with the demo images...
[19:35] <ogra_cmpc> i'm still pondering to use NAND now that i have it actually
[19:36] <ogra_cmpc> though i need to find the right runes for the uboot env and for initramfs
[19:37] <amitk> ogra_cmpc: please file the bug and I'll start looking
[19:37] <ogra_cmpc> amitk, which one ? dss2 ?
[19:38] <amitk> ogra_cmpc: so you get identical oops for halt and dpms?
[19:38] <amitk> right, the dss2 one
[19:40] <ogra_cmpc> amitk, for halt when dpms is active
[19:41] <ogra_cmpc> oh, i guess you meant reboot :)
[19:41]  * ogra_cmpc didnt try halt yet
[19:41] <ogra_cmpc> amitk, yes, just tried, halt and reboot
[19:42]  * ogra_cmpc sighs and climbs the stairs once more
[19:43] <persia> ogra_cmpc: If you have another machine up there, consider a USB-controlled switch :)
[19:43] <persia> (mind you, this may cause you to inadvertently gain weight)
[19:44] <ogra_cmpc> i need a relais to press the reset button
[19:44] <ogra_cmpc> i usually dont work from the living room :)
[19:44] <ogra_cmpc> no danger of gaining weight :)
[19:47] <amitk> ogra_cmpc: so no-go for upload, right?
[19:48] <DanaG> hmm, is there another -500-omap kernel now?
[19:49] <amitk> DanaG: there will be by tomorrow
[19:49] <DanaG> And I did notice that you'd put not only musb_hdrc, but also g_ether (and nothing else) into the kernel.
[19:49] <DanaG> I wish there were a way to compile-in all the gadget drivers, and select via sysfs which one gets to be active.
[19:50] <DanaG> Either that, or have the musb_hdrc built-in but g_* as modules.
[19:50] <amitk> DanaG: I did that but ogra_cmpc reported that it killed his EHCI-connected peripherals
[19:50] <amitk> I have to investigate what is going on...
[19:51] <DanaG> Weird.
[19:51] <amitk> OTG might be fixed as an SRU (after release next week)
[19:51] <DanaG> I also have some weird behavior with my asix.
[19:51] <amitk> asix seems to work just fine here
[19:51] <DanaG> It doesn't work when plugged in during boot.. I have to unplug and replug the usb+ethernet thingy for it to work.
[19:51] <amitk> the USB code is all plain 2.6.33 mainline
[19:51] <DanaG> I can sniff packets with tshark, and get literally zero.
[19:52] <amitk> huh
[19:52] <DanaG> And yet it thinks it's up.
[19:52] <amitk> there is definitely something up with the usb stack of omap3 in 2.6.33 mainline.
[19:55] <DanaG> oh yeah, and I did get a log of plymouth (in this case, on my host) refusing to show splash.
[19:55] <DanaG> www.csc.calpoly.edu/~dgoyette/amtterm.log
[19:56] <DanaG> console=ttyS0 console=tty0
[20:03] <ogra_cmpc> amitk, well, its your reputation ... upload if you feel like
[20:06] <ogra_cmpc> amitk, apw, i'm happy with the functionallity for now if you guys feel ok with an oops on shutdown/reboot ...
[20:06] <apw> ogra_cmpc, /me is just the monkey which pushed the buttons ...
[20:06] <ogra_cmpc> amitk, just note that slangasek just said 0000 UTC is freeze time
[20:07] <ogra_cmpc> ah, you just asked the same :)
[20:17] <goshawk> can i make ubuntu arm running on a Processor       : ARM926EJ-Sid(wb) rev 5 (v5l) ?
[20:18] <Stskeeps> armv5te, so only ubuntu 9.04
[20:18] <goshawk> oh hi Stskeeps
[20:21]  * NCommander waves to Stskeeps 
[20:21] <Stskeeps> 'lo
[20:21] <goshawk> Stskeeps: why only 9.04?
[20:21] <Stskeeps> 9.10 is for armv6+vfp
[20:21] <Stskeeps> and next step again would be armv7
[20:22] <goshawk> k understood
[20:22] <goshawk> 9.04 is enough
[20:22] <goshawk> do you have a rootfs ready somewhere?
[20:22] <Stskeeps> Mer?
[20:22] <Stskeeps> :P
[20:22] <goshawk> Stskeeps: are you collaborating with ubuntu-arm too?
[20:22] <goshawk> Stskeeps: well a mer image could be good too
[20:22] <Stskeeps> nop, i'm in the meego camp now
[20:25] <persia> Mer would be *lovely* but it proves exceedingly difficult to integrate with Ubuntu, unfortunately.
[20:30] <goshawk> can i run rootstock from my x86 machine and have a generated armel rootfs ?
[20:30] <goshawk> it does not seem clear from this infos: https://wiki.ubuntu.com/ARM/RootfsFromScratch
[20:30] <persia> goshawk: That is indeed the central usecase for the existence of rootstock.
[20:34] <ogra_cmpc> sigh
[20:34] <ogra_cmpc> so lool was right, NAND would be trivial
[20:34] <ogra_cmpc> but i cant change the bootargs to actually load an initramfs or to change the cmdline
[20:35]  * ogra_cmpc cires
[20:35] <ogra_cmpc> *cries too
[20:38] <ogra_cmpc> oh man
[20:38] <ogra_cmpc> that would be so easy
[20:41] <ogra_cmpc> sigh, why does redboot appear so much easier every time i try to do something with uboot that goes beyond the defaults
[20:42] <prpplague> hey who was using the AM3517 here?
[20:44] <ogra_cmpc> prpplague, nosse1_away
[20:44] <prpplague> ogra_cmpc: ahh thanks
[20:52]  * ogra_cmpc wonders if anyone ever tried to cat boot.scr into the u/boot mtdblock partition and if that would work
[21:06] <Martyn> it doesnt
[21:08] <amitk> ogra_cmpc: calling it a day...
[21:14] <ogra_cmpc> amitk, did you upload anything ?
[21:15] <ogra_cmpc> apw, ??
[21:15] <apw> ogra_cmpc, i was about to hit return on it
[21:15] <ogra_cmpc> ok
[21:15] <apw> ogra_cmpc, happy ?
[21:15] <ogra_cmpc> justwanted to make sure
[21:16] <ogra_cmpc> apw, far from beimng happy but i'm ok
[21:16] <ogra_cmpc> i still have a very long night ahead to implement what should have happened a week ago
[21:16] <apw> ogra_cmpc, sorry if that is my fault ... i hate working late too
[21:17] <ogra_cmpc> apw, not your fault
[21:17] <ogra_cmpc> circumstances
[21:19] <ogra_cmpc> asac, can we get a last munite MIR ?
[21:19] <ogra_cmpc> *minute
[21:30] <cwillu_at_work> hmm, libcairo2 fails to build from source on karmic afaict
[21:38] <mpoullet> good morning
[21:39] <mpoullet> I'm trying rcn latest Lucid prebuilt image on my Beagle, it works well but at startup I get some "could not write bytes: Broken pipe", what's wrong? http://pastebin.com/Wgr3hP1Z
[21:55] <asac> ogra_cmpc: which one?
[21:56] <ogra_cmpc> asac, heh, not filed yet
[21:56] <ogra_cmpc> asac, uboot-envtools (two commands in the package)
[21:57] <asac> ogra_cmpc: what for ?
[21:57] <asac> omap?
[21:57] <ogra_cmpc> with that i could write kernel/initrd to NAND and have proper env variables set on beagle
[21:57] <ogra_cmpc> yeah
[21:58] <asac> ogra_cmpc: where would the impl change land? flash-kernel?
[21:58] <ogra_cmpc> flash-kernel-installer and flash-kernel, yes
[21:58] <asac> whats the risk?
[21:58] <ogra_cmpc> flash-kernel-installer would actually be the tool making use of the commands
[21:58] <ogra_cmpc> zero ?
[21:58] <asac> uboot-envtools is definitly perfect ;)?
[21:59] <ogra_cmpc> we wipe the NAND and replace the default setup with our vars
[21:59] <ogra_cmpc> no idea if its perfect
[21:59] <ogra_cmpc> its fw_setenv and fw_printenv
[21:59] <ogra_cmpc> doesnt contain much more (some docs)
[22:01] <ogra_cmpc> so the idea is: flash-kernel-installer uses fw_setenv to set bootcmd and bootparms as well as bootdelay
[22:02] <ogra_cmpc> flash-kernel cats uInitrd to the Kernel mtd device and cats uInitrd to the filesystem mtd device
[22:02] <ogra_cmpc> the bootcmd we set before automatically loads uImage and uInitrd and execs bootcmd then
[22:03] <ogra_cmpc> that drops the requirement fo a SD card
[22:03] <ogra_cmpc> we can boot directly from USB
[22:03] <ogra_cmpc> and dont need vfat /boot
[22:36] <ogra_cmpc> asac, bug #563394
[22:36] <ubot4`> Launchpad bug 563394 in uboot-envtools (Ubuntu) "MIR uboot-envtools is needed for flash-kernel installer in omap (affects: 1)" [Undecided,New] https://launchpad.net/bugs/563394
[22:46] <asac> ogra_cmpc: can you fix the build system to not remove source files on make clean ;) ... and add the .o there and then run MAKE clean ;)
[22:47] <asac> also add -g so we get debug symbols
[22:47] <asac> that to debian/rules
[22:48] <asac> also all the CONFIG_ variables are nowhere configured
[22:48] <asac> does that mean we want empty default?
[22:49] <ogra_cmpc> oh, sigh
[22:49] <ogra_cmpc> thats a lot of changes
[22:49]  * ogra_cmpc will be busy with flash-kernel until the freeze kiscks in
[22:49] <ogra_cmpc> and i'm nit even sure i can make that one
[22:49] <ogra_cmpc> *not
[22:50] <ogra_cmpc> i didnt expect it to be that bad
[22:50] <asac> ogra_cmpc: any words when freeze will kick in?
[22:50] <asac> in 1h or rather 12 ;)
[22:52] <ogra_cmpc> 0000 UTC
[22:52] <ogra_cmpc> i'm unlikely to make it with flash-kernel
[22:52] <ogra_cmpc> (and i'm up since 6am ... cant even tyype straight)
[23:31]  * DanaG wishes ubuntu had an official arm cross-compiler.
[23:35] <ogra_cmpc> see /topic :)
[23:42] <Martyn> DanaG : What do you mena?
[23:42] <Martyn> mean?
[23:42] <Martyn> OH .. well, yeah
[23:43] <Martyn> nice thing about building natively on the buildd machines
[23:43] <DanaG> Oddly enough, there _does_ seem to be an official ppc compiler.
[23:43] <DanaG> er, ppc cross-compiler.
[23:52] <ogra_cmpc> phew
[23:52] <ogra_cmpc> so i got a working NAND implementation
[23:53] <ogra_cmpc> ogra@ubuntu:~$ sudo flash-kernel
[23:53] <ogra_cmpc> [sudo] password for ogra:
[23:53] <ogra_cmpc> Generating kernel u-boot image... done.
[23:53] <ogra_cmpc> Erasing Kernel NAND space... done.
[23:53] <ogra_cmpc> Flashing kernel... done.
[23:53] <ogra_cmpc> Erasing Initramfs NAND space... done.
[23:53] <ogra_cmpc> Flashing Initramfs... done.
[23:53] <ogra_cmpc> ogra@ubuntu:~$
[23:53] <Martyn> ogra : What platform?
[23:53] <ogra_cmpc> buti wont make flash-kernel-installer in time i guess
[23:54] <ogra_cmpc> lool, ^^^ fyi
[23:54] <ogra_cmpc> Martyn, omap
[23:54] <Martyn> I heard David Mandala's interesting speech at the Texas Linux Fest -- about a single kernel for ARM platforms.   He sees it as 3 years out...
[23:54] <Martyn> I think we can do better than that :)
[23:56] <rcn-ee> 3 years for maybe "all" arm.. omap should have multi-omap support by the end of the kernel release, then on top of your work and the device tree stuff...
[23:56] <rcn-ee> Martyn, do you have a git tree for your current multi arm work?
[23:59] <Martyn> rcn-ee : Yes, internally at smooth-stone
[23:59] <Martyn> rcn-ee : Not even ready for an -mm release
[23:59] <DanaG> hmm, so is the idea now to nand-flash the ubuntu kernel and initramfs?
[23:59] <DanaG> What about the beagle-xm, which may be sans NAND?