#ubuntu-arm 2009-04-07
<Martyn> ogra : I have an alpha-quality u-boot now
<ogra> nice
<Martyn> ogra : Should I commit a bug and patch?
<ogra> sure, but that wont enter jaunty anymore
<Martyn> frig
<Martyn> we're locked on Redboot for now then, eh?
<ogra> yes, and it works just fine, is configurable from the running system etc
<Martyn> thanks to a -lot- of work by lool, you, etc...
<ogra> http://people.ubuntu.com/~ogra/arm/babbage/ has todays image
<Martyn> It's just a pity we have to do all those contortions :)
<ogra> lool is nearly done integrating the build script into the autobuilders, so std images will show up this week on cdimage.u.c
<Martyn> ogra : Are you experiencing any board lockups or instability surrounding using the USB bus?
<Martyn> ogra : I keep getting hard lockups when using a network USB adapter
<ogra> we were told to not use the normal USB ports but  the mini
<ogra> at least for devices with some payload
<lool> Martyn: Same here, but we moved to the builtin ethernet again now
<lool> Martyn: It's better with the latest 2.6.28 we ahve
<ogra> i have kbd and mouse in normal USB ... HDD on mini with powered HUB
<Martyn> lool : Someone found the slow performance issue for the built in ethernet?
<ogra> we got patches
<Martyn> ogra : using one of those weird usb A-B cables?
<Martyn> mini a/ minib
<ogra> they are in the current kernels but cause other probs
<Martyn> *sigh*
 * ogra points to bug 356517 and bug 356975
<ubot4> Launchpad bug 356517 in network-manager "udev does not detect eth0 on armel" [High,In progress] https://launchpad.net/bugs/356517
<ubot4> Launchpad bug 356975 in linux "imx51 oops after watchdog call" [High,New] https://launchpad.net/bugs/356975
<Martyn> So many issues to solve, and Pegatron is already starting tooling up for ARM based netbooks with the i.mx515 in them
<Martyn> Yeah, I just saw 356975
<ogra> it doesnt stop the NIC from working
 * Martyn lets the 3 hour download from ogra's image repo start
<ogra> but i dont see any plug events anymore for the cable
<Martyn> Is redboot entirely frozen for jaunty?
<Martyn> Or is it possible that I might be able to get a usb-boot patch in?
<ogra> i dont think we can add new features at this point
<Martyn> Oh well.
<ogra> we're close to RC
<ogra> bugfixing is the main focus now
 * ogra would be very very thankful for any idea or help on bug 328167 btw
<ubot4> Launchpad bug 328167 in gnome-keyring "[arm] gnome-keyring-daemon eating 100% CPU at login in Jaunty" [High,Triaged] https://launchpad.net/bugs/328167
<ogra> its our biggest blocker atm
<Martyn> ogra : I'll take a look at it
<ogra> that would be cool, we need as many eyes as possible on it
<ogra> (i know NCommander planned to look as well and i'll donate the the rest of my week to it too)
<NCommander> ogra, as far as I can tell its a Babbage specific issue
<NCommander> ogra, I was unable to reproduce it on anything else :-/
<ogra> it is
<NCommander> ogra, oh, I didn't see that in the bug report :-/
<ogra> but we still need to solve it
<Martyn> To debug the issue, I'm going to have to do a debug build
<Martyn> there's not trace information
<Martyn> not/no
<ogra> there is the upstream bug
<Martyn> NCommander : it happens on the EVM as well as babbage
<NCommander> ogra, the upstream bug doesn't have a full backtrace
<ogra> but what i added there is apparently not enough
 * NCommander is going to have to trace it through the entire GNOME stack until it calls into libc
<NCommander> ddebs are your friend for this
<ogra> Martyn, you have an EVM that survives gnome ?
<Martyn> yeah
<Martyn> but I cheat :)
<Martyn> usb->video adapter
<ogra> soldered RAM on it youreself ?
<ogra> -e
<Martyn> no, I just live with an extremely swappy system
<Martyn> it's slow as tar
<ogra> heh
<Martyn> no, slower
<NCommander> Well, we do know its a regression, we didn't start seeing it until about February
<ogra> yeah
<NCommander> Martyn, sounds like my Babbage running with the pendisk
<Martyn> slow as pure glass flowing down a window
 * NCommander is setting up the other one with the USB HDD
<Martyn> hey, I have a BeagleBoard tucked away in the drawer
<Martyn> this might be a good time to drag it out, and see if I can get the gnome-keyring issue to show up there
<NCommander> Martyn, +1
<NCommander> I couldn't reproduce on something running a 2.6.25 kernel, but I can't upgrade to the latest kernel either
<NCommander> (newest userland)
<Martyn> My only issue there, is the crappy usbOTG on the board
<NCommander> and my slugs don't have enough RAM
<NCommander> Martyn, ow. Thats going to hurt
<Martyn> but I think it's possible to solder two pins together on the mini USB port, and not have to deal with getting a special OTG cable
<Martyn> I should have done the mod ages ago
<ogra> on mine a plain mini->-std USB adapter works
<Martyn> ogra : I need keyboard, mouse, ec..
<Martyn> so I need to connect it to a usb hub first :)
<Martyn> brb
<Martyn> okay, BeagleBoard pulled out of drawer
<Martyn> ogra, any reason to think the kernel that was built for your image wouldn't boot it?
<ogra> ??
<ogra> the imx51 kernel on the beagle ?
<ogra> no, that surely wont boot
<Martyn> ogra : Sorry, brain not working .. I meant "any reason your image wouldn't boot with a proper Beagle kernel..."
<Martyn> error existed between user and keyboard
<ogra> no, should work
<Martyn> good, that gives me a consistent platform to test
<Martyn> Of course, it helps if the clock is set
<Martyn> There has -got- to be a way to kill that @#$@$ annoying bug
<NCommander> Martyn, we know its a regression, it popped up around Feb 20th
<Martyn> I mean, sure, we know it's not really 1970 ...
<NCommander> Oh, THAT bug
<Martyn> yep, the pam bug
<NCommander> That one got fixed
<NCommander> Its not pam, its shadow
<NCommander> Martyn, is that using a daily vs. a beta image?
<NCommander> (it was fixed after beta)
<Martyn> daily, but I'm downloading Oscar's latest one now
<Martyn> 24% complete .. it's a slow download today
<NCommander> Martyn, Oscar?
<NCommander> Martyn, if your still seeing the password bug on a fresh install thats a problem
<NCommander> :-/
<Martyn> ogra
<Martyn> Well, i've got another 30 minutes before the download is complete
<Martyn> NCommander : Then we'll see if the password bug remains
<Martyn> but if it's reported fixed, I shouldn't see it
 * ogra points to http://cdimage.ubuntu.com/ports/daily-live/20090407.2/ look, there is a babbage image ;)
<lool> http://cdimage.ubuntu.com/ports/daily-live/current/ is the stable URL
<ogra> right
<NCommander> ogra, I don't see a babbge image at that URL ...
<NCommander> Oh
<NCommander> bah, you need to mark it armel+imx51 :-P
<ogra> cjwatson didnt want to
<ogra> given that its the only arm live image we build anyway
<ogra> the html text will be updated though
<ogra> anyway, out now ... bye
<NCommander> Martyn, how goes your install?
 * NCommander is currently grabbing all the ddebs
<NCommander> ogra, you around?
<lool> Did someone try usplash on babbage?
<lool> The initramfs is really slow, that surprizes me
<NCommander> lool, it works on PowerPC AFAIK, so it *should* work. How well, I dunno
 * NCommander finally is getting some useful backtraces :-)
<Martyn> re
<Martyn> NCommander : I'm recompiling the kernel for the Babbage board
<Martyn> NCommander : Turns out there wasn't one handily available for some reason
<Martyn> er, Beagle, not babbage
<NCommander> Martyn, there are plenty available, why are you recompiling for Babbage?
<Martyn> Brainfrarting continues
<NCommander> Oh, Ubuntu doesn't officially support Beagle
<Martyn> Right
<Martyn> so I'm compiling Beagle
<Martyn> but >only< changing the parameters needed to get it working on Beagle, so as to hopefully see if I see the same issues
<Martyn> because I'll be using the Babbage userland
<NCommander> heh
<Martyn> time to compilation completion -- 1hr 8min
<Martyn> Ah, the joys of native compilation
<pwnguin> how significant is uclib to the arm port?
<Martyn> we use uclib?
<pwnguin> looks like no
<Martyn> I use uclibc to produce busybox images early on during a bring up of a new arm board...
<Martyn> but AFIK (YMMV) the jaunty arm port is full blown glibc
<pwnguin> yea, i was thinking it'd be part of busybox or something but i guess not
<pwnguin> intersting. uclibc is in hardy
<pwnguin> dropped from intrepid and later i guess.
<pwnguin> only reason i ask is because i was revisiting a patch dump from Garmin, trying to figure out why a patch wasn't applied upstream. it seems tracked down to uclibc, but if debian / ubuntu aren't using uclibc there's probably no interest in the patch or upstreaming it.
 * NCommander headthunks 
<pwnguin> NCommander: ?
<NCommander> pwnguin, working on g-keyring-daemon
<pwnguin> fun
#ubuntu-arm 2009-04-08
 * NCommander is trying to bisect the problem
<Martyn> can't sleep
<Martyn> I've got the BeagleBoard working (the root password reset issue did _not_ show up, btw)
<Martyn> I cannot replicate the issue on the Beagle.
<Martyn> so it -must- be babbage specific
<lool> ogra: Any idea why the initramfs takes so much time to mount the SD when booting the install SD?
<lool> Hmm I wonder whether it tries to mount the SATA disk and times out
<ogra> likely
<ogra> casper iterates over all devices
<ogra> the SATA->USB bridge always creates a device even if nothing is attached
<lool> Yes  :-/
<ogra> next HW version will have PATA
<ogra> for now we have to live with that
<lool> ogra: So we should drop that LIVEMEDIA thing, it doesn't help
<ogra> i think it timed out without it
<lool> Ah
<ogra> let me finish the script parser, i'll check the livemedia thing afterwards
 * ogra curses shell for being bad with multiline strings 
<lool> We should also try splash
<ogra> breaks
<lool> What breaks?
<ogra> usplash
<ogra> try it
<ogra> it totally wasnt on my list for jaunty so i didnt pay any extra attention but to disable it
<ogra> i have it on the TODO for KK
<lool> Is there a bug for it?
<ogra> nope
<Martyn> ogra : I couldn't reproduce the keyring daemon taking up 100% cpu on the Beagle board
<Martyn> ogra : I can, however, reproduce it on the Babbage, and will continue looking at it as soon as I get a mini to standard USB cable
<Martyn> afternoon
#ubuntu-arm 2010-04-12
<ndec> ogra: morning! [i changed my nick to a shorter one...]
<ndec> ogra: I tried the latest OMAP3 image on Zoom2. I don't have the USB issue anymore, but since display driver for Zoom2 is not upstream, there is no display support
<ndec> ogra: i am trying to get a display driver, if I can find something that works i will let you know
<hrw> morning
<ogra> ndec, forward that to amitk then, he cares for kernel implementation
<amitk> ndec: no usb?
<ogra> amitk, no issues :)
<amitk> aah,
 * amitk is still waking up
 * ogra also bumped compcache to 50%, i'll build an image later today that should run flawless on the C4 beagle
<amitk> ogra: is there an official image available now?
<ndec> amitk: well, i am not sure the boot goes fine. there is obviously no kernel panic. but since there is no display I can't see much. on the console I can see some services firing up such as APM, Pulse, ...
<ogra> amitk, yes, but it will OOM without the new compcache setting
<ogra> ndec, change boot.scr and add serialtty=ttyS3
<ogra> ndec, i have it happily booting with that to serial commandline prompt
<amitk> ogra: with splash too, i presume?
<ogra> amitk, hheh, hard to tell on the zoom :)
<ogra> (without graphics driver)
<amitk> right
<amitk> i meant on beagle C4
<ogra> but i usually leave spalsh in place on the cmdline
<ogra> c$ will have plymouth, yes
<ogra> buut the graphics have some issues
<ogra> *c$
<ogra> grr
<ogra> *C4
<ogra> ther wallpaper has stripes and once X comesu up (before the desktop is drawn) i can wipe the wallpaper with my cursor
<amitk> its a _feature_, a paint program at bootup
<ogra> yeah, i thought the same :)
<amitk> if you managed to wipe the entire screen, you get a prize
<ogra> oh, i'll try that
<ogra> what is the prize ? a surprise ?
<amitk> ofcourse, what would be the fun otherwise
<ogra> lool, "I would also prefer if we'd simply change the compcache check from 512 MiB to 256 MiB" can you elaborate what you meant with that ? you would prefer to make compcache to not be used at all ?
<ogra> (thats how i read it)
<ndec> ogra: with serialtty I also have the console... this is really slow, though
<ogra> currently compcache is only used on systems > 256MiB (by definition we dont support anything less) < 512MiB (which the current check code achieves)
<ogra> ndec, its a live image on a 256M board ... dont expect miracles
<amitk> ndec: live images are usually slow
<ogra> half of your FS lives in RAM
<ogra> and on 256M half of that RAM is even compressed
<ndec> ogra, amitk: ok. the problem with display is that the DSS2 panel driver is missing for the Zoom2 (it's a NEC display). we currently have panel driver for .32, which was before some important DSS2 rework. so i cannot easily merge the panel code.
<lool> ogra: I thought you cared to have it work with 256 MB as well?
<ogra> lool, it will automatically work with 256M
<ndec> amitk: for the record, the zoom2 panel driver is here https://patchwork.kernel.org/patch/83907/, but it needs rework
<lool> Ah well, the test is for > 512 M
<ogra> lool, as long as RAM is less than 512M compcache kicks in, determines the actual RAM sice and takes $COMPCACHE_SIZE and compressed swap
<ogra> with 256MB you end up with 384MB of actual usable RAM space
<lool> ogra: Anyway, what I meant is that I find it easier to change the defaults, but that has a much higher impact obviously
<ogra> lool, as i said, we need to rework the world here anyway for maverick
<ogra> the implementation changed completely
<lool> ?
<ogra> so we can find something saner than the current implementation
<ogra> lool, compcache went into mainline with .345
<ogra> *.34
<ogra> its in staging in .33
<ogra> and needs userspace tools that do all the setup now ... instead of module options
<ogra> from hardy to today compcache lives in the ubuntu modules dir
<ogra> with the older implementation
<ogra> the userspace tools require us to reqork the initramfs hooks from scratch
<ogra> *rework
<amitk> ndec: is anybody working to upstream the panel driver?
<lool> ogra: BTWhow was the value <= 512 M chosen?
<ndec> amitk: i guess so, i am checking.
<lool> ogra: I'm a bit surprized that we include 512 MB machine with compcache
<ogra> lool, after discussion with cjwatson ...
<hrw> if ram is issue and you provide SD card image then why not use dual partitions like beagleboard people usually do and have rootfs on mmcblk0p2?
<ogra> the 25% value was chosen in hardy when we could boot with 256M + compcache and that gave us ~300M which prevented OOM
<ogra> with lucid the requirements raised
<lool> What I find odd is that pretty much all discussions revolve arund 256 MB systems
<lool> Yet the check is against 512 MB
<ogra> the check just means "if you are having 512M or more we dont want to use compcache at all since your ram suffices"
<ogra> compccache is *just for preventing OOM on systems with less than 512M*
<lool> ogra: Note that it's turned on for 512 MiB
<ogra> in 512M you can run desktop + ubiquity without hittig issues
<ogra> its not :)
<ogra> read the code you pasted in the bug :)
<lool>     if [ "\${TOTAL_RAM}" -gt 524288 ]; then
<lool>         exit 0
<ogra> right
<lool> Which means that if the RAM is strictly more than 512 MiB, the script is disabled
<ogra> if you have more than 512M the code exits
<amitk> <=
<lool> But if it's exactly 512 MiB it's not
<ogra> ah, that you mean
<ogra> well, feel free to make it  524287
<amitk> < vs. <=
<lool> Geez
<lool> We have -ge thankfully
<ogra> if you find it that important
<lool> ogra: What I don't understand is that even with 524287 you can run the desktop
<ogra> you can ...
<ogra> why shouldnt you
<lool> What I would find logical, is that we turn it on only for x where x+50% = 512M
<ogra> its just to prevent OOM
<ogra> you can run the desktop in 384M
<ogra> so your formula should be  x+50% = 384
<ogra> thats the bare minimum
<ogra> cjwatson simply wanted compcache up to 512 to have a savety net
<ogra> *safety
<lool> ogra: there's a difference between x > 512 and x + 50% > 512
<ogra> yes, the latter raises the minimal reqs.
<lool> Err no, it's the other way around!  we turn compcache on earlier
<ogra> we used to have a minimal req of 256M ... short before hardy that raised to 384
<ogra> so the decision was to use compcache on all systems between 256 and 512M
<ogra> and use 25% of the ram for compressed swap
<ogra> that minimal req doesnt suffice anymore
<hrw> guys...
<ogra> so to run on 256M without hitting OOM you need 50%
<hrw> which arm platform today has video which does not take part of system ram?
<hrw> on omap3 you have 4-12MB for vram so 512MB system has <512MB ram
<ogra> lool, so do you want the -ge change ? i'm fine doing that
<ogra> (since i have the branch open anyway)
<lool> ogra: No, I think the math is wrong; the -ge versus -gt happens to include a larger number of systems to the compcache thing, but I would rather fix the math
<ogra> hrw, that amount doesnt really matter much we use 12M on beagle C4 and it works fine with the 50%
<lool> hrw: Note that while the changes which triggered the discussion are needed for OMAP, the code is used on all platform including x86 systems
<ogra> lool, well, then go ahead as long as you dont break it ... i dont have the time to work much more on that (there are still flash-kernel changes and partman i have to do before thu. and i need a working image from teh archive today)
<lool> Bah I don't want to bother cjwatson if you agreed to the current approach
<ogra> lool, just take into account that there are tools in universe and debian that make use of compcache
<lool> ogra: I'm not sure what you mwan
<ogra> lool, in case you remove variables or change their meaning these tools need transition
<ogra> iirc there is at least one debconf frontend tool in debian to manually set compcache
<ogra> which relies on the values
<ogra> and variable naming
<hrw> ok
<ogra> lool, really, i wouldnt bother in the light that we have to redo it anyway next release
<ogra> and in the light that the current approach works since hardy
<lool> The only thing which worries me is that compcache is turned on for all flavours
<ogra> lool, thats wanted
<lool> Pretty much all vms will have it enabled
<lool> Even if they don't run the desktop
<ogra> why would that be a bad thing
<ogra> thats not true
<ogra> compcache is in casper ...
<lool> and I can imagine that will mess up with things like kvm page sharing algorithms
<ogra> do we use casper in vm images ?
<lool> Well that's the thing, it's an assumption of live image image => desktop
<ogra> if so and if server people dont want compcache that should probably be adressed
<ogra> it surely comes from a time where we definately only used casper in desktop live images
<lool> I guess it's unlikely that someone fiddles with the COMPCACHE settings on server images
<ogra> if that changed someone should indeed change behavior
<lool> Anyway, I guess that if there was a class of affected users, we'd hear about it
<ogra> when i implemented it i did that for calssmates with 256M only ... and cjwatson insisted back then (pre hardy) to have it on all arches/images
<ogra> *classmates
<ogra> its a cheap way to get more ram without much penalty
<ogra> so even VMs might benefit
<ogra> sigh, all builders are busy with big packages ...
<ogra> i want my casper build ... damned ...
 * ogra wonders if we have any example code for the 120min buildd timeout stuff ... libgphoto2 needs such a fix
<ogra> err, 150min
 * ogra goes to test a netinst image while waiting for casper
<hrw> omap3 usb is now working?
<ogra> yes
<ogra> since last kernel upload
<hrw> cool
<ogra> [   25.152954] Trying to unpack rootfs image as initramfs...
<ogra> [   25.154846] rootfs image is not initramfs (no cpio magic); looks like an initrd
<ogra> GRRR !
<ogra> netinst still doesnt work
 * ogra wonders why
<jussi01> persia persia!! seen this yet? http://www.wirefresh.com/sharp-introduces-the-is01-android-powered-smartbook/comment-page-1/
<lool> ogra: On which platform is this?
<ogra> lool, omap netinst
<ogra> [   26.649200] RAMDISK: gzip image found at block 0
<ogra> [   26.762176] RAMDISK: incomplete write (4546 != 32768)
<hrw> jussi01: sharp... argh
<ogra> the same load values that work on all other setups dont seem to work for netinst
<jussi01> hrw: they are the only ones really doing anything near this at the moment though.
<ogra> lool, and i really use very conservative values that should leave enough space
<hrw> jussi01: I have only bad experience when it comes to sharp and linux
<lool> ogra: I'd check ramdisk size (you can override it on the cmdline) or it might be again our kernels being too big
<ogra> lool, well, its only 3M and i leave about 10 with my load address
<ogra> that shold suffice even with the unpacked kernel
<lool> ogra: I'm pretty sure it's the ramdisk size
<lool> It's at 4096
<lool> ogra: Try passing ramdisk_size=16384 on the kernel cmdline
<ogra> yeah, it fixes the corruption but i still cant get it to boot
<lool> ogra: Does it unpack the ramdisk correctly now?
<lool> amitk: Could you bump CONFIG_BLK_DEV_RAM_SIZE to 65536 as on the other kernels?
<lool> It's a lot for OMAP, but the memory is claimed back anyway
<ogra> [   26.690032] /build/buildd/linux-ti-omap-2.6.33/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
<ogra> [   26.699645] RAMDISK: gzip image found at block 0
<ogra> [   26.844573] hub 1-2:1.0: USB hub found
<ogra> so 16384 fixes the corruption
<amitk> lool: ack
<ogra> but it still panics
<lool> amitk: thanks
<lool> ogra: what's the panic?
<ogra> [   27.108520] VFS: Mounted root (ext2 filesystem) on device 1:0.
<ogra> [   27.136840] VFS: Cannot open root device "(null)" or unknown-block(0,0)
<ogra> [   27.143493] Please append a correct "root=" boot option; here are the available partitions:
<lool> ogra: What format is your initrd?  ext2?
<ogra> lool, no idea, what does d-i use for the netinst ones ?
<lool> ogra: depends of the image, usually ext2
<ogra> right, thats what i would expect
<ogra> the cdrom initrd works flawless
<lool> INITRD_FS = ext2 in build/config/armel.cfg
<ogra> its really only the netinst one
<ogra> they should be identical format i think
<lool> cdrom uses INITRD_FS = initramfs
<ogra> really ?
<lool> check build/config/armel/omap/cdrom.cfg
<ogra> i thought d-i uses the same format all over the place to roll them
<lool> ogra: So did you pass root=/dev/ram0?
<ogra> ok, but our kernel surely has ext2 builtin
<ogra> no
<lool> I think you need that
<ogra> i dont need to pass that on other arches
<ogra> neither dove nor imx51 need it
 * ogra tries
<lool> build/config/armel/imx51/netboot.cfg has INITRD_FS = initramfs, but not dove; I don't think we tested dove netboot images for a while though
<ogra> lool, geez !
<ogra> works
<ogra> thanks a lot !
<lool> ogra: So it might make sense to move to initramfs instead
<ogra> yeah
<ogra> will do that
<lool> ogra: You might want to test the dove netboot initrd too; I'm pretty sure you need to pass root=/dev/ram0 there too
<ogra> hrm, and it looks like d-i needs the ethernet modules
<ogra> lool, i have no HW to test dove
<ogra> only NCommander does
<ogra> and GrueMaster
 * ogra wonders which udeb has all the usb ETH modules and firmware
<lool> initramfs is the absolute default and probably we should switch armel to it
<lool> ogra: nic-modules
<ogra> that also has the usb ones ?
<lool> firmwares are likely a separate one
<lool> I'm not sure about usb, but you might need another udeb for usb by itself
<ogra> i thought usb nics are separate too
<ogra> usb support is builtin
<ogra> i need HID though
<lool> You want nic-usb and usb for USB ethernet adapters
<lool> plus the firmware udebs
<lool> ogra: just copy the list from some d-i build file
<ogra> nic-usb-modules and usb-modules are there, but i dont see anything wrt firmware at https://edge.launchpad.net/ubuntu/+source/linux-ti-omap/2.6.33-500.5/+build/1684225
<lool> I dont think it's built from linux-ti-omap
<ogra> its also not in linux-fsl-imx51 :&
<ogra> :/
<lool> it's the nic-firmware udeb
<lool> built from linux-firmware
<ogra> hmm, nor on dove
<ogra> oh, then i'm looking at the worng packages ...
<ogra> aha ... its arch all
<ogra> hrm, where is build/pkg-lists/netboot/arm/omap.cfg gone in the d-i tree
 * ogra thought he added that 
<lool> I don't see it
<lool> I'd copy imx51.cfg
<ogra> just did :)
<ogra> and fixed up the comment
 * ogra also drops gzip compression form the initrd for netinst ... we dotn use it anywhere else in omap
<ogra> (from mkimage)
<lool> ogra: You didn't copy it for netboot though?
<ogra> lool, i just did in my tree
<ogra> there we go
<ogra> and uploaded :)
<ogra> next d-i build should get us working netinst images !
<ogra> so only flash-kernel and partman are left on my list
<ogra> \o/
<ogra> we're getting there :)
<dmart> Hi all, does anyone know a way to inhibit the building of debug packages when building debs?
<dmart> ...or to force the use of a compressor other than lzma
<dmart> I'm having real problems building qt4-x11--- my board has been building debs for about 3-4 days and is swapping so much I can't log into it any more
<ndec> ogra: on the BB, my mouse (USB) is not detected. where do you plug it?
<amitk> ndec: are you using the OTG port?
<ndec> no. host. but it does seem that proper drivers are there, right?
<amitk> EHCI works for me, I'm working on OTG atm.
<amitk> ndec: It doesn't work though powered hub?
<lool> dmart: It's a real -dbg?
<lool> dmart: or -dbgsym?
<suihkulokki> dmart: comment out the -Zlzma from debian/rules
<dmart> suihkulokki: OK, great, thanks
<dmart> lool: -dbg in this case
<dmart> I've a nasty feeling /tmp is a tmpfs
<dmart> which may be causing problems here
<ndec> amitk: i don't have a powered USB hub with me, ATM
<amitk> ndec: AFAIK, BB doesn't support Full speed devices on the EHCI port w/o a powered hub. (http://elinux.org/BeagleBoard#USB)
<hrw> yes
<amitk> ndec: since the port only supports high speed
<hrw> ehci is 2.0 only
<amitk> hrw: ogra: have anything to test the OTG port on the BB?
<hrw> you mean usb-host cable
<hrw> ?
<amitk> hrw: right
<hrw> I would have to dig for it as I do not remember when last time used
<hrw> and definitelly not today
<amitk> ok
<hrw> amitk: will be easier to check in two weeks from now
<ndec> amitk: thx. I need to find the adaptors/HUB
<hrw> and today is not my day for work ;(
<amitk> ndec: I've uploaded another kernel at http://people.canonical.com/~amitk/ti/ to test OTG configuration. Unfortunately, I don't have the usb-host cable to test (Need to go out and buy)
<ndec> amitk: don't have it neither...
<hrw> solder one - easier then buying new one usually
<amitk> hrw: any ready pointers to convert an existing cable?
<hrw> take miniusb->usb cable, unbreak miniusb one, solder two pins, add usba->usba gender changer
 * amitk probably has enough mini->normal usb cables and gender changers. No time, though. :-/
<hrw> I have more then enough usb connectors
<ogra> amitk, i only have a std adapter (several of them) but nothing with the shortened pins (as i told you on friday)
<ogra> NCommander, can you bump the casper build a bit higher so it gets attempted at some point today ? https://launchpad.net/ubuntu/lucid/+source/casper/1.232
 * ogra doesnt understand why d-i just passed it even though it was uploaded hours later
<ogra> they had the same score
<wao> any new arm notebooks?
<zumbi> a rival for ipad? when?
<hrw> ipad? I would rather prefer rival for my dell d400 ;D
<ogra> grmbl
<ogra> so my NIC is seen by the netinst image but no firmware is loaded
<ogra> aha, asix works
 * ogra wonders why the other one doesnt
<zumbi> hrw: ipad is the more successfull arm device in the market (according to news)
<zumbi> hrw: in netbook context
<hrw> zumbi: show me arm netbooks on market (other then touchbook)
<ogra> amitk, hmm, it seems my installation attempts all break on usb-storage atm ...
<zumbi> hrw: sharp netwalker, alwaysinnovating, efikamx, ipad, not sure if amazon wikireader counts as arm netbook
<hrw> so netwalker and efikamx only...
<zumbi> alwaysinnovating is a beagleboard
<hrw> zumbi: I know what AI touchbook is
<hrw> beagleboard + usb hub + display + usb keyboard
<zumbi> is it homemade?
<hrw> netwalker pc-z1 reminds me nightmares
<ogra> amitk, [  212.130981] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40200000 shows up reliably when d-i is trying to detect disks
<hrw> zumbi: touchbook design is based on beagleboard design/schematics but it is whole new device not BB+cables
<hrw> zumbi: efikamx smartbook looks quite good but it is freescale...
<hrw> I have bad experience with both sharp (from zaurus times and 8MB kernel diffs) and with freescale (again 8MB kernel diffs)
<zumbi> yes, i'd like to see imx51 in mainline with efikamx support
<hrw> zumbi: 2.6.50 probably
<zumbi> is .50 guessed by a random function :)
<hrw> so far i.mx support looks like in-kernel maintainer has own version based on code drops from freescale
<zumbi> yes, efika uses freescale SDK... :-/
<hrw> zumbi: 2.6.50 ~= never (or 'when people forgot that such thing existed)
<ogra> Apr 12 11:18:47 main-menu[208]: INFO: Menu item 'partman-base' selected
<ogra> Apr 12 11:18:48 kernel: [  556.388214] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40200000
<ogra> Apr 12 11:18:48 main-menu[208]: (process:7234): Bus error
<ogra> amitk, ^^^^
<amitk> hrw: /me is the maintainer of i.MX51 in mainline
<hrw> phone...
<amitk> ogra: ok, looking at it
<ogra> amitk, cjwatson suggests its misaligned memory access
<amitk> ogra: I am almost sure it has to do with clocks being turned off during module access
<lool> amitk: Oh you are
<amitk> lool: huh?
<lool> amitk: Re: /me is the maintainer of i.MX51 in mainline; I didn't know that
<lool> amitk: congrats!
<ogra> lool, since ages :)
<lool> I hadn't followed that change
<lool> It's not in our lucid kernel tree at least, so can't be that old!
<lool> 4th February
<ogra> iirc it happened early lucid ... so .33 mainline
<ogra> or beginning of .34
<amitk> .34
<ogra> amitk, how fast can we get a fix for the issue above ? since it blocks partman from starting i cant do any of the other image changes (which all happen after partman)
<ogra> amitk, a test kernel for live would suffice
<lool> ogra: Do you have any serial console enabled?
<ogra> lool, not by default
<ogra> you need to change boot.scr
<lool> ogra: But did you turn them on?
<lool> Sometimes it triggers this issue
<amitk> ogra: I'm looking.... can't tell you before I understand the problem
<ogra> lool, it also happens on the live image without serial turned on
<ogra> but i can try a d-i netinst one without right now
 * ogra fiddles with boot.scr
<lool> I wonder whether partman would be attempting to touch the 3/4 possible SD cards which might not all be present on your card
<zumbi> amitk: great! :)
<lool> ogra: Would be interesting if you could identify which device access causes this problem; perhaps with ls-partitions or some other d-i command, or stracing partman
<ogra> lool, already tried its /lib/partman/init.d/30parted but i cant get anything out of it with set -x
<lool> Hmm who's working on the qcm kernel?
<ogra> lool, rtg afaik
<lool> Is any image expected for it?!
<ogra> i dont think so
<lool> I wonder how tested that kernel is
<siji> Hi All
<siji> GoodEvening
<amitk> lool: no image, minimal testing for qcm
<siji> Anybody can Suggest me some nice Window manager for ubuntu ARM
<lool> amitk: k thanks
<ogra> GRRR
<ogra> oh how i hate that you have to define omapfb crap on the console to get any video output *at all*
<lool> siji: This is not really specific to ARM; depends of your use case
<siji> lool, am looking for a handheld device
<lool> ogra: Speaking of which, did we sync both omap xorg drivers from Debian recently?
<ogra> lool, a while ago
<lool> siji: You could checkout matchbox
<siji> I need some fancy Desktop
<lool> ogra: The two of them?
<siji> with smooth animations etc..
<ogra> lool, NEON and non NEON version, yep
<siji> sort of ubuntu-netbook launcher
<ogra> siji, use ubuntu-netbook then
<hrw> amitk: I did not knew
<ogra> and possibly replace the panel with something lighter
<ogra> siji, on armel it will default to use the efl version of the netbook launcher
<siji> ogra, ok
<hrw> ogra: you can also ignore boot.scr, boot device to uboot and enter commands by hand/copypaste
<lool> I could only find the xf86-video-omapfb source, what's the other one??
<hrw> siji: how bug screen?
<hrw> siji: and how big resolution
<siji> 7''
<siji> LCD with touch screen
<hrw> 800x480?
<siji> yes
<hrw> I would use matchbox or something small/light
<ogra> hrw, i'm way to lazy for that :P
 * ogra <3 boot.scr
<hrw> fluxbox, icewm, xfwm4 maybe
<siji> ok
<ogra> lool, its the same source, two binaries
<ogra> lool, one with and the other built without NEON
<lool> Ok just making sure
<ogra> sigh
 * ogra tries since 10min to get some video output from the beagel .... just to find i used the wrong HDMI cable
 * hrw -> phone again
<ogra> hrm, my kbd doesnt work
<ogra> amitk, urgh ...
<ogra> amitk, seems DSS2 doesnt properly work yet
<ogra> i can switch consoles but the screen always shows tty1
<asac> dmart: hi
<dmart> hi there
<asac> dmart: i think i need your input on xine-lib
<dmart> what's up?
<asac> it uses jit like thing for mov pc, lr
<asac> one second
<asac> oh sorry
<asac> its upx... something
<asac> let me find it
<asac> dmart: src/stub/src/i386-linux.elf-main.c:            hatch[1]= 0xe1a0f00e;  // mov pc,lr
<asac> whats the hexcode for bx lr ;)
<asac> hehe
<asac> err
<asac> you know what i mean
<asac> i guess you should check that file
<dmart> hold on, I'll take a look
<asac> dmart: thats apt-get source upx-ucl
<asac> dmart: where can i find a hexcode reference? ;)
<asac> i looked at some disassemblers. but not sure where they got that info from
<dmart> You can look at the ARM ARM, or write a tiny .s file, assemble and disassemble it
<asac> ARM ARM?
<dmart> But if the instruction in question might run as Thumb, it's broken anyway so we should take a closer look
<asac> yes. thats what i figured
<dmart> ARM Architecture Reference Manual
<asac> but thought there must be a documentation that has that info ;)
<asac> ah ;)
<dmart> http://infocenter.arm.com/ -> ARM Architecture (if you don't have it already)
<asac> yeah
<asac> ok needs password it seems. anyway
<dmart> oh yuck
<asac> hmm.
<dmart> that code is making a hand-codedXXX hand-assembled syscall
<dmart> it assumes the legacy syscall ABI which won't work on new kernels
<hrw> ~armarm
<asac> yeah
<asac> dmart: i am not so sure that is actually used
<asac> at least the buildlog doesnt show it being touched
<asac> so i guess we might need to do nothing, or fix the .S .h files
<lool> asac: You just need to register/login and then you can download it
<asac> but those i already tried to kill
<dmart> argh, it also pokes the instructions into some "handy" space in the ELF header e_ident field
<hrw> lool: they do not send CDs anymore?
<asac> yeah. upx-ucl seems to do crazy stuff
<asac> let me spin it ... lets see if the stub things are shipped in some package
<asac> UPX will typically reduce the file size of programs and DLLs by around 50%-70%, thus
<dmart> Probably safest to build this package in ARM for now
<dmart> ...it's a plie of low-level hacks
<lool> hrw: Never heard of that, did they?
<hrw> I have cd with arm documentation somewhere
<hrw> and got it from arm ltd
<asac> dmart: ok will go for -marm then
<dmart> asac: I've got three concerns with upx-ucl: 1) I can't see where the decompressed program is entered.  Can it handle an entry point in thumb? 2) Are caches flushed properly when entering the decompressed executable? 3) The hand-assembled code in i386 appears wrong in 3 ways - no cache flush, not thumb-aware and not compatible with EABI.  Unfortunately, -marm will fix none of these
<dmart> ARM code in i386-* really confuses me too :P
<dmart> Do you know the maintainers for this?  Maybe they could help us to understand how it works.
<asac> dmart: yes.
<asac>  Robert Luberda <robert@debian.org>
<asac>  ;)
<dmart> Would he be on IRC somewhere?
<asac> dmart: sent a mail with you CCed
<asac> let me see if i can find his nick
<ogra> lool, the CD shipped with the EVM did have all ARM docs iirc
<asac> dmart: unfortunately he doesnt have his nick in db.debian.org ... one sec
<asac> ok seems in debian-devel they dont know his nick either
<asac> so lets wait for him to appear or answer the mail
<dmart> OK... I think the conclusion for now is that there's lots of assembler which was written for pre-Thumb days -> many assumptions, so we must build with -marm.
<nosse1> Hi guys. Is there any reason that NFS works poorly?
<asac> dmart: i can upload that for now
<dmart> But there may still be issues with the syscall ABI, cache flushing and compressing executables with a Thumb entry point (which would be the common case in lucid_
<asac> dmart: but as you said. we dont really think this will fix all
<nosse1> I was told that you considered NFS in the build farm, but ditched it. I curious to why
<asac> dmart: right. but this cache flushing etc. is not a regression, right?
<dmart> We need -marm anyway, so may as well do that and try it out.
<asac> e.g. its aproblem across the board?
<asac> dmart: ok uploading that for now
<asac> hmm i get
<asac> dpkg-shlibdeps: warning: debian/upx-ucl/usr/bin/upx-ucl contains an unresolvable reference to symbol __aeabi_unwind_cpp_pr1@GCC_3.5: it's probably a plugin.
<dmart> The cache flushing might be there, but I don't understand all the code yet.  You often get away without the cache flushing when the caches are small, but you may hit problems on newer platforms.  For ages, the linux kernel didn't invalidate the I-cache when loading executable pages...
<asac> ok uploaded with -marm now
<dmart> ok
<nosse1> ubuntu-netbook dependencies are broken again, right?
<GrueMaster> ogra:  Something you needed me to test?
<ogra> GrueMaster, i'm only doing beagle stuff atm
<ogra> do you have a beagle now ?
<GrueMaster> You said something about dove earlier.
<ogra> oh, someone asked about dove ...
<GrueMaster> (01:29:44 AM) lool: ogra: You might want to test the dove netboot initrd too; I'm pretty sure you need to pass root=/dev/ram0 there too
<GrueMaster> (01:30:07 AM) ogra: lool, i have no HW to test dove
<GrueMaster> (01:30:12 AM) ogra: only NCommander does
<GrueMaster> (01:30:16 AM) ogra: and GrueMaster
<ogra> GrueMaster, right, there you have the issue
<GrueMaster> If this is referring to dove netboot images not booting, this is not the fix.  Whatever creates the netboot image for dove needs to change the entry point and address for the kernel wrapper.
<GrueMaster> for uboot.
<ogra> GrueMaster, its referring to the way the dove images are built (not using initramfs but ext2 initrd)
<nosse1> What is a decent seed for something like ubuntu-netbook? I want to test X and desktop and such.
<ogra> well, ubuntu-netbook :)
<nosse1> ogra, but I get unmet dependencies unfortunately
<ogra> it worked tonight when i built images
<ogra> should only be tempoarary
<GrueMaster> nosse1: gtk is going through a respin.  It may be a few days for the churn to settle.
<ogra> GrueMaster, again ?
<ogra> it was done on saturday
<ogra> nah, it should all be fine
<GrueMaster> Yea, someone checked in a bug fix on 4/8, which had a cascade effect.  x86 is done rebuilding everything, but it took us 10 days to get through it last time.
<ogra> nosse1, wha are the actual probs you see (error message)
<nosse1> In the danger of flood filling:
<nosse1>   ubuntu-netbook: Depends: gnome-applets but it is not going to be installed
<nosse1>                   Depends: gnome-control-center but it is not going to be installed
<nosse1>                   Depends: gnome-panel but it is not going to be installed
<nosse1>                   Depends: gnome-session but it is not going to be installed
<nosse1>                   Depends: indicator-applet-session but it is not going to be installed
<ogra> ah
<nosse1>                   Depends: update-notifier but it is not going to be installed
<nosse1>                   Recommends: hplip but it is not going to be installed
<nosse1> So yeah, gtk it is
<ogra> g-c-c was uploaded today
<ogra> no, gtk is fine
<nosse1> hmm. I'll try an update
<ogra> its gnome-control-center ... the others mostly depend on it directly or indirectly
<ogra> https://edge.launchpad.net/builders
<ogra> the builders are nearly all busy with multi day packages
<nosse1> Havent been deployed yet it seems
<ogra> g-c-c likely still sits in the queue
<GrueMaster> ogra: when gtk gets rebuilt, everything that depends on it gets rebuilt.  That's where the cascade effect comes in.
<ogra> GrueMaster, yes, i know
<ogra> https://edge.launchpad.net/ubuntu/+source/gnome-control-center/1:2.30.0-0ubuntu4/+build/1687347
<ogra> nosse1, thats your issue ^^^
<ogra> GrueMaster, but that was done on saturday
<nosse1> 6 minutes ago. heh.
<ogra> GrueMaster, if someone takes actively care for gtk its less than a day to get it sorted ... i only got around to look at it on friday
<GrueMaster> I was just referring to the last time this happened (3/23).
<ogra> nosse1, yeah, that will build for a while and then take 1-1.5h to be published ... if something of the other packages has a versioned dependency that needs to rebuild as well
<GrueMaster> Of course, I'm not following all the change logs.
<ogra> GrueMaster, i usually do :)
<ogra> if i'm not in Nice :)
<nosse1> On a more general note: Is there any reason for NFS misbehaving on the omap?
<ogra> misbehaving ?
<ogra> in what way ?
 * ogra didnt try NFS on omap at all yet
<nosse1> Kernel oops all the time (when doing heavy fs activity)
<ogra> nosse1, file a bug
<ogra> nosse1, which kernel build is that? the latest one ?
<nosse1> Someone told be that you considered using NFS for the buildfarm, but rejected it
<ogra> yes, its way slower than USB or SATA
<ogra> but has nothing to do with OMAP
<ogra> we dont have any omap buildds yet
<nosse1> No I'm on a custom kernel, so I'm not trying to request support for it
<ogra> oh, ok
<ogra> i tought you used the ubuntu kernel
<nosse1> The ti-omap does not work for the AM3517 as I've mentioned before
<ogra> ah, right, i remember
<nosse1> ogra, so you are not building armel on any beagleboards then?
<ogra> not yet, our buildds require a lot of RAM ...
<ogra> 256M simply doesnt cut it 512 is a minimal req.
<ogra> also our IS team wants to use supported ubuntu setups
<ogra> we didnt have omap support in ubuntu until shortly ago
<ogra> for maverick and with bigger beagles you will likely see some beagle based buildds appear
<ogra> or s/beagle/omap/
<nosse1> BTW: Can I force aptitude or apt-get to start pulling down the packages for ubuntu-netbook even with the broken dependecies. I.e. "downl. and install what you've can get"
<ogra> not easily ... just wait
<nosse1> :D
<ogra> how much ram does your board have though
<ogra> below 512M ubuntu-netbook will definately be a pain
<nosse1> the evm has 256M, but the final HW will have 512
<ogra> well, add a lot of swap until you get more ram then ;)
<ogra> and dont expect speed
<nosse1> we won't be running ubuntu-netbook anyway. It was just for playing around more than anything else.
<ogra> well, with 512M the efl version will run quite smooth
<asac> ogra: did you check with lamont
<asac> on builders?
<ogra> on what exactly ?
<asac> ogra: that builders are lagging
<ogra> they are not lagging ... they are busy with huge packages
<cwillu_at_work> ramzswap might be useful
<ogra> buttercup is done with kdeedu now so we have one back that builds "normal" packages
<ogra> cwillu_at_work, thats why we use it on live images since hardy :)
<cwillu_at_work> oh really?
<cwillu_at_work> didn't know that
<ogra> yep
<ogra> to make them work on 256M systems
<ogra> its a good way to prevent OOM
<ogra> i'm not sure it would trust it enough to use it on a constantly heavily loaded buildd though ...
<ogra> but we have 512M buildds so thats no issue anyway
<cwillu_at_work> my arm builds are on a qemu with a gig of swap that's backed by a ramfs on the host
<cwillu_at_work> helps
<ogra> well, our arm buildds are babbage boards with 800MHz, 512M and two gig of swap on disk
<cwillu_at_work> memory backed swap would be faster :p
<cwillu_at_work> er, nvm
<cwillu_at_work> probably not faster than native
<ogra> yeah, but not sure how stable that stays if you really put heavy load on it
<ogra> like an OO.o build for example
<cwillu_at_work> which, the ramfs swap?
<cwillu_at_work> I just built firefox on it
<ogra> ramzswap (or compcache as its still called in ubuntu) is a slightly hackish way of replaying R/W to a virtual swap file
<ogra> not sure how the speed impact is if you constantly drive it under full system load
<ogra> its great as a safety net to avoid OOM ...
<ogra> but on loaded systems ...
<dmart> Is ramzswap dynamically sized
<dmart> ?
<ogra> nope
<ogra> at least not in the versio we currently have in ubuntu
<ogra> you have to define a value at module load time
<ogra> not sure how much it changed when it went into staging though
<dmart> I was just wondering how much extra space you tend to get, and what the performance impact is
<ogra> i know it is said to have changed a lot
<ogra> the performance penalty on a live image isnt really heavy ...
<ogra> but on live images you dont drive the system unbder full load all the time
<ogra> the compression/decompression will surely do some harm if your CPU is busy anyway
<persia> It tends to roughly double the space allocated: so if one allocates 128M, one ends up with ~256M of swap (of course, this depends on swap contents, etc.)
<cwillu_at_work> well, depends on the working set
<ogra> indeed
<cwillu_at_work> if you're cpu bound, but the working set is small'ish, it could be an easy win
<dmart> Doesn't sounds like enough to avoid OOM on large package builds, but I can see it's useful for things like the live images.
<persia> Can help with some classes of large package builds (for limited values of large).  It's not really enough for e.g. boost.
<ogra> it might be a tad faster than using USB disk based swap though
<ogra> depending on your CPU load indeed
<ogra> cwillu_at_work, our beagle live image will use 128M of compcache on the Cx series beagles btw
<ogra> runs relatively smooth (if you think about the fact that nearly a full gnome desktop runs in the backend on top of an aufs'ed sqashfs image)
<amitk> ogra: does rootstock still get stuck on I: Extracting zlib1g..
<amitk> ?
 * amitk forgets what the issue was..
<persia> amitk: The issue is that when unpacking large numbers of large packages in qemu, the emulated system hangs.
<amitk> persia: do you know if it still exists?
<persia> I don't.  I can start a rootstock run to see if you have issues doing it locally.
<cwillu_at_work> I've tripped over that recently
<nosse1> Why do you need to specify "BOOT=" in /etc/initramfs-tools/initramfs.conf. I'm sitting here swapping boots between NFS and local and would rather like to have it as an boot option...
 * nosse1 remebers that he can make two initrds...
<ogra> amitk, the zlib issue only exists with debian systems afaik, i have a fix i havent merged yet
<ogra> amitk, the issue persia mentioned still exists, install ubuntu-minimal and if you want a desktop system, do the rest on the real HW
<cwillu_at_work> ogra, any idea what the root issue is re: hang on qemu?
<ogra> cwillu_at_work, if i would have any clue i would have fixed it :)
<cwillu_at_work> :p
<ogra> its there since end of last year
<cwillu_at_work> just on lucid though?
<ogra> yes
<ogra> just with a lucid target system actually
<cwillu_at_work> any traces which you would like?
<ogra> doesnt show up if you build karmic or jaunty
<cwillu_at_work> yep
<persia> cwillu_at_work: Whichever one demonstrates the issue :)
<ogra> Bug 532733
<ubot4`> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 1 other project) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 3) (dups: 1) (heat: 26)" [High,Incomplete] https://launchpad.net/bugs/532733
<ogra> cwillu_at_work, ^^^
<persia> strace of qemu may give some pointer, but I suspect that's not sufficient, as I expect it's internal to qemu, rather than being external.
<ogra> yes
<cwillu_at_work> bug won't be in kvm
<ogra> thats just the name of the ubuntu qemu package
<ogra> since we use a different upstream to debian our package is called qemu-kvm
<cwillu_at_work> ah, k
<ogra> i traced it down to apt hanging in a read() call but didnt get any further
<cwillu_at_work> the lucid vm kernel?
<ogra> i assume the read() is a pipe to dpkg here ... but likely its neither apt's nor dpkg's fault but rather qemu or kernel
<ogra> yep
<ogra> its easy to reproduce if you follow the rootfs from scratch wikipage, build a minimal qemu image and then install ubuntu-netbook inside
<cwillu_at_work> I've got a hacked up rootstock that demonstrates it whenever I switch it to lucid mode :p
<ogra> the fun stuff is that the issue goes away if you install the apt and dpkg dbgsym packages
<cwillu_at_work> gonna try running it with karmic's kernel
<ogra> i tried different kernels and qemu binaries
<ogra> i also tried all variations of qemu images, filesystems and ways to connect to the image (even qemu-nbd which is very unstable)
<ogra> the only hint i got was the dbgsym packages that make the issue go away ....
<ogra> which doesnt help with debugging indeed :P
<cwillu_at_work> well, I'm building it with karmic's kernel anyway :p
<ogra> anyway, its my turn with cooking today ... and i cant work on images anyway so i'm off
 * ogra vanishes to the kitchen
<lool> GrueMaster: Just FYI, the load address of netboot images for dove hsa been fixed recently
<lool> with version 20081029ubuntu96 of debian-installer
<lool> From Friday
<GrueMaster> I know.  Have new images been spun with this?
<lool> GrueMaster: they are spun at package build time
<lool> GrueMaster: You can see the version of d-i used to build an image in the archive
<lool> GrueMaster: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/
 * cwillu_at_work fails at using qemu on root images which are concurrently loop-mounted on the host system
<lool> cwillu_at_work: Don't do that
<lool> cwillu_at_work: Can't work well
<cwillu_at_work> lool, you think?
<GrueMaster> I'll download and test them today.  Thanks.
<cwillu_at_work> lool, it's hilarious when the vm tries to fsck it
<lool> Eh with some definition of hilarious "eats all your data"  :)
<cwillu_at_work> only data on it is an unpacked firefox source tree :p
<GrueMaster> lool: What is the proper cmdline for booting the dove netboot image?  I am currently booting with "quiet splash".  Tried adding root=/dev/ram0, but that didn't work either.
<GrueMaster> With imx51, the cmdline is "console=ttymxc0,115200 console=tty0", and it just works.
<lool> GrueMaster: I'm afraid I have no idea; perhaps NCommander can help you
<lool> GrueMaster: I would check the boot.script file from an installed system
<GrueMaster> ok.  The boot script from an installed system doesn't load the installer.  And the live image is different from the netboot image.  Guess I can check an alternate image from days back (we stopped building them).
<lool> GrueMaster: I mean, just copy the arguments from the boot script
<GrueMaster> Finding the right boot script is the key.
<GrueMaster> The boot script from an installed system has root=UUID=<disk-uuid>
<GrueMaster> And this is supposed to be for network booting and installing.
<GrueMaster> The imx51 image of the same flavor (which works btw) only has console redirection on it, and would work without it.
<lool> GrueMaster: So in theory it should be the same for dove
<lool> GrueMaster: i.e. copy over the boot args from an installed system, but without root= or with root=/dev/ram0
<GrueMaster> Theory != reality in this case.
<lool> If it doesn't work it's likely a bug
<lool> GrueMaster: How far do you actually get?
<GrueMaster> I tried that.  That's why I asked if there was something I was missing.
<lool> GrueMaster: Does it load kernel and initrd?
<GrueMaster> kernel panic.  Either no rootfs with "quiet splash" or no init with "quiet splash root=/dev/ram0"
<GrueMaster> Yes, it now loads the kernel.
<GrueMaster> Need to get beyond that.
<lool> GrueMaster: So forget quiet and splash, root=/dev/ram0 says "no init"?
<lool> GrueMaster: try init=/bin/sh
<GrueMaster> And these kernel panic messages are appearing on the monitor, which indicates that the kernel is successfully initializing the system.
<GrueMaster> Ok.
<GrueMaster> fail.  No init found.
<GrueMaster> In theory, the initrd should be nearly identical to imx51.  The only differences should be in modules.
<lool> GrueMaster: ok, I unpacked the initrd and found /bin/sh in it. so it might be a problem with the initrd address or the uInitrd buikd
<lool> GrueMaster: do you have a full dmesg?
<GrueMaster> I have is a console log, if that is what you are referring to.
<GrueMaster> http://pastebin.ubuntu.com/413250/
<GrueMaster> That's the relevant info (before that is device initilization output, and I didn't see any errors there).
<lool> GrueMaster: ah [    3.558370] RAMDISK: incomplete write (13368 != 32768)
<GrueMaster> Yep.  Saw that.
<lool> GrueMaster: Could you try passing ramdisk_size=65536?
<GrueMaster> Ok, one sec.
<lool> odd I thought that was the case for dove hmm
<lool> GrueMaster: so root=/dev/ram0 ramdisk_size=65536, and console= if you like
<GrueMaster> Working on it.
<lool> Bah it's definitely the problem
<lool> CONFIG_BLK_DEV_RAM_SIZE=4096 tss
<GrueMaster> Erm, fail.
<GrueMaster> Bad fail.
<lool> GrueMaster: what's the error?
<GrueMaster> http://pastebin.ubuntu.com/413254/
<lool> GrueMaster: Odd; could you try with 16384 instead?
<GrueMaster> ok
 * lool is off for the day
<lool> GrueMaster: In any case, please file a bug against the kernel with our chat; I'm pretty sure the current value of 4096 can't work, but we need to find a good value and/or see which places need an update
<GrueMaster> Same error with 16384
<GrueMaster> Is this a kernel bug or is it a corrupt initrd?  The kernel "should" be the same as the live/installed kernel.
<GrueMaster> I tried loop mounting the initrd from http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/20081029ubuntu97/images/dove/cdrom/ and it fails to mount on my desktop.
<videorechner> does someone know available arm cortex a9 boards? Or when they will be available?
<prpplague> videorechner: the tegra is available now but you have to register and be approved for your specific project, which they keep pretty tight
<prpplague> videorechner: there are other platforms like the blaze from TI as well
<prpplague> videorechner: but that too is somewhat restricted at this stage due to supply and demand
<videorechner> mhm, any guesses, when it will be available for end users?
<prpplague> videorechner: all the market hyped seems to indicate that there will be more available in the first quarter of next year
<videorechner> the blaze or cortex a9 motherboards?
<prpplague> videorechner: correct
<videorechner> ??
#ubuntu-arm 2010-04-13
<lool> GrueMaster: You can't loop mount cramfs; you have to gunzip + cpio -i it
<zumbi> hrw|gone: yet another ARM netbook, http://www.linuxfordevices.com/c/a/News/Science-and-Technology-Co-Ltd-Wabook/
<suihkulokki> VIA arm, wtf.
<persia> They build any sort of processor :)
<ogra> ndec, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ has a live image for the C4 beagle that should boot and run without hitting OOM (still not installable and indeed very slow on that HW, but workable and our future base for later releases)
<ogra> ndec, from now on we should have "usable" dailies
<ndec> ogra: thx.
<ndec> ogra: does the installer support installation on the SD card, or does it require USB drive?
<ndec> ogra: btw, I will be in vacation next 3 days... ;-)
<ogra> ndec, for lucid it requires a USB drive
<ogra> ndec, for later we'll do with other setups, given that thu. is the last day to upload anything to lucid i had to make many compromises ...
<ogra> ndec, the lucid image will also re-use the SD as /boot
<ndec> ogra: ok. but if there is a workaround I can do on the image, please let me know.
<hrw|gone> zumbi: this netbook is parody of all netbooks...
<ogra> ndec, but we're not there yet, the partitioner seems to hit a kernel bug atm
<lool> suihkulokki: Hey, I couldn't get qemu-maemo/-meego to work with SD card images; it hangs agter Uncompressing linux... done., can't get any kernel output; does it work for you with some combination of SD image + qemu-system-arm invocation?  NB: I'm building without the gles forward libs
<lool> (This is with -M beagle)
<ogra> ndec, Bug 561426 ... probably your kernel folks have an idea and could help amitk
<ubot4`> Launchpad bug 561426 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "partman dies when trying to detect disks due to kernel error (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/561426
<hrw|gone> 10" 1024x600 are fine. but 300MHz arm926 cpu and 2h battery life??? my 8 years zaurus is faster and have better battery life
<suihkulokki> lool: http://wiki.meego.com/ARM/Meego_on_Qemu
<ogra> ndec, oh, and i forgot, http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/omap/netboot/omap/ has a working netinstall image too now (as well as http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/) ... they all suffer the same partitioner issue though, but these two are more lightweight
<amitk> ogra: its interesting though that I cannot trigger this on a USB stick (running fdisk/formatting, etc.) from rootfs
<ogra> amitk, well, i would happily give more debug info if i could switch consoles in d-i
<amitk> ogra: serial console?
<ogra> doesnt give me tty4 :)
<amitk> ogra: the exact set of commands that trigger this would be useful
<ogra> i tried already, i cant get any output from the partman script at all
<amitk> live images are not very useful for development, I want to recreate this on an 'installed' system
<ogra> i'll try to attach the script that runs last to the bug ... but i cant identify which command causes the actual failure
<amitk> ogra: tty4?
<ogra> amitk, thats where d-i runs and shows output ...
<ogra> amitk, its not that important ... i tried to redirect script output to a file but didnt get any info from that either, it dies very early
<lool> suihkulokki: thanks
<ogra> like ... before it execs commands it seems
<lool> suihkulokki: Do you run your tree with beagle images from time to time?
<suihkulokki> randomly
<neure> hello
<neure> what is the current status?
<amitk> great!
<neure> where can i get image i can try?
<amitk> you haven't specified what status you're inquiring about nor which image you're interested in :)
<neure> i want to try ubuntu on my beagleboard
<neure> does keyboard, mouse, network work?
<amitk> neure: yes, on the live image.
<neure> where do i get one?
<ogra> neure, what beagle (revision)
<neure> rev c i think
<neure> this is 256MB
<ogra> revC should work (but very slow) with the live image
<neure> very slow?
<neure> why?
<amitk> http://cdimage.ubuntu.com/cdimage/ubuntu-netbook/ports/daily-live/
<ogra> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/
<neure> whicih one?
<neure> i mean which image
<neure> omap?
<amitk> yes
<ogra> neure, because our live images are rather built for 512M ... the 256M HW makes everything slow and the image has to use several hacks to even make it work at all
<neure> can i tell it not to boot to X?
<neure> something like server install?)
<ogra> http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/
<ogra> try that image then
<ogra> note though that we are working on a bug with the partitioner atm, you wont get very far
<lool> suihkulokki: The meego n900 drop boots fine for me with your cmdline, but e.g. an Angstrom beagleboard SD card image doesn't; I'm using:
<lool> qemu-maemo-system-arm -M beagle -m 256 -sd Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.sd-image-2GiB.img  -serial stdio -clock unix
<lool> suihkulokki: Do you use any extra args which could help?
<neure> ogra i need something i can use to build my app
<suihkulokki> lool: try building the kernel with early printk on to see where it ends
<ogra> amitk, so it does seem this time testing i dont even get as far as partman ... seems it rather fails in disk-detect
<ogra> which gets me even less logs :/
<lool> suihkulokki: Ok thanks
<amitk> ogra: seems like disk-detect is d-i-only?
<ogra> no, ubiquity uses it as well
<amitk> (I meant it isn't part of the standard install)
<ogra> it is
<ogra> oh, you mean on the installed system ? no
<ogra> its a script that checks the disk availability
 * ogra treis to log to a file
<amitk> script with no debug output, I presume?
<hrw> hi
<ogra> amitk, debug output added to the bug now (running disk-detect with set -x)
<ogra> amitk, smells like it dies even before
<amitk> ogra: question is, will all debugging have to be done in a live environment only? Or does the installed system have similar commands...
<ogra> amitk, i doubt it
<ogra> lets iedntify what triggers it first
<amitk> ogra: can the disk-detect script be used outside d-i?
<ogra> i dont think so, it sources several d-i componentws
<ogra> http://launchpadlibrarian.net/44009972/syslog somewhat indicates that the issue lies even before disk-detect
<amitk> Apr 13 08:47:27 kernel: [  318.895812] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40200000
<ogra> right
<ogra> thats right *before* disk-detect runs
<ogra> i wonder if it has something to do with the check for missing firmware
<amitk> Apr 13 08:47:23 main-menu[238]: INFO: Menu item 'disk-detect' selected
<ogra> i'll set -x that one (if i can find it)
<amitk> Apr 13 08:47:24 kernel: [  316.195953] sd 0:0:0:0: Attached scsi generic sg0 type 0
<amitk> Apr 13 08:47:24 net/hw-detect.hotplug: Detected hotpluggable network interface eth0
<amitk> Apr 13 08:47:24 net/hw-detect.hotplug: Detected hotpluggable network interface lo
<amitk> Apr 13 08:47:26 check-missing-firmware: no missing firmware in /tmp/missing-firmware
<amitk> Apr 13 08:47:27 kernel: [  318.895812] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40200000
<amitk> ogra: it says you selected disk-detect there...
<ogra> yeah
<ogra> d-i selects it
<ogra> or rather the main-menu process (which is the core of d-i)
<ogra> Apr 13 09:15:46 main-menu[240]: (process:5940): + log no missing firmware in /tmp/missing-firmware
<ogra> Apr 13 09:15:46 main-menu[240]: (process:5940): + logger -t check-missing-firmware no missing firmware in /tmp/missing-firmware
<ogra> Apr 13 09:15:46 main-menu[240]: (process:5940): + return 1
<ogra> Apr 13 09:15:46 main-menu[240]: (process:5940): Bus error
<ogra> Apr 13 09:15:46 main-menu[240]: (process:5940): Bus error
<ogra> Apr 13 09:15:46 main-menu[240]: (process:5940): Bus error
<ogra> so thats with set -x in check-missing-firmware
<ogra> the non-linefetch error still shows above that
 * ogra puts set -x into net/hw-detect.hotplug
<ogra> amitk, https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/561426/comments/3
<ubot4`> Launchpad bug 561426 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "partman dies when trying to detect disks due to kernel error (affects: 1) (heat: 8)" [High,In progress]
<ogra> hmm, adding set -x to net/hw-detect.hotplug doesnt get me any more output
<amitk> ogra: no strace possible?
<ogra> ~ #
<ogra> ~ # parted_devices
<ogra> [ 1034.439666] Unhandled fault: external abort on non-linefetch (0x1018) at 0x40200000
<ogra> Bus error
<ogra> ~ #
<ogra> got it !
<nosse1> ogra, I have the same on my ti-omap variant
<nosse1> hence I doubt it's a ubuntu regression
<ogra> nosse1, no matter if its a regression or not, it breaks the ubuntu (and likely also debian) installer
<ogra> lool, you wanted to change the omap naming scheme, do you plan to do that for lucid ? (i'm just patching libdebian-installer to add proper subarch detection)
<kbingham> anyone know if efence / electric fence is thread safe ?
<kbingham> or rather - i think its not - does anyone know of any thread safe memory bounds tools to run on the arm ?
<lool> ogra: You mean omap3 versus omap?  After yours and amitks explanation, I'm happy to keep it if it means any OMAP
<lool> At least 3 and 4 that is
<ogra> ok
<lool> amitk: Hmm open(/dev/mem)  :-)
<ogra> just wanted to know if i need to take that into account for d-i
<ogra> lool, yeah, it tries to run dmidecode :P
<ogra> or parts of it at least which are copied into parted_devices
 * ogra takes a break
<amitk> lool: yeah, /dev/mem is so irresistible :)
<amitk> ogra: do you know already if the parted fixes fix the problem?
<ogra> amitk, still building with the fix
<ogra> i'll test asap
<ogra> but the parted build takes a while
<amitk> ok
<dmart> ogra: is the mobile IRC meeting cancelled today?
<ogra> dmart, its in 30min
<ogra> dmart, do you share calendars with asac ? he asked the same some mins ago :)
<ian_brasil> are there any popcon figures available for arm?
<dmart> Oh, ... ah my calendar doesn't understand that meeting's in UTC don't move with daylight savings time
<ian_brasil> looked @ http://popcon.ubuntu.com/ and the latest seem to be dapper
<ogra> ian_brasil, http://popcon.ubuntu.com/
<ogra> ian_brasil, i simply doubt anyone enabled popcon on the few armel installs we have
<ian_brasil> ogra, this could be quite useful..could this be encouraged in the installer?
<ogra> amitk, fixed :)
<ogra> Creating ext4 file system for / in partition #1 of SCSI1 (0,0,0) (sda) ...
<ogra> :D
<ogra> wohoo ... i'm in base-install
<asac> nice
<amitk> ogra: nice!
<ogra> and cjwatson already uploaded ...
<nosse1> I have an ever-eating netbook-launcher running on my target. Now it has consumed 525M of ram, on a 256M system.... Anyone else seen this behaviour?
<ogra> netbook-launcher ? or netbook-launcher-efl ?
<ogra> (dont run the former on armel)
<nosse1> ogra, It's the efl version. It is the one started automatically
<plars> nosse1: I've not seen it take up that much, no.  What version, and what are you running it on?
<nosse1> Now its 534M, so I suspect a leak.
<nosse1> ii  netbook-launcher-efl       0.2.6-0ubuntu1             A lite version of netbook launcher written in EFL
 * ogra has only seen netbook-launcher misbehave 
<ogra> but never efl
 * nosse1 cant tell if it should behave this way or if its a leak
<ogra> it shouldnt
<nosse1> Hmm. Its consuming 50% CPU constantly as well
<plars> nosse1: how long has it been running?
<nosse1> demo       894 58.8 67.8 538024 168144 ?       RLl  13:36  77:41 /usr/bin/netbook-launcher-efl
<nosse1> I want to kill it, unless theres something you would like to know
<GrueMaster> nosse1: What version is it?  I have had it running overnight on my systems and it is only using 56104k memory.
<nosse1> It's the 0.2.6-0ubuntu1 version
<nosse1> I updated this morning
<amitk> ogra: uploading a 'final' kernel to people.canonical.com/~amitk/ti . Please test and let me know if you see anything untoward. I'll test it overnight here and upload first thing tomorrow morning.
<ogra> amitk, ok, will do, thanks a lot for the awesome work the last days
<amitk> It has OTG support plus some config fixes, everything else will have to go as SRUs
<ogra> right
<amitk> ogra: thank you :)
<ogra> amitk, oh, we might need to have a uboot-mkimage dependency in linux-image-2.6.33-500-omap
<ogra> apw, ^^^
<ogra> can that be added
<apw> ogra, i'll let amitk handlle that
<ogra> ok
<apw> as i don't have an uptodate omap tree at the mo
<Martyn> morning
 * Martyn is dissapointed .. TI has said there are no plans to bring an omap44xx beagleboard into play.  *sigh*
<Martyn> and nVidia are completely out of tegra250's
<GrueMaster> lool: Thanks for reminding me about initrd being cramfs.  It has been a long time since I debugged an initrd issue.
<plars> GrueMaster: it does seem to grow very gradually,  I've been up for just about 30 min on this system and n-b-l-e is at 24164 RSS, if you are at 54k from overnight, that would indicate it seems to have grown over time, but it's hard to imagine it getting to 525M as nosse1 is seeing very soon at that rate
<plars> something has to be setting it off
<plars> nosse1: are you doing a lot from the console? anything you can think of that may have cause it to suddenly grow rapidly?
<nosse1> No, I just left the target while going for lunch
<ogra> amitk, is your OTG fix supposed to fix that: http://paste.ubuntu.com/413681/ (i get it on an installed system)
<cpearson> Martyn, there will be no OMAP4 'BeagleBoard' but there will certainly be a low cost development board from us... just with a different name
<cpearson> cheer up :)
<Martyn> cpearson: Yeah .. but I will miss the compact cuteness of the beagleboard
<cpearson> um... let's say that it'll be about the same form factor and backwards compatible
 * Martyn perks
<nosse1> Is is possible to install hooks on update-initramfs in order to generate uInitrd images?
<nosse1> How do you do it (i.e. workflow) when u-boot is involved
<GrueMaster> I'm not sure, but I think the kernel post install script does that for the dove kernels.
<GrueMaster> It may be easier to create a wrapper script.
<ogra> nosse1, thast done by flash-kernel
<ogra> nosse1, i'm working on getting that pieces sorted before thu.
<prpplague> cpearson: first day at the conference go well?
<cpearson> yes, just VERY long. The Ubuntu on ARM BoF didn't wrap up until 10pm
<ogra> wow
<ogra> sounds like lots of interest
<cpearson> Dave's talk was good, and our the Ubuntu on OMAP4 demo sparked a lot of conversation
<ogra> sweet
 * cpearson packs up and heads over to the conference
<GrueMaster> ogra: I fixed the dove netboot issue (well figured out what was wrong).  Need a fix for debian-installer.  See my post on bug 541399
<ubot4`> Launchpad bug 541399 in debian-installer (Ubuntu) "netboot image fails to boot. (affects: 1) (heat: 8)" [Medium,In progress] https://launchpad.net/bugs/541399
 * ogra reloads
<ogra> GrueMaster, that proves my point ;)
<ogra> ogra@osiris:~/Devel/branches/debian-installer/ubuntu$ grep INITRD_FS ./build/config/armel/dove/cdrom.cfg
<ogra> INITRD_FS = initramfs
<ogra> ogra@osiris:~/Devel/branches/debian-installer/ubuntu$ grep INITRD_FS ./build/config/armel/dove/netboot.cfg
<ogra> ogra@osiris:~/Devel/branches/debian-installer/ubuntu$
<hrw> which conference? ELC?
<GrueMaster> So, it should be a very simple fix, right?
<ogra> GrueMaster, committed
<GrueMaster> cool, thanks.
<amitk> ogra: this oops occurs _after_ the install?
#ubuntu-arm 2010-04-14
<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/?
<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...
<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?
<rcn-ee> andruk,  you have a zippy1 right?
<andruk> rcn-ee: nope, just a vanilla bb
<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
<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
<rcn-ee> something like this: http://pastebin.com/hZd2XLu6  (had it saved in my temp since our last conversation)
<rcn-ee> andruk, if it actually works for you and your spi devices work, I'll rework the patch and actually commit it...
<andruk> rcn-ee: so, is that a patch for patch.sh?
<andruk> rcn-ee: the pastebin link, I mean
<rcn-ee> yeah, it's a patch for patch.sh and it adds the SPIPatch-2.6.32.diff file...
<andruk> rcn-ee: patch unexpectedly ends in middle of line (\n) patch: **** malformed patch at line 240:
<rcn-ee> yeap, noticed that too...  (my cable modem is very slow tonight) fixing as we speak..
<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"
<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?
<rcn-ee> it looks like you still have the old one, the source was different around: static void __init omap3_beagle_init(void)
<andruk> oh, kay
<rcn-ee> and that was what was causing the patch to stop...
<andruk> uhoh...same error around line 238 this time
<andruk> rcn-ee: ping
<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"
<andruk> rcn-ee: you are too kind for a faltering noob like me
<andruk> :-)
<rcn-ee> laughs, we are all noob's here.. wait till i finally figure out git, then force everyone to git clone my tree.. ;)
<andruk> rcn-ee: is there anything i need to do for Kconfig?
<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...
<andruk> rcn-ee: cool.  thanks.
<andruk> fuck...
<andruk> rcn-ee: http://pastebin.com/L0HdENxz
<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/
<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...
<andruk> rcn-ee: :-/ okay thanks for you help!
<DanaG> hmm, is plymouth going to be used on ARM?  Or rather, present tense, is it used on ARM?
<DanaG> On any system with serial console (in addition to local tty0), Plymouth refuses to show the splash screen.
<DanaG> http://users.csc.calpoly.edu/~dgoyette/amtterm.log -- this is from my host system.
<ogra> plymouth is a dependency of mountall, so yes, its on all ubuntu systems now
<DanaG> Bummer it's not usable with serial console. :(
<DanaG> 'I would expect to see splash on tty0 and messages on ttyS0.;
 * ogra has that here
<ogra> with plymouth
<DanaG> hmm, maybe I should try putting back "quiet"... but that gets rid of messages on serial console, too.
<ogra> amitk-afk, with the new kernel it hangs but without OOPS
<DanaG> I'll have to try it with ARM sometime again.
<ogra> oh, wait
<ogra> if you use console= plymouth wont show a splash at all
<DanaG> yeah.
<ogra> thats known
<DanaG> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/516825
<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]
<ogra> right
<DanaG> it's marked fixed... but I disagree with that.
<ogra> amitk, http://paste.ubuntu.com/414122/ :(
<ogra> thats what i get after some unsuccessful boots
<DanaG> [main.c]                            check_for_consoles:checking if splash screen should be disabled
<DanaG> [main.c]                            check_for_consoles:serial console found!
 * ogra removes the HUB and attaches the USB key directly
<ogra> hmm, hangs too
<ogra> no oops
<amitk> w/o hub, it won't work
<ogra> well, it finds the disk and mounts it
<ogra> but hangs right after with no messages
<amitk> ogra: line 41 on the paste says you had a ext4 error
<amitk> did your FS become corrupt?
<ogra> amitk, i doubt ext4 *can* get corrupt that way
<ogra> its never mounted RW
<ogra> my boot doesnt get that far
<amitk> EXT4-fs error (device sda1): __ext4_get_inode_loc: unable to read inode block - inode=267617, block=1049142
<ogra> right
<amitk> ogra: we've had lots of issues with ext4 corruption, was this tried on a fresh image?
<ogra> i know what you think, but my boot never gets to mountall
<ogra> (mountall is remounting / RW)
<amitk> we are talking about "read" here...
<ogra> amitk, thats the USB install from yesterday
<ogra> using your newest kernel from people
<amitk> so it could be corrupted in the last shutdown
<ogra> amitk, i know, but how would the disk get corrupted if itwas never mounted ?
<ogra> i mean RW mounted
<ogra> hmm, unpowered HUB doesnt work either
<ogra> nor does the mini USB port
<amitk> what are you using the OTG port for?
<ogra> well, i was just trying all options and attached the disk with adapter
<ogra> i didnt expect that to work :)
<amitk> ogra: so you're saying that the kernel is lying about the ext4 error? :)
<ogra> amitk, not sure if it lies or if it has a hiccup
 * amitk doubts it
<ogra> though i'd guess given the other USB issues i see that its not the FS but the underlying layer
<ogra> i havent had any other ext4 errors
<ogra> i dont have any other errors at all now, it just gets stuck
<ogra> sometimes it managed to print the ureadahed message, sometimes it just gets stuck when leaving the initramfs
<ogra> i didnt get further than ureadahead with this kernel
<ogra> the archive kernel got a bit further (up to the apparmor messages ) and got stuck then
<ogra> and either oopsed or not
<ogra> without USB we're a bit screwed :/
 * ogra gets more coffee
<amitk> ogra: you are seeing errors now!
<amitk> [   35.254974] EXT4-fs error (device sda1): __ext4_get_inode_loc: unable to read inode block - inode=267617, block=1049142
<amitk> [   35.267272] EXT4-fs error (device sda1): ext4_find_entry: reading directory #2 offset 0
<amitk> [   35.277526] Kernel panic - not syncing: Attempted to kill init!
<amitk> [   35.283630] [<c003c81c>] (unwind_backtrace+0x0/0xe8) from [<c043e434>] (panic+0x54/0x138)
<amitk> [   35.291900] [<c043e434>] (panic+0x54/0x138) from [<c006717c>] (exit_notify+0x0/0x144)
<amitk> [   35.299804] [<c006717c>] (exit_notify+0x0/0x144) from [<00000001>] (0x1)
<amitk>                                ^^^ that is the beginning of a panic aka oops
<ogra> that was in one out of 20 boots
<ogra> didnt show up again
<ogra> now it just gets stuck
<ogra> no oops no error at all, just locks up
<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
<ogra> its definately not the filesystem
<lool> ogra: did you see my comments on the dove netboot images bug?
<ogra> if it wouldnt take ages i'd try another install right now
<ogra> lool, havent read my bugmail yet, if you made comments today i didnt see them, i saw your last one yesterday
 * ogra looks at evo
<lool> ogra: No need for a full install, just loading the images is a good enough test
<ogra> lool, ah, well, at least we build the netboot initrd the same way the cdimage one is built now
<lool> ogra: So GrueMaster was saying that the initrd has incorrect values
<ogra> lool, i cant test dove i dont have the HW
<lool> So the bug should probably be reopened, but I dont have the hardware either
<ogra> only NCommander GrueMaster or plars can test
<ogra> i was just aiming for consistency, the cdrom initrd which is an initramfs obviously worked for GrueMaster
<ogra> so we excluded at least one breaking factor here
<NCommander> lool: what was the bug number? I can recheck
<ogra> Bug 541399
<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
<ogra> lool, you shouldnt need ramdisk_size with initramfs
<ogra> or /dev/ram0
<ogra> what i dont get is why we use a different load address at all
<ogra> that seems broken
<ogra> building the same setup the cdrom initrd has while keeping the same address should suffice
<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/
<ogra> i wish i had the time to make a dd'able image out of it
<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
 * ogra wants to try if he can probably get away with a minimal install to SD if running netinst
<ogra> thats better than nothing given time runs short
<amitk> ogra: please do, I'm interested in a fresh install
<amitk> I'm doing that here too
<ogra> well, i wont do a USB install
<ogra> which is our main issue atm
<ogra> though i'm not sure parted can handle installing to the media we run from but netinst makes me hope
<ogra> grr, so partman doesnt let me create /boot as fat
<ogra> thats a prob
<amitk> ogra: I'm still ooming on the new image while installing...
<ogra> can you check with free ?
<ogra> if swap is actually 128M
<amitk> ogra: yes it is
<amitk> I checked on serial console
 * ogra curses very loudly
<amitk> I'm stuck at the keyboard layout dialog
<ogra> did you modify anything else than adding serial ?
<amitk> new kernel and serial
 * ogra wonders why it doesnt OOM for him
<amitk> ubuntu@ubuntu:~$ free -m
<amitk> [  684.363372] Out of memory: kill process 1743 (gnome-session) score 50392 or a child
<amitk> [  684.371276] Killed process 1974 (metacity) vsz:32548kB, anon-rss:1000kB, file-rss:7380kB total       used       free     shared    buffers     cached
<amitk> Mem:           240        205         35          0          8         49
<ogra> can you change the cmdline and add only-ubiquity to it ?
<amitk> -/+ buffers/cache:        146         93
<amitk> Swap:          120        118          1
<ogra> i guess we'll have to default to that
<ogra> it wont start the desktop but go directly into the installer
<ogra> indeed the user needs to have a big enough swap in his install
 * ogra sees a pile of release notes ahead
 * ogra is afk for a moment
<amitk> just 1M of swap free, I guess even starting a serial console shell is a step towards oom
<ogra> yes
<ogra> but lets go the only-ubiquity path ...
<ogra> its the best fallback we have
<ogra> <- really afk
<hrw> morning
<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"
<amitk> hrw: morning
<ogra> amitk, at which point ?
 * ogra definately sees an issue with update-initramfs atm
<amitk> ogra: last I saw it was almost finished with the install
<ogra> right, thats likely either the kernel installation or the bootloader step
<amitk> ogra: I have the session active in case you want some information to help you debug
<amitk> hrw: since you're involved with OE, what kernel version do they ship for beagleboard?
<ogra> yeah, file a bug with ubuntu-bug -p ubiquity
<hrw> amitk: 2.6.32 based on linux-omap-psp branch
<amitk> what is psp?
<hrw> TI branch of linux-omap
<hrw> never read what makes it special
<XorA> Platform Support Package
<XorA> TI language for BSP
<hrw> said TI OMAP OE expert
<XorA> and there is nothing special, about it, everything goes upstream
<hrw> XorA: but TI code lands in psp and then migrate to linux-omap - right?
<nosse1> ogra, did you resolve the "Unhandled fault: external abort on non-linefetch" issue?
<XorA> hrw: yes I beleive thatd the path, but its so damn quick these days
<ogra> nosse1, yes, fixed in todays images
<hrw> amitk: git://arago-project.org/git/people/sriram/ti-psp-omap.git
<nosse1> May I ask what it was? Compile flag issue?
<hrw> amitk: OE uses da0c86a8f3bd57fad0ccd05eb1b5e3326d7f36aa revision + 41 patches added
<amitk> hrw: where would I find their defconfig?
<ogra> nosse1, code in parted that tried to run dmidecode snippets to read BIOS info from /dev/mem
<hrw> moment
<XorA> amitk: arch/arm/configs
<XorA> amitk: if you mean TI defconfig
<amitk> ohh, so they use the defconfigs?
<ogra> sigh, so we cant install to mmc
<XorA> OE has its defconfig in metadata
<hrw> amitk: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/beagleboard/defconfig
<ogra> initramfs-tools has no support for it
 * amitk looks, although a lot has changed in 2.6.33
<XorA> so which image should I use on my beagle today?
<amitk> ogra: bug 562888
<ubot4`> Launchpad bug 562888 in ubiquity (Ubuntu) "omap installation failed with unrecoverable error (affects: 1)" [Medium,New] https://launchpad.net/bugs/562888
<ogra> amitk,
<ogra> Jan  1 00:48:52 ubuntu python:   File "/usr/share/ubiquity/install.py", line 1664, in configure_bootloader
<ogra> Jan  1 00:48:52 ubuntu python:     raise InstallStepError("No bootloader installer found")
<ogra> Jan  1 00:48:52 ubuntu python: InstallStepError: No bootloader installer found
<ogra> i wonder why it didnt show the correct error msg though
 * amitk wonders how ogra managed to install yesterday
<ogra> amitk, i used d-i
<ogra> thats more flexible
<ogra> d-i offers you actually to install without bootloader, in ubiquity thats possible too but a bit hidden
 * amitk has wasted 2 hours 
<ogra> on the last page you can select "advanced"
<ogra> there you can check "dont install bootloader"
<ogra> amitk, use netinst and do a minimal install
<ogra> its way faster
<ogra> http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/omap/netboot/omap/
<ogra> as long as your target is USB it will work
<ogra> donty try mmc though, initramfs-tools is buggy
<amitk> ogra: just copy these to casper/ ?
<ogra> amitk, nope, just have a vfat SD card ... copy all three files to /
<ogra> if you want to use serial for installing, edit boot.scr
<ogra> i'll set up wikipages for all install variants after freeze ... once i have time for that
<ogra> amitk, you didnt waste the 2h ... now we are at least sure that only-ubiquity wont OOM, thanks a lot
 * XorA guesses he better find out how to install u-boot on a beagle :-)
<hrw> XorA: you need to finding it out? I thought that you can do that anytime ;D
<XorA> hrw: I have never done it
<XorA> hrw: never needed to until now
<hrw> XorA: use Koen's instructions on angstrom /demo/beagleboard/README
<hrw> XorA: I always used those
<nosse1> ogra, the gnome desktop has become very smooth. Even on my 256M system. I think the fix last night really improved my issues
<ogra> great
<XorA> hrw: thanks, they are nice and easy to follow :-)
<XorA> arse I hit the C3 EHCI bug really quick :-(
<persia> XorA: On the bright side, that means you managed to get the system up and running really quick :)
<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?
<XorA> persia: but as you guys dont support the zippy I cant install it, only live disk
<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)
<persia> XorA: What happens when you try to install?  Bugs are welcome, although most of them probably end up being 10.10 candidates.
<XorA> persia: my EHCI port shuts down, its a hardware bug on C3 and earlier boards
<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)
<persia> Basically, if a patch is simple and easy to maintain, there's no reason for it not to be there.
<persia> Basically, if a patch is simple and easy to maintain, there's no reason for it not to be there.
<persia> XorA: Oh, a known hardware issue that can't be worked around in the kernel?  Yeah, not much hope there.
<persia> bmwiedemann: That'd be a great start, if you don't mind.  Thanks.
<XorA> persia: its what the C4 boards fixed
<bmwiedemann> persia: done
<XorA> you goes should turn on heartbeat on one of the leds by default
<persia> bmwiedemann: Thanks.
<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.
<XorA> persia: ok, its quite easy as you in the led class in sysfs
<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?
<XorA> persia: its literally as easy at echo heartbeat >/sys/class/leds/name/function
<XorA> trigger not function, but you see what I mean
<persia> We we just need a good way to pick *which* led to flash for heartbeat.
<XorA> persia: anyway Im concentrating on just getting the damn thing installed :-)
<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.
<XorA> arse my EHCI port seems to have given up completely
<XorA> any of you guys been installing with OTG port?
<XorA> not using the zoom2 SD card helps
<lool> ogra: 09:18 < ogra> lool, you shouldnt need ramdisk_size with initramfs
<lool> ogra: are you sure?
<ogra> lool, yes
<ogra> i had the same issue with omap
<ogra> initrd needed ramdisk_size set, initramfs didnt
<ogra> thats why i moved dove to initramfs for netinst
<ogra> i'm waiting for feedback from NCommander who wanted to test that hours ago
<ogra> lool, i think its a differece of mounting compressed vs fully unpacking
<ogra> (though thats just a guess)
<ogra> OMAP3 beagleboard.org # ext2load mmc 0 0x80000000 uImage
<ogra> Loading file "uImage" from mmc device 0:1 (xxa1)
<ogra>  ** ext2fs_devread() read error - block
<ogra> ** Unable to read "uImage" from mmc 0:1 **
<ogra> ah well, i had to try at least :/
<nosse1> Anyone else that have had problems with "BUG: soft lockup - CPU#0 stuck for 61s!"?
<ogra> nope
<nosse1> I'm getting it when doing heavy disk activity (e.g. dpkg) when using NFS
<ogra> though i never use NFS
<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
<hrw> XorA: did you upgraded MLO too?
<XorA> hrw: yes
<XorA> hrw: both from Angstrom
<amitk> nosse1: you're not using the Ubuntu kernel though...
<nosse1> It's a coincidence that this occurs at the same time that the HW bug is discussed in this channel :(
<XorA> nosse1: C3 beagle?
<nosse1> amtik, no I'm not
<nosse1> XorA, no. The AM3517-EVM. That's why I cannot run the vanilla ti-omap kernel
<XorA> nosse1: C3 and earlier beagle there is not enough grunt in the power rail of EHCI and port drops out under heavy load
<hrw> and I have C3+C3+B7 ;(
<hrw> hope that TI will release XM soon
 * XorA has C3 and B6
<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
<hrw> and one of C3 has to work as mediaplayer plugged to TV
<XorA> yeah we all need XMs :-D
<XorA> otherwise ubuntu work is going to be painful
<ogra> ++
<ogra> though we're getting closer to at least have *something* for lucid
<hrw> XorA: too bad that this time I would rather have to pay for Beagleboard... the ones which I have I got for free
<ogra> make your employer pay ;)
<hrw> ogra: you mean me myself?
<hrw> :D
<hrw> ogra: I am self employed
<ogra> if you are self employed, reclaim it from taxes ;)
<ogra> its a "tool" :)
<hrw> I know
<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...
<hrw> I just bought 42" plasma TV for my work
<XorA> ogra: you live disk image looks nice, I just cant actually do anything with it
<ogra> thats indeed an important tool to have :)
<hrw> rcn-ee: most of my Debian machines use own kernels
<ogra> XorA, can you define that ?
<XorA> ogra: I have no working usb
<ogra> "anything" is a bit broad :)
<XorA> ogra: so I can stare at the screen :-)
<hrw> XorA: connect BB to TV and boot ubuntu - nothing to stare at ;D
<ogra> XorA, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ tried a recent one ?
<XorA> ogra: usb in the image works, it appears my port just blew
<ogra> it should definately work on the C4 ... not sure about 3
<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?
<hrw> beagleXM with 2xsize and good wifi/bt on board would be nice
<ogra> rcn-ee, attach gdb to the hanging apt and get a backtrace
<rcn-ee> okay, I'll try that.. it only locked up 50/50, on my two runs, so i'll try that...
<ogra> hey, 50/50 is already better than 100% :)
<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...
<ogra> sigh, i want class 20 SD cards
<ogra> i bet the card is worn out once i'm done with install tests
<persia> You just need a better FTL on your card.
 * 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.
<ogra> ok, finallly i get the right initramfs-tools
 * ogra crosses fingers
<ogra> WOHOO !
<ogra> user setup reached
<ogra> and we're in pkgsel
 * ogra gets some coffee while d-i does its duty
<ogra> amitk, so my SD install seems to have similar issues
<ogra> i see no oops though
<amitk> ogra: break=premount doesn't give me a shell
<ogra> ugh
<ogra> it definately shoudl give you busybox
 * ogra tries here
<ogra> what i see is that the SD read LED is flickering very fast
<ogra> but booting stops at
<ogra> Begin: Running /scripts/init-bottom ...
<ogra> Done.
<ogra> init: ureadahead main process (128) terminated with status 5
<nosse1> ogra, This one I also get all the time
<ogra> (note status 5 means it recognozed flash media it doesnt want to read and exited gracefully)
<ogra> nosse1, how did you get stuck with the ubuntu kernel before ? did that look similar ?
<nosse1> Yes, it locked up sometime after that message
<nosse1> I never actually learned what and where it stopped
<ogra> so thats similar then ... and it was fixed for you with a custom kernel but same rootfs/initrd ?
<ogra> amitk, break=bottom clearly gets me to busybox
 * ogra tries premount
<nosse1> ogra, break=bottom worked for me as well
<nosse1> Yes, custom kernel. And generate new initrd from that kernel's modules
<ogra> but using update-initramfs from ubuntu. right ?
<nosse1> yes
<ogra> amitk, so i can chroot /root from busybox but dont get to a prompt
<nosse1> I inject the kernel into the NFS root tree and use update-initramfs with qemu (in chroot env)
 * ogra reboots and checks /dev ... i have a suspicion
<ogra> hmm, no, all devices are there, devtmpfs is mounted fine
<nosse1> ogra, Speaking of which: In my effort to root out the NFS problem, I now try to run the kernel config from TI.
<nosse1> now I have a message during boot saying: mount: mounting none on /dev failed: No such device
<nosse1> But I get into login, and /dev has been mounted properly
<ogra> thats because you dont have devtmpfs enabled in your kernel
<ogra> comes from initramfs' init
<ogra> amitk, i wonder if it makes sense to compare our config to nosse1's
<nosse1> Could this be related?
<amitk> ogra: I'm not getting a shell with break=bottom (I see the panic instead)
<amitk> or break=premount
<ogra> i do on SD card
<nosse1> I mean this error you now describe is the exact reason why I cannot use the ti-omap kernel
 * amitk tries break=top
<ogra> amitk, which kernel do you use ? my install indeed uses the archive kernel still
<amitk> my own kernel
<amitk> installed in chroot
<ogra> right
<ogra> archive kernel definately gets me busybox ... but no boot either
 * amitk tries the arhive kernel
 * ogra goes and makes all initscripts as noisy as he can
<nosse1> I'm sorry guys, I need to leave for kindergarden. I'm unable to be of any further assistance until tomorrow
<nosse1> I am very keen on following this discussion though
 * ogra didnt know nosse1 was *that* young
<nosse1> *lol*
<ogra> :)
<ogra> amitk, hmm, i added --debug to mountall which should be the next thing running after ureadahead and i dont get anything
<amitk> [    0.000000] Kernel command line: console=ttyS2,115200n8 console=tty0 ro root=49b39455-6136-471e-8140-cd5
<amitk> 8dbc48900 vram=12M omapfb.mode=dvi:1280x720MR-16@60 break=bottom debug usbcore.blinkenlights=1 initcall_deb
<amitk> ug
<amitk> ogra: ^ my cmdline, still no busybox shell on break
<ogra> so i suspect we get actually stuck in ureadahead
<lool> ogra: mountall doesn't output to the console by default
<ogra> lool, i added --debug in the initscript
<ogra> it should make a lot of noise
<lool> ogra: If you want it to do that, add console output, and switch from daemon to verbose
<lool> ogra: As I said, it doesn't log to the console by default
<hrw> usbcore.blinkenlights=1? what it does?
<ogra> --debug turned it on when i debugged with KEybuk recently
<ogra> hum
<ogra> indeed lool is right once again
<ogra> --verbose is the parameter
<lool> Right
<amitk> hrw: blinken blinks the lighs on the usb hub (useful to tell if usbcore is working fine)
<ogra> ok, lets see what --verbose gets us
<ogra> no output at all
<lool> ogra: do drop --daemon
<ogra> lool, i did
<lool> ogra: do you have console output in your mountall.conf?
<ogra> its only mountall --verbose
<ogra> lool, seems to be the default
<ogra>  22 # temporary, until we have progress indication
<ogra>  23 # and output capture (next week :p)
<ogra>  24 console output
<ogra> ...
<ogra>  31     exec mountall --verbose # --daemon $force_fsck $fsck_fix
<ogra> but i get no output at all
<ogra> so that somewhat makes me think we get stuck in ureadahead
<amitk> ogra: does break have anything to do with splash (i've removed that)
<ogra> amitk, not to my knowledge
<ogra> but plymouth might have changed the world
 * amitk hates it
<ogra> sigh, where is Keybuk if i need him
<ogra> i wonder if we miss some magical kernel bit for ureadahead
<lool> ogra: Does upstart start at all?
<lool> ogra: are you past initrd?
<ogra> lool, yes
<ogra> Begin: Running /scripts/local-bottom ...
<ogra> Done.
<ogra> Done.
<ogra> Begin: Running /scripts/init-bottom ...
<ogra> Done.
<ogra> init: ureadahead main process (134) terminated with status 5
<ogra> lool, ^^^
<ogra> thats where we get stuck
<ogra> my USB image gets a bit further but hangs then as well
<ogra> on the USB install i can actually see the apparmor profiles being set
<amitk> apw also seemed to think that bits of userspace is being run and exiting...
<ogra> amitk, right, but that a different kernel made it work for nosse1 is suspicious
<ogra> so i suspect we miss a kernel setting that some userspace bit requires
<ogra> which is why i'd love to consult Keybuk ... who isnt here
<ogra> aha
<ogra> Begin: Running /scripts/init-bottom ...
<ogra> Done.
<ogra> init: Failed to spawn ureadahead main process: unable to execute: Permission denied
<ogra> moo
<ogra> i made ureadahead unexecutable
<ogra> and added "echo "moo"" to mountall directly when the script is exece'd
<ogra> it doesnt move on though
<ogra> the SD LED is flickering very fast again
<ogra> amitk, silly question, but what are our console settings ?
<ogra> i dont seem to get any tty0 output at all
<amitk> ogra: yeah, I don't see anything on tty0 either. Only serial
<ogra> right, there is something wonky with text consoles here
<ogra> # CONFIG_FRAMEBUFFER_CONSOLE is not set
<ogra> ah
<ogra> amitk, i guess we need that :)
<ogra> imx51 and dove have it
<ogra> amitk, and that makes me guess that plymouth might be unhappy and crash or something similar
<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)
<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]
<ogra> amitk, init doesnt exit for me
<ogra> and the flashing SD card LED somewhat indicates that something acesses the filesystem
<ogra> amitk, hmm, looking at your log you dont even get into initramfs
<ogra> (you should have shown me the full log earlier)
<ogra> in fact *your* crash is exactly if you enter the initramfs ... is you boot.scr ok ?
<amitk> i posted it up there ^^^^
<ogra> amitk, only the bottom snippet
<ogra> amitk, the full log shows that you are not even entering initramfs
<amitk> ogra: i meant my boot.scr
<ogra> ah, yeah, the log has it too
<ogra> seems ok
<ogra> seems your initramfs isnt though
<ogra> the udev line is clearly *inside* initramfs ...
<ogra> and it dies immediately after firing up udev
<ogra> try to regenerate your initramfs
<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.
<ogra>    Image Type:   ARM Linux RAMDisk Image (uncompressed)
<amitk> ogra: kernel with FB almost done
<ogra>    Data Size:    2261686 Bytes =  2.2 MB
<ogra> way to small
<ogra> there are bits missing for sure ... by whatever reason
<ogra> hmm, or no ... newer initramfses on my systems are as small ...
<ogra> ... more coffee...
<amitk> ogra: kernel with FB in on people
<amitk> that fixed tty0, but our problem still remains...
<ogra> ok
<rsalveti> morning
<ogra> i'd really love to talk to KEybuk, sigh
<ogra> amitk, FB compiled in or module ?
<amitk> compiled-in
<ogra> ah, then i should be able to just use my initrd
<amitk> ogra: but I _still_ don't get a busybox shell
<ogra> do you get through initramfs ?
<ogra> you should see all the "running scripts init-blah" messages
<amitk> nope
<ocs_> hi. how much does a Freescale i.MX51 Babbage board pda cost?
<ocs_> (about)
<ogra> $750
<ogra> amitk, re-roll your initramfs something is corrupt there
<ocs_> and... which is the cheapest board on which ubuntu-arm has been tested ?
<amitk> ogra: doesn't kernel install already do that?
<kaouthia> http://store.digi.com/index.cfm?fuseaction=product.display&Product_ID=1711
<ogra> amitk, it re-rolls, but did you mkimage etc ?
<amitk> ogra: yes, mkimage uImage, uInitrd
<kaouthia> http://www.digi.com/products/embeddedsolutions/connectcore-wi-mx51.jsp#overview <-- Click "contact us" for the Linux version
<kaouthia> Google is your friend
<ogra> amitk, strange ... my boot definately goes through even with your current kernel ...
<amitk> ogra: the latest one?
<ogra> yup
<rsalveti> ogra: did you find why the upstart was stopped during the boot?
 * amitk wonder if he should run a apt-get upgrade on the chroot
<rsalveti> was following the problem but had to get to work
<ogra> amitk, didnt you use your USB installation root ?
<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
<amitk> ogra: I did..
<ogra> thats very strange, i havent seen such behavior
<hrw> rsalveti: u8500 got some available boards or still ST-E internal only?
<ogra> amitk, want a uInitrd on people ?
<amitk> ogra: give me the whole package, uImage, boot.scr and uInitrd
<ogra> ok
<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
<rsalveti> hrw: but the kernel, boot loader, mali driver and etc are all internal only atm
<ocs_> thanks
<rsalveti> hrw: they're pushing the kernel upstream, but the support is still very basic
<hrw> rsalveti: so same like it was with NDK-15
<hrw> but this time they learnt that using few years old kernel is not good
<ogra> amitk, btw, no messages on console ... only a blinking cursor ... did you see kernel msgs ?
<rsalveti> hrw: sure, currently we're using 2.6.29
<amitk> ogra: yes
<rsalveti> quite old and the kernel itself is not that stable, but it's working fine
<ogra> amitk, http://people.canonical.com/~ogra/beagle/
<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
<amitk> ogra: I see the kernel messages
<ogra> note i'm fiddling with boot.scr atm
<rsalveti> hrw: we got oe and maemo running on top of it as a proof of concept
<ogra> you might want to change it for your purpose
<hrw> rsalveti: and android
<rsalveti> hrw: sure, they are working inside mainly with android
<hrw> rsalveti: on SCW'09 ST-E shown android on u8500
<rsalveti> now that maemo/meego stuff got more attention
<rsalveti> hrw: yeah, the kernel is being developed mainly to support android
<ogra> amitk, oh, intresting ... there *are* messages, but the console blanks at the point where i have the hang
<ogra> i just switched my monitor over to late
<rsalveti> hrw: we also have the basic mali support, but this will be closed source in the end, like sgx stuff
<hrw> rsalveti: it it will be redistributable then it will be good
<rsalveti> hrw: currently we're developing basic support for X acceleration, like exa, dri2 and xvideo
<hrw> rsalveti: we (OH) did that for stn8815 few years ago
<rsalveti> hrw: yeah, andrea was talking about it
<rsalveti> then oh went for intel and they had to drop the project
<hrw> anyway stn8815 is dead
<ogra> amitk, whats even more intresting, while i still have the hang, the LDE behavior changed
<ogra> *LED
<ogra> both SD LEDs are solid green now
<hrw> ogra: I have a board which talks after 'system halted'
<amitk> ogra: USR0 and USR1?
<ogra> amitk, HAHAHAHAHA !!!
 * ogra fixes /lib/init/fstab
 * amitk prepares to strangle ogra :)
<rsalveti> hrw: but I think that with u8500 ste will at least make it full supported upstream
<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
<hrw> rsalveti: I hope too - it makes maintaince much cheaper
<rsalveti> hrw: sure, besides making it easier for everyone that wants to used it as a product
<rsalveti> the quality is much better when it's upstream
<rsalveti> vendor's kernel is always a mess
<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)
<amitk> ogra: no change with your initrd and kernel, I'll check my boot.scr now
<ogra> amitk, yeah, probably one of your kernel debuig settings prevents initrd from being used
 * ogra curses 
<rsalveti> persia: yeah, but people seems afraid of mainline developers :-)
<ogra> i cant get past fsck !
<amitk> ogra: did you fix both fstabs?
<ogra> amitk, only /lib/init/fstab that usually suffices
 * ogra edits /etc/fstab too
<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.
<ogra> Starting kernel ...
<ogra> Uncompressing Linux... done, booting the kernel.
<ogra> Ubuntu lucid (development branch) ubuntu ttyS2
<ogra> ubuntu login:
<ogra> WOHOOOOO !!!!
<ogra> amitk, so the console fix is essential :)
<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
<ogra> Linux ubuntu 2.6.33-500-omap #5 Tue Apr 13 11:58:48 EEST 2010 armv7l GNU/Linux
<ogra> Ubuntu 10.04 (lucid)
<ogra> Welcome to Ubuntu!
<ogra> :D
 * ogra is happy that he can finally start to work 
 * amitk hugs ogra 
<amitk> ogra: so fixing both fstabs was reqd?
<ogra> amitk, yep
<ogra> now the point that counts ...
 * ogra tries update-initramfs with vfat /boot
<ogra> asac, why dont i have network on my cmdline system ? shouldnt NM sort that ?
<ogra> oh, i dont have a driver
<ogra> amitk, ergh ... no more USB with your latest kernel from people
<lool> GrueMaster: Ok, the uinitrd settings were *not* changed
<amitk> ogra: new kernel uploaded to people with OTG settings reverted.
 * ogra pulls
<prpplague> ogra: greetings
<ogra> amitk, urgh and shutdown (sudo halt) results in an oops
<amitk> ogra: try with archive kernel first, there are several changes in my kernel that we might not want at such short notice
<ogra> hey prpplague (sorry i'm *very* busy ... final freeze is tomorrow)
<prpplague> ogra: np, just saying hello
 * ogra curses 
<ogra> amitk, so while initramfs creation works, linux-image isnt installable on vfat :(
<ogra> silly postinst !
<amitk> ogra: any luck? (I need a break from this stuff)
<ogra> amitk, gimme a min ... just got into a discussion in -kernel
<amitk> np
<amitk> ogra: so what did you have to change in /lib/init/fstab? Just the 1 -> 0
<amitk> ?
<ogra> amitk, yep
<ogra> crapo i trashed my SD
<ogra> amitk, lookd good
<ogra> *looks
<ogra> amitk, if you upload dont forget to adjust the deps
<ogra> we need flash-kernel and uboot-mkimage
<amitk> ogra: against linux-image-2.6.33.....?
<ogra> yep
<amitk> ogra: so usb is working now, right?
<ogra> amitk, gimme a sec, it works with the SD install ... i want to make sure root on USB works too
<ogra> amitk, root on USB works too now
<ogra> amitk, so lool just pointed me to code that cares for uboot-mkimage ... but flash-kernel shoudl be a dep
 * ogra wonders why he hasnt gotten flash-kernel installed on omap now
<lool> ogra: we might not need flash-kernel as a strong dep for the same reason
<lool> ogra: these are usually recommends
<ogra> lool, i dont have it at all in my two omap installs
<ogra> and iirc we had a reason to make it a dep in imx51
 * ogra chacks again
<ogra> *checks
<amitk> ogra: I don't think it was a dep for imx51
<ogra> Recommends: flash-kernel
<ogra> linux-image-2.6.31-605-imx51
<lool> ogra: You need to update flash-kernel-installer for the same reason
<ogra> so right, make it a recommends
<ogra> lool, yes, i'm doing that with some really ugly code
<lool> ogra: No
<amitk> ogra: only flash-kernel?
<lool> ogra: see debian/flash-kernel-installer.postinst line 48
<ogra> amitk, yes
<lool> ogra: the Recommends is optional and just there to "be nice" to people installing an omap kernel by hand
<ogra> lool, there was a reason for having the recommends ... iirc it was to enable people who manually roll images
<ogra> right
<lool> ogra: Yes
<ogra> so lets stay nice :)
<ogra> and have that recommends in omap too
<ogra> no dep though
<lool> ogra: not related to the fact you're missing it in your installed image
<ogra> i'll handle that in flash-kernel-installer
<ogra> yeah, i know
<lool> If you used ubiquity / d-i that is
<ogra> i did
<ogra> well, d-i
<ogra> ubiquity needs another image chjange before we can use it
<amitk> ogra: I don't think it is even in recommends, in the kernel pkg
<ogra> god, i cant type anymore
<amitk> it is only in the bootloader section
<ogra> amitk, please make it one for people maunally installing kernels
 * ogra thinks these flash-kernel-installer changes will forever destroy the bit of reputation his coding style has left 
<ogra> fiddling with fstab is really really nasty :/
<lool> ogra: So if you used d-i / ubiquity, the problem is in flash-kernel-installer, not in deps
<ogra> hmm
<lool> I agree we want a recommends or a suggests, but I would personally go for a suggests
<ogra> it is in deps
<ogra> its just not executed
<ogra> since there is no match for the beagle
<lool> ogra: Yes, exactly
<lool> ogra: that's not related to deps
<ogra> lool, so ... i need an opinion
<ogra> mdz suggested to create /boot/uboot for the first partition of the mmc (vfat needed for booting)
<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
<ogra> lool, do you have any better idea ?
<ogra> i dont think i can invent a new partman module right now some hours before the freeze
<lool> ogra: You need to update flash-kernel and flash-kernel-installer for OMAP beagleboard
<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.
<ogra> lool, yes, i know
<ogra> lool, i know what to do there ... please read above ... that fstab fiddling is more important
<lool> ogra: Ok; need to finish a call to focus on the questions
<lool> amitk: That's nice to have; I would _personally_ to for a suggests instead of recommends
<ogra> lool, ok, i'll write some code you can review then
<lool> I can argue why, but I'd rather convince ogra so that he agrees with the approach
<lool> s/to/go
<ogra> well, go with whatever you feel is right :)
<ogra> i'm way to focused to finish omap :)
<lool> ogra: So recommends make it a bit harder to replace the bootloader
<lool> ogra: e.g. to use grub for arm, or mukluk
<ogra> well, do you ever expect omap to not use uboot ?
<ogra> oh, ok
<ogra> thats an argument :)
<ogra> amitk, go with a suggests :)
<lool> Hmm that was easy  :)
<ogra> heh
<ogra> lool, i promised you i'D work on it ;)
<lool> ogra: I didn't understand that /boot/uboot story; is this for images, for installed system, or both?
<ogra> installed
<lool> ogra: Also, why do we have this requirement?  is it to have a copy of the installed uboot?
<ogra> to get around the hardlinks on /boot
<ogra> no its for uImage/uInitrd and boot.scr
<lool> ogra: Which hardlinks are these again?
<ogra> lool, dpkg ... when replacing vminuz-*
<ogra> or System.map-* etc etc
<lool> ok, but u-boot is usually in /usr/lib?
<ogra> it tries to create backup files using hardlinks
<ogra> lool, well, we could call it /boot/bootloaderpartition if that makes it clearer
<ogra> i made up /boot/uboot
<lool> ogra: Can't we have anything which needs to have hardlinks in /boot and have /boot be in extN?
<ogra> the point is that we cant have /boot on vfat ... and that the bootpartition needs to be mmcblk0p1
<ogra> lool, nope, omap uboot doesnt support ext2
<ogra> we talked about it in nice and thats supposed to be fixed at some point
<ogra> but not atm
<lool> ogra: Ok; dont we flash the kernel in NAND?
<ogra> no
<ogra> we use SD for booting
<ogra> similar to imx51
<ogra> but with a real vfat partition
<ogra> so that partition should have an fstab entry
<lool> ogra: So the NAND stuff is for post 10.04?
<ogra> yeah
<lool> ogra: Would I be you, I would find it much more easy and clean to implement the NAND stuff right now
<ogra> lool, i have a working kernel since noon today :) i'm trying what i can
<lool> I think in terms of coming up with a working design and such, the vfat approach is horrible
<ogra> it is
<ogra> its quick though
<lool> Also, we will dump it after 10.04!
<ogra> and i only have a few hours left
<ogra> yes
<lool> Upgrades will be disastrous
<ogra> thats was the plan from the beginning
<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
<ogra> thats handleable
<amitk> besides all x86 flavours and fsl-imx51 use it already
<lool> amitk: Oh you mean it's not easy to switch from suggests to recommends?
<ogra> amitk, yes, all i want is the same imx51 does
<lool> amitk: It doesn't matter then
<amitk> lool: it is probably easy, I don't know enough about the ramifications...
<ogra> lool, i think the other way round
<ogra> currently it is a recommends
<lool> ogra: I understand, was justan example
<ogra> in imx51 at least
<lool> amitk: No need to worry about it
<ogra> yerah
<lool> we can visit Recommends -> suggests later
<ogra> just go for it
<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
<lool> ogra: So back to your vfat issue
<ogra> lool, yeah :)
<lool> ogra: flash-kernel was initially meant to flash stuff to NAND
<lool> ogra: It's really meant for that
<ogra> i know
<ogra> but mtd is totally untested with our kernel
<lool> ogra: I would find it easier to just implement that instead of this complex SD setup
<ogra> SD works
<lool> ogra: is it hard to test?
<ogra> no idea
<ogra> i have not much experience with mtd ...
<ogra> and if i trash my board now we're screwed
<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
<lool> ogra: you can't really trash it
<lool> ogra: you can always press user button and boot from SD
<amitk> we'd have to setup partitioning to use mtd and something like ubifs?
<ogra> i dont have *many days*
<lool> amitk: No need for a FS
<lool> amitk: it's just for kernel + initrd
<ogra> i have a few hours
<lool> ogra: Exactly, so would I be you, I would pick the simplest thing being NAND
<ogra> the simplest thing is SD for me
<ogra> since i have experience with that and dont need to start to learn while implementing
<ogra> it just butt ugly
<lool> You're in trouble IMO
<ogra> i am
<ogra> that was supposed to land a week ago
<ogra> but i didnt have anything to work with
<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
<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?)
<ogra> it should create one device for each partition
<ogra> lool, ogra@ubuntu:~$ ls /dev/mt*
<ogra> ls: cannot access /dev/mt*: No such file or directory
<ogra> no mtd support ...
<lool> ogra: For SD; I dont understand enough details of the problem; I suspect it impacts partman which is complex and picky
<ogra> lool, it will be a hack in flash-kernel-installer at this point of time
<ogra> surely not partman at all
<lool> amitk: Do you know why we miss MTDs in the kernel support?  Is this missing drivers, missing config, bug...?
<lool> ogra: "lol"
<lool> ogra: Ok; so here's what I would propose
<lool> ogra: That will make your like easy to some extent
<ogra> ok
<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
<ogra> right, i was planning to
<ogra> essentially planned to steal from imx where i can ... apart from the fstab stuff
<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
<lool> I don't really like /boot/uboot, but it could work
<ogra> well, another option would be mcopy to the partition file
<lool> In reality, it should be /boot but it's too hard to move our files around
<lool> ogra: I suspect you're taking risks by using mcopy
<ogra> yeah, probably
<lool> a) requires to ensure dosfstools is installed, new dep in multiple places
<ogra> but it would overcome the fstab issue
<lool> b) what happens if the partition is also mounted?
<lool> For fstab you have two options
<ogra> hmm, right
<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.
<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
<ogra> right, thats the /boot/uboot approach
<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
<lool> amitk: I think it's desirable, so please include it
<amitk> ogra: you'll have another kernel to test and confirm then (for flash support)
<ogra> lool, ok thats a bit more code than adding the following to flash-kernel-installer
<ogra>         mkdir /target/boot/uboot
<ogra>         uuid="$(block-attr --uuid /dev/mmcblk0p1)"
<ogra>         echo "$uuid vfat defaults 0 0" >>fstab
<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
<ogra> well, /target/etc/fstab ... but essentially that
<ogra> lool, it doesnt
<ogra> we have a bit more freedom in all places were we dont touch other arches code
<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
<ogra> the above is surely the most minimal, quickest but also hackiest approach
<lool> a) you don't actually need an fstab entry b) it's very risky to touch it
<lool> ogra: did you check whether the installer actually creates an entry for you already?
<ogra> you mean i should better deal through flash-kernel with temporary mounting/unmounting ?
<lool> It might be creating entries not mounted by default for other-os partitions
<ogra> it doesnt
<lool> ogra: yes; but if you do mount/umount, check that the fs isn't mounted somewhere else first
<ogra> i added all omap realted code the last two days there isnt anything magic in it yet
<ogra> *any
<ogra> thats all 10.10 or for the interim
<ogra> indeed
<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
<ogra> lool, i'm scared to miss the freeze
<ogra> and that code touches other arches code
<ogra> lool, http://paste.ubuntu.com/414411/
<ogra> thats flash-kernel-installer
 * ogra needs a break and actually some breakfast ... i havent eaten today
 * amitk hands ogra his all-day liquid diet
<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
<lool> ogra: on that note I need to drop off
<ogra_cmpc> lool, thanks a lot
<ogra_cmpc> root uuid only has a meaning for boot.scr
<ogra_cmpc> but i think i'll just create that on the go in flash-kernel-installer
 * persia idly notes that not all hardware has NAND
<rsalveti> persia: at u8500 u-boot is loading the kernel and initrd from the emmc (bigger and chipier)
<rsalveti> Show romanization
<rsalveti> cheaper
<rsalveti> argh
<rsalveti> my logitech mouse is not working as it was before
<persia> rsalveti: That's an example, indeed :)
<rsalveti> persia: i think it's 8gb
<rsalveti> so you can put the whole system there, besides the kernel
<rsalveti> much like a desktop
<persia> rsalveti: Ought be indistinguishable from any SD boot (e.g. booting my amd64 laptop from SD).
<persia> But that depends, of course, on the bootloader :)
<rsalveti> yeah, sure
<sveinse> ogra, did you discover the kernel/initrd issue?
 * sveinse is nosse1@home
<amitk> ogra: people has the (hopefully) final kernel. Will upload after confirmation that it works for you.
<sveinse> amtik, did you have to change the kernel today? I.e. are we looking at a ti-omap -6 ?
<amitk> sveinse: yes, several config changes to make the install process work fine (mtd, framebuffer console, rtc driver, etc.)
<sveinse> amtik, then I can try it once more on my EVM tomorrow then
<amitk> sveinse: I doubt it will help a lot over -5 since I don't really have any EVM hardware to enable..
<amitk> perhaps we'll be able to add more support when we get more boards after release
<sveinse> amitk, well I can try at least. It's not the end of the world if doesnt work though
<amitk> sveinse: sure :)
<sveinse> may I ask the exact nature of the initrd boot issue ogra was working on when I left?
<amitk> the boot would stop somewhere in the initramfs
<sveinse> Because it is very similar to the symptoms I'm seeing on the AM3517-EVM, you see
<rsalveti> I also had this problem yesterday when trying it on u8500
<amitk> it turned out to be missing FRAMEBUFFER_CONSOLE support
<ogra_cmpc> well, in combination with mountall :)
<rsalveti> yeah, probably the issue I had was with mountall
<amitk> right, the actual bug was in mountall
<amitk> but didn't show up because of lack of FB support :)
<ogra_cmpc> cat > /etc/e2fsck.conf << EOF
<ogra_cmpc> [options]
<ogra_cmpc> broken_system_clock = true
<ogra_cmpc> EOF
<ogra_cmpc> thatsthe proper fix btw :)
<amitk> nice, no /lib/init/fstab hacking then :)
<ogra_cmpc> i'll see if we can make that a default on beagle
<ogra_cmpc> since we definately wont have a battery
<rsalveti> cool, will try it when I get home
<ogra_cmpc> its less evil than fstab hacking .... it will still check the filesystem ... but ignore the clock
<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?
<ogra_cmpc> yep
<sveinse> Will the arm release follow the same release schedule (RC then release) as the main release plan?
<ogra_cmpc> yes
<ogra_cmpc> for now at least
<sveinse> and it will be LTS?
<ogra_cmpc> no
<amitk> sveinse: there isn't anything worth an LTS in here yet :)
<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.
<sveinse> Our product is designed for a market lifetime of 5 yrs (2017) after launch.
<persia> sveinse: Even if 10.04 *was* LTS it wouldn't last until 2017.  12.04, if an LTS, would last that long.
<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
<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.
<rcn-ee>  ogra, is the  "broken_system_clock = true" /etc/e2fsck.conf setting official for going forward now? (lucid -> lucid+1)
<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.
<ogra_cmpc> rcn-ee, well, i'm still discussing soemthing like a cmsdline option with Keybuk in -devel
<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).
<ogra_cmpc> rcn-ee, i guess for 10.04 it will be our best option but we'll discuss a better solution at UDS
<sveinse> But we will use Ubuntu for deployment and upgrade. And drive the userspace system as well
<rcn-ee> okay, nothing official yet.. ;)  I'll wait before i rewrite the scripts..
<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).
<sveinse> persia, not the kernel, no. Because we're running custom HW which mandates custom kernel anyways
<ogra_cmpc> rcn-ee, its the most official thing we have
<rcn-ee> of course, by 10.10, all the old beagles will be long gone, and everything should have spots for battery hookups. ;)
<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.
<ogra_cmpc> amitk, http://paste.ubuntu.com/414443/ (tring to reboot into the new kernel)
<sveinse> With Ubuntu, it is now possible to achieve this goal
 * ogra_cmpc climbs upstairs to hot the reset buttomn
<ogra_cmpc> *hit even
<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...
<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.
<persia> ogra_cmpc: "hot" is probably also correct, although implies a lower level of hardware hackery :)
<ogra_cmpc> heh
<amitk> ogra_cmpc: this is on bootup?
<sveinse> persia: and like you said, we can probably switch/participate on 12.04 as well and follow that when the time is right
<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.
<ogra_cmpc> amitk, no that was on shutdown
<ogra_cmpc> amitk, i'm in the new kernel now seeing mtd[0-9] and mtdblock[0-n]
 * ogra_cmpc tries another reboot
<sveinse> persia, like the state of the art armel is called Cortex-A42 and not compatible with A8...
<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
<persia> .04.
<ogra_cmpc> amitk, this time it worked, i'll try another reboot if i'm sure dpms kicked in
<ogra_cmpc> (like in 10min)
<persia> sveinse: Right.  Such a massive change would make 10.04 unsupportable in e.g. 2013, but I think that's unlikely.
<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
<ogra_cmpc> apw, kernel looks good so far i dont think its urgent to have the upload in tonights image though
<apw> ogra_cmpc, cool then i'll await your 'go/no-go'
<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
<persia> sveinse: Hrm.  That gets tricky.  I'm expecting FF for 12.04 in Q4 2011.
<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
<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.
<ogra_cmpc> well ...
<ogra_cmpc> depends how you will define embedded in five years
<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
<ogra_cmpc> i guess thne you are at the state of a normal low powered laptop of today
<sveinse> our system is speced with 512M/1G NAND, so it will work, but not with too great margin (considering the space at least)
<ogra_cmpc> rcn-ee, did you manage to capture any backtrace from apt ?
<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
<persia>  needs to do,and the code does that.
<persia> sveinse: 1G NAND is tight.  Any chance that could be 2G?
<persia> (or emmc works)
<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.. ;)
<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
<sveinse> Perhaps 2G SLCs are becoming more common now
<ogra_cmpc> rcn-ee, pfft 9.10 ... thats so old
<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.
<ogra_cmpc> rcn-ee, i just remembered it because i see kirkland in #ubuntu-devel
<ogra_cmpc> (he's our qemu maintainer)
<persia> (and for general use we really recommend 4G, but 2G works, if necessary)
<rcn-ee> I know.. ;)  but since i release images on rcn-ee.net i need to half ass support them before the next release.. ;)
<persia> rcn-ee: Only two more weeks :)
<ogra_cmpc> persia, well, if i can make it :P
<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.
<rcn-ee> thanks, ogra, i'll watch ubuntu-devel for any hints...
<ogra_cmpc> amitk, so i get the same oops after waiting 10min
<ogra_cmpc> amitk, i guess there is an issue with dpms
<ogra_cmpc> apw, ^^^^
<persia> sveinse: How do you strictly control the packages?  Is there no UI available?
<persia> sveinse: I'm all for folks using Ubuntu in products, but I worry that we may not be able to meet that requirement.
<sveinse> persia, no Ubuntu UI (gnome/kde), only our application.
<rcn-ee> persia, can't wait, specially with daily X-loader/U-boot changes happening in Angstrom right now.. ;)
<sveinse> persia, is there a problem with that?
<persia> (if nothing else, someone can spoof their local DNS, and swap a package name so the automatic updater installed e.g. ubuntu desktop)
<ogra_cmpc> rcn-ee, we dont touch uboot/x-loader in 10.04
<persia> sveinse: I can work around it in 20 minutes.  If that's acceptable to you, then there's no problem :)
<ogra_cmpc> we just rely on them being in NAND
<sveinse> persia, we won't associate ubuntu into this. At least not visibly. We must, however due to copyright and source references of course.
<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
<persia>  right base.
<sveinse> persia, I think that's fine. The product we're building is training equipment for emergency medical personel.
<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
<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.
<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
<sveinse> The only thing we keep to our chest til the business logic
<persia> sveinse: Yeah.  Just wanted to make sure.  Some regulatory regimes for some classes of equipment don't allow that, which makes it tricky.
<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
<persia> Oh, good point.  I always forget about the GPLv3 restrictions.
<ogra_cmpc> hmm
 * ogra_cmpc wonders how to put initrd into nand on beagle
<sveinse> ogra_cmpc, if it's the same as the AM3517-EVM, its a specific region in the NAND
<sveinse> ogra_cmpc, http://elinux.org/BeagleBoardNAND
<ogra_cmpc> sveinse, thats what i'm reading atm
<ogra_cmpc> but it diesnt have an explicid initrd partition
<sveinse> ogra_cmpc, ummm.. it doesn't mention initrd, no
<ogra_cmpc> i guess i need to use the filesystem one
<sveinse> Hold on, I'll dig up the descr for the AM3517
<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 ;)
 * sveinse is wondering if the partition table is hardcoded into u-boot...
<ogra_cmpc> rcn-ee, no way ... amitk would kill me if i requested any change now
<rcn-ee> i know.. ;)  I'm keeping my mouth shut too..
<ogra_cmpc> heh
<persia> sveinse: It's not.
<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...
<ogra_cmpc> i'm still pondering to use NAND now that i have it actually
<ogra_cmpc> though i need to find the right runes for the uboot env and for initramfs
<amitk> ogra_cmpc: please file the bug and I'll start looking
<ogra_cmpc> amitk, which one ? dss2 ?
<amitk> ogra_cmpc: so you get identical oops for halt and dpms?
<amitk> right, the dss2 one
<ogra_cmpc> amitk, for halt when dpms is active
<ogra_cmpc> oh, i guess you meant reboot :)
 * ogra_cmpc didnt try halt yet
<ogra_cmpc> amitk, yes, just tried, halt and reboot
 * ogra_cmpc sighs and climbs the stairs once more
<persia> ogra_cmpc: If you have another machine up there, consider a USB-controlled switch :)
<persia> (mind you, this may cause you to inadvertently gain weight)
<ogra_cmpc> i need a relais to press the reset button
<ogra_cmpc> i usually dont work from the living room :)
<ogra_cmpc> no danger of gaining weight :)
<amitk> ogra_cmpc: so no-go for upload, right?
<DanaG> hmm, is there another -500-omap kernel now?
<amitk> DanaG: there will be by tomorrow
<DanaG> And I did notice that you'd put not only musb_hdrc, but also g_ether (and nothing else) into the kernel.
<DanaG> I wish there were a way to compile-in all the gadget drivers, and select via sysfs which one gets to be active.
<DanaG> Either that, or have the musb_hdrc built-in but g_* as modules.
<amitk> DanaG: I did that but ogra_cmpc reported that it killed his EHCI-connected peripherals
<amitk> I have to investigate what is going on...
<DanaG> Weird.
<amitk> OTG might be fixed as an SRU (after release next week)
<DanaG> I also have some weird behavior with my asix.
<amitk> asix seems to work just fine here
<DanaG> It doesn't work when plugged in during boot.. I have to unplug and replug the usb+ethernet thingy for it to work.
<amitk> the USB code is all plain 2.6.33 mainline
<DanaG> I can sniff packets with tshark, and get literally zero.
<amitk> huh
<DanaG> And yet it thinks it's up.
<amitk> there is definitely something up with the usb stack of omap3 in 2.6.33 mainline.
<DanaG> oh yeah, and I did get a log of plymouth (in this case, on my host) refusing to show splash.
<DanaG> www.csc.calpoly.edu/~dgoyette/amtterm.log
<DanaG> console=ttyS0 console=tty0
<ogra_cmpc> amitk, well, its your reputation ... upload if you feel like
<ogra_cmpc> amitk, apw, i'm happy with the functionallity for now if you guys feel ok with an oops on shutdown/reboot ...
<apw> ogra_cmpc, /me is just the monkey which pushed the buttons ...
<ogra_cmpc> amitk, just note that slangasek just said 0000 UTC is freeze time
<ogra_cmpc> ah, you just asked the same :)
<goshawk> can i make ubuntu arm running on a Processor       : ARM926EJ-Sid(wb) rev 5 (v5l) ?
<Stskeeps> armv5te, so only ubuntu 9.04
<goshawk> oh hi Stskeeps
 * NCommander waves to Stskeeps 
<Stskeeps> 'lo
<goshawk> Stskeeps: why only 9.04?
<Stskeeps> 9.10 is for armv6+vfp
<Stskeeps> and next step again would be armv7
<goshawk> k understood
<goshawk> 9.04 is enough
<goshawk> do you have a rootfs ready somewhere?
<Stskeeps> Mer?
<Stskeeps> :P
<goshawk> Stskeeps: are you collaborating with ubuntu-arm too?
<goshawk> Stskeeps: well a mer image could be good too
<Stskeeps> nop, i'm in the meego camp now
<persia> Mer would be *lovely* but it proves exceedingly difficult to integrate with Ubuntu, unfortunately.
<goshawk> can i run rootstock from my x86 machine and have a generated armel rootfs ?
<goshawk> it does not seem clear from this infos: https://wiki.ubuntu.com/ARM/RootfsFromScratch
<persia> goshawk: That is indeed the central usecase for the existence of rootstock.
<ogra_cmpc> sigh
<ogra_cmpc> so lool was right, NAND would be trivial
<ogra_cmpc> but i cant change the bootargs to actually load an initramfs or to change the cmdline
 * ogra_cmpc cires
<ogra_cmpc> *cries too
<ogra_cmpc> oh man
<ogra_cmpc> that would be so easy
<ogra_cmpc> sigh, why does redboot appear so much easier every time i try to do something with uboot that goes beyond the defaults
<prpplague> hey who was using the AM3517 here?
<ogra_cmpc> prpplague, nosse1_away
<prpplague> ogra_cmpc: ahh thanks
 * ogra_cmpc wonders if anyone ever tried to cat boot.scr into the u/boot mtdblock partition and if that would work
<Martyn> it doesnt
<amitk> ogra_cmpc: calling it a day...
<ogra_cmpc> amitk, did you upload anything ?
<ogra_cmpc> apw, ??
<apw> ogra_cmpc, i was about to hit return on it
<ogra_cmpc> ok
<apw> ogra_cmpc, happy ?
<ogra_cmpc> justwanted to make sure
<ogra_cmpc> apw, far from beimng happy but i'm ok
<ogra_cmpc> i still have a very long night ahead to implement what should have happened a week ago
<apw> ogra_cmpc, sorry if that is my fault ... i hate working late too
<ogra_cmpc> apw, not your fault
<ogra_cmpc> circumstances
<ogra_cmpc> asac, can we get a last munite MIR ?
<ogra_cmpc> *minute
<cwillu_at_work> hmm, libcairo2 fails to build from source on karmic afaict
<mpoullet> good morning
<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
<asac> ogra_cmpc: which one?
<ogra_cmpc> asac, heh, not filed yet
<ogra_cmpc> asac, uboot-envtools (two commands in the package)
<asac> ogra_cmpc: what for ?
<asac> omap?
<ogra_cmpc> with that i could write kernel/initrd to NAND and have proper env variables set on beagle
<ogra_cmpc> yeah
<asac> ogra_cmpc: where would the impl change land? flash-kernel?
<ogra_cmpc> flash-kernel-installer and flash-kernel, yes
<asac> whats the risk?
<ogra_cmpc> flash-kernel-installer would actually be the tool making use of the commands
<ogra_cmpc> zero ?
<asac> uboot-envtools is definitly perfect ;)?
<ogra_cmpc> we wipe the NAND and replace the default setup with our vars
<ogra_cmpc> no idea if its perfect
<ogra_cmpc> its fw_setenv and fw_printenv
<ogra_cmpc> doesnt contain much more (some docs)
<ogra_cmpc> so the idea is: flash-kernel-installer uses fw_setenv to set bootcmd and bootparms as well as bootdelay
<ogra_cmpc> flash-kernel cats uInitrd to the Kernel mtd device and cats uInitrd to the filesystem mtd device
<ogra_cmpc> the bootcmd we set before automatically loads uImage and uInitrd and execs bootcmd then
<ogra_cmpc> that drops the requirement fo a SD card
<ogra_cmpc> we can boot directly from USB
<ogra_cmpc> and dont need vfat /boot
<ogra_cmpc> asac, bug #563394
<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
<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 ;)
<asac> also add -g so we get debug symbols
<asac> that to debian/rules
<asac> also all the CONFIG_ variables are nowhere configured
<asac> does that mean we want empty default?
<ogra_cmpc> oh, sigh
<ogra_cmpc> thats a lot of changes
 * ogra_cmpc will be busy with flash-kernel until the freeze kiscks in
<ogra_cmpc> and i'm nit even sure i can make that one
<ogra_cmpc> *not
<ogra_cmpc> i didnt expect it to be that bad
<asac> ogra_cmpc: any words when freeze will kick in?
<asac> in 1h or rather 12 ;)
<ogra_cmpc> 0000 UTC
<ogra_cmpc> i'm unlikely to make it with flash-kernel
<ogra_cmpc> (and i'm up since 6am ... cant even tyype straight)
 * DanaG wishes ubuntu had an official arm cross-compiler.
<ogra_cmpc> see /topic :)
<Martyn> DanaG : What do you mena?
<Martyn> mean?
<Martyn> OH .. well, yeah
<Martyn> nice thing about building natively on the buildd machines
<DanaG> Oddly enough, there _does_ seem to be an official ppc compiler.
<DanaG> er, ppc cross-compiler.
<ogra_cmpc> phew
<ogra_cmpc> so i got a working NAND implementation
<ogra_cmpc> ogra@ubuntu:~$ sudo flash-kernel
<ogra_cmpc> [sudo] password for ogra:
<ogra_cmpc> Generating kernel u-boot image... done.
<ogra_cmpc> Erasing Kernel NAND space... done.
<ogra_cmpc> Flashing kernel... done.
<ogra_cmpc> Erasing Initramfs NAND space... done.
<ogra_cmpc> Flashing Initramfs... done.
<ogra_cmpc> ogra@ubuntu:~$
<Martyn> ogra : What platform?
<ogra_cmpc> buti wont make flash-kernel-installer in time i guess
<ogra_cmpc> lool, ^^^ fyi
<ogra_cmpc> Martyn, omap
<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...
<Martyn> I think we can do better than that :)
<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...
<rcn-ee> Martyn, do you have a git tree for your current multi arm work?
<Martyn> rcn-ee : Yes, internally at smooth-stone
<Martyn> rcn-ee : Not even ready for an -mm release
<DanaG> hmm, so is the idea now to nand-flash the ubuntu kernel and initramfs?
<DanaG> What about the beagle-xm, which may be sans NAND?
#ubuntu-arm 2010-04-15
<lool> DanaG: lol
<lool> DanaG: Yeah, it will definitely we without NAND
<rcn-ee> DanaG, they ubuntu is currently only targeting C4... ;)
<DanaG> Now, if u-boot had ext4 support, that would be pure win.
<rcn-ee> if u-boot had any extX support.. ;) (that worked)
<lool> u-boot needs to be read from somewhere too
<lool> rcn-ee: ISTR we're using ext2 support in the dove images, not quite sure anymore
<lool> problem is that we still need to load u-boot from MMC I guess
<lool> so with vfat
<lool> because the ROM will load it
<rcn-ee> i know what you mean, i a couple other boards (avr32, etc) that has no problems with extX partitions running mainline u-boot.. Only the beagle has issues...
<ogra_cmpc> lool, http://paste.ubuntu.com/414595/ ... i need uboot-envtools in main and integrate it into flash-kernel-installer (for cmdline/root UUID etc), but it apparently works well already
<Martyn> rcn-ee : Right now the bulk of the work I'm doing is getting the smooth-stone SoC supported, and trying to figure out ways of recycling as much of the ARM tree in an abstracted way to do it
<ogra_cmpc> lool, thanks so much for poking me towards NAND
<DanaG> oh... right, you do still need fat32.
<DanaG> It's a chicken-and-egg problem.
<rcn-ee> Of course Martyn, cant' wait to see what that board can actually do. ;)
<DanaG> Can't read u-boot itself from ext4, anyway.
<Martyn> rcn-ee : One of the big problems, at least for me, is that Grant Likely device tree patches aren't going to make it in until mid 2.6.35, even .36
<Martyn> rcn-ee : Coming to Brussels?
<DanaG> I wonder if you could fit u-boot in an MBR.
<Martyn> DanaG : No.  i've tried
<DanaG> Bummer.
<Martyn> DanaG ; The problem is keeping it under 63 sectors (512bytes*63)
<rcn-ee> Nope, not across the pond anytime soon, but i will be in esc san jose..
<lool> ogra_cmpc: eh
<ogra_cmpc> rcn-ee, thats a shame !
<rcn-ee> DanaG, actually someone did intergrate X-loader into u-boot as a side project... can't remember how many months back on the beagleboard group...
<ogra_cmpc> lool, i got a freeze exception until fri. btw
<Martyn> rcn-ee : Pity .. I'm bringing a prototype of sorts
<ogra_cmpc> for that bit at least
<Martyn> rcn-ee : nVidia is helping :)
<rcn-ee> what? no way! ;)
<rcn-ee> i know they are kinda betting on the tegra platform, so it makes some sense...
<DanaG> now, a Tegra netbook could be cool.
<Martyn> rcn-ee : Heh .. true.  Although I feel kind of guilty being one of the reasons the tegra2 200 platform is hard to get right now
<DanaG> I may not much like nvidia... but at least I'd probably be able to use compiz on the thing.
<DanaG> ... as opposed to PowerVR.
<Martyn> DanaG : I already saw four prototype 'smartbooks' based on the tegra2 .. but the 200 has some problems with Mini PCIe
<Martyn> (weak ordering is supported, strong ordering is not, which breaks the PCI driver in linux_
<Martyn> DanaG : Try the more exciting idea -- the potential for using CUDA
<rcn-ee> Your just helping to get things supported before everyone starts yelling about the issues...
<DanaG> hmm, weak ordering?
<Martyn> DanaG : Yeah.
<DanaG> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg02948.html
<rcn-ee> i just want a PCI-E, then stick ati/nouveu based card into it.. ;)  the open-rd was interesting, but backordered..
 * ogra_cmpc falls dead
<Martyn> ogra :Sleep time?
<Martyn> DanaG : Bingo
<DanaG> Sucks that the Base and Client have different sets of I/O.
<Martyn> and because the assumption is strong ordering (where the tegra2 demands weak ordering) ... we get brokenness all over the place
<DanaG> I want a superset of both... "client" without the onboard IGP, with PCIe slot.
<DanaG> hmm, still doesn't quite say what strong / weak ordering is.  Is it presence or lack of specific instructions?
<rcn-ee> Oh ogra, found another device with no battery backed rtc...  The Always-innovating touchbook doesn't have a backup battery...  There's a mod on their wiki to add one...
<Martyn> think of it as the difference between TCP and UDP
<Martyn> TCP ensures that the order of packets is perserved and checked
<Martyn> UDP .. ordering is -not- guaranteed or checked
<DanaG> ah, but instead of packets, it's "things you tried to fetch from memory"?  (would have to include a sequence marker, of course.)
<Martyn> something like that
<Martyn> there are entire chapters in my PCI book dedicated to the subject
<DanaG> hmm, that reminds me of something I had thought would be interesting: use a PCIe FPGA to do all sorts of stuff.
<DanaG> Something I wanna' see: http://www.sondigo.com/sirocco/overview  -- something like that, but with 2.6 kernel.
<DanaG> It's a c-media PCI audio chip on a Realtek Lexra MIPS CPU.
<DanaG> Most ARM SOCs don't have surround sound.
<Martyn> .. thinks
<Martyn> NO ARM SoC's have surround sound yet, that I can think of
<Martyn> I don't even think the Tegra2 is more than 2.1
<DanaG> yeah, I realized that after I spoke / typed / pressed enter.
<DanaG> http://landley.net/notes-2009.html
<philo> hi
<philo> i need a simple way to setup a virtual machine with ubuntu-arm running it... can anyone point me to some doc ?
<ogra> philo, see topic :)
<aaron_liuj> my board have two output hdmi and lcd ,but it's default out lcd ,how to change it to hdmi display
<aaron_liuj> need i modify the frame buffer ?
<amitk> aaron_liuj: what board is it?
<aaron_liuj> arm
<aaron_liuj> one type arm board
<aaron_liuj> 2 output device , but default is lcd ,i want change it to hdmi tv
<aaron_liuj> how to do that ?
<amitk> aaron_liuj: I'm afraid we need more info than that. What processor does it use? Is it a custom board, etc..
<aaron_liuj> tcc8900
<aaron_liuj> but the i have he right worked hdmi driver
<aaron_liuj> but the i have the right worked hdmi driver
<aaron_liuj> but i don't know how to change the default output device
<amitk> aaron_liuj: that is not an SoC that is supported by Ubuntu, so I'm not familiar with its drivers
<aaron_liuj> i think it's vary samilar with pc have vga and hdmi port
<aaron_liuj> i think it's very samilar with pc have vga and hdmi port
<aaron_liuj> i think it's very samilar with pc have vga and dvi, hdmi port
<amitk> it is probably in the framebuffer driver options somewhere
<DanaG> telechips?
<DanaG> hmm, my Cowon S9 has some telechips thingy of some sort.
<amitk> never heard of them before
<aaron_liuj> yeah from telechips
<NCommander> aaron_liuj: ususally its a kernel command line option, or if you just care about X, you might be able to get by with just xrandr, but I can't tell you the specifics
<NCommander> Martyn: dove has surrond sound
<ogra> hrm, so broken_system_clock in e2fsck.conf doesnt help :(
<saeed> hi there
<saeed> ogra: hi
<ogra> hey saeed
<saeed> I would like to boot lucid on dove with console on serial
<saeed> it would be very usefull if we can append args to bootargs of the boot.scr
<ogra> saeed, that will breake the splash screen on all desktop installs, do you  want that ?
<ogra> plymouth sadly breaks once a console= option is on the cmdline and wont display any splash anymore
<saeed> ogra: what is splash sceen?
<saeed> ok, I googled it
<saeed> anyway, the console option will be added only for debug
<ogra> heh, its the progressbar screen you see on boot of ubuntu desktop systems
<saeed> also, we may add other options
<ogra> it's a bit late to change these options, we need to talk to the release team given that final freeze was yesterday
<ogra> how confident are you that they are 100% not causing any problems (the additional options i mean)
<saeed> I see, please consider it for next release
<ogra> we'll do, we can get a freeze exception but it must be a 100% bulletproof change
<ogra> if the images get unbootable due to some cmdline option you request thats a disaster
<saeed> ogra: I'm not looking to add permanent options to the cmdline
<saeed> only temporary options for debugging specific issue
<ogra> you can easily change boot.scr yourself
<ogra> if its only for you for debugging
<ogra> just grab it, remove the binary header, save it as boot.script and edit bootargs to your liking
<ogra> then run: mkimage -A arm -T script -C none -n "Ubuntu boot script" -d <path to your boot.script file> /boot/boot.scr
<ogra> its trivial
<saeed> ok
<nosse1> Morning everyone
<aaron_liuj> good night all
<lool> ogra: I think saeed was just asking for a local workaround
<ogra> lool, yeah, i didnt get that
<lool> saeed: What we kind of miss is some UI to offer multiple kernels and versions with options
<lool> saeed: Could probably be done with the soft bootloader PoC, or some other bootloader like petitboot and such
<lool> saeed: But locally you could regenerate boot.scr or break into u-boot I guess?
<saeed> lool: I used to create my own bootcmd based on the boot.scr one, I also tried to modify the boot.scr as ogea suggested. both methods work
<saeed> however, if the next release is comming with softbootloaded, then that will be great
<saeed> btw, what is the status of the softloader?
<saeed> Ncommander worked on that, right?
<amitk> lool: atleast openmoko uses a u-boot that supports menu entries IIRC
<lool> saeed: No it's not coming with softbootloader
<lool> saeed: I think ogra and NCommander had a working proof of concept, but I'm not sure what prevented its wider use; for a long time kexec was badly broken
<lool> saeed: Perhaps the kexec breakage prevented its use?  Not sure
<lool> saeed: project name is now https://launchpad.net/mukluk
<saeed> look: issues with kexec were fixed
<amitk> http://wiki.openmoko.org/wiki/Booting_from_SD#Add_uboot_boot_entry
<lool> So I cant comment in place of NCommander and ogra
<ogra> lool, kexec broke suspend/resume on most arches we added it ...
<ogra> i think it was withdrawn from most of our kernels again until thats better understood by the kernel guys
<ogra> amitk, since you are affected by bug 563618, would you mind to confirm it ?
<ubot4`> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "there is no way to tell fsck to ignore broken clocks on embedded systems (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/563618
<ogra> else Keybuk will close it immediately again and tell me its fixed :)
<amitk> ogra: done
<ogra> thanks :)
 * ogra waits for dpms to kick in so he can reproduce the DSS2 bug finally
<nosse1> ogra, does the new ti-omap -5 cover the changes you made to the kernel yesterday?
<nosse1> comparing to the -4 config, there doesn't seem to be anything changed related to console
<amitk> nosse1: that isn't built yet... long backlog of arm packages just before freeze
<amitk> https://edge.launchpad.net/ubuntu/+source/linux-ti-omap/2.6.33-500.6/+build/1692899
<nosse1> amtik, thanks. I can extract the config from those sources
<amitk> nosse1: use tab for my nick :)
<nosse1> amitk, sorry. Didn't mean to offend. I've tried using the tab, but maybe this isn't a function in chatzilla
<amitk> nosse1: none taken, just trying to point you to a (timesaving) feature. :)
<nosse1> trust me, I have been looking... ;)
<saeed> ogra: I'm trying to debug the hibernate issue https://bugs.launchpad.net/bugs/509006
<ubot4`> Launchpad bug 509006 in linux-mvl-dove (Ubuntu Lucid) (and 1 other project) "[dove] hibernation failed to resume (affects: 2) (heat: 12)" [High,Confirmed]
<saeed> I suspect that the issue is that the initramdisk mounts the root partition before doing the resume
<lool> saeed: You can break into the initrd by passing extra args
<lool> saeed: break=top break=bottom etc.
<lool> saeed: if you unpack an Ubuntu initrd and grep for maybe_break, you should see all the possible break points
<saeed> lool: thank, I'll try it
<ogra> or look under /usr/share/initramfs-tools
<ogra> (easier than explicitly unpacking)
<ogra> lool, http://paste.ubuntu.com/414821/
<ogra> lool, i have one prob left ... if you look below "Erasing Initramfs NAND space" you will notice that i use $kmtdsize (4MB) to erase the initramfs space
<ogra> lool, the default size of that space is just to big to erase it all ... without erasing we cant write (generates IO errors) what would you recommend to use for a erase size ? i was pondering to hardcode a value somewhere
<lool> ogra: You mean it's too slow to erase it all?
<lool> ogra: how large is it?
<ogra> yeah, its 2Gig
<lool> For Kernel?
<ogra> its the filesystem space for the rootfs originally
<ogra> no, kernel is 4MB
<lool> Who creates the Kernel partition?
<ogra> the kernel
<ogra> for a later release we need to sort that stuff in kernel
<ogra> but for 10.04 i doubt we can
<lool> Ok, there's a space for a rootfs and you use it for the initramfs
<ogra> right
<ogra> and its to big to erase it all
<lool> ogra: Can't you change the partitions to be sensible?
<ogra> takes 10-15min
<ogra> no, they are set in kernel
<lool> ogra: pointer?
<ogra> in the omap mtd driver actually
<ogra> lool, 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
<lool> thanks
<nosse1> amitk: Are there any other changes to the kernel except for config changes?
<lool> ogra: Could you possibly use the kernel part for both, or is it two small?
<ogra> for both ?
<ogra> whats both ?
<ogra> oh
<ogra> 4MB is definately to small
<lool> Yeah
<lool> ogra: So I have some ideas, but first could you explain where these IO errors come fronm?
<lool> I thought you could write whatever you like to mtdblock parts, the kernel will do the NAND flashing to 0xff for you if needed
<ogra> lool, no idea, i get them if i write to unerased space
<amitk> nosse1: no other changes, they'll happen after release as SRUs
<lool> ogra: I suspect it's a bug in the offset / size you're writing
<ogra> as soon as i zero it everything works flawless
<ogra> i got the offset sizes from the beagle docs
<ogra> they seem to be identical across all beagles
<lool> ogra: I would say you should have at least 16 MiB for the initrd data
<ogra> ok
<lool> for safety, you could go to something higher
<lool> like 64
<ogra> where would you put it ?
<lool> in the rootfs part
<ogra> in the script (i dont use flash-kernel.conf yet and would happily not)
<ogra> ok
<lool> ogra: how do you load the initrd ATM?
<ogra> nand load
<lool> certainly *some* components needs to be made aware of the actual size we care about
<lool> ogra: do you have control of that script?
<nosse1> amitk: How do you generate the .config? Cat everyting together from debian.ti-omap/config ?
<ogra> see the top part of my paste
<ogra> line 10-26
<ogra> it uses uboot-envtools to set the u-boot env
<lool> ogra: yeah, so you're essentially already listing the initnrd size
<ogra> right
<ogra> i have to change it in both places
<ogra> or would you suggest to parse bootcmd in flash-kernel ?
<lool> ogra: I guess that's ok; if would be nice if you followed the usual u-boot variables
<lool> beagleboard comes with a nice set of u-boot envs vars
<ogra> mine doesnt anymore :P
<ogra> after i played with the flash :)
<lool> ogra: Well if you were to use proper vars, it would be nice to parse in flash-kernel
<lool> e.g. (I'm not sure what exists already) initrd_nand_addr, initrd_nand_size etc.
<lool> ogra: you can reset the values to their defaults
<lool> resetenv or something
<ogra> ah, right
<lool> ogra: I suspect they don't use the rootfs as an initrd though
<lool> sorry initramfs
<lool> ogra: Perhaps it would be more elegant to just write what you need to write and use it as an initrd instead of initramfs?
<ogra> right
<ogra> there are no vars at all for initramfs usage
<ogra> nor for initrd
<lool> ogra: Hmm really
<ogra> yeah
<ogra> initrd isnt a concept on beagle
<lool> jffs2args=setenv bootargs console=${console} ${optargs} root=/dev/mtdblock4 rw rootfstype=jffs2
<ogra> even finding proper docs with google is painful
<ogra> right, thats for a rootfs
<lool> Oh it's certainly supported for sd
<nosse1> I see you changed the HZ. Why is that?
<ogra> nosse1, ??
<lool> ogra: So I'd introduce a nandinitrdboot or similar which would set root=UUID=something and load some configurable megabytes of the rootfs as an initrd; I'd read that value from flash-kernel to zero it
<ogra> ok
<lool> You can re-use rdaddr
<ogra> amitk, bug 563650 with kisses for you :)
<ubot4`> Launchpad bug 563650 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "DSS2 oops when shutting down while DPMS is active (affects: 1)" [Medium,New] https://launchpad.net/bugs/563650
<lool> I wonder whether it would be possible to point the kernel at the nand for the initramfs and unpack it in RAM
<ogra> lool, what scares me a bit is to rely to much on uboot-envtools
<ogra> lool, thats for 10.10 :)
 * ogra will already be happy if he ends up with a bootable *something* on lucid beagle ... given bug 563618 and Keybuks attitude towards the prob thats not looking good atm
<ubot4`> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "there is no way to tell fsck to ignore broken clocks on embedded systems (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/563618
<amitk> nosse1: right, cat together all of it
<amitk> ogra: thanks
<NCommander> saeed: softbootloader was blocked on lack of kexec()
<NCommander> saeed: kernel support landed too late for lucid unfortunately
<lool> ogra: i'm glad I told you 64 MiB because the usual ubuntu config is actually 4 MiB
<lool> *64
<ogra> i would have gone with 16 :)
<ogra> i dont think i have ever seen a bigger initramfs in my life
<lool> ogra: given that the size in the kernel config is 64 MiB, that would seem a prudent value to use
<lool> ogra: are you checking the file size before writing it?
<ogra> not explicitly, no but thats just a copy paste job
<lool> ogra: Make sure there's some check in place?
<lool> quoting is a bit inconsistent in your diff too
<ogra> check_size "Kernel" $(($kfilesize + 8 + 64)) $kmtdsize
<ogra> like that ?
<lool> apw: Would you be open to bumping the default ramdisk size in the dove config to 65536 instad of 4096?  :_)
<ogra> (stolen from QNAP)
<lool> ogra: something like that, I'm afraid I lack the specifics
<lool> ogra: note that you're actually writing an u-boot image which is slightly bigger than the initrd
<apw> lool, i think that is becoming the default on the other arm branches
<ogra> lool, indeed
<apw> i presume you mean for SRU
<lool> apw: Yes, it's the case in pretty much all other branches, not sure why not on dove
<lool> apw: I guess it's for $next-upload, SRU or late upload; happy either way
<lool> apw: I would like if it's in git and I can forget about this discrepancy  :-)
<apw> lool, as dove is in the can is there a bug as we'll need one to SRU the change
<lool> apw: no open bug, can file one now
<apw> lool thanks
<apw> assign it to me
<lool> apw: https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/563679
<ubot4`> Launchpad bug 563679 in linux-mvl-dove (Ubuntu) "CONFIG_BLK_DEV_RAM_SIZE should be 65536 as in other kernels (affects: 1)" [Undecided,New]
<apw> lool ta
<saeed> NCommander: what is the current status of mukluk
<NCommander> saeed: on hold. Will look at implementing for 10.10
<saeed> NCommander: does the current version partialy work?
<ogra> NCommander, what was the prob again with missing uboot-mkimage on certain dove installs ?
<ogra> NCommander, were these d-i based or live ones ?
<NCommander> ogra: live images, sometimes blew up due to network not being present
<NCommander> saeed: yes, but the script ot make the config file automatically is buggy
<ogra> NCommander, weird, i'm just looking at the redommends
<ogra> *recommends
<ogra> in ubiquity
<ogra> and uboot-mkimage is definately in the list so it should be inside the livefs
<ogra> oh
<ogra> it was added on Fri Mar 26
<nosse1> is there a link to the armel build queue somewhere?
<ogra> https://edge.launchpad.net/builders
<ogra> lool, erasing 64M is still taking more than 2min, i'll go with 16
<ogra> asac, so looking at uboot-envtools ...
<asac> ogra: thanks. and sorry i didnt fix it yet for you ;)
<ogra> asac, using make clean breaks because the quilt patches that clean up Makefile are not applied
<ogra> donty worry, i'm nearly done with all the omap stuff ... just needs that package
<ogra> asac, so, i cant easily fix up the build system without adding my completely own Makefile debian/patches has Makefile patches that need to be applied to exec anything at all but rules calls unpatch in clean
<ogra> i guess thats the reason for the rm commands in rules
<ogra> asac, laso it doesnt remove source files it seems but it removes the link
<ogra> asac, the missing config is caused because its actually a snipped from uboot, it would be configured during uboot build but the package here tries to be generic and thus ships only example configs
<ocs> hi, which is the cheapest arm-board where ubuntu can run ?
<rsalveti> ocs: beagleboard?
<rsalveti> ocs: you can get it for $150
<ocs> rsalveti: are you sure there are not cheaper ones?
<rsalveti> ocs: if you want to run lucid, then I guess it's the cheaper one
<ocs> rsalveti: lucid <--- ?
<rsalveti> otherwise if you are happy with older releases, you can get an armv5 or armv6 board
<rsalveti> ocs: ubuntu lucid, the next release
<ocs> rsalveti: thanks
<rsalveti> ocs: sheevaplug is cheaper ($99), but it's armv5
<rsalveti> ocs: you can run ubuntu 9.04 or debian
<rsalveti> or oe based distros, like angstrom
<ocs> rsalveti: but sheevaplug doesn't have a video connector
<ocs> right?
<rsalveti> ocs: yep, you're right
<ogra> rcn-ee, your /etc/e2fsck.conf works with mountall ?
<ogra> (note that mountall doesnt use e2fsck but fsck from util-linux which doesnt respect the config file)
<ogra> GrueMaster, did you test the d-i fix for the netinst images already ?
<ogra> (for dove)
<GrueMaster> Yes.  Netboot install now works.
<ogra> with the default initrd without having to fiddle with mkimage etc ?
<GrueMaster> I even wrote a little netboot.scr script for it that gets pulled via bootp.
<ogra> sweet
<GrueMaster> I used the latest images from http://ports.ubuntu.com/dists/lucid/main/installer-armel/20081029ubuntu98/images/dove/netboot/dove/ with out any modification.
<ogra> perfect, thanks
<GrueMaster> I'm still trying to figure out how to use the bootp protocol to send uboot commands.
<GrueMaster> But I don't think uboot supports it.
<ogra> probably not uboot, but kernel/initramfs should be able to read dhcp strings you send
<Martyn> Is there a list of packages that are -not- attempted to be built on ARM?
<armin76> libx86 :D
<armin76> s390-tools :D
<asac> Martyn: we have a architecture specific blacklist file yes. but dont ask me where ;)
<asac> ogra: ^^ where is pas?
<persia> asac: P-a-s isn't the entirety of it, really.  There's also package arch: fields.
<asac> persia: sure
<asac> but thats not in list form ;)
<persia> No, my point is that such a list doesn't exist.
<persia> And I know we attempt builds of silly stuff (e.g. libx86, wine1.2).
<persia> Anyway, https://code.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu
<Martyn> thanks :)
<Martyn> persia : That will do as a starting point
<persia> Martyn: patches accepted for that, if you think there's something listed as not-for-ARM that should be for ARM.  I had to unburden a number of packages when working on the lpia port.
<Martyn> right now, I'll take stability over coverage
<Martyn> smooth-stone is looking over all the packages, and building a blueprint for UDS-M
<Martyn> we're currently looking for a way to use eucalyptus either with LXC, or completely non-virtualized
<persia> That shouldn't be hard at all.
<persia> Just replace eucalyptus-nc with another component.
<persia> I strongly recommend chatting with kirkland or smoser in #ubuntu-server about it: they are likely to be able to share good strategies.
<persia> And I know at least one of them shares your timezone, which may make that easy :)
<persia> Actually, they're both there now :)
#ubuntu-arm 2010-04-16
<the_eye__> I am running ARM Ubuntu on a HTC Diamond how can I upgrade to latest
 * persia checks specs, as this is often *not* a good idea
<persia> the_eye__: According to http://www.qctconnect.com/products/msm_7201.html upgading to the latest Ubuntu will likely result in illegal instruction errors.
<persia> You want to run Ubuntu 9.04 on that hardware, and *not* upgrade to any later release of Ubuntu.
<the_eye__> ok
<the_eye__> How to upgrade to 9.04 then
<the_eye__> ?
<persia> WHich version are you running?
<persia> Because ARM support wasn't added to Ubuntu until 9.04.
<persia> (but the mojo project did have some builds)
<rcn-ee> oh, i wouldn't touch those, too bit rotten.. ;)
<the_eye__> 8.04
<persia> rcn-ee: I'm presuming that it's an old install, and looking for recovery to sanity.
<persia> the_eye__: That's indeed likely to be a mojo build.  That's not directly upgradable, because of a change to the architecture name ("arm" to "armel").  You'd have to reinstall.
<rcn-ee> good point.. yeah that was hasty, it actually worked on a htc phone?
<the_eye__> I understand so I had to install the new one all the way
<the_eye__> rcn-ee: yes it works
<persia> the_eye__: Unfortunately, yes.  Sorry about that.
<rcn-ee> the_eye__, cool.. i remember helping the mojo guys out, with first getting to run on the beagle....
<persia> the_eye__: And only install 9.04.  9.10 and newer require newer processors than that device contains.
<rcn-ee> did you do a chroot install or just a debian-install?
<the_eye__> no bad feelings :)
<the_eye__> I try 9.04 then
<persia> Good luck with it.
<the_eye__> rcn-ee: I installed an image from here http://forum.xda-developers.com/showthread.php?t=640785&page=77
<persia> the_eye__: You may want to try to get a working 2.6.28 kernel first, as this is what 9.04 will expect.
<rcn-ee> okay i see, they provided an image to dump in the sd card..
<the_eye__> yes, and I loaded with haret, without changing my rom
<DanaG> what is the "el" in armel?
<persia> I've always thought it stood for endian-little
<persia> But I could be wrong.
<persia> An alternate interpretation is "EABI little-endian", which makes more sense, as compared to "endian-big" as a proper opposite.
<rcn-ee> that's correct... i had to refresh my debian naming... at the time of the armel creation they left open the possibility of a 'armeb' for big-endian..
<persia> rcn-ee: armeb predates armel in Debian.
<rcn-ee> yeap, that was the old abi variant..
<rcn-ee> i'm so close with rootstock, ogra's last change gets me a little farther, but it's kinda random past that...
<persia> debootstrap seems to be working again for lucid.  What's the blocker?
<rcn-ee> right now its: http://pastebin.com/twaXDppk  so far for about 8/10 runs.. but i'm also playing with the cache settings as mentioned in 532733
<rcn-ee> one of the runs about an hour ago, segfaulted after closly finishing "uboot-netbook"
<persia> Ugh.  That does end up being 90 random things.
<DanaG> http://www.ifixit.com/Misc/iphone_processor_crossection.jpg
<DanaG> nice
<DanaG> that's a good way to describe package-on-package.
<DanaG> "add bootloader = flash-kernel"...
<DanaG> hmmm
<DanaG> [   26.829498] HS USB OTG: no transceiver configured
<DanaG> [   26.834442] musb_hdrc musb_hdrc: musb_init_controller failed with status -19
<DanaG> great.... my asix is broken again.
<DanaG> And my musb also is broken.
<DanaG> http://pastebin.com/THwXNMEE
<DanaG> wow, that's a nice "word".
<DanaG> thwxnmee!
<DanaG> ah, adding twl4030-usb to initramfs ahead of musb_hdrc fixed it.
<styol> is there a way to retrieve/store/copy the contents of a flash drive prior to formatting it?
<styol> basically ive got this awesome $90 netbook that comes with windows CE and an ARM processor but im essentially looking to backup the current OS and replace with something else like ubuntu arm, angstrom, or some other streamlined linux OS.. any general recommendations?
<DanaG> You may be able to copy the contents of the MTD stuff using dd.
<DanaG> What netbook is this?
<styol> this is an EPC-702
<styol> im not familiar with MTD or dd sorry im a supreme newbie to ARM and this sort of stuff :( im technically savvy just not with this (yet)
<DanaG> MTD is "memory technology device"
<DanaG> such as NAND flash.
<styol> gotcha yeah this is a 2gb nand flash utilizing XIP
<styol> so far i've got "F1 to update the system" at boot, asks for password, its ztk, then it gives me the options to format nand disk, format xip disk, format flash2 disk, update xip, update eboot
<DanaG> hmm... any option to boot from an sd card?
<DanaG> Or to check what's in the disk?
<DanaG> hmm, there's both nand and flash2?
<DanaG> xip is the kernel, most likely.
<DanaG> eboot... not sure.
<DanaG> sounds like the winCE boot loader.
<NCommander> styol: its likely someone has to port the linux kernel to that board or device before you'll have any luck running on it
<DanaG> http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Q_25366423.html -- is this you?
<NCommander> persia: armeb is dead in Debian and was never an official port. If we need an EABI big endian port, it will be armeb
<styol> thats not me but thats where i got the password from hehe
<styol> my friend has an ad blocker and apparently it makes the answers appear, nothing particularly helpful
<styol> DanaG yeah it has SD reader.. not sure why theres both nand and flash2
<DanaG> hmm, unfortunately, there seems to be very little info on that EPC-701 thingy.
<styol> how can i find out more information about this board? this is about all i have to go off of CPU: AK7802 and this at boot - http://img.vishun.com/IMG_0759.JPG
<DanaG> Not even a spec of what ARM it is.
<styol> 702 not sure if it makes a difference
<styol> a friend claims that its the same processor that the motorola razr v3m uses
<DanaG> http://en.wikipedia.org/wiki/ARM_architecture
<DanaG> arm926ej-s
<DanaG> search for that.
<DanaG> hmm, is that "versatile"?
<styol> not sure.. im a bit confused ;)
<DanaG> somebody more knowledgeable about ARM stuff would have to answer that.
<DanaG> interesting... my Cowon S9 has a Telechips 7901 in it.
<styol> thanks very much for your help DanaG, its much appreciated
<DanaG> hmm, you could also ask in #hardware, perhaps.
<styol> ill give it a whirl for sure
<NCommander> styol: its unlikely you'll be able to run Linux on that device. Unlike most other architectures, ARM doesn't have a standized mechanism of bringup, so the early system components through to the kernel must be tailored for each device
<styol> NCommander ah ok.. hrm yeah it does seem to be something that might be a bit of a stretch.. curious, how do devices that run ubuntu arm normally get ubutu arm installed?
<styol> found one thing thats promising.. http://www.arm.com/community/software-enablement/linux.php
<NCommander> styol: on paper, there are two ways
<NCommander> 1. A vendor works with Canonical and Canonical adds the support to Ubuntu
<NCommander> 2. Community members take Ubuntu/ARM and port it themselves (i.e., beagle community). Due to optimizations used in ubuntu, only a small subset of devices can run Ubuntu/ARM sadly
<styol> yeah that makes sense
<NCommander> styol: looking at your device, Ubuntu's specs are too high (your chip only implemented ARMv5 it seems. Ubuntu on AMR needs Ubuntu ARMv7+Thumb2)
<NCommander> s/AMR/ARM
<styol> ARMv5TEJ yeah?
<styol> how about something like Angstrom, or ttylinux
<styol> http://www.angstrom-distribution.org/ http://www.minimalinux.org/ttylinux/downloadARM.html
<NCommander> styol: well you still need kernel support before that's going to work unfortunately.
<styol> kernel support by one of those systems?
<styol> how about http://www.arm.linux.org.uk/
<NCommander> styol: the Linux kernel is a special type of application that sits inbetween the raw hardware, and the userland (aka, the set of applications that the user interacts with it)
<styol> how can i determine what this has presently?
<styol> the first arm.com has an image you can download that says the kernel is supported for
<NCommander> styol: if its running Windows CE, then its running the Windows CE client :-)
<styol> ARM926EJ-S (http://infocenter.arm.com/help/topic/com.arm.doc.ddi0184-)
<NCommander> styol: its not that simple. Even if the SoC (or processor) is supported, the board as a whole must also be supported
<DanaG> ARGH -- stupid asix.
<DanaG> It's giving me ZERO packets.
<DanaG> wow, and now it randomly came up.
<DanaG> nope, it's just seeing its own outgoing arp.
<DanaG> I see this looping on usbmon1:
<DanaG>   7.039795          4.1 -> host         USB URB_INTERRUPT
<DanaG>   7.039825         host -> 4.1          USB URB_INTERRUPT
<DanaG> It loops, and never goes anywahere.
<DanaG> Even does it with no ethernet cable plugged in.
<DanaG> Upon plugging in a different usb-ethernet thingy, I see usb URB_CONTROL
<DanaG> I suppose I should ask on the mailing-list about that.
<nosse1> Do you know how to control the screen (tty / fb) blanking interval? After a given time the LCD goes blank
<amitk> nosse1: setterm -blank 0 -powerdown 0 ?
<nosse1> amitk: thanks
<asac> hmmm ... so ffox debug build from trunk doesnt have frame/scrollbar issue for me
<dmart> NCommander: hi there
<hrw> hi
<ogra> rcn-ee, meh, your initramfs patch uses bashisms ...
<ogra> asac, can you put bug 563618 on the release meeting agenda ? it hits us hard on beagle
<ubot4`> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
<hrw> hi blotr
<TheWhiteGhost> hey hrw
<asac> ogra: seems the initramfs approach looks quite ok
<asac> is that tested?
<ogra> not yet
<ogra> i'm still in rootstock tests that eats all my resources
<ogra> asac, also that not all of it, there needs to be a hook to get all the binaries into the initramfs
<ogra> i'll try to improve and test it today
<dmart> A couple of comments...
<dmart> You assume that the argument to root= is a UUID.  For systems set up by Ubiquity that's probably not a problem, but embedded devs will often use the device name instead when tweaking the boot config by hand
<ogra> embedded devs will probably not even use an initramfs
<dmart> Does that work these days?  I remember it being very unreliable in karmic days
<ogra> but yes, i see your point ... the fix i work on is rather for the current official omap image though
<ogra> it got a lot better
<persia> no-initramfs works fine, but requires a bit of tweaking to boot (and is less safe as a generic model)
<ogra> and i think the approach is that you *can* run your system without initramfs if youwant in certain cases
<ogra> right
<ogra> it will always stay for the std distro
<dmart> Also, the hwclock backend often doesn't work during kernel porting I remember having a lot of trouble with this earlier during iMX51 support
<ogra> but if people have a selected set of packages and cant install harmful stuff its pretty safe to go without one
<ogra> i'm not sure if fsck even looks at the hwclock
<ogra> it might suffice to use date --set
<dmart> No, but hwclock --hctosys is used to set the soft clock
<dmart> Maybe do both?
<ogra> yeah, i'll discover such stuff when i test :)
<persia> It's not feasilble to have both online-updates and can't-install-harmful-stuff
<ogra> persia, it is if you use your own archive
<persia> We can only do hard-to-install-harmful-stuff
<persia> ogra: No it isn't, because of DNS spoofing.
<dmart> ogra, anyway, looks like a reasonable workaround
<ogra> and restrict to it indeed
 * dmart still thinks e2fsck is wrong, but that's another discussion...
<ogra> dmart, i agree though i also agree with Keybuk who says it needs to be solved on the actual filesystem layer
<ogra> i guess we need to fix both
<dmart> sure, it needs more thinking about
<persia> Gets harder for ext3/ext4 than ext2, but yeah.
<dmart> But if we rely on the reliability of the RTC _at all_ for preserving low-level fs consistency, that sounds really scary, especially for dual boot configs where something else may interfere with the clock sometimes
<ogra> lool, writeback hangs too (just reached iso-codes in rootstock this second)
<persia> dmart: Without reliance on the RTC, how can we know the time?
<dmart> If you need to know the time, you are at risk.  I need to understand more about the way the fs works though, in order to understand whether knowledge if the time is actually needed to ensure consistency
<dmart> It's worth considering that the journal has already been replayed before we get into userspace, so if the RTC really mattered, the fs has already been corrupted.
<persia> I don't know the deep details, but my limited understanding is that the journalling is timestamped.
<persia> Well, except in the initramfs case, in which case we're in userspace without actually using the filesystems.
<persia> (or rather, without using on-secondary-storage filesystems)
<dmart> fair point
<dmart> afaict, serial numbers (not timestamps) are used in the on-disk structures in jbd{,2}.h, but I confess I don't really understand how it all works yet...
<persia> heh, yeah.
<persia> Would probably benefit from a discussion with the fs devs at some conference.
<ogra> i dont think the journal has been touched until you get to mountall ... and it wont be touched until mountall remounts in RW mode (note that we specify ro on the cmdline by default)
<persia> ogra: The journal has to have been replayed to be able to mount RO.
<persia> Otherwise you have an inconsistent filesystem state.
<dmart> Mouting a dirty journalled filesystem ro does replay the journal
<ogra> persia, replayed but not changed
<persia> right.
<ogra> there wont be changes on disk yet
<persia> But the issue we have is at fsck time, not at mount time.
<persia> Well, except for refuse-to-mount-because-of-fs-age
<dmart> Not sure about that -- the kernel prints out "temporarily mounting fs read-write to recover the journal" (or something like that(
<persia> (but that's just a sanity check)
<ogra> dmart, aww, evil
<persia> dmart: Ooh, that makes lots of sense, and completely changes the semantics :)
<dmart> maybe that just happens when mounting the root fs... ?  dunno
<dmart> easy to test
<dmart> I guess you need to replay or unwind the journal to mount, because the metadata might be inconsistent garbage until you do that
<ogra> ah, yeah
<persia> That makes sense.  So we need to be sure we're somewhere sane.
<dmart> Unless you're using ext2 (it's still garbage, but you just hope the system doesn't explode ;) )
<persia> No, if we happen to have a reliable, working, RTC, I expect that having a date in the future is a good indication of likely corruption.
<persia> s/No/Now/
<dmart> I think 90% of the times I've triggered that problem it's been the RTC, not the fs, which is corrupt.  But it depends on what you're trying to do.  "Normal" users shouldn't hit that so much.
<ogra> wow, neither hwclock, nor date nor dumpe2fs are in the initramfs
<dmart> argh
<ogra> i would have expected the latter to be missing
<dmart> settimeofday?
<ogra> but surely not the first two
<persia> RIght.  The tricky bit is to come up with something that works for both end-users and bring-up-developers
<ogra> nah, no issue, i'll write a hook that copies them
<ogra> i just didnt expect date to miss ...
<ogra> nor hwclock
<dmart> Is the "last mount time" recorded in the fs the time the filesystem was last mounted, or the time it was unmounted?
<ogra> both i think
<dmart> Really we would want to set the clock to the last unmount time (except where there was a crash the the fs wasn't unmounted)
<ogra> last mount action
<dmart> hm
<persia> How is "mount action" defined?  Is that mount+unmount?
<ogra> i guess so
<ogra> (i was also guessing above)
<ogra> there is only that value in dumpe2fs
<persia> That sounds like desired behaviour.  Now I wonder if that's how it's implemented.
<dmart> The ext3 superblock has "mount time" and "write time".  Dunno their behaviour though
<ogra> yeah, i see the same in dumpe2fs
<dmart> Does anyone know a filesystem expert?
<ogra> i guess the stamp is updated by mount/umount
<ogra> Keybuk is probably closest
<dmart> It could still be worth discussing it at UDS
<asac> ogra: session name?  booting clockless systems with journaling FSes?
<asac> BootingWithTimeZero ;)
<ogra> asac, RTCless
<ogra> but yes
<ogra> or batteryless :)
<asac> ok i will add that
<amitk> asac: not clockless please, use non-rtc or something
<asac> amitk: Booting With Time Zero ;)
<ogra> our prob is that we *have a clock*
<asac> whatever causes this condition is probably irrelevant ;)
<persia> dmart: Keybuk suggested a discussion at UDS would be fruitless unless we had the fs developers there (and it may be late for them to make travel plans)
<ogra> persia, i disagree
<persia> Fair.  Just sharing.
<zumbi> hi! about gcc-4.4 in karmic, which is current? 4.4.1 (--with-arch=armv6) or 4.4.3 (--with-arch=armv7-a)?
<ogra> while i agree for the superduper proper fix that might be needed it isnt for finding the cleanest solution that doesnt involve filesystems
<ogra> since the filesystem fix might take years
<persia> zumbi: According to https://launchpad.net/ubuntu/+source/gcc-4.4 4.4.1 and it ought be ARMv6, as the rest of karmic is supposed to be that.
<zumbi> uhm.. ok thanks persia
<persia> ogra: Oh, a session on workarounds could work, as long as everyone understands it's workaounds.
<ogra> right
<ogra> the filesystem fix will likely require a design change
<zumbi> so Lucid is armv7-a :)
<asac> ogra: dmart: let me know if you think you can lead a session on that booting zero time stuff
<asac> otherwise i will note it down as a blueprint without session
<ogra> asac, i'm happy to
<persia> zumbi: Mostly.  Only ~7000 packages have been recompiled, so there's still bundles that may be ARMv6 or even ARMv5.
<asac> ogra: but do you have all the details so we can achieve something?
<ogra> asac, though i dont know how many sessions i have assigned at all
<ogra> might be a lot or none ... nobody tells me
<persia> zumbi: But I'd say that the majority of packages that generate ELF binaries are likely to have been recompiled.
<asac> ogra: you had two ... iirc
<ogra> asac, well, i know the problem and the possible areas for fixing
<asac> i avent added them to the table/schedule yet. but will do
<asac> if you want to drop one of the suggested ones let me know
<ogra> nah, all fine
<ogra> if its not 50 that i dont know about yet there is nothing to discuss :)
<asac> bug 559295
<ubot4`> Launchpad bug 559295 in flash-kernel (Ubuntu Lucid) (and 1 other project) "flash-kernel-installer needs to learn to handle omap (dup-of: 562888)" [High,New] https://launchpad.net/bugs/559295
<ubot4`> Launchpad bug 562888 in ubiquity (Ubuntu Lucid) (and 3 other projects) "omap installation failed with unrecoverable error (affects: 2) (dups: 2)" [Medium,Invalid] https://launchpad.net/bugs/562888
<asac> bug 559297
<ubot4`> Launchpad bug 559297 in flash-kernel (Ubuntu Lucid) (and 1 other project) "flash-kernel needs to learn to handle omap (dup-of: 562888)" [High,New] https://launchpad.net/bugs/559297
<asac> bug 559301
<ubot4`> Launchpad bug 559301 in partman-uboot (Ubuntu Lucid) (and 1 other project) "partman-uboot needs to handle omap installs (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/559301
<asac> bug 563618
<ubot4`> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
<asac> ogra: what about partman? is that RC still?
<ogra> asac, invalid
<asac> can yo do that?
<ogra> done
<asac> ogra: both flash-kernel things too=
<asac> ?
<asac> e.g. see above
<asac> bug 559144
<ogra> they are duped to the ubiquity one
<ubot4`> Launchpad bug 559144 in udisks (Ubuntu Lucid) (and 1 other project) "[armel] udisks-part-id crashed with signal 7 in memcpy() (dup-of: 561426)" [High,New] https://launchpad.net/bugs/559144
<ubot4`> Launchpad bug 561426 in parted (Ubuntu Lucid) (and 1 other project) "partman dies when trying to detect disks due to kernel error (affects: 1) (dups: 1)" [High,Fix released] https://launchpad.net/bugs/561426
<asac> ogra: so all invalid for flash-kernel-* ?
<asac> bug 541030
<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)" [High,Fix released] https://launchpad.net/bugs/541030
<asac> ogra: so only omap issue is bug 563618 ?
<ubot4`> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
<ogra> asac, nope, the flash-kernel task on bug 562888 is fix released already ... ubiquity was just uploaded
<ubot4`> Launchpad bug 562888 in ubiquity (Ubuntu Lucid) (and 3 other projects) "omap installation failed with unrecoverable error (affects: 2) (dups: 2)" [Medium,Invalid] https://launchpad.net/bugs/562888
<asac> bug 541399
<ubot4`> Launchpad bug 541399 in linux-mvl-dove (Ubuntu) (and 1 other project) "netboot image fails to boot. (affects: 1)" [Undecided,Invalid] https://launchpad.net/bugs/541399
<asac> hmm
<asac> so that was fix committed ... now its invalid
<asac> well
<ogra> asac, only *known* omap issue, i need to have images i can test now
<asac> bug 514257
<ubot4`> Launchpad bug 514257 in xine-lib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1) (heat: 8)" [High,Won't fix] https://launchpad.net/bugs/514257
<asac> bug 528524
<ubot4`> Launchpad bug 528524 in speex (Ubuntu Lucid) (and 5 other projects) "Sound not working in all apps through pulse on arm (affects: 3) (dups: 1)" [High,Fix released] https://launchpad.net/bugs/528524
<asac> ogra: we never had a working image?
<ogra> bug 541399 is a mess
<asac> bug 528524
<ogra> asac, no, flash-kernel and ubiquity were missing, we never had one that finished the bootloader part
<asac> yeah
<asac> but thats not our release goal afaiui
<asac> so its not RC
<asac> oh
<asac> hmm
<asac> ogra: ok
<asac> so bootloader missing?
<ogra> asac, Bug #541399 is fix released for d-i (i did the change and upload)
<ubot4`> Launchpad bug 541399 in linux-mvl-dove (Ubuntu) (and 1 other project) "netboot image fails to boot. (affects: 1)" [Undecided,Invalid] https://launchpad.net/bugs/541399
<ogra> the bot shows the wrong task
<asac> ogra: ok. i dont list released bugs anymore
<asac> ;)
<asac> bug 532733
<ubot4`> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 2 other projects) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 4) (dups: 1) (heat: 32)" [High,Incomplete] https://launchpad.net/bugs/532733
<asac> bug 528887
<ubot4`> Launchpad bug 528887 in maximus (Ubuntu Lucid) (and 2 other projects) "maximus does not give default focus to newly started apps in combination with efl launcher (affects: 3) (heat: 18)" [Medium,Triaged] https://launchpad.net/bugs/528887
<asac> bug 555977
<ubot4`> Launchpad bug 555977 in openoffice.org (Ubuntu Lucid) (and 1 other project) "openoffice.org FTBFS on armel (affects: 1)" [High,Fix released] https://launchpad.net/bugs/555977
<asac> is ooo build now?
<asac> ogra: please checkout https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
<asac> plars: ^^
<asac> i am cros checking with the buglist now
<ogra> looks fine
<asac> hmm
<asac> bug 559065
<ubot4`> Launchpad bug 559065 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "ifconfig eth0 down will cause system hang after fec.c driver update (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/559065
<asac> whats up with that?
<asac> ogra: ?
<ogra> mountall+fsck and qemu-kvm hang are my most serious ones
<asac> wasnt that done?
<ogra> i think the description is nonsense
<ogra> plars, ?
<ogra> well, or it should be fix released
<plars> ogra: I didn't see that with the newest kernel
<asac> is that RC? .... what does driver update mean? module reloaded?
<ogra> since the described issue is gone
<asac> usually we dont reload modules
<plars> ogra: I think that bryan saw that, and thought it may be related to the suspend/resume issues
<ogra> well, but you dont see the hang anymore
<plars> but his kernels that I tested, that certainly did not have this bug in it, still would not suspend/resume
<asac> bug 522858 is new?
<ubot4`> Launchpad bug 522858 in maximus (Ubuntu Lucid) (and 2 other projects) "Sometimes app windows come up undecorated, unselectable, and not full screen (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/522858
<plars> asac: the fec driver code was updated in the kernel
<asac> plars: but how can that change something?
<asac> without reloading the kernel/module?
<plars> asac: because we have a new kernel with the new code in it
<asac> bug 67544
<asac> whats that?
<ubot4`> asac: Bug 67544 on http://launchpad.net/bugs/67544 is private
<plars> very old apparently...
<asac> why is such an old bug targetted for us?
<ogra> 67544 ?
<asac> i will drop that
<plars> are you missing a digit?
<asac> no
<asac> plars: no seems doko gave it to us
<persia> Please don't drop it.
<plars> looks like persia has commented on it before
<persia> It's an old bug, but it's very valid.  That bug represents pascal support for armel.
<ogra> asac, doko is also fixing it it seems
<asac> yeah
 * persia has been watching that bug since before armel was available in Ubuntu.
<asac> persia: good. i will call you to give info during release meeting when questions come up ;)
<asac> so be prepared (in 20 minutes i guess)
<persia> If I'm still awake sure.  Ping me first (I'm getting really close to sleep).
<persia> Basically, some of us can build it, and lamont can't, and nobody knows why.
<persia> doko did a first-stage bootstrap that is hoped to ease the situation.
<persia> Oh, I will be awake.  The release meeting seems to have moved with DST.
<asac> persia: right. as i said: about 20 minutes till we are on :)
<plars> asac: you said all done for porting to thumb2, but there are still a couple of needs porting to thumb2 bugs that are rc targeted
<asac> plars: those are not armel tagged then
<asac> i just looked at the list
<plars> asac: yes they are
<asac> https://bugs.edge.launchpad.net/ubuntu/lucid/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscrib
<plars> asac: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/514253
<ubot4`> Launchpad bug 514253 in qt4-x11 (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1) (heat: 10)" [High,Won't fix]
<plars> asac: https://bugs.launchpad.net/ubuntu/+source/xine-lib/+bug/514257
<asac> plars: thats wont fix
<ubot4`> Launchpad bug 514257 in xine-lib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1) (heat: 8)" [High,Won't fix]
<asac> plars: wont fix too
<plars> ah
<plars> didn't look in the bug, just did a search
<plars> must have at least one task that isn't won't fix
<asac> plars: a search that includes won't fix? ;)
<asac> plars: lucid task is wont fix
<asac> i probably left the normal task open
<plars> yeah
<asac> so yeah
<plars> asac: was that intentional? just won'tfix for lucid then?
<plars> I will untarget them then
<persia> It's a bug in LP that there's no good way to do that :(
<asac> bug 528524
<ubot4`> Launchpad bug 528524 in speex (Ubuntu Lucid) (and 5 other projects) "Sound not working in all apps through pulse on arm (affects: 3) (dups: 1)" [High,Fix released] https://launchpad.net/bugs/528524
<plars> no sense in having them targetted if they are wontfix
<asac> plars: wont fix is the way to untarget
<plars> hmm, except they are still milestoned
<asac> plars: thats the way you get a normal task back
<asac> plars: but they are wont fix ... so they are hidden from all listss ;)
<asac> unless you search for invalid+wontfix ;)
<asac> feel free to change them to match your needs though
<plars> asac: I just did search for tags including armel and milestoned for 10.04, and I did not include invalid or wontfix
<asac> plars: right. you didnt search for "lucid"
<asac> you have to go to bugs.launchpad.net/ubuntu/lucid
<asac> nd then use advanced search there
<asac> and
<plars> yeah, I just started from ubuntu
<asac> feel free to unmilestone ... but if the not targetted task is milestoned its not RC in the book of release team
<asac> means: opportunity to fix for that milestone
<asac> or for personal prioritization
<plars> asac: there is https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/551491 that ericm milestoned for 10.04, but it's not targeted to lucid, I doubt it will happen in time though
<ubot4`> Launchpad bug 551491 in linux-mvl-dove (Ubuntu) "BSP update for Marvell Dove kernel LSP 5.1.0 (affects: 1) (heat: 8)" [High,In progress]
<asac> plars: thats not rc ...
<asac> SRUs etc.
<asac> we can target and milestone for :later
<asac> if we want to ensure that gets in
 * plars would like to confirm ericm's plans with him first, but that's my assumption
<ogra> ogra@ubuntu:~$ date
<ogra> Sat Jan  1 01:01:14 CET 2000
<ogra> ogra@ubuntu:~$
<sn9> has anyone tried any flavor of ubuntu on one of these? http://delstar.net/multi-function-devices/ds700-netbook.html
<ogra> wohoo !
<ogra> works !
<sn9> no one?
 * asac out to run some errands
<ogra> sn9, no kernel for that device and 128MB wont be fun
<sn9> i was thinking MID edition or something
<TheWhiteGhost> ogra what hardware you running on?
<sn9> which generation arm is that, anyway?
<ogra> TheWhiteGhost, frescale imx51, marvell dove and beagle
<ogra> recent ubuntu requires ARMv7
<persia> And doesn'T include MID anymore (it ended up being too hard to integrate the libgtk stuff).
<sn9> i don't know whether samsung qualifies
<sn9> persia: because of arm?
<persia> sn9: Not at all.  It was about the nature of the hildon-gtk changes.
<sn9> i mean, MID is gone from arm, or gone altogether?
<persia> gone altogether.  flavours are independent of architectues.
<sn9> anything replacing it?
<persia> Not right now.  There's been a lot of work to get LXDE ready, but it didn't quite make it for lucid.  It will probably make it for maverick.
<sn9> ko
<sn9> *ok
<persia> There's also been a lot of work on the Qt/Plasma front, which might hit maverick or might hit maverick+1, depending.
<persia> The Mer folk did a tremendous job of integrating later releases of hildon, but we just couldn't merge all that back into Ubuntu because of the libgtk issues.
<persia> And I don't know of anyone chasing that anywhere to make it work (hildon work seems unfashionable these days)
<sn9> so, basically, for lucid, it's netbook edition or bust, but 128MB is too thin for that, right?
<persia> Or roll-your-own works.
<sn9> right
<persia> LXDE should mostly just work, but the integration isn't 100% yet (and there aren't any images)
<persia> The Qt/Plasma stuff isn't ready at all yet, although there's kubuntu netbook which has some of the same technologies (but has the same issues at 128MB)
<sn9> which generation arm are the samsung cpu's?
<persia> Depends which samsung cpu :)
<persia> (but none of them have distro kernels)
<sn9> unfortunately, that page did not say, as you saw
<persia> Oh, that?  I heard that device was ARMv5.
<persia> I may be mistaken though.
<hrw> most of s3c are armv4t, some are armv5te. s3c6410 is armv6 iirc
<sn9> google seems to suggest arm9
<hrw> sn9: arm9 can be armv4t or armv5te
<hrw> sn9: there are ARM core numbers and ARM ISA (instruction set arch) numbers
<hrw> arm920t is armv4t, arm926ejs is armv5te
<sn9> S3C2450
<hrw> arm926ejs
<sn9> so no ubuntu
<sn9> past jaunty
<hrw> yep
<hrw> but Debian may work
<hrw> but getting linux working in it is probably more expensive task then buying something linux supported
<sn9> debian is armv6 and above, i thought
<hrw> no, Debian is armv4t
<sn9> i know for a fact debian does not support armv4
<hrw> it is hard to find armv4 device today
<sn9> 920 is not all gone yet
<sn9> i think gentoo is the only thing that supports armv4
<hrw> gcc 4.4 can generate EABI binaries for armv4....
<hrw> sn9: OpenEmbedded distros also supports
<hrw> I have to go
<sn9> ok
<persia> We tend to recommend folks with older HW run Debian though, just because 90% of bugs found in Debian also apply to Ubuntu (as well as the fixes), and using the same development technologies makes it easy to come back once one has newer hardware.
<sn9> interesting how just-released hardware is "old"
<persia> sn9: Older processors.  You can go buy a brand-new device that implements the i486 instruction set if you want, to show a parallel to ia32.
<persia> That can't run Ubuntu either.
<sn9> looks like there's a forum thread: http://ubuntuforums.org/printthread.php?t=1414364&pp=75
<persia> So the age is about the time-since-processor-design, or even time-since-architecture-specification rather than about time-since-manufacture or time-since-purchase
<dmart> ogra, you still there?
<ogra> dmart, yep
<ogra> seen -devel ?
<dmart> Thanks for offering to lead the BootingWithTimeZero thing --- I was offline for a while (honest!)
<ogra> heh
<ogra> have a look at the backlog in -devel :)
<dmart> ogra: Oh you mean the upstreamed proposal to ignore date issues in e2fsck with broken_system_clock
<dmart> Hmmm, does that mean we don't need to bother?
<ogra> well, probably not for maverick
<ogra> but for lucid ...
<dmart> right... I guess we need to pull together the proposed workarounds and choose one
<ogra> hrm, it doesnt work and i dont get why
<rcn-ee> ogra, just an odd ball idea, have you tried bypassing qemu's image files and just using a real disk?  i know it's not the best method in the end, but i just add 2nd sata drive to test... ;)
<rcn-ee> laughs, it actually seemed to get farther, right before a kernel panic: [ 1306.403516] Kernel panic - not syncing: Attempted to kill init!  current patch (didn't implement the final save to file conversion) http://pastebin.com/FK3TaViG
<andruk> rcn-ee: hey, did you ever get the spidev patch working?
<rcn-ee> nope, sorry andruk, not yet, it's still on my list for this week..  I'm playing with a hacked up rootstock at to the moment..
<prpplague> ~seen davidm
<prpplague> hmm guess no bot in the channel
<armin76> !seen davem
<ubot4`> I have no seen command
<armin76> :D
<prpplague> ahh thanks different prefix
<prpplague> ~seen davidm
<prpplague> !seen davidm
<ubot4`> I have no seen command
 * prpplague checks the bot help
<prpplague> bummer
<styol> NCommander after a couple hours i was finally able to determine which cheap device i will need to try accomplish what im trying to do ;) ping me when you're around, id love to share
#ubuntu-arm 2010-04-17
<NCommander> styol: I'm around now
<styol> hey there NCommander
<NCommander> styol: so what gadget did you get?
<styol> VIA ARM 8500 or 8505
<styol> aka WM8505 and aka VT8505 i tink
<styol> ello DanaG1 :)
<styol> NCommander basically theres a 75 page thread on ubuntu forums dedicated to getting linux on cheap netbooks like the one i got, mine is mentioned but not supported
<styol> in this thread they even got android on the device
<NCommander> styol: nice!
<styol> and those similar devices are also similar in price.. yee haw!
<styol> trying to put together enough paypal monies to purchase a prototype, the place i got mine from gas those devices but wont exchange or refund
<styol> *has
 * XorA begins to wonder how many days rootstock is supposed to run for to generate an image
<rcn-ee> XorA, stuck at iso-codec's?
<XorA> rcn-ee: yes
<rcn-ee> bug 532733 real pain at the moment... ;)
<ubot4`> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 2 other projects) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 4) (dups: 1) (heat: 32)" [High,Incomplete] https://launchpad.net/bugs/532733
<XorA> rcn-ee: arse thats a real blocker for me
 * XorA needs to get lucid on at least one of these damn omap3 devices
<rcn-ee> and me...  that's why my demo images for lucid are all minimal..
<rcn-ee> XorA, this will atleast get you booted into a minimal lucid : http://elinux.org/BeagleBoardUbuntu#Lucid_10.04_.28beta-2.29
<XorA> rcn-ee: so once I get in there, I can apt-get install netbook stuff?
<rcn-ee> yeap, and then it works fine...  qemu just can't handle that package, my beagle has no issues...
<XorA> rcn-ee: you rule, thanks
<rcn-ee> No problem, sorry about the default username/password.. I'm trying to get oem-config working on my images so we can bypass that issue.. but it's dieing with oom errors..
 * XorA was beginning to think it odd that OE can BFS an image quicker than ubuntu can bootstrap it :-)
<rcn-ee> and with lucid release on april 29th.. alot of people will wonder that...
<samuel_Sayag> irc://irc.efnet.net/bt-chat
<XorA> rcn-ee: thanks for the help, waiting for 350M of packages now :-)
 * XorA thinks installing ubuntu would be so much easier if dpkg didnt segfault all the time
<nosse1> XorA: dpkg segfaults, what is your rootfs?
<XorA> nosse1: one from here http://elinux.org/BeagleBoardUbuntu#Lucid_10.04_.28beta-2.29
<XorA> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<XorA> E: Sub-process /usr/bin/dpkg received a segmentation fault.
<andruk> rcn-ee: i need to give patch.sh the pwd in the variable DIR, right?
<andruk> rcn-ee: ping?
<nosse1> Anyone here?
<nosse1> When you build apps natively on target, configure usually prints something like "checking C++ compiler flags...... use default: -O2  -g -DNDEBUG"
<nosse1> Does this imply the build options "-march=armv7-a -mthumb -mfpu=vfpv3-d16 -mfloat-abi=softfp -Wa,-mimplicit-it=thumb", as printed on https://wiki.ubuntu.com/ARM/Thumb2
#ubuntu-arm 2010-04-18
<DanaG> nice... the kernel on my beagleboard just segfaulted.
 * DanaG wishes there were a board that had a superset of "openrd-base" and "openrd-client".
<DanaG> Base doesn't have many USB ports, but client doesn't have PCIe slot.
<persia> What we need is some good way to share open board layouts, and a contract assembly plant with quick turnaround.
<DanaG> The openrd-client would be perfect if not for that stupid onboard XGI.
<DanaG> With a PCIe slot, instead, we could stick an ATI card in there and have arm eyefinity. =Ã¾
<persia> Or just add a USB hub to openrd-base
<DanaG> Does the client use a hub, or 4 real separate ports?  I'm not quite sure how that works.
<DanaG> Even on an ordinary x86 system... is there any difference between 4 ports off the root, versus 4 ports on a hub off one root port?
<DanaG> Base also doesn't have audio, rs485 (not that I'd know what to do with it), or the second GbE connector.
<persia> Audio is trivial: use USB.
<persia> I'm not sure of the implementation, but I suspect it's an internal hub, rather than real separate ports.
<persia> Except for drives, this doesn't typically matter all that much.
<DanaG> hmm, I wonder which would have better quality... onboard, or USB?  I doubt many SOCs have 24/96 abilities. =Ã¾
<DanaG> s/many/any/
<DanaG> hmm, looking at the block diagram, it does look like merely an onboard hub.
<DanaG> http://www.globalscaletechnologies.com/t-openrdbdetails.aspx#hw_block
<DanaG> http://www.globalscaletechnologies.com/t-openrdcdetails.aspx#hw_block
<persia> That's common.  It's a cheap component, and adds perceived value to a board if there's leftover space.
<DanaG> also weird... base block-diagram shows only esata... yet manual shows an onboard sata as well.
<persia> Real ports typically have to be in the SoC directly, so it's rare to not get the same number on every board for a given SoC.
<persia> (well, some boards trim them, but usually at least provide headers when they do)
<DanaG> The real bummer is the loss of that second GbE.
<persia> "onboard sata" might be a USB-SATA interface on the board.
 * persia has heard of that on a few boards now
<DanaG> nope, the block diagram in the openrd-base manual (pdf) shows sata-#1 internal and sata-#2 esata.
<persia> That's just branding.  The difference between "SATA" and "eSATA" is the plug.
<DanaG> heh, every time I see "OpenOCD", I think "Open Obsessive-Compulsive Disorder"
<persia> Does it have a header, if it doesn't have a plug?
<DanaG> openrd-client block diagram on web site: 2 sata connectors (one internal, one external).  openrd-base on web page: 1 sata.  OpenRD-Base PDF: 2 sata.
<persia> Hurrah for communication between the tech writers and the marketing dept.!
<DanaG> Oh, and a handy hint for win7: there are built-in "RNDIS-Compatible" drivers that work perfectly... and are signed.
<DanaG> Just have to uncheck "show only compatible drivers".
<DanaG> It's likely they revised the product at some point, and forgot to update the web site.
<DanaG> Revision log in the PDF shows only one version... so I wonder which is the current state: one port, or two?
<DanaG> NetworkManager: <WARN>  wireless_get_range(): (wlan0): couldn't get driver range information (95).
<DanaG> NetworkManager: <WARN>  constructor(): (wlan0): Device unsupported, ignoring.
<DanaG> grr, stupid networkmanager,
<DanaG> .
<DanaG> wlan0     Interface doesn't support scanning.
<DanaG> nice job, kernel.
<DanaG> /boot/config-2.6.34-rc4-l0:# CONFIG_CFG80211_WEXT is not set
<DanaG> /boot/config-2.6.33-500-omap:# CONFIG_CFG80211_WEXT is not set
<DanaG> hmm, the omap kernels seem all screwed up to various degrees.
<RoyK> hi all. I'm thinking of using ubuntu on a Moxa box - is this likely to function well?
<rcn-ee> Which Moxa box? (model #)
<RoyK> erm - don't remember - I just found out ubuntu supports arm... it'll be a new model. don't they all use arm7?
<rcn-ee> nope..  always look closely, it looks like (moxa.com) is an xscale house which is old armv5 hardware, which would mean Jaunty only. (bring your own kernel off course)
<saeed> asac: ping?
<philo> hi have a arm related but non ubuntu related question
<philo> can someone confirm that "ldr <register> , = <expression>" is a valid opcode for gas ?
<rcn-ee> DanaG, i just enabled CONFIG_CFG80211_WEXT it'll be on my 2.6.33.2-dl7 uploads..
<DanaG> Cool.
<DanaG> Oh yeah, which time-zone are you in?
<rcn-ee> us central..
<DanaG> ah.
<DanaG> Cool, thanks.
<DanaG> Do you have a kernel somewhere that's compiled with musb_hdrc built-in and yet all the g_ether and such built as modules?
<rcn-ee> kinda...  I have too many Bx boards, so i don't build that way: but the config diff is located here: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head:/patches/rcn/002-defconfig-disable_gadget_stuff.diff  just use that to change patches/lucid-defconfig in my 2.6-stable repo
<rcn-ee> andruk, it seems to work: /dev/spidev3.0  /dev/spidev3.1  /dev/spidev4.0
 * XorA|gone wonders why so many segfaults :-(
<XorA|gone> rcn-ee: is there any kernel config stuff you can think of that would make apt/dpkg segfault a lot?
<XorA|gone> rcn-ee: Angstrong is rock solid on this kernel
<rcn-ee> yeap.. that sounds like the thumb erata..
<XorA|gone> you guys are using thumb?
<persia> XorA|gone: To test, does karmic run clean, and just lucid segfault (karmic was -marm)
<rcn-ee> make sure: CONFIG_ARM_ERRATA_430973=y is set...  lucid is thumb2...
<rcn-ee> all r1pX cores such as the omap35x need it..
<XorA|gone> rcn-ee: ah cool, Angstrom ditched thumb as it was too unreliable with a lot of gcc/binutils mixes
<persia> One of the luxuries of being able to specify the use of the native internal toolchain :)
<rcn-ee> yeap, i know what you mean.. i started with angstrom too..  the ubuntu guys wanted to try it. ;)
<persia> It's (mostly) working for us, after we ported a heap of apps.
<XorA|gone> persia: that doesnt help, we found many many glaring bugs in binutils
<persia> XorA|gone: Do you know if they have been fixed?  I know we carry some patches.
<XorA|gone> I think they finally got fedup of us bitching though, recent ones work a whole lot better
<persia> If not, that might be unfortunate.
<persia> I suspect that's the case (and thanks for the complaints :) )
<XorA|gone> we use Phil Blundel to do our nagging :-)
<XorA|gone> anyway I am off to check my defconfig
<XorA|gone> lucid working nice on zoom2 apart from segfaults though
<rcn-ee> that sounds like the config... other then segfaulting most things will still run...
<rcn-ee> i ran into it in teh early alpha1-2 days since i was runing deb-pkg on top of fakeroot, and fakeroot was segfaulting..
<XorA|gone> rcn-ee: do you have all 3 erratas turned on?
<rcn-ee> no, i haven't ran into needing 458693 or 460075 yet
<XorA|gone> rcn-ee: just found your defconfig
<rcn-ee> CONFIG_ARM_ERRATA_430973: ARM errata: Stale prediction on replaced interworking branch
<rcn-ee> basicly if you have thumb binary and arm binary running, something bad could happen..
<XorA|gone> yeah I remember the discussion on linux-omap now
<XorA|gone> I just forgot as we dont use thumb
<rcn-ee> yeap, it only came into play with lucid..  but i had to go back and enable the option for all since my builders run squeeze and build all distro's in chroots...
 * XorA|gone feels lucky this compile isnt being done on the zoom2 :)
<rcn-ee> it only takes 5ish hours with all modules.. ;)
 * XorA|gone curses and hunts who broke OE
<XorA|gone> ah my bad, I acked the patch :-)
 * XorA|gone notices ubuntu needs a rule in udev to link /dev/fb0 to /dev/fb
<persia> What unfixably depends on /dev/fb ?
<XorA|gone> persia: well you could patch xserver-video-omapfb (and omap3 version) to look properly
<persia> That sounds less invasive (only affects the one bit that has issues).
<persia> Does a patch exist?
<XorA|gone> persia: no, as we just create the link
<XorA|gone> persia: I will get tasked with that eventually by TI more than likely
<persia> heh, OK.
<persia> The alternative would be to have the xserver-xorg-video-omapfb package install a udev rule, but that feels hacky.
<persia> (on the other hand, it's probably faster)
<persia> dh_installudev ought give you the hints to do that easily.
<persia> But we should avoid patching udev, as folks on other platforms don't need/want the link.
<XorA|gone> persia: yeah, I see that
<XorA|gone> I think the issue is the meanings on the fb's is kind of hardcoded into omap3
<XorA|gone> fb1 fb2 are the hardware overlays for video
<XorA|gone> rcn-ee: thanks, looking a lot better now
<rcn-ee> good to hear XorA|gone
<XorA|gone> just two bugs to figure out on zoom2 and its usable
<rcn-ee> which two are left?
<XorA|gone> touchscreen is uncalibrated and keyboard is not working
<XorA|gone> usb keyboard is working, so it must be something simple
<persia> Does the driver provide a /dev/input/event interface?
<XorA|gone> persia: I think so, Im pretty sure its some minor issue, its working in poky and angstrom with xorg 1.8 with no patches
<persia> I'm just wondering if it's a side-effect of Ubuntu's attempts to not use xorg.conf
<persia> Lots of stuff that works just fine needs tweaking to work in Ubuntu due to needing to fit into autodetection
<XorA|gone> ah crap, it could be a rule missing from hal/libudev so it doesnt ID it as a keyboard
<XorA|gone> we use autodetection as well
<persia> Right.  I thought I remembered ndec saying something about the zoom2 keyboard being a bit funny.
<XorA|gone> I dont remeber us having a custom rule, but its possible we do
 * XorA|gone adds it to the list
<persia> Oh, and in case you didn't notice, hal has been deeply stripped in Ubuntu as part of the efforts to make it go away entirely, so if you're depending on HAL behaviour, you mayfind it differs.
<XorA|gone> persia: there is a dev branch of Angstrom that is nearly totally hal gone, so we should be about the same level
<XorA|gone> persia: it will be some minor tweak Im sure
<persia> Probably.  Glad to hear that Angstrom is dropping HAL also: it always feels better to be part of the crowd :)
<XorA|gone> Ill be sure to post patches when I actually start coding on this
<XorA|gone> BTW is there any plans to make Lucid initialise the OTG port on boot?
<persia> I doubt it.  Lucid is in final-freeze.
<XorA|gone> ok
<persia> So only RC stuff is getting pushed at this point.
 * XorA|gone is still a little upset at the EHCI port on his beagle burning out
<persia> Understandably.
<DanaG> Hmm, so will it end up still having that kernel oops (and segfault on reboot)?
<DanaG> That's what I get with the Lucid kernel on my beagle.
<persia> DanaG: Which bug #?
<DanaG> erm, lemme' see if there is one.
<persia> I promise that if there's not a bug, there's no chance it will be changed for lucid :)
<DanaG> What's the plan for officially installing the ubuntu kernel?  Will it have an equivalent of update-grub?
<persia> No.
<persia> But that's mostly because update-grub does a very different thing than is currently suitable
<persia> (someone should port grub and fix this)
<DanaG> Hmm, bummer.  it'd be nice to have it auto-copy uimage to the fat16 partition.
<DanaG> that's what I meant.
<DanaG> yeah, I guess that is way different from grub, after all.
<persia> DanaG: Well, flash-kernel can do some of that: it's designed to copy the kernel from /boot to somewhere else for devices that don't have decent bootloaders.
<XorA|gone> hmm, zoom2 keyboard decides to work again
<persia> And I believe the kernel calls flash-kernel on postinst.
<persia> XorA|gone: heisenbug?
<DanaG> I also figured out something interesting with my asix ethernet:
<XorA|gone> persia: maybe the driver went wrong due to that thumb issue
<DanaG> The thing that was making it not work on boot... was that I had "ethtool -s eth0 wol g" in rc.local.
<persia> Ah, that might be it.
<DanaG> Apparently enabling WOL kills asix.
<XorA|gone> so just touchscreen
<XorA|gone> and the patch Angstrom has for that is not suitable upstream
<persia> What's the issue with touchscreen?
<XorA|gone> I beleive it thinks its a touchpad, not a touchscreen
<XorA|gone> but its how to tell libudev how to properly identify them
<persia> Oh, yeah.  The Netwalker has the same issue.
<persia> The (hacky) solution in the netwalker was to just hint the synaptics driver when the device was discovered in HAL.
<persia> But that's 9.04.
<persia> For lucid, you might get away with the same trick in udev.
<XorA|gone> koen did a hack where if driver returns pressure use tslib
<persia> (but better to fix properly, if one can)
 * XorA|gone will talk to hrw he had similar issues with bug which he might have fixed
<persia> That's a plan :)
<XorA|gone> not as fast as that omap4 board, but speed isnt bad on the UI :)
<persia> Everyone fusses about speed, but really, unless you're doing something especially complex (like rendering multi-input graphic interfaces in realtime: e.g. web browsing), most stuff doens't really need a high-spec processor.
<DanaG> wlan0     Interface doesn't support scanning.
<DanaG> ah. here's my oops: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/563650
<ubot4> Launchpad bug 563650 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "DSS2 oops when shutting down while DPMS is active (affects: 1) (heat: 8)" [Medium,Confirmed]
<persia> DanaG: OK.  That's been determined to not be release-critical: it's scheduled for a post-release update.
<persia> (milestoned against lucid-updates)
<DanaG> Ah, the only other big thing is "iwlist s" not working -- probably due to WEXT being disabled.
<DanaG> /boot/config-2.6.33-500-omap:# CONFIG_CFG80211_WEXT is not set
<XorA|gone> DanaG: same ooops present on zoom2
<DanaG> NetworkManager: <WARN>  wireless_get_range(): (wlan0): couldn't get driver range information (95).
<DanaG> NetworkManager: <WARN>  constructor(): (wlan0): Device unsupported, ignoring.
<XorA|gone> well thats me happy for tonight, thanks for the help guys
<DanaG> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/566238
<ubot4> Launchpad bug 566238 in linux-ti-omap (Ubuntu) "wlan0 "Interface doesn't support scanning." -- CONFIG_CFG80211_WEXT is not set (affects: 1)" [Undecided,New]
#ubuntu-arm 2011-04-11
<davidm> hello
<ogra_> diwic, hey ... no upload of the alsa-libs config files yet ? i think they are harmless and we need them
<ogra_> (and having them in now will prevent from asking for freeze exceptions for pluse *and* alsa-lib)
<diwic> TheMuso, ^^ (if you're still awake)
<diwic> ogra_, TheMuso, I don't think we need an FFE for just the alsa-lib config files, what do you think?
<diwic> maybe I got so focused on the big PA patch that I forgot about the config files
<ogra_> well, its an upload ... it will end up in the queue and need review after todays freeze
<ogra_> so getting it in now saves some work for everyone
<diwic> ogra_, FYI, there just was a new upload of alsa-lib but the build failed due to some gcc stuff on the buildds
<ogra_> i already talked to te release team about pulse uploads/freezes and we can go forward if we think its safe
<diwic> at least on amd64
<ogra_> well, if it needs a re-upload adding the configs would be good
<diwic> ogra_, how much testing has been done of the config files
<ogra_> do they need much testing ? they enable the devices on my panda after running alsaucm
<diwic> well, if you have tested them, then that's at least something :-)
<ogra_> i must admit i trust TI here that they will work
<diwic> ogra_, as TheMuso is the uploader, there is not much I can do - I hope you two can agree on what needs an FFe and what doesn't and that the FFe paperwork is done where it's needed.
<TheMuso> Sorry was away for dinner.
<ogra_> TheMuso, can we get an alsa-lib upload with the config files added ? they should do no harm
<ogra_> and save is a freeze exception
<TheMuso> Hrm ok, it seems we are frozen now though...
<ogra_> hrm
<ppisati> so, what's the magic to get kexec working on arm?
<ppisati> kexec -l /boot/vmlinuz-2.6.38-1207-omap4 -append="console=ttyO2,115200 ..."
<ppisati> Memory for crashkernel is not reserved
<ppisati> Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
<ppisati> but if i add"
<ppisati> :
<ogra_> kexec is depending on the moon phase and humidity
<ppisati> crashkernel=16M
<ogra_> only if both match the tight values at the right time it will work ;)
<ogra_> *s/tight/right/
<ppisati> to /boot/boot.script and flash-kernel, the board doesn't boot anymore
<ppisati> :)
<ppisati> sounds like a work for the A-Team
<ppisati> tataratataaaaaaaa...
<ppisati> no, really
<ogra_> there were several A teams on it in the last few years
<ppisati> do i need that crashkernel thing? and if yes, acceptable value?
<ogra_> it usually works exactly one upload long .. the next change usually breaks it
<ppisati> :(
 * ogra_ has no idea about crashkernel= 
<ppisati> k
<ogra_> ask in #ubuntu-kernbel i guess
<ogra_> -b
<TheMuso> ogra_: ok so given what you said in -devel, do you want me to get the alsa-lib config files in the queue?
<ogra_> TheMuso, that would be awesome, i'll make sure to have the pulse bits tested before final freeze too
<TheMuso> ogra_: Ok thanks, will do.
 * TheMuso checks to see if the bug for this work has an alsa-lib task.
 * ogra_ adds a pulse task to the bug so only the alsa-lib bit gets closed on upload
<ogra_> it has :)
<TheMuso> Right.
<TheMuso> yeah jsut confirmed.
<TheMuso> ogra_: I am going to put these config files in libasound2 only, and not in any bi-arch packaging, since 1) they're not needed in bi-arch packages afaict and 2) they're only for arm anyway.
<ogra_> yeah, sounds fine
<TheMuso> sweet.
<TheMuso> ogra_: Just to check that the files in this tarball, http://afuera.cortijodelrio.net/~ddiaz/paucm/PA_UCM_cofigFiles.tar.gz are the ones you want?
<ogra_> TheMuso, righto
<TheMuso> ok thanks again.
<TheMuso> Uploading now.
 * ogra_ hugs TheMuso 
<TheMuso> sorry about all the trouble with this. :)
<ogra_> lets hope we get the pulse patches solved asap then :)
<ogra_> not your fault ... you didnt provide patches short before freeze ;)
<TheMuso> Yeah hope so.
<ogra_> its not a new problem, we already released maverick without sound, TI could have started earlier
<TheMuso> I'll make another package available with the namereg patches included, as per David's review.
<ogra_> k, i'll do an armel build and test then
<TheMuso> And will start testing here on x86.
<ogra_> great
<TheMuso> ogra_: Ok an updated package of UCM enabled pulse has been uploaded to my PPA, ppa:themuso/ppa.
<TheMuso> Source should be published in an hour or so.
<ogra_> thanks, will pull and build then
<TheMuso> np.
<hrw> I see that janimo works on gconf
<ogra_> janimo, any isea about the segfaults of evo-indicator and gnome-games ?
<janimo> ogra_, I hope the gconf build fixes indicator
<ogra_> i gave both back today and they actually ended up on other buildds but with the same result
<janimo> gnome-games was a libgles not found issue, unrelated to the gconftool crashers
<janimo> these are liferea, tomboy, indicator-session and evo-indicator
<ogra_> ah, tomboy too ? great
 * ogra_ was just opening the log
<janimo> ogra_, I could not reproduce the gconf crash if I rebuilt locally with -O0 so I uploaded that and fingers crossed
 * ogra_ crosses too
<hrw> and then some packages needs to be rebuilt
<janimo> ogra_, not sure if you said anything else, but I needed to reboot because of natty upgrades being funny again
<ogra_> nope, i didnt
<ppisati> cooloney: is the XM ok for the test?
<rsalveti> ppisati: for the usb otg, yes
<ppisati> rsalveti: k
<ppisati> rsalveti: BTW, all that memory bugs in omap[3|4}
<ppisati> rsalveti: don't you think are somehow related?
<ogra_> what are "all that memory bugs" ?
<ppisati> 633227, 746137 and 690370
<rsalveti> ppisati: sorry, which ones?
<ogra_> snap :=
<ogra_> :)
<rsalveti> let me take a look
<rsalveti> bug 633227
<rsalveti> where is our bot? :-)
<ogra_> bot still dead ?
 * ogra_ thought we were over all memory bugs now ... at least on omap4
<rsalveti> ppisati: I believe 690370 is a side effect of both 633227 and 746137
<rsalveti> ppisati: for now let's just add a comment there requesting a new test with beta-2 image
<rsalveti> that should have the workaround for the page allocation and the new boot args for 1g
<ppisati> k
<rsalveti> ogra_: janimo: btw, thanks for the uploads
<ogra_> thanks for the code :)
<janimo> rsalveti, cheers
<rsalveti> :-)
 * ogra_ would appreciate someone who is not him to also test the pulse packages from https://bugs.launchpad.net/ubuntu/natty/+source/alsa-lib/+bug/746023
<rsalveti> ogra_: sure, can give it a try
<ogra_> awesome
<ogra_> you might need to wait for alsa-lib to appear, not sure it has hit the arcive yet
<rsalveti> np
<rsalveti> ppisati: do you have a proper cable to test the usb otg?
<rsalveti> otherwise I can also help testing that
<ppisati> rsalveti: yep
<rsalveti> ppisati: cool
<ppisati> rsalveti: i mean, i have the cable
<rsalveti> sebjan: now x-loader package should now be gitorious's head
<rsalveti> sebjan: with the additional 3 patches that I sent to the m-l
<rsalveti> that should help with panda es >= 2.2 and newer beagle xm
<ppisati> can't we enable tftp support in uboot?
<ppisati> flashing new kernel is really a waste of time...
<rsalveti> well, it'd need usb and ethernet support
<rsalveti> don't know if they are working already
<rsalveti> jcrigby should know the answer
<jcrigby> rsalveti, I have discussions about musb for beagle to enable ethernet but I don't think it works upsteam right now.  I may be working in some other tree.
<jcrigby> s/have/have seen/
<jcrigby> sorry can't type
<jcrigby> also there are other usb protocols that would allow easier testing
<ppisati> jcrigby: but that would mean another cable lying around
<jcrigby> yes
<ppisati> jcrigby: while we all have an eth attached to the boards
<ppisati> and tftp is so handy
<ppisati> i can compile/rootstock everything on my desktop
<ppisati> and boot from there
<rsalveti> problem is that the ethernet part is connected with the usb hub
<jcrigby> ppisati, I agree that usb/ethernet in u-boot would be useful
<ppisati> yep, i know
<rsalveti> so, no easy workaround for you here
<ppisati> anyway, if it's not ready yet, there's not much we can do
<rsalveti> flashing into the sd is still the easiest solution
<sebjan> rsalveti: thanks!
<ppisati> rsalveti: lp608312
<ppisati> rsalveti: i should just connect the usb cable to the board, right?
<ppisati> flag@omap:~$ ls -la /sys/devices/platform/musb_hdrc
<ppisati> ls: cannot access /sys/devices/platform/musb_hdrc: No such file or directory
<rsalveti> ppisati: in theory, yes
<rsalveti> hm, weird
<ppisati> flag@omap:~$ uname -a
<ppisati> Linux omap 2.6.38-8-omap #42 Mon Apr 11 16:48:29 CEST 2011 armv7l GNU/Linux
<ppisati> natty kernel
<rsalveti> check the config options for OTG
<ppisati> [flag@newluxor ubuntu-natty]$ grep -i otg debian/build/build-omap/.config
<ppisati> CONFIG_ARCH_OMAP_OTG=y
<ppisati> CONFIG_USB_OTG=y
<ppisati> # CONFIG_USB_OTG_WHITELIST is not set
<ppisati> # CONFIG_USB_OTG_BLACKLIST_HUB is not set
<ppisati> CONFIG_USB_MUSB_OTG=y
<rsalveti> ppisati: /sys/devices/platform/musb-omap2430/musb-hdrc/mode
<ppisati> # OTG and related infrastructure
<ppisati> CONFIG_USB_OTG_UTILS=y
<ppisati> ok
<rsalveti> probably just changed the sysfs path
<rsalveti> at least this is what I have at my panda
<ppisati> ok ok
<ppisati> find will do it
<ppisati> btw, i just attached the usb-power cable to the mini-usb socket, right?
<ppisati> s/attached/attach/
<rsalveti> ppisati: yes, the usb powered one
<ppisati> k
<GrueMaster> rsalveti: Can the edid data be probed through the i2c hooks on panda?  I want to see if I can detect what may be happening on my panda when it is using the switchbox.  Figure I could easily monitor with the headless image.
<GrueMaster> (assuming I can get that to work).
<rsalveti> GrueMaster: I know you can if you're using dvi, not sure with hdmi
<GrueMaster> ok
 * rsalveti lunch
<GrueMaster> marvin24: ogra said you are working on the AC100 audio.  Do you have access to the datasheet for the audio codec?
<ogra_> marvin24_DT, ^^^
<marvin24_DT> GrueMaster: yes
<marvin24_DT> em
<marvin24_DT> you need a pdf or is an online version sufficient?
<GrueMaster> I have one.  Didn't know if you did or not.
<GrueMaster> I used to work on HDA drivers.
<marvin24_DT> I only have a leaked draft from baidu
<marvin24_DT> so you are also working on a codec driver?
<GrueMaster> ogra said it is the realtek alc5623.
<marvin24_DT> no, alc5632
<GrueMaster> I don't have a system, and am too involved with ubuntu testing to do dev work atm.
<marvin24_DT> I only used the 23 for reference
<GrueMaster> Oh.
<ogra_> ah
<marvin24_DT> they are similar
<marvin24_DT> but you cannot do it in the same driver
<marvin24_DT> I think the difference is too large
<ogra_> pfft, its only 9 product revisions :P
<marvin24_DT> the id register says its revision 0x5c!
<marvin24_DT> that's even more
<ogra_> heh
<marvin24_DT> maybe that's why this register is undocumentated
<GrueMaster> Nah, the revisions are just how many changes it took to get it working.
<GrueMaster> :P
<GrueMaster> I used to have a contact at realtek, but that was 5 years ago.  Wish I could help more.  I don't even have a system to play with (even if I had the time).
<ogra_> i thought you sit on michaels ac100 now :)
<GrueMaster> ENOTIME.
<GrueMaster> I could work on getting that working and just skip beta 2 release testing, but it may reflect poorly on my review.  :P
<ogra_> tsk, you sound like if we had a release in a few weeks
<GrueMaster> rsalveti: I think I figured out the problem with HDMI and my switchbox.  During boot, the port is reset along with the board causing the switch to jump to the next active port (I catch this and switch back before the kernel loads).  When X starts, the port is again reset and immediately probed.  This reset also causes a switch and the read immediately after gets junk data.
<GrueMaster> I think there needs to be a slight delay between reset and read.
<GrueMaster> I have a new HDMI switch with "built in equalizer".  Will see how it performs.
<rsalveti> GrueMaster: hm, ok, good to know
<rsalveti> yeah, give it a try and we'll see the behavior
<rsalveti> ogra_: still got 2 asoc: no valid backend routes for PCM: SDP4430 Media messages
<rsalveti> now let me test the sound
<rsalveti> seems that it'll only work with hdmi
<rsalveti> ogra_: can't get audio to work here
<GrueMaster> Gahh.  Getting a dpkg error upgrading pulseaudio-utils.
<GrueMaster> Appears that pulseaudio-utils is trying to remove a non-existant man page (that I don't think is even pulseaudio related).
<rsalveti> ogra_: why deb-src is not setting universe and multiverse too?
<rsalveti> $ cat /etc/apt/sources.list
<rsalveti> deb http://ports.ubuntu.com/ubuntu-ports natty main restricted universe multiverse
<rsalveti> deb-src http://archive.ubuntu.com/ubuntu natty main restricted
<rsalveti> same for natty-security
<GrueMaster> This should really be fixed in oem-config, not a jasper hack.
<rsalveti> agree, but not the case atm
<rsalveti> do you know if we have a bug for oem-config for it?
<GrueMaster> I remember filing one.  Let me look
<ogra_> that might be solvable through a preseed option, let me check
<ogra_> rsalveti, can you try running alsaucm ?
<rsalveti> ogra_: still nothing
<ogra_> did you get any output from alsaucm ?
<rsalveti> ogra_: Im setting defaults
<ogra_> well, that somewhat suggests it sets up something
<GrueMaster> rsalveti: The sources.list bug was 659754, but against jasper-initramfs.
<ogra_> it is set there
<ogra_> oem-config doesnt ship apt-setup
<ogra_> iirc
<GrueMaster> How is it done on x86?  Because that works.
<ogra_> in oem-config ?
<ogra_> on the live image casper sets it up
<GrueMaster> Ah.
<ogra_> but ubiquity goes over that sources list later
<GrueMaster> And since we don't use jasper...
<ogra_> we do use jasper
<GrueMaster> Is there a rc.once hook we could add to first-boot?
<GrueMaster> I meant casper.
<ogra_> why would we do that ?
<GrueMaster> To better use the apt api and update the sources.list properly.
<ogra_> jasper uses python-apt just fine to set it up, it just doesnt set up the deb-src lines, i'll simply add them to the script
<GrueMaster> Universe & multiverse are there, just commented.  The api properly uncomments them instead of hacking them on to the end of an existing line.
<GrueMaster> How does casper do it?  Jasper should mimic that functionality.
<ogra_> GrueMaster, we use the same api
<ogra_> its also the same api software-properties uses
<GrueMaster> Very odd.  The sources.list on my panda doesn't look the same as on my x86 VM.
<ogra_> http://paste.ubuntu.com/592844/
<ogra_> thats the script
<GrueMaster> yea, I have the bzr branch.
<GrueMaster> At any rate, more critical issue with pulseaudio-utils.  Bug 758073.  Not sure if it will clobber new images, and since we are in beta freeze with image builds emminent, I think this should take some priority.
<ogra_> grmbl, where is the bugbot
<GrueMaster> awol.
<ogra_> GrueMaster, are you sure your SD is still ok ?
<ogra_> the bug looks more like a filesystem corruption than anything else
<ogra_> GrueMaster, hmm, did you rip out the card while the panda was running ? else your dmesg shows some serious SD errors
<GrueMaster> I installed several other packages ok.  Of course, this is the *great* SD card from Dallas.
<marvin24_DT> GrueMaster: where to report errors in alc5623.c?
<GrueMaster> alsa-devel ml.
<marvin24_DT> ok
<ogra_> hmpf, disconnects ...
<ogra_> GrueMaster, the pulse bug looks like a corrupt FS, the manpage belongs to the pa package
<ogra_> i also wonder why you got ubuntu2 ... ubuntu3 is in the archive since yesterday already
<GrueMaster> Reread the bug report.  Errors were encountered while processing:
<GrueMaster>  /var/cache/apt/archives/pulseaudio-utils_1%3a0.9.22+stable-queue-24-g67d18-0ubuntu3_armel.deb
<ogra_> oh, grrr apport
<GrueMaster> yep
<ogra_> Package: pulseaudio-utils 1:0.9.22+stable-queue-24-g67d18-0ubuntu2 [modified:
<ogra_> :P
<GrueMaster> I renamed the bug report to be a little more readable.  The main info is in the description.
<ogra_> well, its doing valid stuff there, the fact that the file it wants to remove ends in .dpkg-tmp is worrying, but at first glance it looks like a filesystem issue
<ogra_> you pull the SD out without shutting down, right ?
<GrueMaster> I'm not seeing any filesystem issues in dmesg or syslog that correlate time-wise.  The sd issues were from first boot (when my HDMI swithc mangled screen output and I had to reset).
<ogra_> well, at the end of dmesg there is a bunch of IO errors
<GrueMaster> Not sure what they are from.  Corresponding lines in syslog show it to be prior to first login, way before apt-get update;apt-get dist-upgrade.
<ogra_> your disk isnt full, is it ? :)
<GrueMaster> 16GB SD???  No.
<ogra_> its weird that it happens during unpack
<GrueMaster> Yea, well.  As I said earlier, this is on one of the wonderful SD cards we got in Dallas.  I'm trying again on a known good SD.
<ogra_> well, check twice, probably the partition was resized but the fs resize failed or some such
<ogra_> given that we add 50MB spare space that would work a while before you run out of space
<GrueMaster> I've already spent most of the day on this, mainly due to the slow speed of these SD cards.
<GrueMaster> Time to move on an redo.
<ogra_> k
<ogra_> did you upgrade right after install ?
<ogra_> or was that an old install ?
<GrueMaster> This was the 20110410 image, and I tried to do a dist-upgrade shortly after first login (mainly to see if the gconf crash I had was legit.
<ogra_> well, good to know 0410 worked at least :)
<GrueMaster> Well, headless was fubar, but I haven't figured that one out yet.  Only one platform supports serial console and I needed it to test the netbook image.
<ogra_> i can take over QA responsibility for headless if you want but only after the sound stuff is solved
<ogra_> that occupies my time a bit atm
<GrueMaster> No, I can handle it.  Biggest issue is a lack of images.
<GrueMaster> With freeze, it should help.
<ogra_> heh, yeah, that will change soon
<ogra_> and with a hopefully working acorn
<ogra_> (thats the omap buildd)
<ogra_> it crashes way to often recently
<GrueMaster> maybe we should have it switched to one of the beaglexm's.  Little more stable.
<ogra_> funnily it worked fine most of the release with one or two outages to fail close to release ...
<ogra_> its like a deja vu ... i'm 100% positive we had the same in maverick
<GrueMaster> Are they special images or can any of the buildds do image building?
<ogra_> they need to be native and dedicated
<GrueMaster> Might be a good idea to have some sort of intelligent failover.
<ogra_> the pandas will help
<ogra_> it only has to survive until release day
<GrueMaster> I understand both of those, but was currios if the image on them was specific.
<ogra_> yes
<ogra_> its a special setup afaik
<GrueMaster> ok.
<GrueMaster> Still, not a bad idea to have a failover mechanism in case a platform goes out to lunch.
<ogra_> i think the build script can do that as soon as we have more HW
<ogra_> it has mechanisms, but they are currently working on a per-subarch base because we only have two buildds
<GrueMaster> Well, this is good news.  I have a new HDMI switchbox that doesn't auto-jump on signal loss, meaning I can go from poweron first boot to oem-config and still see the screen.
<ogra_> if acorn doesnt come up anymore i can switch omap manually over to the omap4 one for now, if we have more HW i'll switch it to an automated behavior
<ogra_> well, but your switch box was a good stresstest for the driver :)
<GrueMaster> Yes, and still a valid test (since the driver is broken when I use it).  I bought a new one as I plan to reconfigure my office with 3 different stations:  1 VGA, 1 DVI, 1 HDMI/1080p.
<GrueMaster> The DVI will have the systems that don't do 1080p (and will be close enough for crossover testing).
<GrueMaster> I.E. Beagle/BeagleXM/Babbage.
#ubuntu-arm 2011-04-12
<ppisati> ericm|ubuntu: the target to get a binary for a beagleboaard on natty/master is binary-omap, right?
<ericm|ubuntu> ppisati, I believe so
<ericm|ubuntu> ppisati, cooloney should know more detail
<ppisati> ericm|ubuntu: k
<doko> ogra_, janimo: the test rebuild for armel did finish for main, now building the universe packages. however I would like to start another test rebuild using gcc-4.6 for main, setting the priority of this test rebuild higher than the current running rebuild for universe
<doko> ok with you?
<doko> once gcj-4.6 is built
<janimo> doko, fine by me. There are not many important uploads remaining
<doko> ok, thanks
 * ogra_ wishes we could exclude packages on demand for such rebuilds
<ogra_> doko, fine with me, though if all big packages jump on the buoldds at the same time and lock all buildds i'll ask lamont to kill a build
<doko> it's done alphabetically
<doko> and if you are interested, you should be able to set the priority for single remaining builds
<ogra_> ah, i didnt know, yesterday we only had two left, the rest was taken by things like thunderbird, firefox, eglibc gcc etc ...
<ogra_> yeah, i know, doesnt help if all buildds are taken by packages that take more than a day
<ogra_> go ahead, just be aware that i'll ask lamot to kill stuff if its urgent and the rebuild is blocking
<ogra_> (i assume things will get retried anyway if they are killed)
<ogra_> bug 758732
<arun_> has anyone noticed a problem with the gcc-4.5-arm-linux-gnueabi package for natty? it has an unmet dependency: "Depends: libgcc1-armel-cross (>= 1:4.5.2-8ubuntu3cross1.47) but 1:4.5.2-8ubuntu1cross1.61 is to be installed"
<lool> hrw: ^
<arun_> i think it's a recent problem. i updated the toolchain this morning.
<hrw> yes, we know that
<hrw> I have a talk with steve in <1h so we will discuss this too
<arun_> hrw, cool. thanks.
<GrueMaster> headless images fail to start oem-config.
<GrueMaster> debconf database is locked apparently.
<GrueMaster> ogra_: I am going to have to fail the headless images due to bug 758858.
<ogra_> GrueMaster, hrm
<ogra_> netbook looks fine apart from one jasper issue with the ppa icon that i need to fix
<GrueMaster> I just booted netbook.  Appears to be ok so far.
<ogra_> it feels quite a lot slower though
<GrueMaster> Hmmm.  oem-config died near the end on my netbook image.
<GrueMaster> Generating a bug report now.  Not sure if it is reproducable yet (these types of failures take ~30 minutes to reproduce).
<ogra_> didnt die for me here
<ogra_> did you get an apport report ?
<GrueMaster> yes.  Looking over the logs now.  I also have a stack trace.
<ogra_> very strange
<GrueMaster> ogra_: bug 758910.  I'm going to reflash and retry.
<ogra_> GrueMaster, you say it restarted, did it finish on the second run ?
<GrueMaster> yes
<ogra_> hmm, itz gtk boog i'd say
<GrueMaster> Grumble.  Need a proper German translator bot.  :P
<ogra_> lol
<ogra_> well, keep an eye on it, but i doubt we'll see it again
<ogra_> i did three installs already and havent seen it
<GrueMaster> I'm reflashing & retrying now.  Unfortunately my desktop system tends to degrade over time flashing sd cards and I end up having to reboot.
<ogra_> bah
<GrueMaster> Hmm.  Running evolution, firefox, amarok, kde desktop, two VM's in virtualbox and flashing an sd card seems to low my system down a bit.
<GrueMaster> loagavg:  5.90
<ogra_> on the panda ?
<GrueMaster> Pfft.  Panda doesn't do VM.
<ogra_> ah, indeed :)
<GrueMaster> oh, as to the win32 image writer my son developed for jaunty, we are on our own if we want to add functionality to it.  He is too busy to help before summer.
<GrueMaster> I'll see if I can get Ncommander to look at it before release.
 * ogra_ takes a short break and will then jump into headless mode ...
 * GrueMaster thought that was ogra_'s standard modus operendi.  
<GrueMaster> Nice.  My panda is now detecting my wireless AP on the other end of the house.  With no antenae.
<ogra_> there is an antenna on the PCB
<GrueMaster> (also detecting my neighbor's wifi.  Mua haha).
<ogra_> the socket is just for an extender
<GrueMaster> Ah.
<ogra_> i couldnt get bT to work though
<ttyandroid> hi all
<ttyandroid> ubuntu-arm works with Devkit8000?
<GrueMaster> ttyandroid: Possibly.  Try downloading the latest natty headless image to start with.  We also have a netbook image as well.  May need to replace x-loader & u-boot, but the rest of the pool should work fine.
<ttyandroid> Many thks GrueMaster
<GrueMaster> ttyandroid: Be aware that since it is essentially a beagle, not an XM, memory will be a major limitation.
<ttyandroid> GrueMaster:   i have buy one BeagleBoard-XM A3 and stop working
<GrueMaster> HW failure?
<ttyandroid> GrueMaster yes mmc card
<ttyandroid> GrueMaster: i try to buy other Beagleboard-XM but not find
<GrueMaster> The card or the card reader?
<ttyandroid> GrueMaster: card reader
<GrueMaster> Ouch.
<ttyandroid> GrueMaster u-boot bin from original SD don't work
<ttyandroid> GrueMaster: no load other u-boot.bin  and console seems nothing
<GrueMaster> Which image are you trying?
<ttyandroid> GrueMaster original SD image
<ogra> oh, intresting !
<GrueMaster> ogra_: ???
<ogra> on headless i see asoc set up the sound stuff correctly
<ttyandroid> GrueMaster: Angstrom-demo-image
<ogra> on netbook i still had the old errors
<ttyandroid> GrueMaster have another seller of BeagleBoard-xM ?
 * ogra doesnt get that
<GrueMaster> ogra_: that is very odd.
<GrueMaster> ttyandroid: I'm in the US.  I just used Digikey.
<ogra> GrueMaster, http://paste.ubuntu.com/593227/
<GrueMaster> WTH???
<GrueMaster> I'll check it here, since I have two boards to play with side by side.
<ogra> yeah, confusing, isnt it ?
<ogra> headless was built last while netbook was built first in a chunk of ten image builds or so
<GrueMaster> I wonder if it is because of the alsa-utils stuff we added post-maverick?
 * ogra goes to check the manifests
<ogra> thats a good idea .... i'm just noticing that headless doesnt have any alsa userspace stuff
<ogra> i bet TheMuso carried that over from maverick
<GrueMaster> Silly little aussie.  :P
<ogra> well, nobody told him to drop it :)
<ogra> hmm, there are no processes at all on the headless image
<ogra> i dont get why it would fail
<GrueMaster> oem-config?  Don't know either.
<ogra> bah, crap ...
 * ogra forgot he has no job control in the rootshell
<ogra> starting over
<GrueMaster> ogra_: Interesting tidbit.  I removed /usr/share/alsa/init/omap4 and after a reboot, I now have no dmesg errors relating to asoc.  Checking to see if sound works.
<ogra_> GrueMaster, that would be awesome
<GrueMaster> No sound.  Mucked with alsamixer controls, nothing.
<GrueMaster> Haven't tried the patches and updates you have yet.
<ogra_> ah, well, you will need the new pulse from people.c.c
<rsalveti> tried with new pulse and nothing
<ogra_> i get a new device in the sound properties
<ogra_> but it only provides an input device apparently
<ogra_> i sadly dont have the time to play more with wound today
<ogra_> *sound
<ogra_> will have to wait until post beta
<ogra_> well, in any case dropping the maverick scripts should be a step forward
<ogra_> GrueMaster, do you remember when we had the last working headless images ?
<GrueMaster> Beta 1.
 * ogra_ tries to figure out the uboquity changes that might have caused this 
<ogra_> i'm pretty sure there were images after b1
<ogra_> but i dont know for how long
<GrueMaster> I have all dailies since Beta.  Haven't been able to test them as I was hobbled last week.  I can do a binary test and see where the point of failure started.
<ogra_> i would guess with april 3rd
<ogra_> i see two debconf related changes in the ubiquity upload from the 2nd
<GrueMaster> Ok, starting there.
<GrueMaster> ogra_: 20110403 fails
<ogra_> if 02 works i think i know what it is
<ogra_> i'll try to remove that code bit here, lets see what happens then
<GrueMaster> Checking 02 now.
<GrueMaster> (as well as juggling a mirade of other test images).
<GrueMaster> 02 passes.
<GrueMaster> So the relevant version of oem-config is 2.5.32->2.5.33
<ogra_> yep
<ogra_> +  * Do a quick check at startup to see if the debconf database is locked by
<ogra_> +    something else, and exit slightly more gracefully than by raising an
<ogra_> +    exception (LP: #746020).
<ogra_> thats what i suspect to be at fault
 * ogra_ tests
<GrueMaster> Is there a tool to check the debconf db?
<ogra_> no idea
<GrueMaster> Could be a simple boolean error.
<ogra_> i dont think there is a tool
<ogra_> works !
 * ogra_ is at the language selection screen 
<ogra_> aaaand ... install successfully finished \o/
<ogra_> yup, all fine, even after a reboot
<GrueMaster> You mentioned that jasper is doing something with debconf?
<ogra_> yes, but it does that since before beta1
<ogra_> and it does it before the reboot, i already asked colin if it could cause any issue, but he denied
<ogra_> it only sets debian-installer/framebuffer to false
<ogra_> i simply think the check is worng, but i wouldnt know how to write it different or better
<ogra_> i fear we need cjwatson
<steev> hey all, i have an arm machine that unless the hdmi cable is plugged in, it freezes during boot.  i've set the console to equal our serial console, and i added debug=vc to the kernel command line... and it appears it gets to this point: + /scripts/init-top/plymouth
<steev> and then it stops
<GrueMaster> What is the platform?  Image?
<steev> uImage, Maverick, ARM mx515
<GrueMaster> I don't think we had an mx515 kernel for maverick.  I know we didn't have images.
<GrueMaster> Might check with #linaro folks.
<lool> The Linaro kernel supports some mx515 boards, but I guess it's a custom kernel
<steev> you know it is lool :P
<lool> steev: This is in the initrd still; plymouth touches framebuffer (it outputs the boot progress splash and messages etc.)
<lool> steev: To poke at what's happening, you can add break=something to your kernel cmdline, this will give you a shell in the initrd
<lool> steev: rgrep maybe_break /usr/share/initramfs-tools to see possible breakpoints you can use
<steev> lool: my understanding was that, plymouth was supposed to see if it could use a framebuffer and if not (ttymxc0) was supposed to go down to a text console, it doesn't appear to be going to a text console
<lool> steev: For instance, break=top is a good choice to get started
<steev> okay, ill give that a shot :)
<lool> steev: I can't speak for what plymouth attempts to do, you might have to research this yourself; but I can tell you how to run things by hand  ;-)
<steev> well if i can step through it, that will point where i need to go :)
<lool> steev: To read the sources, take the initrd.gz from the system and unpack it in a directory of your choice: mkdir i; cd i; gunzip -c < ../initrd.gz | cpio -i
<lool> steev: That will give you the same contents as what's in the initrd from the shell you will have
<lool> steev: You can run exactly the same shell commands to see at which points it goes wrong
<steev> is there a way to make plymouth itself be a tad more verbose, like saying what it's attempting to do?
<ogra_> GrueMaster, see -release ... fix underway ;)
<GrueMaster> I've been monitoring it.  Cool.
<ogra_> :D
<ogra_> so apart from sound we should be good now
<GrueMaster> Yep.
<ogra_> and the odd color change in headless :)
<GrueMaster> I still don't see that.
<ogra_> i still wonder why only i seem to see it
<ogra_> snap :)
<ogra_> but i see it on all machines, its not client bound ... else i would have blamed the ac100
<GrueMaster> Maybe it looks different when not viewed through a beer glass.
<ogra_> hmm, i should try that
<GrueMaster> heh
 * ogra_ goes to look for a whisky botte to replace the glass
<ogra_> *bottle
<ogra_> GrueMaster, but do you use screen ?
<GrueMaster> screen+byobu
<ogra_> (i think i remember you said byobu)
<ogra_> that might apply colormap changes
<GrueMaster> Well, the system that the serial console is hooked to is headless.  So ssh->byobu->many screen sessions.
<ogra_> ah
<ogra_> i wouldnt mind having it b/w
<ogra_> i wonder if there is a way to enforce that on the installer side
<steev> where does /conf/param.conf come from (we don't have one, which is why i ask)
<GrueMaster> ogra_: I'm going to go ahead and greenlight armel rebuilds after oem-config is fixed.  I haven't found anythhing that is critical and no one on kubuntu is interested in testing prior to rebuild.
<ogra_> GrueMaster, yeah, just go ahead, i'll test tomorrow as soon as i get up
<GrueMaster> That will really help, as I have an am post-op appointment tomorrow.
<ogra_> no prob
<rsalveti> even when setting up the postfix (calling debconf) the colors were weird
<rsalveti> pink and gray IIRC
<ogra_> mine are completely inverted
<ogra_> rendering the whole ui unreadable
<rsalveti> yeah, seems to be inverted
<ogra_> https://bugs.launchpad.net/bugs/747229 has screenshots
<GrueMaster> Wow.  I am definately not seeing that.
<GrueMaster> (of course, I am currently not seeing much of any oem-config atm)  :P
<ogra_> heh
<Schamus> hi is anyone available to help me with a Ubuntu 10.10 ARM/OMAP question?
<Schamus> Run into a bit of a problem working with the USB connection
<GrueMaster> Schamus: Give more details.  What are you seeing?
<Schamus> Quite right, I'm running a Beagleboard xM A3,with ubuntu 10.10. I'm coding a python script to manipulate an LCD screen via USB
<Schamus> The python script uses import serial, sets up the connection, and shoots hex bytes controlling and manipulatingthe screen to show items, however, on the beagleboard its apparently not sending the information over correctly
<GrueMaster> Ok.  Not sure how much help we can be.  have you tried this on x86 first?
<Schamus> On any other laptop this script works perfectly, but the beagleboard does not
<Schamus> So i was curious if USB drivers on the Ubuntu 10.10 ARM edition are a bit different than a standard Ubuntu 10.10 install
<GrueMaster> They should be the same.  I believe the kernel was the same for both x86 & armel.  Could be a config issue though.
<Schamus> How so?
<GrueMaster> Check /bot/config-`uname -r`
<GrueMaster> boot
<GrueMaster> The code is the same tree as x86.  If it is a usb issue, it is either in the core arch code or a missing config option.
<GrueMaster> The rest is arch generic.
<GrueMaster> Also, try the latest maverick kernel or the natty kernel.
<Schamus> yeah i did updates yesterday
<Schamus> so, excuse my amateur, you mean something like "gedit /boot/config-'uname -r' correct?
<GrueMaster> yes
<GrueMaster> (you can actually just use tab completion, but it was easier to type uname -r to indicate the config for the running kernel)
<Schamus> yeah i've been picking up linux over the past month or two so i'm a little ignorant in some basics still
<Schamus> im pulling up a blank with that command
<GrueMaster> type 'ls /boot-config*'.  That should give you a list of config files.
<GrueMaster> Look at the latest one.
<Schamus> Ah, got it now.
<Schamus> is there a specific section im looking at for USB?
<GrueMaster> I have no idea personally.  I don't have one of these lcd screens to try to reproduce this issue with.
<GrueMaster> What image are you running on your laptop?  If it is running the same release, check to see if it has the same kernel rev.
<GrueMaster> That is the easiest starting point.
<Schamus> 10.04 on my laptop, 10.10 on the beagleboard
<GrueMaster> I would suggest upgrading the laptop.  It will be easier to diagnose that way.
<GrueMaster> You can also just download the iso and use usb-creator to make a bootable usb drive to test with.
<Schamus> Yeah, I mean I tried many other USB devices, (i.e. bluetooth dongle, mouse, keyboard) and they all work, just this LCD screen doesn't seem to want to accept streams from the beagleboard
<Schamus> could it be a problem with permissions?
#ubuntu-arm 2011-04-13
<MarcN> my dreamplug just arrived today.  A little disappointed it came with Jaunty preinstalled...
<armin76> lol
<steev> yeah... the jaunty thing was surprising to me too
<hrw> they used 9.04 on original sheevaplug and nearly nothing changed probably in rootfs for new devices
<hrw> kgilmer: hi
<kgilmer> hi hrw.  saw your tweet, sorry not enough people in the meeting :/
<hrw> kgilmer: happens
<hrw> kgilmer: I saw Froyo on bug2 post - nice
<kgilmer> thx, yeah good to get a release out on time.  even if no one is using it...
<kgilmer> hrw, dinner calls.  ttyl.
<ppisati> here comes the 1M question: what the heck is musb?
<GrueMaster> ogra: ping.  When you did the netbook image, did you select autologin?
<ogra_> nope
<ogra_> why ?
<ogra_> do you see issues ?
<GrueMaster> Could you retry it?  I want to see if this is just me.
<ogra_> hrm
<GrueMaster> oem-config restarted on my system.
<GrueMaster> I'm going to restart fresh and retest.
<GrueMaster> Then I have to leave for the Dr.
<rsalveti> ogra: will enable the release ppa with our current sgx packages
<rsalveti> then we can test if it's working fine
<GrueMaster> ogra: I am now seeing the color issues on headless oem-config.  Colors are slightly different here, bug fugly none the less.
<GrueMaster> Didn't see this yesterday (nor did I see oem-config, but hey).  :P
<ogra_> GrueMaster, hmm, my test might take a while, cron decided that it wants to run update-apt-xapian index right before the package removal step
<ogra_> so it sitting there now "waiting for apt to finish"
<ogra_> rsalveti, yeah, one of us needs to do that before release
<rsalveti> ogra_: should be done in a few minutes
<ogra_> though the current image still points to maverick
<rsalveti> hm, yeah, saw that you just fixed these bugs
<ogra_> fix is uploaded, but i didnt want a rebuild for that
<GrueMaster> I'll test the ppa packages later today or tomorrow.  After I get the release testing done.
<ogra_> you will have to fiddle with the channel setup first
<GrueMaster> np
<ogra_> else it pulls maverick
<ogra_> k
<ogra_> if you dropped back into oem-config with autologin enabled, the package removal step cant have run
<ogra_> that looks more like an installer crash
<ogra_> (if package removal would have run, there wouldnt be oem-config binaries)
<GrueMaster> Nothing was in the logs.
<GrueMaster> True.
<GrueMaster> Possible SD corruption.  That's why I reflashed and retried.
<ogra_> yup, i found a bad SD too today
<ogra_> my first one actually
<ogra_> i have five worn out USB sticks, but never managed to trash an SD
 * ogra_ goes upstairs to see how far the xapian crap is
<GrueMaster> Looks like a normal glitch.  It is in package removal phase now.
<ogra_> yup, finished and logged in automatically here
<GrueMaster> Also, I think I found a uboot issue.  On my beagle (C4), I hold the user button when resetting, then it loads uboot from SD.  But it fails to load the boot.scr from mmc unless I do "mmc init ; mmcinfo".
<GrueMaster> If I don't do mmcinfo, fatload fails.
<ogra_> sounds like a broken u-boot
<ogra_> are you sure the one from SD is actually used in that case ?
<ogra_> (compare the versions)
<GrueMaster> X-Loader 1.5.0 (Apr 11 2011 - 09:47:05) & U-Boot 2011.03-rc1 (Feb 09 2011 - 01:33:04)
<ogra_> sounds fine+
<GrueMaster> MMC: block number 0x1 exceeds max(0x0)
<GrueMaster> ** Can't read from device 0 **
<GrueMaster> ** Unable to use mmc 0:1 for fatload **
<GrueMaster> So I reset and go manual.
<ogra_> well, only C4 ...
<ogra_> we can document around it
<ogra_> as long as xm works fine
<rsalveti> weird, will try to reproduce at my C4
<rsalveti> xm should be fine
<GrueMaster> Yea, xm is fine.  No nand to fall back on.
<GrueMaster> Ok, panda netbook worked this time.
<GrueMaster> Gotta go.  Dr. appt.
<ogra_> good luck
<GrueMaster> Just pulling a few stitches.  I'm getting more mobile each day.  Currently at ~60%.
<alf_> Hi! Currently the omap4 gfx -dev packages replace, provide, conflict: libgles2-dev, libgles2-mesa-dev
<alf_> Is the 'libgles2-mesa-dev' part because some packages only have libgles2-mesa-dev as a dependency instead of libgles2-dev | libgles2-mesa-dev?
<rsalveti> alf_: if you check the mesa package, it's not providing libgles2-dev for example
<rsalveti> it just provides the normal package, not the -dev ones
<rsalveti> that should probably be fixed too
<rsalveti> tried to talk with roaf be got no answer
<rsalveti> alf_: I believe the only package that is depending on the mesa one is the mesa-utils
<rsalveti> most other packages are depending on libgles2-dev | libgles2-mesa-dev
<alf_> rsalveti: and cairo, too
<rsalveti> alf_: hm, why cairo is depending directly on the mesa packages?
<alf_> rsalveti: not sure, just noticed it probably just a mistake
<rsalveti> yeah
<alf_> rsalveti: I will send an email to raof and cc you
<rsalveti> alf_: cool, thanks
<rsalveti> would be good if we could get that fixed before the release
<alf_> rsalveti: so just to be in tune, we want libegl/gles...-mesa-dev to provide/conflict/replace libeg1/gles2...-dev, right?
<rsalveti> alf_: yes, I believe that would be the right solution, but not yet sure, that's why I wanted to talk with raof
<rsalveti> to understand how it's done with GL, and nvidia/radeon drivers
<rsalveti> the libegl1/gles2-dev are needed because we want to depend on something that can be used by the packages
<alf_> rsalveti: yes, we need to come up with guidelines of how to package up alternative drivers... so other vendors can package up correctly
<rsalveti> the only thing it seems weird is that in the end the provided packages for -dev are all the same, even if it's from mesa, sgx or imx
<rsalveti> as the headers should all be the same, provided by khr
<rsalveti> alf_: yes
<alf_> rsalveti: well almost, eg eglplatform.h can be different
<rsalveti> alf_: why? because x11 integration?
<rsalveti> if they are all the same we could just have a common header package
<rsalveti> but not yet sure if they need to be the same
<rsalveti> or if the vendor could also add some other definitions there
<alf_> rsalveti: khronos recommends to use their file (of course ;)) but each vendor may need additional intergration with systems not covered by the default headers
<rsalveti> alf_: hm, ok
<alf_> rsalveti: or variations of existing systems etc for which the default is not suitable
<rsalveti> alf_: but then, if we compile a package with a specific set of headers, is it going to work fine with a different set of libraries?
<rsalveti> if we can't guarantee that then the 'provide' is not necessarily right
<alf_> rsalveti: supposedly, everyone should provide the same (or equivalent) definitions for the same system config
<alf_> rsalveti: Khronos STRONGLY RECOMMENDS that you use the default definitions * provided below, since these changes affect both binary and source * portability of applications using EGL running on different EGL * implementations.
<rsalveti> ogra_: this is the current postinst script for the extra package: http://paste.ubuntu.com/593647/
<rsalveti> ogra_: what do we need to change to fit the unity-2d favorite system?
<rsalveti> alf_: I see
<rsalveti> it should be the same bug we cannot guarantee
<rsalveti> I'd prefer to have a common package set for the headers
<rsalveti> so we can kind of force the vendors to respect the default definitions
<rsalveti> but then, would prefer to discuss this with raof
<rsalveti> to understand if they had the same issues with the normal desktop gl drivers
<rsalveti> alf_: can you put these questions at your email?
<alf_> rsalveti: the thing is that they may want to just extend them and forcing a single set of headers won't do (for them)
<ogra_> rsalveti, unity-2d uses a gconf key for the list of favorites
<ogra_> so some gconftool-2 call that removes the .desktop file from that list is needed
<rsalveti> alf_: yeah =\
<ogra_> though hmm
<ogra_> you can just remove the override file that adds this entry and run update-gconf-defaults
<rsalveti> ogra: first I don't understand why this script was removing the .desktop file
<rsalveti> probably a hack
<ogra_> yes, and still in place
<rsalveti> but why we need to remove it?
<ogra_> because its not comoing from a package
<rsalveti> oh, sure
<rsalveti> once installed it should remove the icon
<rsalveti> as jasper is the one putting it there
<ogra_> right
<rsalveti> ogra_: can you create this new postinst script?
<ogra_> rm /usr/share/gconf/unity-2d/default/25_jasper-favorites-override
<rsalveti> I believe you can easily test at your system
<ogra_> update-gconf-defaults --source /usr/share/gconf/unity-2d/default --destination /var/lib/gconf/unity-2d.default --no-signal
<ogra_> thats what needs to be added
<rsalveti> hm, ok
<ogra_> for oneric i'll finally put some time into doing it with a package
<rsalveti> ogra: so /usr/share/gconf/unity-2d/default/25_jasper-favorites-override is now the file that jasper is installing?
<ogra_> right, it pulls the original favorites list out of the ubity-2d file
<ogra_> and appends the ti .desktop entry
<ogra_> because its a higher sequence number update-gconf-defaults then overrides the default entry
<rsalveti> ogra_: oh, ok
<rsalveti> ogra_: http://paste.ubuntu.com/593654/
<ogra_> so rm'ing it and running update-gconf-defaults again will restore the original system defaults
<ogra_> well, and the .desktop file
<ogra_> you should still remove it to not leave unpackaged cruft around
<rsalveti> yeah, sure
<ogra_> but yes, apart from that thats what should happen
<rsalveti> ogra_: is there any image where I can use to test this?
<rsalveti> with your latest jasper fixes
<ogra_> no
<ogra_> unless someone re-rolls
<rsalveti> hm, ok
<ogra_> but you can manually hack the two files in netbook
<ogra_> /usr/share/app-install/channels/ has the files
<ogra_> you want to modify .list
<ogra_> (indeed before clicking the TI icon)
<rsalveti> sure
<rsalveti> ogra_: should we also remove the ti-ppa.svg or we can't?
<ogra_> rsalveti, that should probably go too, yeah
<rsalveti> ogra_: ok
<rsalveti> ok, I'm upgrading my natty rootfs and should be able to test it soon
<GrueMaster> ogra: That oem-config restart issue I saw earlier on panda netbook I am seeing again on my beagleXM.
<GrueMaster> Way more than possible coincidence.
<jcrigby> rsalveti, we would like to update u-boot but obviously do not want to break you guys in the process.   My proposed branch is here:https://code.launchpad.net/~jcrigby/ubuntu/natty/u-boot-linaro/proposed-2011.04.1  slangasek  is working on merging it
<rsalveti> jcrigby: we should be fine with it, did you test with latest x-loader with both omap3 and 4?
<jcrigby> rsalveti, the reason is device tree support needs to be there for Linaro 11.05 release
<jcrigby> yes
<rsalveti> jcrigby: hm, ok
<rsalveti> jcrigby: will test it with our images here, ping you back once it's done
<jcrigby> thanks, I realize I may not have latest x-loader.  An update happened but flash kernel didn't like my arch name
<jcrigby> not sure if latest was in the last hwpack I downloaded
<jcrigby> I will test again
<rsalveti> jcrigby: ok, latest one was uploaded at the beginning of this week
<jcrigby> ok, my hwpack was from last week
<dcarr_home> Hey
<dcarr_home> Are there any good opengl examples in the ubuntu 10.10/TI ppa for testing OpenGL (ES) support on the panda board?
<dcarr_home> any help would be greatly appreciated
<rsalveti> dcarr_home: if you build the mesa-utils package available at natty you'll be able to run es2gears
<rsalveti> a nice and simple example
<GrueMaster> rsalveti: Is the edid detect code in the omap kernel yet?
<rsalveti> GrueMaster: nops
<GrueMaster> ok.
<dcarr_home> rsalveti: thanks
#ubuntu-arm 2011-04-14
<jcrigby> rsalveti, just to let you know.  I have now tested the proposed u-boot with the latest x-load on panda and beagle
<jcrigby> beagle c4
<rsalveti> jcrigby: yeah, just tested fine on panda, xM and at my c4
<rsalveti> I'm now booting at my b5
<jcrigby> rsalveti, thanks for doing that
<rsalveti> jcrigby: http://paste.ubuntu.com/593805/
<rsalveti> at my B5
<rsalveti> jcrigby: same sd card works fine at my C4
<rsalveti> jcrigby: could be a regression, just don't know exactly which upload could be the culprit one
<rsalveti> quite a while that I don't test it with my B5
<jcrigby> hmm
<rsalveti> let me flash a maverick sd card and we can start tracing it
<rsalveti> want also to make sure it's not the x-loader
<jcrigby> ok
<rsalveti> or not a hardware issue
<rsalveti> jcrigby: yup, 2010.09-rc1 from maverick worked fine
<rsalveti> so it's a regression
<jcrigby> ok, thanks
<rsalveti> will try with the one we're using, then I can just open a bug for it
<rsalveti> using at the image
<rsalveti> also, let me first update just the x-loader
<jcrigby> ok, so latest in archive is also broken?
<jcrigby> for B5
<rsalveti> jcrigby: trying now
<rsalveti> jcrigby: worked fine with latest x-loader
<rsalveti> so it's probably a regression at u-boot
<jcrigby> ok
<rsalveti> jcrigby: yup, broken
<rsalveti> jcrigby: https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/760350
<jcrigby> so 2011.02.1 is also broken
<jcrigby> rsalveti, I believe that is what is the latest in the archive right?
<rsalveti> jcrigby: yes
<jcrigby> and we don't  know when the regresson happend.  Just sometime between 2010.09 and 2011.02.1
<jcrigby> rsalveti, this is going to be fun
<rsalveti> jcrigby: haha, yeah :-)
<rsalveti> there's also a new error with latest u-boot: timed out in wait_for_pin: I2C_STAT=0
<rsalveti> but can be normal, probably trying to identify the expansion board
<rsalveti> but would be good to check
<jcrigby> yes, I saw that too, I will make sure it is expected with no expansion board
<TheMuso> ogra_: FYI, threw in another patch from upstream for UCM. It basically enables UCM only for devices that have a UCM argument setin the udev rules, which should now cover OMAP4.
<rsalveti> jcrigby: will be out for dinner, should be back in one hour, then we can try to bisect it
<TheMuso> ogra_: So source should b epublished by the time you get online.
<jcrigby> rsalveti, I will be out then so may need to wait until tomorrow.  I will be back later tonight I will ping you.
<rsalveti> jcrigby: sure, np
<jcrigby> sakoman, ping?
<GrueMaster> TheMuso: Does that also cover omap?  It will have UCM support as well, hopefully by next week.
<TheMuso> GrueMaster: Yes it does.
<GrueMaster> Excellent.
<TheMuso> As I said, the udev stuff is to cover omap4
<GrueMaster> OK.  That looks like jack detection, which isn't needed for beagle/beaglexm but may be needed for other omap based systems.  Not worried about it now.
<TheMuso> Its not jack detectino. It basically uses a definition in the pulse udev rule to tell pulse to enable UCM only for omap4, which reduces regression potential for other hadrware.
<GrueMaster> Oh.  Hmmm.  I'll have to look over the patches again.
<GrueMaster> This is from PA_UCM_patches_20110407.tar.bz2 right?
<TheMuso> No, its another one that was sent to david and myself.
<GrueMaster> Not attached to the bug?  Hate when that happens.
<TheMuso> Its in teh package I just uploaded to my PPA.
<GrueMaster> ok
<TheMuso> I'll attach it to the bug if you'd like.
<GrueMaster> It makes tracking easier, but I can find it.
<TheMuso> ok
<jcrigby> rsalveti: http://comments.gmane.org/gmane.linux.distributions.gumstix.general/57467
<jcrigby> looks like multiblock reads are broken in older omap silicon
<rsalveti> jcrigby: yeah, that makes sense
<rsalveti> jcrigby: will try that patch
<NCommander> rsalveti: re: IC2_ERROR, almost certian that error has to deal with the expansion port.
 * NCommander is catching up on backscroll)
<rsalveti> yup, probably
<jcrigby> rsalveti, I'm going to do a patch that would be acceptable to upstream.  Something like what gcl suggests in the thread.
<jcrigby> rsalveti, that is if it works for you
<rsalveti> jcrigby: cool, sure
<rsalveti> jcrigby: yup, worked fine
<jcrigby> great!, thanks
<rsalveti> GrueMaster: ogra_: https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/760350
<rsalveti> this should be at the beta-2 release notes
<rsalveti> our image doesn't work with older beagles, probably <= rev B5
<rsalveti> jcrigby: just updated the bug with the test result
<GrueMaster> Ok.  Very odd, but I'm not sure we really even support hw <512M (except maybe headless).
<jcrigby> GrueMaster, that might explain why this problem has never been reported
<GrueMaster> I've seen my own issues with u-boot on beagle C4.  Currently, when I reboot I hold the user button to load x-loader & uboot from SD, but my bootcmd fails.
<GrueMaster> bootcmd=bootcmd=mmc init;mmcinfo;if fatload mmc 0 0x82000000 boot.scr;then echo boot.scr found! Executing ...;source 0x82000000;fi
<GrueMaster> It would fail without the mmcinfo.
<rsalveti> GrueMaster: headless image can be useful for those old boards
<rsalveti> GrueMaster: can be be used to be a small server, or something like that
<GrueMaster> yes, I realize that.  That's why I dusted mine off and have it hooked up.
<GrueMaster> I usually install openssh, and basic server.
<rsalveti> we don't expect it to work fast, but it should at least boot :-)
<GrueMaster> Fast is relative to the bottlenecks in the environment.  For a printerver, it should be great (haven't tested yet).
<rsalveti> yeah
<GrueMaster> Unfortunately, my office is in flux and need of an overhaul (hopefully this weekend).
<ppisati> what's musb?
<hrw> musb is TI driver for OTG port in omap2-4 chip
<ogra_> can you use more acronyms please :P
<ppisati> :)
<ppisati> and, do i need a particular cable for OTG?
<ppisati> or any usb should do it?
<ppisati> s/usb/usb cable/
<hrw> which board?
<ppisati> beagle
<ogra_> which beagle :=
<ogra_> :)
<ogra_> (model)
<hrw> for device you just use normal miniusb cable
<ppisati> beaglxm in this case
 * hrw has only c3/b7
<ppisati> so, can i connect the xm to my pc using the mini-usb connector? the one used to power it? is it ok?
<ogra_> i thought linaro is drowning in XMs, they didnt gove you one ?
<ogra_> *give
<ppisati> anyway, i've a plain beagle too
<hrw> yes, you can connect
<ppisati> uhm, k
<hrw> ogra_: do I look like a8 collector? :D
<ppisati> because we have 2 issues here
<ogra_> heh
<ppisati> first, in natty we lost the musb driver
<hrw> ogra_: I do not use beagles now
<ogra_> who does anyway ;)
<ppisati> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759913
<ppisati> and the second, is that the musb is kind of broken
<ppisati> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/608312
<ppisati> but i can't get the a_idle state with the cable connected
<ppisati> anyway, i'll debug it a bit more
<ogra_> ppisati, i would recommend talking to koen on #beagle
<ppisati> koen?
<ogra_> he probably has fixes for such bugs in angstrom already
<XorA|gone> musb is broken in upstream 2.6.38 kernel
<XorA|gone> Angstrom doesnt have a fix
<ppisati> that's a patch provided by cooloney, should work in maverick (didnt;'t try yet)
<ogra_> XorA|gone, ah, thx
<ppisati> but the same patch makes my board hangs at boot in natty
<ppisati> XorA|gone: what you mean is broken?
<XorA|gone> ppisati: will go into host mode but will never negotiate a usb address successfully with device
<ppisati> XorA|gone: it doesn't work? it doesn't attach? it panics? it format the sd and install freebsd? :D
<ppisati> XorA|gone: but i should get the "a_idle" state with the cable connected, right?
<XorA|gone> ppisati: I cant rmemeber the states, it does get you all hopeful and does detect device insertion
<ppisati> ok
<XorA|gone> I think agreen was looking into something similar
<ppisati> ok
<ppisati> anyway, time to debug some more
<ogra_> does anyone know if the usb based booting on the panda can pull the kernel via usb too ?
<hrw> ogra_: omap4 bootrom loads xloader from usb and gives control to it - right?
<ogra_> i think it loads MLO and u-boot
<ogra_> but i'm not sure if u-boot then has access to the usb link to pull the kernel from there
<hrw> probably not
<ogra_> then i wonder whats the benefit of it
<ogra_> if i need the SD to hold the kernel anyway, it seems to be a bit pointless
<hrw> ogra_: if xloader is able to fetch uboot from usb then it is able to fetch kernel instead of uboot too
<ogra_> hmm
<hrw> and if you merge initramfs into kernel image...
<ogra_> yes, that could probably work
<lool> ogra_: There is a tool from TI to do this USB boot stuff
<ogra_> lool, i know, i read the doc, but it only talks about loading MLO and u-boot
<ogra_> and io was wondering how to then get the kernel if u-boot doesnt have USB support ...
<ogra_> though the merged kernel/initrd instead of u-boot loading might work
 * ogra_ tries to find an alternative way of providing PPAs without having to use the addon board 
<ogra_> lool, i'm collecting spec ideas ... i was wondering if we should have a flash-kernel rewrite spec so we can break up the stuff into assigned work items
<lool> ogra_: Dunno
<doko_> janimo, ogra: armel rebuild with GCC 4.6 and binutils trunk started: https://launchpad.net/ubuntu/+archive/test-rebuild-20110419-arm/+builds?build_text=&build_state=failed
<doko_> yes, typo in the date
<armin76> go future
<ogra_> looks pretty calm
<ogra_> if you stop it now we wont have much work :P
<ppisati> cooloney: dude, i can't musb to enter a_idle state
<ppisati> flag@omap:~$ cat /sys/devices/platform/musb_hdrc/mode
<ppisati> b_idle
<sakoman> jcrigby: very belated pong :-)
<ppisati> exactly, what do i have to do to reproduce your scenario?
<ppisati> cooloney: lp608312
<ppisati> i'm powering my beagle xm via the usb socket
<ppisati> is it enough? shall i get a_idle?
<ogra_> doko_, i see you still have an open natty WI on the armel tracker
<ogra_> do you plan to get to that (testing xvfb on hatty) or should it probably be postponed ?
<ogra_> (or is it done already and just missing the paperwork)
<doko_> ogra: pointer?
<ogra_> http://people.canonical.com/~platform/workitems/natty/ubuntu-armel.html and https://launchpad.net/ubuntu/+spec/multimedia-desktop-n-xorg-general-planning
 * ogra_ wonders why that spec is associated at all with the armel team
<doko_> ogra: hmm, don't know why. I appear to show up on different teams ... but it's done
<ogra_> :)
<rsalveti> ogra_: you can boot and get everything you need by the musb
<ogra_> rsalveti, ah, sweet, that could be an alternbative to the addon board for PPAs then
<rsalveti> also, there is a u-boot patchset that enables the smsc usb+eth device
<ogra_> indeed we need a central USB server
<rsalveti> with that we can probably use tftp
<ogra_> cool, so lets have a BOF and spec for that in O
<ogra_> :)
<rsalveti> jcrigby: did you ever try this smsc patchset with your panda?
 * ogra_ added something to the spec ideas wikipage
<ogra_> rsalveti, btw, i think "Send the pull request to the kernel team" WI can be closed ... request was sent :)
<rsalveti> ogra_: haha, sure, will close and put some more comment on the bug
<ogra_> :)
<ogra_> i guess we have to hope for an SRU here
<ogra_> up to the kernel team though
<rsalveti> yes, I'm planning to make another patchset, and also send it upstream at the same time
<rsalveti> if we get good reviews, then it'll be easier to do an SRU
<ogra_> yeah
<rsalveti> will just update the sgx drivers again and will get back to this patchset
<ogra_> rsalveti, oh ! i thought the WI was only omap3
<rsalveti> ogra_: it was
<ogra_> "send it upstream, to omap4 branch and to Linaro, to get more feedback"
<rsalveti> ogra_: it should be included at omap 4 branch
<ogra_> ah
<rsalveti> to have xrandr support
<ogra_> i thought it was already
<rsalveti> that's fine
<rsalveti> no, not yet
<jcrigby> rsalveti, patchset?
<rsalveti> upstream to get more feedback
<ogra_> k
<rsalveti> and linaro just to also add this functionality
<rsalveti> ogra_: that's why I didn't create more WI for it, because the original plan was just omap 3
<jcrigby> sakoman, google is my friend.  It was about the broken multiblock xtrers on old beagles
<rsalveti> jcrigby: the smsc one, that adds usb+eth support
<jcrigby> sakoman, sent a fix to list last night
<rsalveti> jcrigby: I'm about to build and try your fix
<jcrigby> rsalveti, oh good (on both)
 * ogra_ sees an u-boot upload, does that already include the fix ?
<jcrigby> rsalveti, is is patchset in history here?
<rsalveti> jcrigby: nops, saw it at the u-boot m-l
<jcrigby> rsalveti, oh ok, I'll go look.  I was thinking yesterday that it really is a pain to plug/unplug sd card for every kernel or u-boot rebuild
<rsalveti> jcrigby: yes, at least tftp support would be nice
<ogra_> no hurry though :)
<ppisati> tftp support would be awesome
<ogra_> hatty is nearly done
<ogra_> *natty
<sakoman> jcrigby: I guessed that from the discussion earlier
<sakoman> I'll look at the list for the patch
<rsalveti> jcrigby: yup, worked fine
<rsalveti> jcrigby: will comment at the bug
<jcrigby> rsalveti, fantastic
<rsalveti> will reply with a tested-by too
<jcrigby> great
<rsalveti> jcrigby: ops, one bug
<rsalveti> jcrigby: xm ES revision is ES1.0
<jcrigby> rsalveti, crap
<jcrigby> rsalveti, I put the ifdef in there to only get OMAP3 but I forgot about different omap3.
<jcrigby> so if 34xx and old is the condition
<jcrigby> then we avoid 36xx right?
<rsalveti> jcrigby: 35xx should be fine (probably this 34xx)
<rsalveti> jcrigby: afaik yes
<jcrigby> ok, I'll go rev the patch, may need to ask sakoman for help
<rsalveti> at least XM ES1.0 works fine with multi-block read
<jcrigby> right, patch as is will just slow it down
<sakoman> jcrigby: was just reviewing the patch and noticed the same thing
<sakoman> I think a run time check for cpu type and revision is needed
<jcrigby> sakoman, right
<sakoman> since we have a single binary for both 35xx and 37xx
<sakoman> there are still a few places in the kernel that make this same error iirc
<jcrigby> ok, so I will leave the ifdef to leave omap4 out
<jcrigby> and change the runtime check
<rsalveti> yeah, that should do it
<sakoman> there is code in sys_info.c to get cpu type and revision
<rsalveti> I'm also afraid the same issue happens at the kernel
<jcrigby> sakoman, for kernel it needs to be just runtime checks right?
<sakoman> correct
<sakoman> since we want a single omap binary
<jcrigby> right
<sakoman> u-boot is at least board specific, so you only need to deal with the board options
<jcrigby> sakoman, one more dumb question, what are AM35xx devices?
<sakoman> jcrigby: I believe that is what TI calls "Sitara"
<jcrigby> ok, yes
<sakoman> http://focus.ti.com/dsp/docs/dspplatformscontento.tsp?familyId=1875&sectionId=2&tabId=2643
<jcrigby> sakoman, ok changing to	if ((get_cpu_family() == CPU_OMAP34XX) && (get_cpu_rev() <= CPU_3XX_ES21))
<sakoman> jcrigby: seems reasonable to me
<jcrigby> ok, thanks
<hrw> http://www.amazon.com/dp/B004EPV7TK/ref=xs_gb_A3BWIOFSXKB0OY?_encoding=UTF8&smid=A1KWJVS57NX03I&pf_rd_p=441937901&pf_rd_s=right-1&pf_rd_t=701&pf_rd_i=20&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1JPCN2R605ZZV5R7T0DN - Tegra2 tablet for 280USD
<rsalveti> cool
<Sarvatt> its been abandoned by nvidia, i dont recommend it :)
 * Sarvatt has one
<GrueMaster> Why was it abandonded?
<hrw> Sarvatt: harmony?
<Sarvatt> yeah
<Sarvatt> they moved on to a newer platform
<hrw> http://developer.nvidia.com/tegra/forum/honeycomb-harmony
<hrw> For our partners' Android devices, NVIDIA provides support until the hardware partner chooses to no longer support the device. So, for instance, NVIDIA will support the Xoom on all versions of Android Motorola requests until Motorola ceases to support the Xoom. The same goes for ViewSonic with the G-Tablet, Notion Ink with the Adam, Acer with the Iconia, LG with the Optimus 2X and so on.
<Sarvatt> oh good, they updated it yesterday
<hrw> yes
<Sarvatt> aside from that the viewing angles on the screen are horrific on it, it really hinders using it as a tablet
<Sarvatt> haven't been able to find a decent replacement screen for it yet because its a really thin type, something like an asus transformer is well worth the extra 130 bucks
 * rsalveti lunch
* GrueMaster changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  wanna cross build ? http://42.pl/u/2u8U | Natty Neta 2 at http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/beta-2/| Now taking ideas for Oneric at https://wiki.ubuntu.com
* GrueMaster changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  wanna cross build ? http://42.pl/u/2u8U | Natty Neta 2 at http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/beta-2/| Ideas for Oneric at https://wiki.ubuntu.com/ARM/Oneric
* GrueMaster changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  wanna cross build ? http://42.pl/u/2u8U | Natty Beta 2 at http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/beta-2/| Ideas for Oneric at https://wiki.ubuntu.com/ARM/OnericObjectiv
<GrueMaster> grrr.
* GrueMaster changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  cross build ? http://42.pl/u/2u8U | Natty Beta 2 at http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/beta-2/| Ideas for Oneric at https://wiki.ubuntu.com/ARM/OnericObjectives
<GrueMaster> Yea!
<zaery> what is the package name of the new onscreen keyboard
<GrueMaster> zaery: florence
<zaery> thx
<GrueMaster> You should be able to find it in universe.
<zaery> installed, but how do i start  it
<GrueMaster> Not sure.
<GrueMaster> There are two packages.  florence & florence-applet.
<GrueMaster> I'll load them in a sec and test.
<GrueMaster> what image are you working with?
<zaery> natty x86
<zaery> keyboard up.
<zaery> can it auto show/hide?
<GrueMaster> I have no idea.  I haven't worked on it or with it.
<GrueMaster> I just remember it being packaged by a teammate.
<GrueMaster> If you are using this on x86, why ask on #u-arm?
<zaery> david said to talk to his guys here :)
<GrueMaster> ah.
<zaery> will also be looking at arm tablets soon
<GrueMaster> Amazon is having a fire sale on the Viewsonic tablet.
<GrueMaster> I'm not sure that florence is unity compliant.  I installed it on my netbook (amd64) and it doesn't show up in the applets icons.  I can launch it through the dash under Universal Access.
<zaery> david couldnt remember the name. he said it was brand new
<GrueMaster> Yea, still very early development.
<easwar> o/
<easwar> I'm having trouble getting Ubuntu to boot on a BB xM Rev B
<easwar> I did the install and the boot.scr to give me a serial tty login
<GrueMaster> Which image are you using?
<easwar> GrueMaster, the maverick omap 3 preinstalled
<GrueMaster> We have a headless image specifically for this purpose.  http://cdimage.ubuntu.com/ubuntu-headless/releases/natty/beta-2/
<easwar> GrueMaster, no, I want the GUI
<GrueMaster> The preinstalled maverick images assume you have kvm.
<GrueMaster> Then you need to add console=/dev/tty1 as well as serial console.
<easwar> GrueMaster, ok, and what's the deal with cdimage.ubuntu.com/ubuntu-netbook/ports/releases tree having both maverick and 10.10 as child directories?
<easwar> which one are you supposed to select?
<GrueMaster> For maverick on beagleXM, follow the instruvctions at https://wiki.ubuntu.com/ARM/OMAPMaverickInstall.  As to the release naming, one is a link to the other.  maverick is the codename for 10.10
<easwar> GrueMaster, ok, so one is a symlink to the other
<GrueMaster> Line natty is the code name for 11.04.
<easwar> cool
<GrueMaster> Also, there is an issue with booting the stock maverick image on beagleXM >rev A3.  They changed the hardware right at release time.
<GrueMaster> Requires a kernel fix (which is in maverick updates) to enable video.
<easwar> GrueMaster, that is the same as the one on the OMAPMaverickInstall page, correct?
<GrueMaster> yes
<easwar> downloading the kernel and uimage from rsalveti's page
<GrueMaster> Follow the directions on the https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<GrueMaster> Very straight forward.
<easwar> GrueMaster, yes, those are the ones I'm following
<GrueMaster> For grins, you should also try the new Natty Beta 2 image (just released today).
<GrueMaster> see /topic for link.
<easwar> GrueMaster, might try it later, right now this is kinda (academic) project critical
<easwar> :)
<easwar> thanks for your help !
<ogra_> GrueMaster, what do you think about a packaging tools profiling spec ? to identify the slow areas of dpkg/apt/update-manager
<ogra_> (i think you suffer most from the slowness)
<GrueMaster> I think it might get resolved with armfp, but I don't know.  I think it is related to fp emulation as opposed to hw fp.
<ogra_> (armhf) ;)
<GrueMaster> yea, that
<ogra_> well, i think its a general issue on SD cards as well
<ogra_> hardfloat will surely improve a bit here
<GrueMaster> I get varying degrees of performance from different SD cards.  For example, package updates are 2x faster on my 8G class 10 than on the microcenter 16G class 6 cards.
<ogra_> well, but what means 2x faster ?
<ogra_> its still likely 3x slower than say your x86 netbook
<GrueMaster> I'd have to run time sudo apt-get update on both with the same base image to give details.
<GrueMaster> but even flashing the sd cards is a noticeable difference.
<ogra_> well, then not only the same base image but the same media
<ogra_> well, was just an idea for a possible spec
<ogra_> its just that it feels like the whole system is totally responsive but a dist-upgrade with 120 packages takes half a day
<GrueMaster> I think the SD size has something to do with it as well.  I flashed the omap netbook image onto a 4G microSD Class 6 at 8.0MB/s and the omap4 image on a 8G class 10 at 4.2MB/s
<ogra_> at least thats my impression
<GrueMaster> Yes, that is true.
<GrueMaster> Part of it is download & SD io.
<ogra_> i think its more the unpack/configure phase than download actually
<GrueMaster> I see a 4-10x speed improvement using my internal mirror instead of ports.u.c.
<ogra_> sure, we cant do much about the download speed ...
<GrueMaster> Depending on activity/time of day.
<GrueMaster> hence the internal mirror.
<ogra_> but i think there is room for improvement for the debconf stuff
<GrueMaster> Possibly.  What about btrfs support?
<ogra_> not sure how well resizing works with it
<rsalveti> fs benchmarks would be nice
<ogra_> we should consider it for sure
<ogra_> i was a bit in love with nilfs2 recently
<GrueMaster> I remember it was argued against in maverick as it was still too early, and that carried forward with natty while we still had .35 based kernels.
<ogra_> but it has no resize options at all :(
<GrueMaster> ouch.
<ogra_> i have seen measurements that show its even faster than btrfs
<ogra_> and its a snapshot based fs
<GrueMaster> ext3 faster than btrfs?
<ogra_> you can roll back to any state you like
<GrueMaster> Ah.
<ogra_> ext3 is slower than btrfs i think
<ogra_> at least on SD
<ogra_> btrfs has specific SD optimizations
<GrueMaster> I know there is a conversion tool.  Wonder if it could be added to jasper.
<ogra_> so it would actually be good to switch, but its a question of stability and feature completeness
<GrueMaster> Definately some things to test in early Oneric alpha.
<ogra_> we should find out what the actual last blocking factors are in ubuntu
<ogra_> if its just some grub issues we dont need to care for example
<ogra_> i'm not sure conversion is such a good idea
<GrueMaster> That was on the n900 kubuntu-mobile wiki.
<ogra_> you are gambling with the users data ...
<GrueMaster> https://wiki.ubuntu.com/ARM/n900
<GrueMaster> The conversion could be run after grow-root. No user data to implode.
<GrueMaster> I can do some experiments on it, but I should see about getting alsa-ucm support for beagle first.
<ogra_> yeah, thats all oneric ...
<ogra_> note it down as idea though :)
<GrueMaster> Added to wiki.
<ogra_> awesome
<ogra_> GrueMaster, i have changed the monimal size req for headless from 4 to 2G on the wikipage
<GrueMaster> Ok.
<ogra_> (for headless thats sufficient)
<GrueMaster> Hrm.  Looks like btrfs is still in flux.
<ogra_> yeah
<ogra_> still not default in ubuntu
<ogra_> i think arnd from
<GrueMaster> Beyond that.  They haven't finalized the format.
<ogra_> #linaro works upstream
<GrueMaster> https://btrfs.wiki.kernel.org/index.php/Main_Page
<ogra_> well, the warning is for .31
<ogra_> we'll be at 39 or 40 in oneric
 * ogra_ goes to make some meeting coffee
<GrueMaster> v2.6.37 (January 2011) On-disk free space cache, asynchronous snapshots, unprivileged subvolume deletion, extent buffer switches from a rbtree with spinlocks to a radix tree with RCU.
<GrueMaster> From the changelog.
<ogra> yep
<ogra> line is up
<ogra> ergh
#ubuntu-arm 2011-04-15
<rsalveti> sebjan: how many days are you going to be out for vacation?
<ogra> hmm, so i see the analog device in pulse now
<ogra> and can select pulse profiles
<ogra> but i cant select the analog device as output
<ogra> [ 2928.497467] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
<ogra> [ 2928.582244] omapdss DISPC error: SYNC_LOST_DIGIT, disabling TV
<ogra> rsalveti, ^^^^
<ogra> ndec, ^^^
<arun_> ogra, is this related to the pandaboard display issue?
<arun_> actually, i think that's only an issue with linaro kernels. nevermind.
<Wizard> yo
<Wizard> does anybody run ubuntu on pandaboard?
<prpplague> Wizard: it is probably the most popular full distro that prople run on beagle board and panda board
<Wizard> :)
<Wizard> cool
<Wizard> thanks prpplague
<prpplague> Wizard: http://www.elinux.org/PandaBoard_Netbook
<XorA|gone> prpplague: where mine :-D
<XorA|gone> my netbook is still x86 :-)
<prpplague> XorA|gone: hey hey
<prpplague> XorA|gone: you name got kicked around a few times this week
<XorA|gone> like an old deflated football :)
<prpplague> XorA|gone: more like the corpse of a dead dog in an alley
<XorA|gone> hehe
 * prpplague jokes with XorA|gone 
<XorA|gone> prpplague: were you at ELC?
<prpplague> XorA|gone: as soon as i get my hands on some phycores, i'll get you a net boot
<prpplague> XorA|gone: yea
<prpplague> XorA|gone: did a presentation
 * XorA|gone has one of his XMs running Ubuntu natty
<XorA|gone> just need to tuck it under the TV now
<prpplague> XorA|gone: for an anti-social nerd, doing all this socializing wears you out
<XorA|gone> prpplague: hehe, the beer makes it easier
<XorA|gone> prpplague: what bad things were people saying about me?
<prpplague> XorA|gone: hehe, no bad names, khilman was discussion some linux-omap stuff
<GrueMaster> rsalveti: Apparently there is a bug on banshee library watcher (bug 760902).  Try disabling it and rerun banshee to see if performance is better.
<ubot2> Launchpad bug 760902 in banshee "Banshee's Library Watcher should be disabled by default in Ubuntu 11.04" [Wishlist,Incomplete] https://launchpad.net/bugs/760902
<GrueMaster> (my systems are tied up with other tasks atm).
 * XorA|gone needs to setup his XM so I can remote controll PA on it and send audio from my desktop to 5.1 surround system
<rsalveti> GrueMaster: interesting
<rsalveti> and cool, the boot is back
<GrueMaster> the boot?
<rsalveti> ops
<rsalveti> bot
<rsalveti> :-)
<GrueMaster> Oh, bugbot returns.
<GrueMaster> yea.
#ubuntu-arm 2011-04-16
<zlobozel> http://www.bsod.ro/ some geek quotes before the official opening
#ubuntu-arm 2011-04-17
<dcordes> Hello. I am looking to prepare a natty image for use on my cortex-a8 device. Is it save to use http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/beta-2/ubuntu-netbook-11.04-beta2-preinstalled-netbook-armel+omap4.img.gz ?
#ubuntu-arm 2012-04-09
<prpplague> GrueMaster: grumble grumble grumble, url links no longer open in a browser after doing package update.......
<GrueMaster> Sorry to hear that.  You should file a bug on launchpad.
<prpplague> GrueMaster: i like whinning about it to you and the #ubuntu-arm channel, much more fun, hehe
<prpplague> GrueMaster: weird looks like a bunch of desktops settings got changed including the preferred apps settings, reset it and it appears to be working now
<GrueMaster> Well, pretty soon (Friday), whining to me will be futile, as that looks to be my last day with Canonical (unless something radical happens).
<prpplague> GrueMaster: doh!
<prpplague> GrueMaster: sorry i had not heard!
<LeonBo> I just installed Ubuntu 12.04 on my pandaboard
<LeonBo> Works great but my wireless is not working anymore
<LeonBo> Does someone know if there are any outstanding issues with pandaboard&wireless on Ubuntu 12.04?
#ubuntu-arm 2012-04-10
<ppisati> janimo: where is the git repo for the ac100 kernel package?
<janimo> ppisati, on zinc, jani/linux-ac100 I believe
<ppisati> janimo: http://kernel.ubuntu.com/git?p=jani/ubuntu-ac100.git;a=summary ?
<janimo> ppisati, http://kernel.ubuntu.com/git?p=jani/ubuntu-ac100.git;a=shortlog;h=refs/heads/packaging-chromeos-ac100-3.0
<janimo> not the master branch
<ppisati> janimo: than you forgot to push something
<ppisati> janimo: debian.linaro/changelog
<janimo> ppisati, most definitely, last upload was not pushed, sorry
<ppisati> janimo: 3.0.19-1.1
<ppisati> janimo: ok
<janimo> I will. Are you doing some changes to all arm kernels or reviewing something
<janimo> ?
<ppisati> janimo: just reviewing
<janimo> ok, thanks for the notice.
<janimo> ppisati, uploaded (after the obligatory fight with git push and configs)
<oneman> hello
<oneman> I'm an omap n00b and I am trying to find the right info on how to get 3d desktop working, I am on a fresh install of ubuntu on pandaboard, with omap extras installed
<oneman> so do I have to use linero if I want composited desktop?
<jeremiah> oneman: Linaro has Linux kernels for ARM boards, like the OMAP 4 (Pandaboard)
<jeremiah> oneman: If you want compositing, you'll likely want some kind of compositor
<jeremiah> Which is higher up from the kernel in userland
<oneman> right
<oneman> I'm just not finding any information on this beyond "install the linero image"
<jeremiah> Check the graphics capabilities of the OMAP 4, see if there is the ability to do 3D graphics. I know they use a mostly closed driver from Imagination.
<jeremiah> for at least some of their graphics.
<jeremiah> s/linero/Linaro/
<oneman> yeah there was more nasty blob action than I originally thought
<prpplague> ogra_: ping
<lobotony> hi! where can I find a ubuntu version for my Pandaboard Es with omap 4460 that runs with hardware accelerated OpenGL?
<lobotony> or do I have to get drivers separately from somewhere else? I've now tried various installations (Ubuntu 11, 12.03, 12.04, Linaro) and neither did the job out of the box
<lobotony> I also tried to install the TI omap4 extras for Ubuntu 11 I think, but that didn't work as well
<lobotony> any ideas?
<lobotony> I'd really like to know if omap4460 support is still problematic, or if I'm missing any packages?
<ZaEarl> lobotony,  I would think 12.04 beta 2 with ubuntu-omap4-extras-graphics would do it for you.
<lobotony> ZaEarl: thanks! Do you mean one of these Ubuntu images? http://cdimage.ubuntu.com/daily-preinstalled/current/
<ZaEarl> those are similar. the beta is at http://cdimage.ubuntu.com/releases/precise/beta-2/
<lobotony> awesome! re: gfx extras, do I install these via adding a ppa?
<ZaEarl> yes
<ZaEarl> probably in https://launchpad.net/~tiomap-dev
<lobotony> ok, great, I've done this before, but with a different ubuntu version
#ubuntu-arm 2012-04-11
<MrCurious_> installing 11.10 on a pandaboard, i am stuck in a loop asking language, location, ...
<MrCurious_> anyone have any hints/clues?
 * MrCurious_ takes his 4th trip through system configuration
<MrCurious_> nice success sorted itself out
<rsalveti> ogra_: infinity: can any of you review bug 978563?
<ubot2> Launchpad bug 978563 in jockey "FFe: jockey support for pvr-omap4 (Pandaboard)" [Undecided,New] https://launchpad.net/bugs/978563
<rsalveti> I just want to have another opinion on how to proceed with it
<ogra_> rsalveti, oh, wow !
<ogra_> rsalveti, has the second variant been tested ? i would prefer the second one, since we might want an nvidia-common on arm thats totally different from the x86 one at some point (for tegra)... and to not seed unneeded x86 packages indeed
<lilstevie> whats this about with nvidia-common?
<ogra_> read the bug :)
<ogra_> it carries board definitions for nvidia and other drivers on x86
<lilstevie> ah
<lilstevie> reading bug now
<lilstevie> when is unity 3d getting a GLES version :p
<steev> i though it existed already
<lilstevie> well I keep hearing that but never see it
<XorA> I saw it mis render lots on omap4 a year ago
<lilstevie> lol
<steev> something something office of the something linaro executive summary iirc
<steev> maybe it was the graphics wg mail
<steev> something about it's in bzr, but as a branch
<XorA> why anyone wants Unity 3D considering the terrible state of linux 3d no-one can answer :-D
<steev> https://code.launchpad.net/~linaro-graphics-wg/unity/linaro-gles2
<steev> XorA: since when?
<steev> works fine here
<suihkulokki> I'm pretty sure the current Linaro Ubuntu Desktop builds for pandaboard and snowball come with unity3d running :)
<XorA> I have 3 computers, tried 4 different GPUs Unity 3D always runs so slow I can see individual frames render, then it tends to render some nonsense then crash
<steev> XorA: were they modern gpus?
<XorA> steev: moderns radeons, nvidia, intel and old intel
<XorA> heh, maybe Im just pickier than average Linux user :-D
<suihkulokki> and better bug reporter as well? ... ;)
<steev> dunno, i'm not much a fan of intel cards (and the only one i have here is an 815 which isn't even remotely close to being considered modern), i have an APU system, which, well, sucks hard with ATi/AMD's drivers (seriously, did they just move the same team to AMD? wish they'd hire some people who knew wtf they were doing) but is decent with the opensource driver, quite usable, though there are issu
<steev> es, but it's a fairly new platform.  all my nvidia cards work fine with nouveau.  i have a 7800, 310M, G210, 450, 580
<ogra_> lilstevie, the gles version of unity should work in 12.04 since last week
<janimo> ogra_, is the gles/unity in the archives already>
<janimo> ?
<ogra_> janimo, yes, broken with the next upload again though (since -desktop decided to go with a new upstream version tomorrow) ... i'm working on fixing it
<ogra_> jockey support for pvr is uploaded too, sitting in the queue waiting for approval
<janimo> ogra_, is the runtime selection part left for post 12.04 ?
<ogra_> runtime selection ?
<ogra_> of what
<janimo> gles/opengl
<rsalveti> ogra_: I tested the second version alredy, and worked as expected
<ogra_> i dont think that bit made it into our paqtch yet
<janimo> for x86 where both are possible depending on hw
<janimo> ok
<ogra_> rsalveti, thats good, since its already uploaded ;)
<rsalveti> ogra_: oh! :-)
<ogra_> janimo, and thats rather something to have in upstream
 * rsalveti just woke up
<ogra_> i dont want to touch any x86 related code with the arm patches in precise
<ogra_> so that bit has to wait
<marvin24> janimo: I updated the ac100 kernel tree during the weekend
<janimo> marvin24, yes, seen that yesterday, did not get around to making a new package though yet. thanks for the reminder
<marvin24> janimo: thanks, please also update the cpu errata settings
<janimo> marvin24, I'll just sync up with the erratas you have in defconfig right?
<marvin24> yes
<marvin24> or disable CONFIG_PL310_ERRATA_588369
<marvin24> and enable CONFIG_PL310_ERRATA_... eh
 * marvin24 reads backlog
<marvin24>  CONFIG_PL310_ERRATA_727915
<marvin24> looks like omap has 588369 enabled, but I think tegra is not affected
<marvin24> at least that is the conclusion on the tegra ml ...
<lilstevie> ogra_: ok I should update my install then
<janimo> slangasek, dpkg --assert-multiarch on precise prints an error. According to a linaro wikipage it should tell you if dpkg supports multiarch and that should be the case since natty
 * ogra_ curses the compiz branch mess once again
<slangasek> janimo: according to the source, it's --assert-multi-arch
<janimo> slangasek, ok so just wiki typo
<janimo> thanks
<janimo> slangasek, do you know if the cross-build capable sbuild has any blockers from going from linaro ppa to precise?
<slangasek> well, there's feature freeze :)
<slangasek> I don't know anything about the code though, generally
<rsalveti> ppisati: were you able to find the issue related with the lack of display after applying the stable updates?
<ppisati> rsalveti: got the board today, i'm debugging it
<rsalveti> ppisati: ok
<rsalveti> ppisati: would you mind also taking a look at bug 924419
<ubot2> Launchpad bug 924419 in ubiquity "oem-config detecting camera where no camera exists" [Medium,Incomplete] https://launchpad.net/bugs/924419
<rsalveti> ?
<rsalveti> ppisati: I believe we'd just need to disable CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT
<rsalveti> if that is pushed, remember that this fix needs to land before the release, otherwise the pre-built images would still be using the older kernel
<ogra_> i thought that was the concclusion we came to months ago
<rsalveti> ogra_: yup, but it seems it still not fixed
<ogra_> aww
 * rsalveti just installed latest daily
<ogra_> well, then we should make sure to have it disabled with the next kernel at least
<ogra_> not sure there will be any uploads before release though
<rsalveti> ogra_: yup
<ogra_> so it wont help with the installer
<rsalveti> ogra_: that's why I was concerned about it
<ogra_> yep
<rsalveti> because the main issue is related with the user experience with the isntaller
<ogra_> right
<ogra_> there are two ways to fix it indeed ... make ubiquitys cam detection better would be the other one
 * ogra_ tries to find out where the pvr upload went
<infinity> There should be one more kernel before release, re-based on the current linux upload.
<rsalveti> I think if we just change ubiquity to open the camera device first, it might already be useful
<infinity> ppisati: confirm/deny?
<GrueMaster> Actually, having the driver detect and enable/disable would be better.  It isn't just Ubiquity that will fail, all apps that detect a camera will get a false feed.
<rsalveti> but that would be a change for all archs
<ogra_> heh, funny, so https://launchpad.net/ubuntu/precise/+queue?queue_state=3&queue_text=pvr tells me pvr source went to restricted .... but binaries ended up in universe
<rsalveti> that's true
<rsalveti> other softwares will also show an error saying the device is invalid
<ogra_> (where they arent actually)
<rsalveti> because it's the first and the default one, even when plugging a usb device
<rsalveti> and I don't think we have folks with cameras around, I only saw it once, and that was robclark :-)
<ogra_> rsalveti, still, GrueMaster has a point ... the driver shouldnt expose capabilities if there is no device to use them
<ppisati> infinity: a new upload? if release team accept it, yes
<infinity> ppisati: Consider it done.
<ppisati> infinity: ok
<infinity> ppisati: We just had linux/lbm/meta yesterday.
<rsalveti> cool, so disabling the option would probably be the faster and easier way to get this fixed
<infinity> ppisati: I would have assumed you'd rebase ti-omap4 to match.
<infinity> ppisati: And if you can fix rsalveti's issue at the same time, cool.
<ppisati> ok so, i'll disable panda camera too, ack
<rsalveti> ppisati: thanks
<robclark> fwiw, camera boards are available to the public, as are sensors..  not necessarly easy to get, but doesn't mean no one has one
<rsalveti> robclark: wouldn't be a way for the kernel to check if the camera is available before exporting the interface?
<GrueMaster> robclark: The idea is to support the lowest common denominator.  If a user has a camera, they can rebuild the kernel with the module.
<rsalveti> always exporting the interface seems wrong
<rsalveti> GrueMaster: +1
<GrueMaster> I'd say to disable it for now, and revisit in 12.10.  No time to do a proper fix +testing (even if I were still testing it).
<infinity> Well, v4l not sucking would be nice.
<infinity> But disabling the driver seems simpler for now.
<robclark> rsalveti, not sure
<ogra_> is it actually a module ?
<robclark> the bigger probably is probably none of you have a camera to test w/
<ogra_> we could buuild it and ship a blacklist file for it by default
<ogra_> so you dont need to recompile
<rsalveti> not a module
<infinity> Oh, indeed.
<robclark> btw, what is the issue the camera is causing?  I guess I missed some of the discussion..
<GrueMaster> robclark: That is true, but easily resolvable, if the camera is removable.
<infinity> Could it be a module?
<rsalveti> robclark: bug 924419
<ubot2> Launchpad bug 924419 in ubiquity "oem-config detecting camera where no camera exists" [Medium,Incomplete] https://launchpad.net/bugs/924419
<robclark> hmm
<GrueMaster> robclark: What ends up happeneing, is on systems w/o a camera, it is using a screen capture or some other feed.
<GrueMaster> *happening
<robclark> if it is using the MCF based driver, the issue is that the sensor is a separate driver..
<robclark> /dev/video0 is the output.. the ISP exists.. only the sensor does not ;-)
<robclark> anyways time is limited so I guess folks w/ a camera can rebuild kernel, or modprobe or whatever
<robclark> but I wonder what happens when MCF becomes more common..
 * ogra_ would be for modprobing but that requires the driver to be a module 
<robclark> and that doesn't work?
<ogra_> no idea
<XorA> sounds like it needs a subsystem like ASoC where video device is not instantiated until all parts on the path are
<robclark> anyways, at some point the camera will probabably support some memory-to-memory modes too.. so probably some day oem-config needs to get more MCF saveey
<rsalveti> robclark: it's fine to fix this after the release
<rsalveti> the issue is with the released kernel
<robclark> because really it should care about if the *sensor* exists, not the /dev/videoN device exists
<rsalveti> as the pre-built images would have the bug at oem-config
<robclark> right.. anyways, I think it is ok to not enable the camera.. we can add it in our PPA or whatever..
<robclark> (but some day oem-config would have to deal with this ;-))
<rsalveti> so that's why disabling it for now might be a good workaround, and then if it's the case of the device becoming common, or even another fix is around, we can simply just enable it again
<rsalveti> with the proper support
<ppisati> guys, do you have an LP bug for the camera?
<rsalveti> ppisati: bug 924419
<ubot2> Launchpad bug 924419 in ubiquity "oem-config detecting camera where no camera exists" [Medium,Incomplete] https://launchpad.net/bugs/924419
<rsalveti> robclark: sure, but I wonder if we could have it generically enough to make it compatible with any app trying to access the camera devices
<rsalveti> the only thing oem-config does is to check for devices exporting the proper capabilities
<rsalveti> and guess that's also what is done with any other camera-based application
<robclark> maybe if the app uses libv4l?  Probably a better question to ask the linux-media folks
<robclark> right
<GrueMaster> I believe other apps may work that way too.
<rsalveti>  g_udev_enumerator_add_match_property (enumerator, "ID_V4L_CAPABILITIES", ":capture:");
<ogra_> it just uses a gstreamer qeury for the capture capability
<robclark> I think the v4l folks goal was the bury the sophistication in libv4l rather in the kernel..   but I'm not the MCF expert
<rsalveti> ogra_: just installed the daily image, updated jockey and installed the pvr driver with jockey's interface
<rsalveti> all went well :-)
<rsalveti> and now with just a few clicks I got gles support ;-)
<GrueMaster> rsalveti: Cool.  I may actually try it (just for personal gratification).
<rsalveti> GrueMaster: :-)
<infinity> rsalveti: Did you write automagic detection in (ie: does the jockey icon pop up in the notification area on Pandas and offer you the drivers, or do you need to manually run it?)
<rsalveti> infinity: I thought jockey would automatically do that, but it seems this is not the case
<ogra_> it should
<rsalveti> infinity: do you know what needs to be changed to get it to work in that way?
<infinity> Well, if you've given it detection patterns, wherever that happens, it probably already does work that way.
<infinity> And the only reason you wouldn't have seen it is because you booted with a version that didn't.
<rsalveti> if I open the interface, it'll try to detect the drivers and it'll then work as expected
<rsalveti> but I'm not sure what needs to happen in order for it to automatically detect the drivers at the first boot
<rsalveti> infinity: could be
<ogra_> lets see what happens once its actually in the image
<rsalveti> yup
<ogra_> do you get unity 3D ?
<rsalveti> ogra_: didn't yet check, let me give it a try
<ogra_> theoretically that should wrok too now
<rsalveti> ogra_: seems nux is still not building for gles on arm
<ogra_> gar
<rsalveti> ogra_: I might easily get the patch for it, let me check
<ogra_> well, compiz and unity patches are in at least
<ogra_> i'm just finishing the testbuild with an updated patch for compiz-plugins-main
<rsalveti> should be the last part then
<GrueMaster> If those aren't building, wouldn't that hold up image builds?
<rsalveti> ok, meanwhile will enable nux and test
<ogra_> GrueMaster, indeed
<ogra_> thats why i do testbuilds :)
<carli2> hi
<carli2> I have a pandaboard and only a dvi plug.
<GrueMaster> Use a DVI<>HMDI cable or converter.  Should work fine.
<carli2> :o
<carli2> my monitor is not able to display the hdmi content
<carli2> and when I plug it into the dvi connector, it dosen't show anything
<GrueMaster> HDMI is essentially the same video signal as DVI-D (Digital).
<GrueMaster> Use the HDMI connector.
<GrueMaster> The connectors on the panda are the same.
<carli2> it dosen't work. the monitor tells me "input not supported".
<carli2> did I choose a wrong resolution? (my monitor can only display a few)
<GrueMaster> What resolutions does your monitor support?
<GrueMaster> The panda driver should autodetect.
<carli2> 1920x1080 and some spare other resolutions
<GrueMaster> What model monitor do you have.  Might be easier for me to look at the specs for it.
<GrueMaster> It should be fine with 1920x1080.  That is standard HD resolution.
<ogra_> bug 897390
<carli2> acer g225hqv
<carli2> should I try an other version of ubuntu?
<GrueMaster> ogra_: That bug doesn't exist.
<GrueMaster> carli2: Which release are you running, and which rev Panda?
<carli2> GrueMaster: 12.04 beta2, pandaboard ES
<carli2> do I need a serial cable to get the pandaboard running?
<MrCurious> http://www.kickstarter.com/projects/597507018/pebble-e-paper-watch-for-iphone-and-android
<GrueMaster> Not for the desktop image.  I'm looking up your monitor info now (had an interrupt).
<GrueMaster> The manual I found is too generic.  It lists VGA and possibly DVI and possibly HDMI capabilities.  Not specific enough for me to go on.
<GrueMaster> I would suggest downloading the ubuntu server preinstalled omap4 image and booting it.  You will need a serial cable as it is setup through the serial console.
<GrueMaster> Once setup, you can determine if it is detecting your monitor properly.
<carli2> i'm using ubuntu 11.10 and 12.04 on pandaboard es, i have a hdmi-to-dvi converter I plug the hdmi part into both hdmi connectors on the pandaboard, in one the screen stays black, in the other, my monitor shows "input not supported"
<carli2> what can I do?
<rsalveti> robclark: got the following while trying to run xbmc on ubuntu:
<rsalveti> [ 14547.411] PVR:(Error): PVRSRVMapDeviceClassMemory: Invalid params [1648, /bridged_pvr_glue.c]
<rsalveti> [ 14547.481] (EE) pvr(0): [dri] PVRDRI2CreateFlipChain: Couldn't create flipchain
<rsalveti> [ 14547.481] (EE) pvr(0): [dri] PVRDRI2AssignAndExportBuffers: Couldn't create flipchain
<rsalveti> ro elevator=noop vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 root=UUID=b518b2b6-8d08-41ad-b196-95a04e83657b fixrtc quiet splash
<rsalveti> seems that using 32 as vram might not be enough here
<robclark> right.. you need 40
<rsalveti> robclark: any other value you'd suggest in this case?
<robclark> fwiw, for new driver in 12.04 it no longer matters..
<rsalveti> ok, then we need to change the default boot args at precise
<robclark> no fixed/preallocated flipchains
<robclark> yup
<rsalveti> cool, nice to know
<robclark> number of bootargs should be dropping significantly.. no more mem hole for syslink either, with the upstream rpmsg stuff
<rsalveti> yeah, finally :-)
<rsalveti> [   105.608] (EE) pvr(0): [dri] PVRDRI2CreateFlipChain: Created flipchain 1 (stride: 7680)
<rsalveti> yeah, 40 made it work
<rsalveti> infinity: ogra_: then we'd need to change the current vram argument at the pre-installed image, from 32 to 40
<mkopack> Quick ? - has Unbuntu 12.04  for ARM been finalized yet? (i.e., full final release)â¦ Soecifically images for PandaboardES ?
<rsalveti> mkopack: we have daily images if you'd like to try
<rsalveti> http://cdimage.ubuntu.com/daily-preinstalled/current/
<rsalveti> final release is expected to happen at the end of this month
<mkopack> Nah, not a fan of daily'sâ¦ I'll stick with 11.10 until there's a full release version
<rsalveti> the omap4 is compatible with panda and pandaES
<mkopack> Ok, cool. I'll wait till thenâ¦
<rsalveti> ok
<mkopack> thanks, I just wasn't sure when the expected release was
<infinity> rsalveti: I'm confused by robclark's statement that it's not needed for the "new driver in 12.04", and you just told me it is. :P
<rsalveti> infinity: the new driver that TI will release on their own PPA
<rsalveti> that will require the 3.3 kernel
<rsalveti> so that's not part of the official precise release
<rsalveti> would be optional for users once the PPA is in place
<infinity> Ahh, check.
<infinity> rsalveti: Can you file an RC bug about the command line needing to change, so I can point people at it when I fix it? :P
<infinity> rsalveti: I'm not even sure how many places have that hardcoded.
<infinity> flash-kernel and debian-cd both seem like likely candidates.
<rsalveti> infinity: yeah :-)
<rsalveti> I dream with the day where this will all be integrated at one single place :-)
#ubuntu-arm 2012-04-12
<rsalveti> alf_: ogra_: https://bugs.launchpad.net/ubuntu/+source/nux/+bug/979438, for gles support at nux
<ubot2> Launchpad bug 979438 in nux "Nux should be built with OpenGL ES2.0 support at ARM" [High,Confirmed]
<rsalveti> debdiff attached
<MrCurious_> anyone here know how to manually install omap4 addons on a pandaboard?
<MrCurious_> scratch that, accidentally solved it
<MrCurious_> ubuntu on pandaboard is stuck in the install loop.  does anyone know the command to break it out of tha tloop
<MrCurious_> it keeps asking keyboard, location, username, password, then resets and repeats
<MrCurious_> ubuntu 11.10 desktop omap4 image
<MrCurious_> scratch that remembered  oem-config-remove
<twb> I'm surprised it doesn't remove oem on its own -- unles it doesn't have write access to the ramdisk?
<MrCurious_> beats me
<MrCurious_> i did it manually, and the train is now back on the tracks
<marvin24> looks like ubuntu does not provide a "xf86-video-modesetting" driver
<twb> marvin24: ubuntu's kernel does KMS, but probably not for relatively obscure arm GPUs
<marvin24> well, I wouldn't name geforce/light an obscure arm GPU ...
<twb> Shrug
<twb> Compared to the vast numbers of x86-y intel/ati/nv GPUs, it is
<twb> That's what I meant
<marvin24> I just wanted to test it on my ac100 with the newly tegra drm posted yesterday
<marvin24> but there's still other stuff to do and compiling it myself should be too difficult
<twb> What I do know, is that on my tegra2 TF101, I have a native-resolution fbcon.
<twb> I kinda assumed that meant it had KMS, but i haven't investigated.  Oh- but that's with the android kernel, not the ubuntu kernel
<marvin24> twb: I was talking about mainline code
<marvin24> there is fbdev for tegra yet
<twb> lilstevie told me the GPU support is best (for tf101, but they're mostly the same) in the Chrome OS kernel
<lilstevie> not at the moment it isn't :p
<twb> I have native res in my fbcon and that's all I really care about
<lilstevie> heh
<lilstevie> yeah
<lilstevie> cause your odd and use xinit for everything
<marvin24> well, android is on 2.6.39 (I guess) and chromeos on 3.0 ...
<lilstevie> marvin24: specific case is neither for those
<lilstevie> CrOS is at 2.6.38 and android at 2.6.36
<twb> It would be NICE if the animated gif didn't make xinit /usr/bin/midori http://www.bom.gov.au/products/IDR023.loop.shtml#skip visibly laggy, but not enough that ICBF maybe breaking my only working computer
<lilstevie> cause the 2.6.39 android kernel is silly
<marvin24> mmh, I don't know which kernels are shipped with which version (of android or chromeos)
<marvin24> but ac100 has a chromeos kernel with accel'ed X
<marvin24> and it is version 3.0 (but still too old for precise)
<marvin24> so we badly need a newer kernel sooner or later
<lilstevie> tf101 can have accelerated X with .39 but it is stupid
<lilstevie> there is some odd bug
<lilstevie> breaking fbdev
<marvin24> no console?
<lilstevie> yep
<lilstevie> and f'd colours
<marvin24> same here on the nv 3.1 kernel
<marvin24> I posted something on the tegra forum, but no reply
<lilstevie> heh
<marvin24> lilstevie: anything on xda-developers, you know of?
<lilstevie> nope
<twb> fucked as in yuv thinking its rgb kinda thing?
<lilstevie> I am otherwise sidetracked with [redacted]
<lilstevie> twb: yes
<marvin24> so let's hope the open source driver will make fast progress
<twb> I didn't know there even was an accelerated open driver for it
<lilstevie> its new
<twb> ah, cool
<lilstevie> this kind of new http://www.phoronix.com/scan.php?page=news_item&px=MTA4NjA
<lilstevie> there are a few other little whispers that I am hearing from nvidia, but they are no more than whispers
<lilstevie> we are having some good luck with getting 3.1 running on the tf201 though
<lilstevie> so far we can boot and mostly use android with it
<twb> Do you get the impression that nvidia are slowly getting a clue about dealing with the FOSS community?
<twb> The tf is the first product I've bought from them EVER since they have such a bad rep
<lilstevie> well the whispers I am hearing are that they are starting to embrace FOSS, at least in the arm sector
<twb> Probably because it's not their core market
<twb> Sounds like I should continue to boycott them on the desktop/server segment
<serishema> The arm-ubuntu and ubuntu core rootfs FAQs are not clear on who is and is not a developer.
<infinity> ?
<serishema> I've built stable kernel source for armv7 (920T core, WM8505/Via8505) on one of those generic 7" netbnooks
<infinity> Anyone who wants to write software is a developer, I imagine.
<serishema> ahh ok
<infinity> I'm not sure what your statement means.
<infinity> (Which FAQ are you referring to?)
<serishema> infinity: https://wiki.ubuntu.com/Core
<serishema> this one.
<infinity> Also, the 920T isn't ARMv7...
<serishema> infinity: i was meaning that I will probably not contribute anything useful to the project
<serishema> but still want to hack on it
<serishema> andl that peice of info saves me a lot of effort to just get a crash at boot up doesn't it
<infinity> A 920T is probably v4t...
 * serishema didn't know and it's on the channel topic. Arm cores != ISAs how embarassing
<serishema> that explains why it is so hopelessly slow
<infinity> So, not even remotely supported by ubuntu-core.
<infinity> Debian may well support it.
<serishema> The actual chip is a via/wondermedia 8605 @ 600 Mhz
 * serishema is wrong about the 920t core part
<infinity> Sure, it's not about slow, it's about pure incompatiblity.
 * serishema realizes it would be an ISA / EABI issue 
<serishema> so the wm8605 is definately an arm v4? and not v7?
<infinity> Oh, an 8605 sounds more like an ARMv7. ;)
<serishema> ahh
<serishema> good
<serishema> I guessed from the /board directory name in the wmt uboot code
<infinity> But yeah, slow it will be, relatively speaking.
<serishema> infinity: tl;dr basically I had been living under a rock (read: working for a boss who makes her run and develop for windows) for too long and wasted effort trying to write drivers for the on chip hardware when they actually exist
 * serishema is not expecting this to run X btw if that makes a difference
<infinity> It could run X, I'm sure.
<infinity> And many other shiny things.
<infinity> But yeah, it'll probably perform similarly to a beagleboard, or a Nokia n900, none of which are particularly speedy by today's standards.
<infinity> So, patience will be a virtue. ;)
 * infinity is surrounded by fast ARM kit, and keeps forgetting that's a relatively new invention.
<serishema> basically if it ran ssh, rdesktop and a browser (chrome or firefox,) vi, basic shell prompt tools.. could connect to the internet via my nokia 2730 classic and decode and play mp3/ogg vorbis, etc i'd be really pleased with that
<serishema> This is essentially intended as a mobile dumb terminal.
<serishema> All real processing happens on amazon EC2 anyway
<infinity> Well, any of that's doable.
<serishema> so it was a natural choice to use something so cheap it was virtually disposable rather than a real laptop :)
<infinity> We build out full userspace for ARM, so... It really comes down to kernel and video support for that SoC, which we obviously don't support out of the box.
<infinity> s/build out/build our/
<infinity> (And, I'd recommend basing your work on precise/armhf ... Especially on a slower SoC, you'll be glad for the performance boost)
<infinity> Unless you're stuck using binary softfp drivers from a vendor. :/
<infinity> Then armel it is.
<serishema> this is VFP?
 * serishema can't get her hands on any vendoer specific code. 
<infinity> Well, it's all VFP, it's the ABI that changes.
<infinity> Welcome to the confusing world of ARM.
<serishema> time for a rebuild then.
<infinity> soft = soft floating point, softfp (which our armel port is) = vfp ops with soft calling conventions, hard = vfp ops with new calling convention to make use of extra registers, breaking ABI.
<infinity> ubuntu-armhf/debian-armhf = hard, ubuntu-armel = softfp, debian-armel = soft
<serishema> basically I got given a bricked one of these netbooks bricked.
<serishema> for free
<serishema> I've got as far as vfs: cannot mount root fs on uknown block (cos I haven't even made a root fs or initrd)
 * serishema is mostly just curious to see if there is a easier way than doing everything from scratch :)
<infinity> Well, at least you have a kernel.
<infinity> As for "from scratch", given that no installer will work for you, you get to put a tiny bit of effort in.
<infinity> But using ubuntu-core as your rootfs will work fine.
<infinity> Just need to maybe chroot in and add a user (or set a root password) before you try stuffing it on another device. :P
<serishema> nice. I most likely just have to recompile with the right eabi
<serishema> I am pretty sure I used armel
<serishema> which I don't want
<infinity> The kernel doesn't care.
<infinity> You're fine.
<infinity> Same kernel can run armel and armhf userspaces.
<serishema> oh. so the kernel will load any elf for init with the correct header and ISA type?
<serishema> and an eabi is a userspace dynamic linker thing?
<infinity> Basically, yeah.
<serishema> ahh this is a good thing
<serishema> I was going to just gcc -static everything to avoid this problem
<infinity> Ew.
<serishema> but that would be unrealistic on a board with 256mb of ram
<serishema> I assume running swap space on a SD card is a bad idea?
<infinity> Very.
<ogra> works, but is no fun at all
<infinity> Unless you like throwing out cards.
<infinity> (It's also just dead slow)
 * ogra hasnt managed to kill a card with that yet but its close to unusable if you start swapping
<infinity> Keeping your VM commit under your RAM size is the saner option, if you're building for a specific use case.
<ogra> and i have cards that are constantly in use for 2 years
<infinity> ogra: You're a very lucky man.
<infinity> ogra: Or your definition of "constantly" is different from mine.
<serishema> I just assumed that the write perf would suck too much to be useable.
<serishema> I didn't think about it wearing out the card
<ogra> well, in my testbuild machines i always use the same cards
<infinity> serishema: Write performance is awful, but wear is the real concern.
<ogra> across the releases
<infinity> serishema: Anal retentive SSD owners often swap to external rotary disks for wear reasons.
<infinity> (Or people like me just don't use swap)
 * serishema nods 
<serishema> if I can't run ssh on a single VT with 256Mb of ram and no swap I have done something seriously wrong :)
<infinity> Indeed.
<serishema> it worked on my 486 with 8Mb
<serishema> 10 years ago
<infinity> Well, times have changed a bit since kernel 2.0
<serishema> we can't have all forgotten how to program because of java, etc that badly
<infinity> But, yeah, 256 is still "a lot" until you get into fancy desktop environments.
<serishema> and compilers are better so I assume any hand written arm ASM will be trash compared with gcc's output with -O2?
<serishema> which wasn't nessacarly true on 486 in 1999
<ogra> oh, fun, compiz FTBFS
<ogra> ah, KDE issue
<ogra> phew ... wasnt my patch
<infinity> serishema: Depends on the quality of your assembly, or what you're trying to do.
<infinity> serishema: (Also depends on the quality of your C, as a good C programmer knows more or less what the compiler's going to optimise out anyway)
<infinity> serishema: But yeah, in general, GCC's not awful.
<serishema> if i'm writing asm it's because i'm doing eairly power up and can't do it in C. I hate ASM.
<infinity> ;)
 * serishema just stole the code WMT was forced to release for GPL violations for dram controller init 
<serishema> I hate that stuff
<serishema> Board designers problem
<serishema> I have designed boards, but reverse engineering an unknown board is too hard for me :)
<serishema> I will definately need to get a newer uboot on it
<serishema> theirs is full of crappy bugs
<infinity> Meh.  If it's good enough to jam some blobs at some offsets and jump, who cares?
<serishema> true.
<serishema> The only actual bug which matters is the power button GPIO
<serishema> which doesn't have a proper debounce, just a delay by a constant
<serishema> but the real delay it should wait varies with the battery voltage
<serishema> so you have to press the power button 10 times before it will turn on
<infinity> I'm unconvinced that anything related to power buttons is ever correct on any ARM device I own.
<infinity> From dev boards to phones to... Well, everything.
<serishema> that's normal?
<serishema> I noticed a // can't power off myself comment on a function which jumps into some bizare assembly
<infinity> Well, your specific issue isn't necessarily normal (though I have two phones that behave like that).
<serishema> which appears to among other things set the hibernate flag (WMT specific)
<infinity> But I have other boards that are equally but differently confused about what power buttons do. :)
<infinity> And a netbook that never actually powers off, just goes into a suspend state.
<serishema> that would explain my mysterious battery drain
<serishema> and the meaning of the // can't power off myself comment
<infinity> Potentially, yeah.
<serishema> ahh.. so is this software controllable at all? I can get my hands on a JTAG, etc.
<serishema> so reflashing the bootloader is OK
<infinity> Depends on the SoC.
<infinity> That's a big "maybe".
<serishema> when i connect the battery does it actually jump to __start or is that board specific?
<infinity> And I don't know anything about the one you've got.
<infinity> That's also board specific.
<serishema> ahh ok.
<infinity> Some reset on power, and jump somewhere sane, some just start garbled and wait for a keypress event.
<infinity> (ie: a soft power button that shouldn't even exist)
<serishema> urgh
<serishema> so just wiring a hardware power switch onto the battery is a bad idea
<serishema> since it probably wouldn't work
<infinity> Unless it would.
<infinity> It would work on a Pandaboard.
<infinity> (Maybe even all OMAP SoCs)
<serishema> OMAP SoCs are the only ones i've seen which I don't think are insane
<infinity> It wouldn't work for beans on an iMX53, which insists on powering on to confusion.
<serishema> unfortunately they are too expensive
<serishema> I get my arm stuff for free because people give me their bricked devices
<serishema> usually they have not even overwritten the boot loader, so a board/soc specific micro SD card can load a kernel onto them
<serishema> otherwise.... it's down to the university electronics lab for some unauthorized use of university resources :)
<serishema> anyway it doesn't matter. I will just put the 26 amp hour deep cycle battery which is just sitting on my floor on float charge in my car as a 2nd battery
<serishema> and then it can waste as much power with soft off as it likes :)
<serishema> I occasionally use it to power flourecent lights during power cuts in winter, but that's about it
 * serishema lives in the wop wops so every time the wind gets up the power and xDSL go out 
<serishema> anyway enough blathering. I will download this and put it in qemu-system arm and see if I can get it to go
<serishema> infinity: and as for the orriginal question. I will just subscribe to both mailing lists and lurk
<serishema> and should I happen to accidentally do something useful I will post the patch :)
<infinity> Heh.  Sure.
<infinity> #debian-arm on oftc is another place worth lurking.
<serishema> oftc?
<infinity> irc.oftc.net
<serishema> ahh. another fs/oss related net?
<ogra> debian hides there :)
<infinity> Yeah
<infinity> irc.debian.org points to oftc.
<serishema> I wonder where #debian went
<infinity> So, that would be your answer. ;)
<serishema> Cool
<infinity> We only moved, like, a decade ago.
<infinity> *cough*
<serishema> hhyaha
 * serishema disappeared sometime around kernel 2.6.35
<ogra> not true, i remember still seeing debian channels around at warty days
<serishema> and has just come back
<infinity> ogra: Yeah, the move was slow.
<ogra> but close to a decade already :)
<serishema> naturally it is taking forever to get back up to speed on everything
<serishema> there have been so many changes in 3.x
<serishema> but I just grabbed the source and broke stuff, rather than trying to find answers on the internet
<serishema> hopefully that wasn't stupid
<infinity> That's the best way to do it, IMO. :P
<infinity> Even if you end up duplicating effort, you learn.
<infinity> And then you can submit patches and make the various subystem maintainers cry.
<serishema> haha. I'm not that evil
<infinity> I derive so much pleasure every day from reading davidm's rants about idiot submissions.
<serishema> link?
<serishema> oh .. I shall have to join that mailing list too?
<infinity> I wouldn't subscribe to LKML, if I were you, unless you're a masochist.
<serishema> oh LKML?
<serishema> I've heard the horror stories
<serishema> didn't realize
 * serishema wouldn't even attempt to get a patch into mainline
<infinity> Well, Dave's rants tend to be on places like his G+ account, and in private with friends, but.  LKML's educational, if you're bored.
<infinity> I tend to stay on the other side of the syscall layer, but a disturbing number of my friends are kernel developers.
<serishema> the right side generally
<infinity> Both sides suck. :P
<infinity> It's just insanity to try to work with both.
<serishema> but I had the misfortune of actually being able to make sense of the wrong side of the syscall layer of that certain popular proprietary OS
<serishema> haha snap
<infinity> So, I let other people do kernel crap, and I'm sitting here with 5 parallel glibc builds going right now.
<serishema> So before the recession I got paid as much as $80US an hour to do consulting with user mode/ kernel mode interface crap on windows drivers
<serishema> mostly for fixing STOP IRQL_LESS_THAN_EQUAL
<serishema> I don't remember the code
<serishema> I don't want tio
<infinity> Everyone's favourite bluescreen.
<serishema> Yeah.
<serishema> Since it's ALWAYS caused by the dev not reading the docs :)
<serishema> unfortunately this includes MS internal devs
<serishema> on wincore who should know better
<infinity> I never did learn enough to know what it meant.  Based on the constant name, I'm assuming integer over/underflows and a lost pointer to an IRQ or something?
<serishema> Nah
<serishema> IRQL is an abstraction
<serishema> a moronic one
<infinity> Of course.
<serishema> it represents IRQ mask registers on the board/CPU specific interrupt controller
<serishema> basically if you don't know that certain things require eg the timer interrupt to be masked off
<serishema> you shouldn't be writing drivers
<serishema> But MS came up with an abstraction to make it easier which actually makes it harder
<infinity> Ignorance has never prevented driver development in the past.
<serishema> NT kernel = bastardized version of VMS
 * serishema doesn't even have windows installed
<infinity> I used VMS in high school, but we never wrote to the hardware.
<serishema> i only read about VMS
<serishema> for class
<serishema> before my time
<infinity> For some reason, they didn't think that doing kernel development classes that would let us crash the entire school by offlining the VAX would be a good idea.
<serishema> they were probably right
<infinity> Probably. ;)
<serishema> I didn't learn how to do windows kernel at university
<serishema> basically I was at a school which forced us to use Windows
<serishema> so at that age I had the naevity to try and make it not suck
<infinity> My friend's doing a CS degree right now, and I'm moderately impressed that most of their classes are on Linux systems.
<serishema> I became the bane of the network admins for all my custom stuff which some how ran when I logged in even though they had supposedly disabled user login scripts
<infinity> Most of his profs are idiots.  But at least they're learning on open systems.
<serishema> Yeah I transfered
<serishema> Being forced to use windows was the lesser evil than being the only girl in a class of 185 with an openly mysogenistic bigot for a professor
<serishema> getting my boobs grabbed and being asked if they were real and responding with a ju jisu  wristlocking was a day in the life
<serishema> But their course was also 10 years out of date
<infinity> You got groped?  Seriously?
<serishema> In terms of material
<infinity> What the fuck is wrong with people?
<serishema> infinity: it was a get wasted, party and get laid type of school
<serishema> I missed the memo
<infinity> I mean, I'm used to geeks being socially inept, and moreso with women, but... Wow.
<serishema> people who actuially wanted to work went else where
<serishema> by other students only.. but yeah.
<infinity> Sounds lovely. :/
<serishema> if a staff member did that the cops would hear about it. But they quickly learnt that I was not to be got on the wrong side of
 * serishema lived in ghettos .. built computers out of rubbish and learnt C instead of participating in drugs/gangs, etc 
<infinity> Right, remind me not to invite you to the Ubuntu-ARM frat kegger.
<serishema> depends.
<serishema> infinity: I won't comment since freenode: "there are no girls on the internets" will be in effect.. but let's just say my boyfriend has another girlfriend and I am fine with this.
 * serishema isn't your average blond
<serishema> anyway this is getting far too OT
<serishema> PM?
<XorA> serishema: you sound kickass :-D
<XorA> backlog was one of the more enjoyable return to work after lunch reads Ive had for a while
<serishema> hi XorA
<XorA> VMS is a long and distant memory
<serishema> XorA: when it comes to VMS I actually don't know what I'm talking about
<serishema> i'm 27 so therefore too young to have seen a real live VMS system
<XorA> ah right, at univerity the student email/blah system was VMS
<tomtiger11> infinity: Why try Debian?
<XorA> I was already used to posix style from Amiga so all the [blah]bleh; stuff used to confuse me until I got the hang of it
<serishema> tomtiger11: I suspect he was answering my questions when I thought my chip was something older and ubuntu core wouldn't go .
<infinity> tomtiger11: Why provide context with your question?
<StevenK> I've seen a VMS system. It was even running. It just wasn't doing anything.
<serishema> infinity: *steal*
<tomtiger11> infinity: Seriously, Is ubuntu-arm incompatible with Raspberry Pi?
<infinity> tomtiger11: Yes.
<XorA> tomtiger11: yes, Raspberry Pi is old technology
<tomtiger11> infinity: Is it the RAM?
<infinity> tomtiger11: The Pi is ARMv6, we build for ARMv7.
<tomtiger11> Oh
<XorA> you have to be nimble to keep up with the ubuntu boys
<XorA>  /girls
<ndec> ogra: do you think we still need our biweekly call?
 * serishema much prefers "get a real computer" or "bitty box" and leaving it at that :)
<serishema> since being a bitty box is actually the whole point with arm :)
<xranby> tomtiger11: bring the question to the next UDS, to lower the optimization level for the community maintained armel to get back to debian level now when ubuntu-arm have switched to use armhf
<infinity> xranby: It's already being discussed internally.
<infinity> xranby: And, honestly, while it would be a community port, it needs to be driven by Canonical for infrastructure reasons, so you may as well let us beat the horse dead a bit first.
<infinity> xranby: (But it's being beaten)
<pnphi> i want to build the package for Ubuntu ARM
<pnphi> how do i do ??
<xranby> pnphi: you have some ptions  1. setup a complete build environment on a ubuntu arm machine and simply build it using dpkg-buildpackage
<xranby> 2. use xdeb to cross compile a package
<pnphi> from source of package ubuntu ??
<xranby> pnphi: yes from source
<pnphi> by the way
<pnphi> in the Chroot, can i build the package ?
<pnphi> from source
<xranby> yes, as long as you have installed all compilers inside the chroot
<pnphi> what link will i add source list ??
<pnphi> that i can get source
<xranby> pnphi:  deb-src http://archive.ubuntu.com/ubuntu/ precise main universe restricted
<pnphi> ok
<xranby> its the same source archive for all architectures
<pnphi> for all ? ok i do
<pnphi> ok thank you so much
<xranby> pnphi: youre welcome
<xranby> infinity: ok i take canonical wants to try a neon build .. what other optimizations are currently untested=
<xranby> ?
<infinity> xranby: Err, we do?
<xranby> let me rephrase the question.. what is it left to flog on the horse? :)
<infinity> No, no.  The other direction.
<infinity> As in, we also want to drop the baseline for armel.
<infinity> But we're discussing in-house how much effort that will be, and if we really want to do it.
<xranby> ok, thank you for the heads up
<pnphi> where is the tutorial for xdeb ??? i don't search The xdeb
<xranby> pnphi: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/UsingXdeb
<xranby> pnphi: wookey are the person to ask about current xdeb status
<ogra_> ndec, not really i think, in ubuntu we just swallow what linaro gives us nowadays, but for ppisati it is important to get the kernel issues across, i wonder if we could take that bit to mail or so
<ndec> ogra_: ok. i see. we just need to make sure ppisati, sebjan , me and andy discuss sometimes...
<ogra_> right, i dont know how important the call is for ppisati ... i guess thats something he needs to answer
<pnphi> ok thanks
<pnphi> i install the package "g++-arm-linux-gnueab" but  E: Unable to locate package g++-arm-linux-gnueabi E: Couldn't find any package by regex 'g++-arm-linux-gnueabi'
<ogra_> apt-get install gcc-arm-linux-gnueabihf
<ogra_> try that one
<ogra_> hmm, so doing a dpkg --get/set-selections between two ac100 precise installs (one armhf the other armel) makesd me end up with linux-image....-mx5 installed on the target system
 * ogra_ wonders why
<ogra_> hmpf, actually i end up with *only* the linaro lt-mx5 image installed
<ogra_> :(
<pnphi> install the package "g++-arm-linux-gnueab" but  E: Unable to locate package g++-arm-linux-gnueabi E: Couldn't find any package by regex 'g++-arm-linux-gnueabi'
<ogra_> apt-get install gcc-arm-linux-gnueabihf
<pnphi> joined
<pnphi> install the package "g++-arm-linux-gnueab" but  E: Unable to locate package g++-arm-linux-gnueabi E: Couldn't find any package by regex 'g++-arm-linux-gnueabi'
<pnphi> what do i add source ?
<ogra_> apt-get install gcc-arm-linux-gnueabihf
<pnphi> E: Unable to locate package gcc-arm-linux-gnueabihf
<pnphi> how use Xdeb to build package ??
<rsalveti> ogra_: I don't know if you saw it yesterday, but it'd need to change vram from 32 to 40 at panda
<rsalveti> to make SGX to work properly, with flip chain and such
<ogra_> rsalveti, yup, i did, i forgot to ask infinity if he had changed it already
<ogra_> wasnt there also the option to drop the mem= args too ?
<rsalveti> didn't yet open a bug for it, as I know we have tons of places with that thing hardcoded
<ogra_> since we dont have ducati support in this kernel ?
<rsalveti> not with current kernel I guess
<rsalveti> oh, that's true
<rsalveti> the next support will be with the newer kernel
 * ogra_ will make sure that changes before release
<rsalveti> so we can safely remove the hole then
<ogra_> k
<rsalveti> ogra_: thanks
<MrCurious_> anyone know anything about a gstreamer0.10-plugins-bad package and how to get around this show stoper
<MrCurious_> looks like that package is corrupt
<MrCurious_> and reflash and retry :/
<rsalveti> MrCurious: you mean at the TI PPA?
<MrCurious_> not sure what you mean?
<MrCurious_> the ti licence accepting?
<MrCurious_> i installed ubuntu 11.10 desktop omap4
<MrCurious_> then did apt-get update upgrade and dist-upgrade
<MrCurious_> then tried to install ubuntu-omap4-extras
<MrCurious_> then found gstreamer bad was failing
<MrCurious_> was following these instructions http://blog.sarine.nl/2011/12/07/installing-ubuntu-11-10-on-pandaboard/
<rsalveti> yeah, that one
<rsalveti> the broken package was caused by an issue with the builder
<rsalveti> there's one way to get it fixed, that's to skip the test checking
<rsalveti> let me email TI about it
<MrCurious_> how do i skip the test checking?
<rsalveti> needs to rebuild the package
<rsalveti> if you build it locally, you'll not face that issue
<rsalveti> the problem only happens at the launchpad builder
<MrCurious_> guess that means my install is on hold until they fix it
<rsalveti> MrCurious: you can build it locally and install it by hand
<rsalveti> I'll send the proposed fix now by email, I believe they will be able to fix it tomorrow
<MrCurious_> awesome
<MrCurious_> i am not sure where to get the sources for that, and i have never worked out how to tell apt i did sumething manually
<MrCurious_> but i think i can wait until tomorrow
<MrCurious_> oh wow! the install didnt loop around kbd, username, .... this time
<infinity> rsalveti: Running the testsuite generates a broken package?  That seems a bit wrong.
<rsalveti> infinity: when running the test suite under qemu it basically explodes :-)
<rsalveti> that's the problem
<rsalveti> that's why skipping the test run fixes the build problem, because the build is fine
<rsalveti> and goes fine at qemu, just when running the tests that everything breaks
<infinity> Oh, I see.  As in, it's actually put qemu in a broken state.
<infinity> And people still think qemu is a sane and reasonable solution...
<MrCurious_>  i am seeing that ppa.launchpad.net oneiric release is missing a public key, and cant be verified
<scientes> anyone know a good ARM SoC with CAN?
<scientes> maybe i.MX28  ?
<scientes> http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=IMX28_FAMILY
<scientes> wait, thats ARM9, aka like v5, so old
<scientes> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX357
<rcn-ee> scientes, how about the ti am335x (2 can ports) beaglebone...
<infinity> scientes: Expand CAN?
<scientes> infinity, Controller Area Network
<scientes> its a broadcast-only (!) bus heavily used in automotive
<infinity> can: controller area network core (rev 20090105 abi 8)
<infinity> ^-- Should I assume that means I have one?
<scientes> infinity, yeah
<infinity> (That's dmesg on an i.MX53 QuickStart)
<scientes> check if you have a can0 with ip link
<scientes> (i.e. if there is a SocketCAN driver)
<infinity> I have no can0, but that could just be a module not loaded...
<infinity> Or not built in.
<infinity> This kernel's somewhat sketchy...
<infinity> scientes: The i.MX53 Data Sheet, at least, claims "Two controller area network (FlexCAN) interfaces, 1 Mbps each"
<scientes> infinity, try modprobe flexcan mpc5xxx_can
<infinity> scientes: That would work better if I had either of those modules. ;)
<infinity> scientes: Did I mention my sketchy kernel on this board?
<scientes> well, they are in drivers/net/can
<scientes> so do a kernel rebuild!
<scientes> is it mainlined?
<infinity> I could just install a different kernel.  The machine's my mirror right now, and I don't want to offline it.
<scientes> yeah, that $149 board is alot better than the $100 usb dongles some are selling
<scientes> > 720p encode
<scientes> woah
<scientes> and SATA nice
<scientes> "VMware player to bring up the Linux image on a Windows PC"
<scientes> never knew VMware did emulation
<infinity> It's a good board.  And the SoC clearly supports what you want.  What I have no idea of is if the board provides ports/pinouts for what you need. ;)
<scientes> wow, the picture of it, its just so packed with ports
<GrueMaster> scientes: rcn-ee also pointed out the beaglebone.  You can find it on http://beagleboard.org.
<scientes> GrueMaster, but the iMX53 is clearly a much more powerful board
<GrueMaster> Define "powerful".  It really depends on your usage model/budget.
<GrueMaster> (and I was just pointing out another option).
<scientes> yeah thxc
<scientes> i did see that
 * scientes would really like a 4X core
<rcn-ee> i think we all are waiting for that day. ;)
<scientes> i'm actually using a E-350 x86 board
<scientes> but i'd like CAN, and with the prices of usb ones (that are just integrated ARM chips with a gadget port) it makes sense to use one of these
<scientes> if i want CAN at all
<GrueMaster> Not to brag, but I have tested one.  Server side only though.
<GrueMaster> 4x Core system, that is.
<infinity> I've played with i.MX6s too.  Sadly, they don't actually exist.
<infinity> The ones I used were, I was told, figments of my imagination.
<GrueMaster> Heh.
<rcn-ee> so did you take it home for yourself, and just tell them it never existed..
 * GrueMaster wants armv8.
<scientes> 64-bit baby
<Haikarainen> anyone awake?
<Haikarainen> I tried to install Ubuntu 11.10 with a preinstalled omap4 desktop image on my brand new Pandaboard ES
<Haikarainen> It worked fine, until third reboot(after it resized my partition, and then checked the fs) it just greeted me with a terminal login
<Haikarainen> I checked the /etc/passwd and the /home folder, no users except root
<Haikarainen> got image from http://cdimage.ubuntu.com/releases/11.10/release/
<Haikarainen> well, there were plenty of users in etc/passwd but no regular one, and no folders in homedir
<scientes> are there some cheaper LVDS touchscreens?
<prpplague> scientes: tincantools will have some lvds boards and kits available at the end of next week
<prpplague> scientes: first models will be without touchscreen
<prpplague> scientes: works with panda and beagle - http://tincantools.com/product.php?productid=16158&cat=0&page=1&featured
<prpplague> scientes: is there something specific you are looking for?
<scientes> no really prpplague
<scientes> i have a mimo usb touchscreen
<scientes> that is working with multiseat
<prpplague> anyone have a snowball board?
<XorA> whats that?
<prpplague> XorA: hehe
<XorA> what?
<XorA> do I miss something?
<prpplague> XorA: hehe, no just points out that it isn't well known
<XorA> I had to goggle it
<MrCurious_> woo hoo, got 11.10 on my pandaboard, and got the omap extras installed
<scientes> > omap extras
<scientes> *binary blobs
<jimerickson> pandaboard ES and 12.04, after latest update there is no desktop, just the login screen over and over.
#ubuntu-arm 2012-04-13
<rsalveti> and goes fine at qemu, just when running the tests that everything breaks
<rsalveti> argh
<rsalveti> jimerickson: do you have the pvr driver installed?
<rsalveti> did you try to login at ubuntu 2d?
<infinity> rsalveti: Did you break something?
<rsalveti> infinity: nops, just wanted to know if the issue is related with unity 3d
<rsalveti> but I noticed today that nux also got updated to a newer version
<rsalveti> seems to be still at proposed
<infinity> I think that's all waiting on some co-ordinated unity release.
<infinity> I've lost track.
<rsalveti> I'm scared that this could break the desktop again, we'll see
<rsalveti> at beta 2 I couldn't even login at unity 3d
<jimerickson> rsalveti: yes i had the pvr driver installed. yes tried login at 2D.
<rsalveti> jimerickson: even 2d failed?
<jimerickson> yes
<rsalveti> I'm updating my rootfs, will check in a few minutes
<jimerickson> i am re-imaging my sd card with yesterdays image. will try again without pvr driver installed.
<rsalveti> sgx shouldn't interfere at unity-2d
<rsalveti> hm, ubuntu-desktop is not installable anymore
<rsalveti> the update removed a few packages as well
<rsalveti> probably archive out-of-sync issues
<jimerickson> should i wait to update?
<rsalveti> yes
<jimerickson> rsalveti: ok i will wait.
<jimerickson> rsalveti: ok i am back to normal with yesterdays image. no pvr driver installed this time.
<djszapi> Hey! Which ubuntu image do you recommend for Pandaboard ? http://www.omappedia.org/wiki/Prebuilt_ubuntu_binaries
<djszapi> perhaps this one ? https://wiki.ubuntu.com/ARM/OMAPHeadlessInstall
<djszapi> oh probably even this one: wget http://cdimage.ubuntu.com/ubuntu-core/releases/11.10/release/ubuntu-core-11.10-core-armel.tar.gz
<infinity> janimo`: Why did your last ac100 kernel upload make zcache builtin?  It's modular everywhere else..
<ogra_> as long as zram isnt gone ...
<infinity> ZRAM didn't appear to change, no.
<infinity> So, I'm sure it's all fine.
<ogra_> iirc zcache doesnt work without kernel cmdline option anyway
<janimo`> infinity, it was suggested on the ac100 mailing list by marvin24
<marvin24_DT> infinity: basicly, zcache as a module doesn't work
<marvin24_DT> either built-in or nothing
<marvin24_DT> looks like my 3.2.0 from precise also has zcache=m ...
<jimerickson> hmm no more gwibber. sad.
<makaru> hi
<makaru> hi
#ubuntu-arm 2012-04-14
<olegfink> anyone here owns an hp t5335z by chance?
<spych102> I'm struggling with getting an ubuntu image onto my sd card
<spych102> i follow the instructions at the download website and then nothing seems to get copied to my sd card
<spych102> the command i used was gunzip -c ubuntu-11.10-preinstalled-desktop-armel+omap4.img.gz | sudo dd bs=64k of=sdb1
<spych102> but when i look to see what's on sdb1 i have exactly the same contents as was previously on the card
<spych102> i have just realised my mistake, should have been of=/dev/sdb1
<spych102> rather than of=sdb1
<GrueMaster> spych102: Actually, it should be /dev/sdb as the image file is for the entire SD card, not just a single partition.
#ubuntu-arm 2012-04-15
<spych102> GrueMaster: Thanks, that explains why it still didn't work
<scientes> are any  of these new quad core arm's going to have hdmi?
<infinity> scientes: I'm sure the MX6 will, since the MX53 already does.
#ubuntu-arm 2013-04-08
<ppisati> ogra_: hi, do you know if the latest nexus7 img contains the x-input fix you told me last week?
<ogra_> nope, doesnt yet, seems thats hard to backport
<ppisati> ogra_: :(
<ogra_> and we cant update to the newer xorg because the nvidia driver is binary
<ogra_> so until nvidia releases new blobs we're stuck
<ogra_> #ubuntu-x should know an ETA though
<ppisati> ogra_: ok, i'll ask there then
<ppisati> ogra_: thanks
#ubuntu-arm 2013-04-09
<Snark> when I'm on this page: https://launchpad.net/ubuntu/raring/armhf/gcc-4.7/4.7.2-23ubuntu2
<Snark> how do I find the list of known bugs?
<Snark> I might have another to report
<infinity> Snark: https://launchpad.net/ubuntu/+source/gcc-4.7/+bugs
<Snark> infinity: thanks, but where was the link on the page of the package?
<infinity> Snark: From the binary package pages like that, I'm not sure there's an obvious way.
<infinity> Snark: If you clicked the source link, then the "bugs" link at the top goes to the right place.
<Snark> I won't take the time to report that as a launchpad bug, but it certainly is :-P
<Snark> ok, new bug submitted against gcc
<Snark> https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1166628
<ubot2`> Launchpad bug 1166628 in gcc-4.7 "New compile error on ARM" [Undecided,New]
<infinity> I bet if you drop the whitespace in "[ r0 ]" it works.
<infinity> Snark: http://launchpadlibrarian.net/125024108/gmp_2%3A5.0.5%2Bdfsg-2ubuntu2_2%3A5.0.5%2Bdfsg-2ubuntu3.diff.gz
<infinity> Snark: I knew I'd seen that before. :P
<infinity> Snark: It's a binutils bug/misfeature, but that works around it.  I uploaded that a few months ago.
<Snark> infinity: uh... but it's still not included?
<infinity> Snark: Not included in what?
<infinity> Snark: That version of gmp has been in raring for months.
<Snark> the fact that gcc cannot compile mpir 2.6.0 and upstream is annoying
<infinity> s/gcc/binutils/
<infinity> The upstream code could be changed for less tolerate assemblers.
<infinity> But, sure, binutils should also be fixed to be more liberal again, probably.
<Snark> that would be nice, if you know whom to ask :-/
<marvin24> janimo`: I put a new 3.1 kernel to https://launchpad.net/~ac100/+archive/ppa/+packages
<janimo`> marvin24, thanks. Does it work ok, just needs copying into the archive?
<janimo`> marvin24, is the included changelog all that is different from the current package?
<marvin24> janimo`: no, I had to increase the version number several times
<marvin24> sorry, I didn't know how to combine them
<janimo`> marvin24, np
<marvin24> becasue launchpad doesn't like the same version twice uploaded
<janimo`> marvin24, in the PPA I thought you can delete a package and then you can reupload. But I may be wrong
<marvin24> maybe, deleteing the old package and uploading a new should work
<marvin24> but maybe there is some better, official way
<marvin24> janimo`: ok, should I just try to delete the old packages and upload a new version with combined changelog?
<janimo`> marvin24, if you can do that in LP that would be better
<janimo`> so that the new package is the next version and the changelog appears in one place and on the -changes mailing list
<marvin24> how to notify the chnages ml?
<janimo`> marvin24, that happens when the package is uploade to the main archives
<janimo`> nothing to be done by developers
<janimo`> and it's a mail showing the latest changelog entry
<janimo`> so it's good to have all changes there in one place
<marvin24> janimo`: ok, I'll try to delete the "test"-packages first
<dannf> ppisati, infinity : fyi, i filed a few bugs w/ patches/MPs last night to get highbank support working again in d-i
<ogra_> i think that was discussed in #ubuntu-installer ort #ubuntu-release
<ppisati> dannf: lp?
<dannf> ah, ok
 * dannf isn't in those channels
<dannf> ppisati: yeah - this is the d-i MP, and has links to the other bugs: https://code.launchpad.net/~dannf/debian-installer/create-arm-generic/+merge/157801
<marvin24> janimo`: mmh, can't delete old packages because there are none selectable
<marvin24> and also cannot upload old versions because they still exist
<blackjack> hy
<blackjack> where download iso file rapsbery for ubuntu
 * ogra_ points to the channel topic
#ubuntu-arm 2013-04-10
<jP_wanN> hello
<jP_wanN> is this the right place to ask something about the ubuntu-android project?
<ogra_`> well, ask and we'll see
<jP_wanN> it's about the OUYA. That's a new android-based console. I wanted to know whether Ubuntu android could run on there
<jP_wanN> http://en.wikipedia.org/wiki/Ouya
<jP_wanN> a friend of mine got positive feedback from the OUYA CEO about a partnership with canonical.
<jP_wanN> http://forums.ouya.tv/discussion/646/ubuntu-for-ouya
<jP_wanN> but we didn't get any response when writing to canonical via mail
<kulve> why ubuntu-android? Why not plain android?
<kulve> argh
<kulve> why ubuntu-android? Why not plain ubuntu?
<ogra_`> jP_wanN, well, would you want to have "ubuntu for android" which essentially acts like an app ... or would you want to actually run ubuntu (whouch would be Ubuntu Touch, which also is android based but a full OS)
<ogra_`> while there is the opportunity to run a plain ubuntu as well, with the switch to Mir you really want ubuntu touch on such a device (unless you want to run it as a plain server)
<kulve> why not X.Org?
<jP_wanN> well, I'll definitely try to install normal ubuntu on it as soon as I have a console to play with
<jP_wanN> but the question was about running ubuntu as an app within the preinstalled system
<ogra_`> right, thats ubuntu for android ... which is actually depending on the manufacturer talking to canonical directly
<jP_wanN> okay, thanks for the information
<jP_wanN> but is there a way to install ubuntu for android on an existing system?
<ogra_`> there are no public images for it
<jP_wanN> I know it is officially only possible to have it preinstalled
<ogra_`> so no ... there isnt
<ogra_`> it needs pretty close system integration, so canonical requires collaboration from the manufacturer for this
<ogra_`> i guess ubuntu touch is your best bet
<ogra_`> and i'm sure as soon as the first ouyas show up in the wild at developer desks someone will port it
<jP_wanN> well, the OUYA team supports hacking the device (not that sure what's about the guarantee)
<ogra_`> porting UTouch is pretty trivial
<jP_wanN> well, not the downloading part :D
<ogra_`> took me a weekend to port it to my galays S2
<jP_wanN> cool thing
<jP_wanN> I'll ask you again
<jP_wanN> about something else
<jP_wanN> but first, about the ouya
<ogra_`> kulve, xorg drivers suck ... Mir can make use of the existing android GL drivers
<jP_wanN> if there were official images, it would be possible to replace the existing system with an android build with ubuntu android, right?
<ogra_`> right
<jP_wanN> okay
<jP_wanN> well than the main thing to get ubuntu android on the current version of OUYA is probably to wait for images
<jP_wanN> but now about porting ubuntu touch
<ogra_`> the ouya should be pretty close to the nexus7 HW wise ...
<ogra_`> you couold use the nexus7 desktop image on it with slight modifications i guess
<jP_wanN> ubuntu touch on OUYA is something I'll face somewhen else
<jP_wanN> but I've got an Sony Xperia Sola on which I want to install ubuntu touch
<jP_wanN> actually I only bought it to try ubuntu touch on it
<jP_wanN> it's the only smartphone with good enough HW for ubuntu touch, a microSD slot and less than 4" display width
<ogra_`> well, if it isnt on https://wiki.ubuntu.com/Touch/Devices yet ... you will have to port it yourself
<jP_wanN> yes, I know
<ogra_`> (there is also the #ubuntu-touch channel btw)
<jP_wanN> but my internet connection is so slow, I'll let a friend download those 15GB sources :D
<ogra_`> :)
<jP_wanN> okay
<ogra_`> yeah, its a bit painful
<ogra_`> i left it suckling over a weekend here ... that worked fine
<jP_wanN> I read that Ubuntu Touch uses some parts of cyanogenmod
<ogra_`> yup
<ogra_`> kernel, drivers and the hardware abstraction layer
<jP_wanN> could I get into trouble because the Xperia Sola is not supported by cyanogenmod?
<ogra_`> on top of that you have a normal ubuntu rootfs
<ogra_`> you would have to port it to CM first ... or find an unofficial CM 10.1 port, yes
<jP_wanN> sounds a lot of fun ^^Â°
<ogra_`> heh
<jP_wanN> but probably I don't have to do that
<jP_wanN> there is an unofficial port
<jP_wanN> http://freexperiaproject.com/
<jP_wanN> but I don't know for which CM version
<jP_wanN> oh found it
<jP_wanN> only v 9
<jP_wanN> well that'll take some time I think
<jP_wanN> but thanks :)
<ogra_`> good luck :)
<marvin24> janimo`: I failed to upload a kernel package to launchpad due to version name problems
<marvin24> I put an archive of the source package to http://tinyurl.com/c9hwg3u
<marvin24> there's nothing more I can do I guess :-(
<ogra_> marvin24, did you try to delete the old upload first ?
<ogra_> that should theretically work
<marvin24> ogra_: I couldn't
<marvin24> it is not shown on the delete page
<ogra_> you own the PPA, you should be able to
<marvin24> also launchpad forbits pushing the same version twice
<marvin24> ogra_: yes, this could work though
<marvin24> will try later again
<ogra_> ++
<ogra_> tell me if it doesnt
<ogra_> i think i used that way in the past and it used to work
<marvin24> ok, uploading ...
<marvin24> I guess that's why there is a "UNRELEASED" tag in the changes files instead of the disto name
<ogra_> well, thats to prevent you from accidentially uploading something unfinished
<marvin24> ah, so I cannot upload such a package - I thought that it will just not be published
<ogra_> it will reject it (or should at least)
<marvin24> so how to check if a package actually builds on launchpad without wasting a precious version number?
<marvin24> ok, personal ppa
<marvin24> arr, need to enable armhf on personal ppa
<ogra_> well, one mail
<marvin24> to czajkowski ?
<ogra_> yeah, i think so
<marvin24> ah, last time I did it via questions interface
<ogra_> yeah, that should work too
<ogra_> but might help to ping here as well
<ogra_> *her
<rookie2030> hi everybody
<rookie2030> its possible to connect in one eth port the router cable with DHCP and the other eth port the cable to PC and have the same IP
<rookie2030> i have a dreamplug
<rookie2030> with 2 ports ethernet
<rookie2030> I have a sheeva plug with 2 ethernet port and i need to connect one port to internet and the other port to my computer its possible to do in linux
<rookie2030> uses as physical link but i need to use the sheeva plug
#ubuntu-arm 2013-04-11
<lithiumjake> had anyone successfully compiled NodeJS on ubuntu-arm?
<ogra_> lithiumjake, it is in the archive, so yes
<lithiumjake> the archive?
<ogra_> in bthe ubuntu archive
<lithiumjake> great news though, mine keeps segfaulting everytime i try to use it
<ogra_> you can just apt-get install nodejs
<lithiumjake> yeah, that .6 though
<lithiumjake> i just did it
<lithiumjake> i guess i could just get a vps somewhere
<lithiumjake> nodejs is at like .10.2 or something now
<lithiumjake> thank you though
<ogra_> well, whatever is in debian ...
<ogra_> we just pull from there
#ubuntu-arm 2013-04-12
<marvin24> ogra_: https://launchpad.net/~marvin24/+archive/ppa/+build/4487296
<marvin24> this stupid lp expected starting time is really non-sense
<marvin24> better just write how many packages are before in the build queue
<ogra_> marvin24, complain in #launchpad :)
<ogra_> i cant change that
<ogra_> (well i could, LP is opensource but i have no clue about it)
#ubuntu-arm 2013-04-13
<marvin24> ogra_: I think it would be nice to get cbootimage into the distro (ubuntu or debian)
<marvin24> similar to abootimg
<marvin24> what's the best way to get there?
<ogra_> marvin24, whats the advantage over abootimg ?
<ogra_> (in debian you file an ITP bug, in ubuntu its similar (we dont have ITPs though, just a bug against the ubuntu product with "please package ... foo")
<marvin24> abootimg flashes kernel, cbootimage flashes bootloadr
<marvin24> the package is already build
<marvin24> but ok, I'll try to file a bug
#ubuntu-arm 2013-04-14
<codefree> Hi
<codefree> this is not the same as ubuntu phone is it?
<codefree> this is the actual thing, right?
<tassadar_> yeah)
<codefree> Why was there any need for ubuntu phone, though?
<tassadar_> probably because desktop system shrinked to small screen is really not easy to use
<codefree> I mean, are we ever going to have support for the actual thing on phones?
<codefree> well that doesn't apply to galaxy mega and tablets, right?
<tassadar_> touch and "the actuall thing" should be eventually the same thing
<codefree> but I heard ubuntu phone will only get html 5 apps
<codefree> or was that firefox os?
<tassadar_> firefox
<codefree> so we're free to use gcc on ubuntu phone?
<tassadar_> that's the goal I think
<codefree> Thanks. any idea for when they're going to support other devices than the nexus 7 or atleast get brand new ones on the market?
<popey> many of your questions are answered on the wiki codefree http://wiki.ubuntu.com/Touch
<tassadar_> not really, no, but touch and normal ubuntu should merge in 14.04 release
<codefree> Oh. So that's what I was missing. Searching for mobile didn't return me anything. Thanks guys.
#ubuntu-arm 2014-04-08
<davidm> infinity, ping
#ubuntu-arm 2014-04-09
<infinity> davidm: Hrm?
<davidm> hi infinity sorry I solved it, was banging my head on wiki.ubuntu.com it's working now
<infinity> Kay...
<Haikarainen> Hey, is init.rc (/etc/init.d) discouraged these days? Been a long while since I tampered around with ubuntu, need to do some maintenance, can someone point me to the appropriate man pages for the service management?
<Haikarainen> noticed they nag about using upstart, but then also some start utility named "start"..
<miseria> "los discursos politicos y su demagogia, para torturar un pueblo, son decorados con la frase: *derechos humanos*" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<Haikarainen> hey, anyone else having issues with GLFW3 not working as it should (for EGL / GL ES2.0)?
<Haikarainen> info here: https://gist.github.com/haikarainen/40817653e7a03cc45e82
#ubuntu-arm 2014-04-11
<arg> Hi, I am a newbie. Can anyone please help me tell how to add the guest user to "video" group ?
#ubuntu-arm 2014-04-13
<extravagantdrake> Does anyone know if there will be support for Ubuntu on the Raspberry Pi (Which has an armv6 architecture, rather than Ubuntu for ARM's supported armv7) in the future?
<ogra_> no
#ubuntu-arm 2015-04-09
<MeanderingCode> hello all.  i'm wondering: is there such thing as a bootable image for armv7 (tegra 3) with a "secure boot" signed bootloader?
<MeanderingCode> because, well, that would make my day
<MeanderingCode> or my month :)
<both> Are there any ARM beginners here?
<MeanderingCode> anyone up for my previous question?
<k1l_> MeanderingCode: best is to ask the community around that device to get to know what to do
<MeanderingCode> k1l_: there is no community around the device :)
<k1l_> MeanderingCode: its not like on the desktop where we have one .iso and generic drivers for all sort of hardware.
<MeanderingCode> k1l_: i've been gathering that, from reading yesterday.  but, there must be a bootloader, yes?
<MeanderingCode> and with it, one could make a bootable USB
<MeanderingCode> *bootloader, or this "Shim" thing i've read about w/ secure boot signed x86 bootloaders
<k1l_> so you got a locked bootloader on that device?
<MeanderingCode> it's a surface rt, tegra 3 processor...the UEFI is locked to secure boot.  it will boot from USB, but it would have to be a signed bootloader for the uefi secure boot to load any code
<MeanderingCode> *and i know no one is working on it, and no one cares, and it's considered a dead end/lost cause, but i have inherited one and (if there is a signed shim or bootloader for armv7), there is really no reason it couldn't run linux for arm
<k1l_> iirc the microsoft tablets are locked bootloaders and you cant sign a kernel because you dont get the microsoft key
<k1l_> see http://forum.xda-developers.com/showthread.php?t=2655398
<MeanderingCode> k1l_: yes, i've read that.  essentially (before it spun off into exploit and bootstrapping), one person said they thought they recalled that there were no signed bootloaders/kernels for linux on arm.  there is on x86, and that's one of the 2 or 3 unauthoritative places i've seen that statement made, which is why i thought i'd ask here about secure boot signed arm bootloaders/shim
<k1l_> MeanderingCode: secureboot on pc (x86) is a total other business than arm for microsoft.
<k1l_> on arm its locked by default
<MeanderingCode> i realize that.
<k1l_> so it will not help that its different on x86 as long as there are no keys for arm.
<MeanderingCode> are you saying that you know there are no signed linux bootloaders for arm, or that it is different
<MeanderingCode> because i already know that it is different
<k1l_> which microsoft made because to save their business for arm.
<k1l_> microsoft demands locked bootloaders if the device ships microsoft windows.
<k1l_> (on arm)
<k1l_> MeanderingCode: the setup on most arm is: hardcoded bootloader which either boots only signed kernels or could be opened to boot even unsigned kernels. for microsoft shiping devices microsoft demands to only boot microsoft signed kernels.
<k1l_> i am not aware of a method to evade that hardcoded bootloaders. even on devices that ship android (linux kernel) they could not break that but used other methods like kexec to boot another unsigned kernel after the original signed kernel was booted. but i am not aware that works with microsoft.
<k1l_> that is why you should ask the surface community, because they will know best on the specific setup of that device.
<MeanderingCode> k1l_: thanks for all the insight.  maybe i'll dig futher to see if anyone's done it, or maybe i'll just give it to my kids to play games when out and about :)
#ubuntu-arm 2015-04-10
<lilstevie> MeanderingCode, the WHQL process for windows RT devices mandates that secureboot is always active, and that it only includes the microsoft root public key, on x86/x64 they require it to also include the intermediate public key. Microsoft code is signed with the root key, verisigned code is done with the intermediate key.
<hvn52> hi, I'm using kernel 3.17.1-armv7 on my BeagleBoard Classic Rev C4 and find that I can write to the RS232 port but not read from it. When I look at vanilla kernel 3.19.3 for the settings of the SERIAL_8250_OMAP, I notice it's dependent on TTY + HAS_IOMEM + SERIAL_8250 + ARCH_OMAP2PLUS. Does it have any dependencies for read/write ability ?
<hvn52> BTW, kernel 3.17.1-armv7 is part of Ubuntu 14.04 armhf.
<mijk> hey, anyone know of any ARM laptop/netbook that runs Ubuntu well?
<mijk> and by well, I mean hardware accelerated video :P
<genii> mijk: If you don't mind a tablet instead, most of them that are based on the Texas Instruments Blaze Tablet platform can run linux and have native drivers for the powervr gpu onboard. Need to get an external keyboard then though.
<mijk> hmm good to know
<askk> hi i installed ubuntu 14.10 on tablet pc hp stream 7 i installed the driver for wifi and touch screen my question how i save the state and size of the virtual keyboard florence on ubunut login any idea ?
<askk> hi i installed ubuntu 14.10 on tablet pc x86 hp stream 7 i installed the driver for wifi and touch screen my question how i save the state and size of the virtual keyboard florence on ubunut login any idea ?
#ubuntu-arm 2016-04-12
<tmash> hello arm fans XD
#ubuntu-arm 2016-04-14
<Osirus126> im in need of some help regarding installing a package called kodi-rbp on my ubuntu mate for raspberry pi 3 desktop
<Osirus126> i had installed it the other day under ubuntu mate 16.04 using apt-get install but now i cannot seem to find it
<Osirus126> can someone please help me
#ubuntu-arm 2017-04-11
<suhamera> HI
<suhamera> i'm trying to run Ubuntu Core on my DragonBoard 410c
<suhamera> there is no problem when i'm using SD
<suhamera> But I would like to put the image to the built-in eMMC - is this possible? If so, is there an instruction or manual?
<ogra_> suhamera, hey ... come over to #snappy :)
<suhamera> ok, moving on it
#ubuntu-arm 2018-04-11
<Rainy> Hello!
<Rainy> I was curious, I've been able to stably run grub on a surface RT tablet, but, should I somehow try and chainload u-boot for armv7 or is there some type of devicetree for microsoft surface RT that might not lock up?
<Rainy> In grub debug, I get to "Caching Disabled! Jumping to entry point." From there I just hard lockup using tegra30 .dts device trees.
#ubuntu-arm 2018-04-13
<sieuhgisaeg> Lots of problems, no one helps :(
#ubuntu-arm 2018-04-14
<laddite> 404 Not Found [IP: 91.189.91.23 80], E:Failed to fetch I've looked into the parent paths and there is stuff from x86 and amd64, but not for arm? isn't arm supported?
<laddite> hello! I'm trying to upgrade to arm64 version of Artful, but when I run the upgrade I get errors like this: http://us.archive.ubuntu.com/ubuntu/dists/artful/main/binary-arm64/Packages
<laddite> 404 Not Found [IP: 91.189.91.23 80], E:Failed to fetch I've looked into the parent paths and there is stuff from x86 and amd64, but not for arm? isn't arm supported?
<laddite> sorry, lines got mixed up
<genii> laddite: Use ports.ubuntu.com
<fxnoob> hello
<fxnoob> how long is the timeframe for a new release to be on ARM?
<fxnoob> for example 18.04, I'm interested in LTS
<lyakh> hi, I flashed ubuntu core 16 to an SD card, trying to boot a raspberry pi 2 B, it's flashing 4 short and four long green pulses repeatedly, I found that 4 flashes mean "loader.bin not launch-able (corrupt)", but there's no loader.bin at all on the card?
<lyakh> just tried ubuntu mate - running well, so, my pi is ok
