#ubuntu-arm 2009-06-16
<nat2610> hey, I'm curious, how do you compile everything for arm. IO
<nat2610> I'm looking at doing some cross compilation and generating an application that I'm working on, on my i386 linux and I'd like to generate an arm binrary
<nat2610> I'm stock on the system library, for instance, I link libobjc.so.2 to my app but ld if I use arm-none-linux-gnueabi-gcc, ld complain that it can't find that lib since the one my system have is compiled for i386
<nat2610> but I know I have it on my arm system with ubuntu
<nat2610> hmmm let me try to say that again
<playya> nat2610, ubuntu prefers native builds
<playya> you need a arm5 device to compile it there
<nat2610> playya, so I can't do any cross compiling at all ? I saw some stuff like http://www.freedesktop.org/wiki/Software/sbox2 but I don't really know who uses that (I was hopping ubuntu would be ;) )
<nat2610> playya,  I forgot to add, I have a arm5 device but it's really slow so I'm trying to build everything on my pc i386 and just copy over the binraries generated
<armin76> nat2610: ubuntu is about using pre-built binaries :)
<[g2]> nat2610: depending on what you are trying to cross-compile, you may want setup a full environment, or just run the arm-rootfs in qemu and cross-compile from within a native environment
<kblin> hi folks
<kblin> I'm running jaunty on a beagle board using one of ogra's kernels, and it seems like there's something weird going on with /proc
<kblin> specifically, /proc/<pid>/maps and /proc/<pid>/smaps are empty
<kblin> any idea what could be causing this?
<Martyn> kblin : An incomplete implementation
<Martyn> kblin : find one of the OMAP3 git trees, and you'll have to build a custom kernel
<kblin> ok, I'll have to look into that then
<Martyn> There is a good 2.6.29 (and now .30) kernel that compiles well.  Don't use the tree that has the alternate video driver (ubuntu doesn't know how to drive it, and you'll end up with just a text console)
<kblin> hey, I can fix the ip6tables modules while at that :)
<kblin> Martyn: it's a headless ubuntu-server box, I don't mind :)
<Martyn> oh!
<Martyn> Well, then...
<kblin> I'm trying to turn it into a file server, active directory domain controller
<Martyn> you're going to find that IO performance on the beagle is ATROCIOUS
<Martyn> Seriously poo-poo
<kblin> yeah, I know
<Martyn> I am using USB->SATA on a Beagle C3, and frankly I just want to throw it at a wall most days
<Martyn> Then again, I'm getting /really/ used to working with the power of the new Cortex-A8 processors, and even Cortex A9 in the software FastModel simulators
<kblin> especially as it seems like networking flakes out on my revB if I use a 2.0 USB hdd
<Martyn> There's nothing like having 2, even 4 cores to really make things go zoom
<Martyn> Yes
<Martyn> there's a power issue on the RevB
<Martyn> don't even bother with the B
<kblin> well, that's what I got here..
<kblin> btw, power issue? would that matter on a powered hub?
<kblin> anyway, this is more or less a proof of concept to show off at the storage developer's conference
<Martyn> kblin : no, it's a matter of the on-board 100mw
<Martyn> kblin : For some reason, the USB OTG hub tends to 'brown out' for no good reason
<kblin> ok, weird :)
<Martyn> which causes the hub to go into a bad state
<Martyn> the host controller, rather
<Martyn> yeah, feh :)
<Martyn> C2/C3 doesn't suffer from the issue
<Martyn> and has a PROPER port on it
<kblin> that matches what I see in dmesg
<kblin> well, crud :)
<kblin> I guess if I really want to do this with a decent performance, I should be using a system with on-board ethernet anyway :)
<Martyn> this is similar to the problem my company is trying to solve.  Yep.
<Martyn> kblin : There will be  (soon)  some boards based on the OMAP3 and i.mx51 that are similar to the beagle
<Martyn> with more onboard devices
<Martyn> there are also beagle-clones that /do/ have ethernet
 * kblin nods
<Martyn> one even has a USB->SATA bridge
<kblin> as I said, this one is a proof of concept
<kblin> I'm sure if someone wants to turn this into a product, they'll bring the embedded know-how to build a system with the correct specs
<kblin> I just want to go to a storage conference showing off that opensource can run an active directory domain controller with 2 Watts
<broonie> You want to redo the old ARM demo and arrange to power it with the waste heat from a PC. :)
<kblin> hehe
<kblin> I'm not sure if a stirling engine-type generator won't look too much like a bomb on X-ray :)
<suihkulokki> kblin: if you want decent headless network server, you should look at something like the sheevaplug
<kblin> suihkulokki: yeah, planning to
<kblin> suihkulokki: I'm currently looking for a way to get shipping to be less than 70% of the unit costs
#ubuntu-arm 2009-06-17
<ttx> Hey guys, I have an armel build failure at: https://launchpad.net/ubuntu/+source/wesnoth/1:1.6.2-1ubuntu1/+build/1079861
<ttx> Boils down to "configure: error: C compiler cannot create executables"
<ttx> Any hint on how I could debug that ?
<kblin> no c compiler installed?
<ttx> kblin: that's on an armel buildd so I suppose there is build-essential installed :)
<persia> Maybe related to the recent binutils upload?  I heard a rumour that there were increased build failures on all non-x86 hardware.
<kblin> good point, I see the line where gcc 4 is installed
<kblin> doesn't the ubuntu build system do something like "cat config.log" if configure fails?
<ttx> kblin: unfortunately, not :)
<persia> Adding cat config.log would be something someone could do in debian/rules to debug something.
<kblin> because that's where I'd start
<ttx> persia/kblin: I'll see if the rumour confirms itself and if not, do some debian/rules instrumentation in my PPA
<ttx> thanks
<persia> ttx, If your PPA has non-x86 :)
<persia> Otherwise, I'd recommend looking for some hardware or virtualisation environment.
<kblin> qemu-arm works ok..
<persia> (it shouldn't take that long to get to ./configure, even in low memory-limited qemu-system-arm)
<ttx> ok, I'll look into that.
<kblin> if you get past the random installer hangs
<kblin> though I didn't try 9.10 there
<ttx> looking at the buildd logs at https://launchpad.net/builders/nageia/+history it might just make sense to retry the build.
<ttx> all builds are currently failing
<kblin> ouch
<kblin> I agree, given that all of those fail a couple of minutes into the build, with configure: error: C compiler cannot create executables :)
<lool> ogra: build-arm-rootfs is a huge success; I keep reading about it in various places; I wish it would become a real project though: source code control, new features, bug reports and the like
<ogra> its in the works
<lool> ogra: Could you make that happen?  I'm happy to contribute if it's in some shared place
<ogra> i'm currently pondering how to integrate oem-config properly
<ogra> https://blueprints.launchpad.net/ubuntu/+spec/mobile-arm-karmic-offline-installer-gui :)
<ogra> i want to get over the script in the qemu instance and use proper tools ...
<ogra> i'll put a branch up today
<ogra> and prepare a package before end of the week
<lool> Ok, cool
<lool> ogra: e.g. 53052.124.124.219.226.1245156274.squirrel@iwavesystems.com
<lool> ogra: With time, I'm starting to think we could use an ubuntu-arm@ ML, and perhaps a LP team
<lool> We have a release out of the door, will support more SoCs and get more enthusiasts over time which use Ubuntu as a base
<ogra> yeah, fully agreed
<ogra> i'm getting chased down by a guy on ubuntu-users@ about his arm probs since weeks, he alone would have filled such a list since UDS :)
<ogra> lool, there you go https://launchpad.net/ubuntu-arm-roofs-builder ... i'll create a maintainer team (or hand it to a newly created LP ubuntu-arm team) later
<ogra> https://launchpad.net/ubuntu-arm-roofs-builder/trunk will have it with the next publisher run (i already pushed)
<lool> ogra: Hmm consider naming things without ARM
 * ogra sees lool answered savita on ubuntu-devel ... 
<lool> ogra: only to one of the two questions
<ogra> he is the guy i try to educate on ubuntu-users i mentioned above
<ogra> yes, i answered all of his questions several times already
<ogra> he asks them over and over and doesnt understand
<lool> That sucks
<ogra> yeah
<ogra> well, thats the nature of ubuntu-users@ .... i asked him several times to come here, but he didnt find his way yet
<ogra> in a one to one IRC conversation i'm sure he would get his imx31 system up and running fast
<lool> ogra: Back to ubuntu-arm-roofs-builder, I think the approach would work very well with other use cases such as mips or even i386, so it would be nice to not use arm in the name :)
 * lool lunch &
<ogra> well, its initially written for armel only :)
<ogra> i can rename it if qemu grows support for other arches we support with it
<ogra> (usb-imagewriter supports SD cards too, but i wouldnt rename it to be just imagewriter (to generic) or usb-and-sd-imagewriter (to long)) :)
<playya> sometimes its better to post in on a ML. then the recipient can read it again and again
<lool> ogra: qemu-system-<tab>  :)
<lool> ogra: The thing is that it's going to be hard to rename later when it's referenced, and it's not hard to make it generic
<ogra> lool, any suggestions ?
<ogra> playya, well, he asks the same question within five mails he sends within 15min at that speed IRC is more convenient
<ogra> grmbl, indeed you can change everything but the url of the LP project
<lool> ogra: Well rootfs-builder, or some cool project name
<lool> argo!
<ogra> so should i register a new project ?
<lool> ogra: I think you can rename it
<ogra> argo?
<ogra> i can rename everything but the initial url i picked
<playya> assisted rootfs gold obtainer
<lool> ogra: Yeah, just a code name, and as you started it, agro sounded good  :)
<ogra> heh
<playya> can some of you poke the bzr guys to implement git import, please.
<ogra> pfft git
<lool> Another Rootfs Growing Oddball
<lool> playya: That's done?
<ogra> lool, i can change everything in the details page, but not the project url, so i need to create a new one or leave the url but change the rest
<lool> ogra: Really?
<ogra> yeah
<playya> lool, i can't pull git sources into LP
<ogra> https://launchpad.net/ubuntu-arm-roofs-builder/+edit doesnt offer to change "ubuntu-arm-roofs-builder"
<playya> and i want to have several projects. not only branches *hides*
<ogra> playya, no, you need to convert the git tree to something sane (i.e. bzr) and then you can push
<lool> playya: I think you can now
<lool> ogra: I think it's a separate action, like rename project
<lool> ogra: Otherwise, you can simply file a question to ask for the change
<playya> ok. I'll test it when i finished the debian dirs for the core stuff
<lool> https://answers.launchpad.net/launchpad/+question/8299 example
 * ogra checks
<lool> Crap, I can't easily find a project I own
<lool> Ulteo PC Virtualization Seminars: ?550 for the whole day
<lool> 550 EUR!
<ogra> fun
<ogra> how about "jarb"
<ogra> (just a rootfs builder" :)
<playya> or just another ...
<ogra> jaurb probably, since its written for ubuntu only (yet)
<lool> ogra: Well argo had the advantage of being ogra in reverse  ;-)
<ogra> yeah, but no meaning at all :)
<lool> I like jarb
<playya> is anyone working on a graphical image builder?
<lool> Simple, short, to the point, catchy
<ogra> jarb is an abbreviation :)
<lool> I hope it's not an insult in some language
<ogra> playya, i am :) https://blueprints.launchpad.net/ubuntu/+spec/mobile-arm-karmic-offline-installer-gui
<lool> playya: See, that's the kind of things we could do if we had some common project
<lool> I personally thought it would rock to have it in python, or integrated in uvb, but this is all rather futuristic  ;)
<ogra> yeah, and really a lot crappy overhead
<playya> vala vala vala
<ogra> i want a gui to select the options and then it should launch oem-config from inside qemu
<ogra> and i dont want to rewrite it in python :)
 * ogra considers calling it kxvlpm03582 ... thats surely not an insult in any language :)
<ogra> and as good to pronounce as the renamed screen-profile project :)
<ogra> which gets me an idea ... persia any nice japanese suggestion for naming ubuntu-arm-roofs-builder ?
<ogra> (japanese seems to be the current hype)
<playya> call it anata wa rootf builder
<playya> if i remember my japanese course correctly
<ogra> awrb ?
<dpb> awrb sounds like something written in ruby
<ogra> awrb.sh :)
<lool> argh no, not .sh!
<ogra> argh ... "arm rootfs generation helper"
<ogra> ;)
<ogra> or s/arm/another/ ... as you like
<persia> ogra, æ ¹ä½ (but I'm not sure how to pronounce it)
<ogra> is there an utf8 able equivalent i can use for LP ?
 * persia tries a couple things
<persia> nesaku probably isn't horridly wrong.
<ogra> sounds good
<ogra> what does it mean exactly ?
<persia> Meaning is roughly "The harvesting of the source/basis" or "root build"
<ogra> perfect
<ogra> lool, ^^^^^
<persia> Copy it to http://www.csse.monash.edu.au/~jwb/cgi-bin/wwwjdic.cgi?1B for a closer gloss.
<persia> it's not a normal compound, just one I cobbled up (so not an actual Japanese word or anything)
<persia> ogra, Do let me know if you're seriously considering it: I'll ask in #ubuntu-jp
<ogra> well, sounds better than all former suggestions yet
<ogra> lool seems asleep though ... or has no opinion ...
<persia> asleep at this hour?
<ogra> heh
<lool> a) I'm not asleep, just deep in a context and avoiding switches  :-)   b) I'm getting a headache  c) I disable beeping anyway!
<lool> ogra: A non-feature-bound term is fine by me!
<ogra> so lets go with "nesaku"
<lool> As long as you don't name the project ogra's-arm-and-ubuntu-only-shell-rootfs-tarball-builder, it's going to work
<ogra> nah, that would be to short
<ogra> but probably nesaku.sh ?
 * ogra hides
<lool> Nice try
<ogra> :)
<persia> ogra, Let me see if anyone in jp is still awake, to avoid making a silly mistake.
<persia> ogra, #ubuntu-jp folk say not to use that name.  It creates a reminder of farmers in olden times.  I have no good suggestions.
<lool> ogra: nesaku-(not-the-old-farmers)
<persia> heh.  No.
<ogra> heh
#ubuntu-arm 2009-06-18
<cars> Hi, I'm looking for a Korean IME for my netbook.
<persia> cars, For application-level discussion, I'd recommend #ubuntu-mobile, but does lanugage-selector not let you enable the default IME?
<vanexx> hey does anyone used web cam on a ARM board?
<vanexx> I pluged in my UVCVIDEO web cam, dmesg and lsusb says its a logitech orbit AF and that all is ok, but the problem is that cat /dev/video0 produces "no such device", whenever i connect the webcam it makes a directroy under /dev/.udev/names/video ... any idea on whast going on?
<lool> vanexx: You could crank up the udev debug level to find out
<lool> /etc/udev/udev.conf
<vanexx> lool so if i dont get the cam in /dev/video0 there is some problem right?
<lool> vanexx: I'm not 100% sure whether cat is a good test
<lool> vanexx: You might want to use some v4l2 program
<ogra_> arent there some cams that are not using /dev/video anymore ?
<lool> vanexx: Actually cat is a bad test, I just tried on my webcam and it doesn't work but the webcam works
 * lool moves himself to #ubuntu-meeting 
<vanexx> lool test a ls
<vanexx> ls /dev/vido0
<vanexx> u may got garbage chars right?
<lool> You mean /dev/video0
<lool> ls wont get you any garbage, no
<lool> vanexx: Just use vlc or cheese
<vanexx> vlc?
<lool> vanexx: apt-get install vlc, then "vlc v4l2://"
<lool> It's a media player
<vanexx> omg i am idiot
<vanexx> it works
<vanexx> but.. it even not worked with ffmpeg
<vanexx> i tried ffmpeg -i /dev/video0
<vanexx> and the same ting... hmm
<vanexx> thks for all loooooooooooooooooooool
 * ogra_ doubts lool highlights on that :)
<lool> Fortunately not :)
<vanexx> does anyone outputing web cam stream in AARM?
#ubuntu-arm 2009-06-19
<suihkulokki>  
<shunobies> Hello all I have a quick question probably like most. Does anyone know how to get Quick Synergy to work?
<shunobies> I have attempted to set it up several times now and have not luck
<shunobies> Hello all
<vanexx> Can anyone suggest me a goos ARM board with usb host? cheap pls.. :)
<lool> vanexx: beagleboard is probably the nicest you can get for now
<lool> it's v7 and has advanced modern hardware
<vanexx> yeah but is there any seller here in europe?
<vanexx> i know it is 149 $
<vanexx> but shpping cost is 80
<vanexx> hmm hey what about this.. http://plugcomputer.org/ it is cool
<lool> You can group orders; don't think there's a reseller in Europe
<lool> vanexx: The sheevaplug is cute and nice and cheap, but keep in mind it's ARMv5 and has no VFP
<lool> You can run Jaunty or Debian on it, but soon you wont be able to run karmic
<vanexx> I am crosscompiling UVCVIDEO to an arm board with linux 2.6.14, uvcvideo needs to be compiled with version > 2.6.14.
<vanexx> So its ok, I crosscompile it with 2.6.28 in my PC with no problems,  the problem is: when I try to insmod the compiled uvcvideo.ko into the ARM kernel i got errors of the type
<vanexx> "undefined symbol X", thats normal because those symbols (symbols from v4l2 etc)  are not in 2.6.14 os version, so is there way for compiling
<vanexx> uvcvideo specifyng that all refrences must be static instead of dynamic?
<gaspa> vanexx: you need to compile the module with the kernel you really use.
<gaspa> if uvcvideo needs a kernel  > 2.6.14, then it needs that version to run too.
<vanexx> but.. i cant change the os in the ARM board
<vanexx> it is 2.6.14 and cannont be changed..
<vanexx> I do believe it is possible without compiling with the version  I really use.. it is only a matter of compiling statically
<gaspa> no, it's not.
<vanexx> I mean gaspa, the only diff between 2.6.14 and 2.6.15 for example are new functions and symbols
<gaspa> why can't the kernel be changed? it's on a ROM?
<gaspa> "only" ?
<gaspa> :P
<vanexx> so if u export those symbols to ur static compilantion...
<vanexx> well no really only but, yes for that  matter
<ogra> you will at least need the headers for that kernel
<vanexx> gaspa no its on a flasy and yes it can be changed but i have no support from the vendor to do it
<ogra> (the *configured* headers, which means you need the source)
<vanexx> ogra yes... thats true
<gaspa> ogra: "(01:42:26 PM) vanexx: I am crosscompiling UVCVIDEO to an arm board with linux 2.6.14, uvcvideo needs to be compiled with version > 2.6.14."
<ogra> yep, i saw that
<vanexx> thats what i want: use the kernel headers but when compiling the resulting module must have all their references static
<ogra> backport it then :)
<ogra> or forwardport the missing functions
<gaspa> i think backporting is what you need to do.
<vanexx> how can I do it?
<ogra> with a lot of coding :)
<gaspa> change the code of uvcvideo to match the interface of 2.6.14...
<ogra> and there is no guarantee it will work
<ogra> (which you will only find out in the end)
<vanexx> and what if I dont change the OS in the ARM but in /lib i put libraries from the 2.6.28 for ex?
<vanexx> using busyboc for ex
<vanexx> busybox
<gaspa> vanexx: no, userspace library doesn't matter at all. uvcvideo is a kernel module, and so, must be compiled against the "same" kernel that will run it.
 * bizkut i am back
#ubuntu-arm 2009-06-21
<yeik> hey can anyone suggest me a good arm board?
#ubuntu-arm 2010-06-21
 * mozzwald is away: I'm busy
<hrw> morning
<NCommander> ogra_cmpc: ping?
<ogra_> NCommander, hey
<NCommander> ogra_: oh good, you live :-)
<NCommander> ogra_: have you had a chance to review the d-cd branch?
<ogra_> NCommander, could it be that you did a merge of d-cd upstream into your branch without committing ?
<NCommander> ogra_: ?
<ogra_> your code looks fine, but there are some weird things with tools/boot/maverick/boot-i386 and tools/boot/maverick/boot-amd64 in the diff
<NCommander> I did a merge of trunk into my code, but that should be a separate commit
<ogra_> oh, i see
<NCommander> ogra_: if that's an issue, I can make that commit go poof
<ogra_> no, should be fine, the files dont show up in a merge log
<ogra_> i was just not sure your upstream merge wouldnt touch them again and clash
 * NCommander might have done something wrong :-/
<ogra_> nope, all fine
<mpoirier> davidm ?
<davidm> Hello
<vstehle> ogra_cmpc: Hi! About this UART-usb-udev thing we discussed last week...
<vstehle> ogra_cmpc: I fiddled a bit and found nice udev attributes our FTDI have: ID_SERIAL and ID_SERIAL_SHORT :)
<ogra_cmpc> ah, nice
<vstehle> ogra_cmpc: looks like a symlink is not far...
<ogra_cmpc> great :)
<NCommander> ogra_cmpc: ping
<ogra_cmpc> NCommander, yep
<NCommander> ogra_cmpc: merged?
<ogra_cmpc> NCommander, cdimage ? not yet, later today
<NCommander> ogra_cmpc: oh nifty, for some reason, I thought you EODed already
 * ogra_cmpc struggles with mtools atm
<NCommander> ogra_cmpc: resizing still hurting you?
<ogra_cmpc> heh, i started late today so i'll surely work late
<NCommander> or is this with our antimony stuff?
<ogra_cmpc> no, its the resizing
<ogra_cmpc> i found out that mcopy works way better to make sure MLO ends up where it should be
<NCommander> ogra_cmpc: what's the currently issue with it? (since I'm mostly done smacking d-cd, I can probably help you on this)
<NCommander> ogra_cmpc: :-)
<ogra_cmpc> but somehow exporting the skip_check stuff doesnt work in initramfs
<NCommander> ogra_cmpc: are you exporting the MTOOLSRC variable pointing to the config file?
<NCommander> (for some stupid reason, you can't do MTOOLSRC=*file* mcopy, it won't work)
<ogra_cmpc>        Global variables may also be set via the environment:
<ogra_cmpc>             export MTOOLS_SKIP_CHECK=1
<ogra_cmpc> from the manpage
<NCommander> Hrm
<NCommander> That didn't work for me
<ogra_cmpc> so i'm just exporting the var before the mcopy call
 * NCommander grabs the source
<ogra_cmpc> well, then the manpage is wrong
<ogra_cmpc> but i would expect it to work
<ogra_cmpc> iirc we use that somewhere else on antimony in the same syntax
 * ogra_cmpc goes grepping
<NCommander> I use an MTOOLSRC file :-/
<ogra_cmpc> yeah
<ogra_cmpc> i wuld like to get through that without creating an extra file
<ogra_cmpc> but somehow that doesnt seem to work
<ogra_cmpc> well, i'll go back to create a file then
<ogra_cmpc> the annoying part is that rebuilding the image takes so long its very time consuming to test a change
<NCommander> ogra_cmpc: :-/
<NCommander> ogra_cmpc: can't you just respin the initramfs to test?
<ogra_cmpc> yes
<ogra_cmpc> its just a ton of manual steps to do that and get it in place
<hrw> ops
<hrw> zumbi: http://pastebin.com/vN4EH1bB + http://pastebin.com/EFG9YdgH
<hrw> ARGHHH..... I just killed my working dir...
<ian_brasil> asac: can you set up the CD builds for liquid?
<ian_brasil> we are ready for that now
<asac> ian_brasil: \o/
<asac> ian_brasil: join #linaro ;)
<ian_brasil> cool
<hrw> ogra_cmpc: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=shortlog;h=refs/heads/omap4-next-upstream
<hrw> have a nice rest of day
<prpplague> jkridner1: greetings
<jkridner1> hi prpplague.
<jkridner1> I'll try to drop by sometime today.
<hrw|gone> zumbi: https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/597020
<ubot2> Launchpad bug 597020 in gcc-4.5 (Debian) (and 2 other projects) "Merge rules for cross builds into normal one (affects: 1) (heat: 6)" [Unknown,Unknown]
#ubuntu-arm 2010-06-22
<DanaG> http://www.liliputing.com/2010/06/toshiba-ac100-10-inch-netbook-with-android-nvidia-tegra.html
<DanaG> Spiffy.
<DanaG> Now, if Tegra is actually a GeForce, that'd mean we'd be able to do Compiz.
<wocao> Illegal instructio
<wocao> Illegal instruction
<hrw> morning
<ogra> GRR
 * ogra starts to have fat filesystems with passion
<ogra> *hate
 * jussi hugs ogra
<hrw> ogra: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=shortlog;h=refs/heads/omap4-next-upstream
<ogra> hrw, thats in the package since a while
<hrw> ogra: if you want fresh uboot for pandaboard
<hrw> ok
<ogra> from omapzoom.org
<hrw> I still wait for early adopters production run
<ogra> but i see there are newer commits, i'll update it soon
<ogra> argh, crap
<ogra> now i dd'ed to a mounted device
 * ogra starts over
<ogra> hooraaaay
 * ogra finally found the right set of options for sfdisk so it doesnt trash anything when resizing partitions on the fly on first boot
<lag> Is OMAP3 in the Maverick tree?
<amitk> lag: yes, in the master branch
<amitk> lag: this question is better for #u-k, though
<lag> I assumed because it was Arm related?
<amitk> lag: it is still the kernel, so responsibility of #u-k, IOW, you, mpoirier and cooloney ;)
<mpoirier> amitk: what is #u-k ?
<amitk> mpoirier: #ubuntu-kernel, I'm lazy
<lag> I see. I assumed arm-kernel == arm
<lag> But *-kernel == kernel
<lag> Got it
<ogra_cmpc> well, we dont maintain your trees
<ogra_cmpc> we're only your users ;)
<ogra_cmpc> (or testers)
<ogra> GrueMaster, http://people.canonical.com/~ogra/jasper/ has a new image to play with :)
<ogra> GrueMaster, kernel upgrades wont work yet, the rest should be fine so far
<sshekar> ogra: a question on OMAP4...
<GrueMaster> ogra: thanks.  Downloading now.
<sshekar> we have dual display on the OMAP4 SDP/ Blaze...the easiest way to drive these would be with xorg.conf......but Ubuntu is not using xorg.conf, what do you recommmend?
<sshekar> ogra: to fix in X display driver itself?
<GrueMaster> sshekar: Ubuntu can run with an Xorg.conf file.  That's the only way to get nVidia SLI or twinview to work.  The default is not to have one and generate settings on the fly.
<sshekar> GrueMaster: thanks.
<lag> Whats the default console on the Beagleboard XM?
<GrueMaster> lag: are you referring to the serial port?  If it is the same as the Beagleboard, it is ttyS2.
<lag> GrueMaster: Thought as much, thanks
<GrueMaster> I don't have an XM to verify with, though.
<asac> ogra: what did you do about CHS?
<AndyJ> not certain I am in the right channel but I'm trying to get help building some software on a mx51 board running ubuntu 10.04 and I'm getting the following error:  Error: selected processor does not support `swp r3,r2,[r1]' .  Anyone have any thoughts?
<AndyJ> cat /proc/cpuinfo  : http://monobin.com/__m7b7c9b3c   if that helps anyone the processor should run swp just fine from the looks of it
<armin76> AndyJ: thats weird, the ubuntu gcc uses -march=armv7-a by default
<ssvb> AndyJ: 'swp' instruction is deprecated
<ssvb> and it is not supported in thumb2 mode
<ssvb> you can try compiling '-marm' option
<ssvb> *with
<AndyJ> ssvb: thanks will give that a shot
#ubuntu-arm 2010-06-23
<lag> What flavours are supported on Panda/Beagle?
<lag> Is Panda just Maverick?
<lag> And Beagle? Both?
<cooloney> lag: beagle is omap3 which is a flavour in our master branch of Maverick
<cooloney> lag: panda is omap4 which is a separated topic branch from master, it is ti-omap4 branch
<cooloney> but in the future, when all the omap4 patches are merged into mainline, we don't need the ti-omap4 branch anymore
<amitk> lag: omap3 is branch in lucid (ti-omap), part of master in maverick. omap4 is maverick-only (ti-omap4 branch)
<cooloney> amitk: do you know what's the difference between x-loader and u-boot?
<cooloney> amitk: i just clone the x-loader for omap4, it looks like u-boot.
<lag> Isn't x-loader == MLO
<sebjan> cooloney: x-loader is a stripped version of u-boot. So same code base but minimal size.
<cooloney> sebjan: thanks, man. and is x-loader required for omap4 board booting?
<sebjan> cooloney: today yes. We shall be able to get rid of it in a near future.
<cooloney> sebjan: ok, so in the near future, u-boot is good enough for booting the system, right?
<sebjan> cooloney: yes, that's it :)
<hrw> morning
<cooloney> hrw: morning
<cooloney> sebjan: back to lag's question, x-loader == MLO? what's MLO?
<cooloney> sebjan: or it's a secret name
<hrw> MLO is X-Loader
<lag> I though MLO was for cards
<cooloney> hrw: just another name of x-loader?
<lag> MLO == x-loader for MMC
<lag> Not a secret
<sebjan> MLO just has an additional header added to the x-loader binary
<DanaG> omap4 "panda"? That's new.
<DanaG> I wanna' see a pic of that.
<hrw> DanaG: I want hw to take a pic
<DanaG> It seems to be so brand-spanking-new, the only google results are the kernel commits.
<hrw> DanaG: iirc release in fall
<DanaG> http://marcin.juszkiewicz.com.pl/2010/05/14/uds-continues/
<DanaG> I still say: I don't call 3D useful until it can do compiz. Open or closed, doesn't matter too much.
<DanaG> Well, as long as the closed thing actually builds -- TI PowerVR build script fails miserably.
<DanaG> A username and password are being requested by http://www.pandaboard.org. The site says: " pandaboard.org is coming soon.  Please check back later.  "
<DanaG> I also think it really sucks that there's an x86 Flash, an x86_64 flash (though not anymore), an ARM-based Android flash... yet no simple ARM flash!
<DanaG> Same for dropbox.
<DanaG> All it takes is copying files, installing headers, and running "make" (at least, that's what my own software required).  Is that too much to ask?
<amitk> DanaG: all it takes is someone to give Adobe a six-figure cheque for that
<amitk> if you have spare change lying around, perhaps you want to become the hero of the OSS community? ;)
<DanaG> I mean, Android would have taken MORE effort than just plain ARM!
<DanaG> That makes no sense.
<hrw> DanaG: there is one company behind android... forgot?
<DanaG> Yeah, I know Google does Android, but the fact that they have Android means they probably have ARM hardware.... and thus there's no excuse for not doing a mere "make" on the existing Flash code.
<DanaG> On ARM.
<hrw> money is a reason
<DanaG> What money does it take to do "scp" and "ssh" and "make"?
<amitk> each of them gave Adobe cheques. A much larger cheque is required to free it all. OTOH, perhaps effort is wasted there and everyone should help with gnash instead?
<hrw> if you can get money from Google, Nokia, others when why release basic one?
<DanaG> And same is true of Dropbox.
<hrw> never used
 * amitk neither
<DanaG> And unfortunately, ubuntuone rather completely devours my CPU.
<cooloney> DanaG: dropbox is blocked in China, although some people are using it
<DanaG> 100% of one core.
<amitk> probably a bug
<DanaG> My use case is having Pidgin logs in it.
<DanaG> Thousands of files.
<DanaG> In fact, the transition from 32-bit to 64-bit x86 has more changes, at least in my experience, than the transition from 32-bit x86 to 32-bit ARM.
<amitk> more changes in what sense?
<DanaG> Oh yeah, are any of you in positions to talk directly to those companies (Dropbox or Adobe)?
<DanaG> In terms of things like pointer size, and "cast from pointer to uint32_t loses precision" (or such).
<DanaG> http://laptopmemo.com/2010/06/22/adobe-leaks-out-all-android-handsets-that-get-the-upgrade-to-2-2-froyo/
<DanaG> Say, does "meego" use Xorg?
<sshekar> yes, Meego uses X
<DanaG> ah, then this means they will be making an ARM-based X-based Flash.
<DanaG> Sweet.
<sshekar> not sure abt that
<DanaG> I'd find it particularly awesome to have an Ubuntu phone.
<amitk> that would require significant amounts of new UI work
<DanaG> Or even just something that I could do "ssh -X" from would be enough.
<DanaG> Android doesn't satisfy that.  Then again, there are probably VNC clients for Android.
<hrw> DanaG: maemo has flash too
<DanaG> har, I go to get.adobe.com/flashplayer in chromium... it gives me x86 version.
<DanaG> ah, must just not bother trying to detect.
<hrw> DanaG: dig a bit there, fake useragent so maybe you will get android
<DanaG> http://get.adobe.com/flashplayer/otherversions/ -- nothing ARM there.
<DanaG> ah, looks like it's just not available yet.
<amitk> DanaG: ARM versions are Adobe's cash cows at the moment, since they give away the x86 ones for free
<amitk> they're getting lots of money from each of the mobile vendors, so why make it easily downloadable?
<DanaG> Aah, that's the best explanation anyone's ever given me.
<DanaG> Oh, the generic ARM one wouldn't work on Android...
<DanaG> Perhaps once they make it for one of the Xorg-running embedded ones, it'll be hackable.
<amitk> perhaps Steve Jobs is right and we should all abandon Flash completely and concentrate on HTML5
<DanaG> Yeah, I'd agree with that.
<DanaG> Flash sucks everywhere.
<DanaG> Dropbox, though, remains as a target for ARM.  Perhaps we just need market prevalence with ARM netbooks.
<DanaG> That Toshiba one that's really new looks nice -- though could use an extended-battery option.
<DanaG> http://www.liliputing.com/2010/06/toshiba-ac100-10-inch-netbook-with-android-nvidia-tegra.html
<DanaG> It'd be awesome to be able to get all-day (as in 12-hour, not 8-hour) battery life.
<DanaG> http://www.liliputing.com/2010/06/lenovo-ideapad-u1-hybrid-skylight-arent-dead-yet.html
<DanaG> Would be awesome with Ubuntu.
<hrw> DanaG: my x86-64 laptop does 8-10h on one charge
<DanaG> yeah, that's what I mean... why bother going to ARM for just 8 hours battery life?
<DanaG> Something ARM should have way longer battery life to be worthwhile.
<DanaG> Well, they can be lighter, I'll grant that.... but some people would rather have slightly heavier for way longer battery.
<kai> I'd love to see a mixed arch system, not sure if that's really possible, but it'd be dandy
<DanaG> You'd have to have Universal Binaries (like what Apple did with PPC and x86 / x86_64).
<hrw> I want 1GB RAM, at least 16GB of storage, bt, wifi, 12-13" screen with 1280x800/1366x768, good keyboard and fast enough to run kde4 desktop
<DanaG> My killer-app any system I buy must be able to run: Compiz.
<hrw> kai: arm cpu + x86-64 one?
<kai> a low power chip for all the hard-core idling a usual desktop system is doing, and then a beefy multi-core that'll kick in when I start a copile or number-crunch job
<hrw> DanaG: I prefer kwin
<DanaG> Or that.
<hrw> kai: omap4 you mean?
<kai> I don't actually care about the arch
<DanaG> But the key is texture_from_pixmap support.
<DanaG> Even an old Radeon 7500 can do that.
 * ogra wonders about all the flash babbling ... there *is* and adobe flash for ARM, but you have to sign contracts with adobe to get it 
<kai> I just know that compiling samba on my beagle takes two hours, compiling it on my desktop takes two minutes
<hrw> ogra: I plan to check maemo flash on beagle running ubuntu
<ogra> yeah, thats the one
<kai> and I'd like to have the low power consumption of my beagle, _unless_ I actually need the power
<hrw> kai: stack few beagles?
<DanaG> Ah, they could just say that, on their page...
<DanaG> instead of pretending it doesn't exist, say "go to meego or android or whatever"... or such.
<ogra> well, if you are $big_company you likely know where to ask at adobe :)
<ogra> i dont think they want to make it available to the public in general
<DanaG> Damn.
<DanaG> If I were to get an ARM netbook, I'd want Ubuntu, quite specifically.
 * zyga wants to throw a few cents
<DanaG> grreat, and youtube.com also tells me "I need to upgrade my flash player!!!!1one!"
<zyga> I worked with one version of flash for arm several years ago
<zyga> they had this nice porting layer you'd have to write
<zyga> at least at that time flash didn't even care about X existing
<zyga> we could plug our own rendering code
<zyga> and a/v sink
<DanaG> ah, had to "leave html5 beta" and then "join html5 beta".
<zyga> and it would more less 'just work'
<ogra> DanaG, HTML5 FTW :)
<ogra> (ah, you found it already)
<DanaG> hmm, it's being dog-slow... but that may partly be due to me running it over ssh. =Ã¾
<DanaG> Browser is Chromium.
<DanaG> And even scrolling, with no videos, is dog-slow.
<DanaG> And even closing tabs is slow.
<ogra> you likely need hardware optimization in ffmpeg
<DanaG> WebM is also slow on my 64-bit host system, both with fglrx on Linux and with binary driver on Windows.
<DanaG> No hardware accel, for now.
<hrw> update-initramfs: Generating /boot/initrd.img-2.6.34-3-omap
<hrw> Cannot find mtd partition 'Kernel'
<hrw> root@beagle:~# cat /proc/mtd
<hrw> dev:    size   erasesize  name
<hrw> root@beagle:~#
<hrw> auch
<hrw> which module do I need to load?
<DanaG> I'm going to try firefox on ARM.
<hrw> ogra: who maintains xserver-xorg-video-omap3? it needs rebuild for newer xserver
<kai> hrw: I'd probably have to stack a lot of beagles.
<DanaG> Silly hack: http://hackaday.com/2009/02/22/x11-on-android/
<ogra> hrw, anyone who likes to touch it :)
<DanaG> They used VNC to localhost?
<DanaG> Why not just use fbdev?
<DanaG> =Ã¾
<ogra> hrw, given that i touched it last i'm probably in charge :P
<hrw> ogra: any hints for kernel update problem?
<DanaG> https://wiki.ubuntu.com/Specs/M/ARMGraphicsStackOnX
<DanaG> woot
 * DanaG wishes his uefi weren't broken.
<DanaG> Specifically, it claims GraphicsOutputProtocol support, but then claims the framebuffer address is zero.
<ogra> asac, for CHS i needed to add -D to the sfdisk call to enforce DOS compatibility, that solved all probs
<ogra> that apparentlxy leaves a slightly bigger gap at the beginning of the partition to add the bootloader binary
<asac> ogra: good.
<asac> have you tried on a tiny and big SD card?
<hrw> ogra: I said long time ago - check OE script...
<hrw> {
<hrw> echo ,9,0x0C,*
<hrw> echo ,,,-
<hrw> } | sfdisk -D -H 255 -S 63 -C $CYLINDERS $DRIVE
<ogra> hrw, doesnt help for that use case, but thanks
<ogra> this is about repartitioning on the fly with changed CHS values
<ogra> (we're using the OE script as a base for building the images, the repartitioning is a lot harder)
<hrw> ok
<ogra> for example the vfat is trashed afterwards and needs to be reformatted
<ogra> intrestingly that doesnt seem to affect any linux partitions, only vfat/fat
<asac> i still believe this is not all worth it ;)
<asac> write a great media creation script/app -> done ;)
<ogra> to late
<asac> i know
<ogra> its all done and in the infrastructure now
<asac> heh
<ogra> only flash-kernel changes are pending and a udev rule to hide the boot partition
<asac> ogra: is it possible to disable this resizing feature?
<ogra> then we should have preinstalled dailies
<asac> e.g. can i just use jasper to get the default configs?
<ogra> asac, if you have root=UUID=... on the cmdline it wont run
<asac> ogra: hmm
<asac> ogra: and the settings?
<ogra> the settings look for /root/etc/flash-kernel.conf
<asac> and oem config etc. thats done outside?
<ogra> if that does exist they'll skipp configuration
<ogra> oem-config is run after boot
<ogra> jasper is run during boot
<ogra> they are distinct but jasper depends on oem-config so it gets removed automatically after oem-config was run
<asac> what settings are done in jasper? what settings are done in oee-config?
<asac> is jasper just doing this resizing?
<ogra> nearly all settings are done in oem-config, jasper only enables oem-config and creates the initial fstab ... and to make sure X comes up it sets up loopback networking
<ogra> and i'm pondering to add the udev rule for hidint the vfat from jasper_setup
<ogra> jasper_growroot is doing the resizing in local-premount, jasper_setup is doing the setup from local-bottom
<asac> ogra: i assume jasper also finds the root partition like casper?
<asac> or did you hardcode that ;)?
<ogra> it only looks at root=
<ogra> asac, feel free to look at the code :) there is a MIR pending ;)
<asac> ogra: anyone from your team that could help out on MIRs ;)?
<ogra> currently its totally bound to the way we build the images
<ogra> i'm the only core dev in the team
<ogra> and i really cant MIR my own packages :)
<asac> its not about jasper, but about the huge backlog
<asac> ogra: wow. you used functions in your sh script ;)
<ogra> pfft
<asac> j/k
<ogra> i even plan to add a jasper_functions file to source common functions across the scripts :P
<ogra> i.e. i want the root device detection in both scripts ...
<ogra> though with the recent kernel changes i shouldnt even need a function for finding root= anymore
<ogra> (new kernels will just export cmdline entries completely to initramfs so they are in env vars)
<asac> ogra: did you also fix flash-kernel to flash if available and otherwise update first vfat partition?
<asac> (for OMAP)
<ogra> not yet, thats next on my list
<asac> ogra: that cmdline to env stuff was already there in lucid, wasnt it?
<ogra> it will check for UBOOT_PART
<asac> at least i remember that i could access them there
<ogra> no, it wasnt
<asac> but could be it was after initram
<asac> or was that in casper done manually?
<ogra> * [Config] enable passing all kernel command line to init
<ogra>     - LP: #586386
<ogra>  linux 2.6.35-5.6#
<ogra> casper works differently (though a lot of stuff could be dropped with the new kernel feature)
<ogra> it exports all that stuff var by var
<asac> right. so casper does that on its own. thats what i remember
<ogra> (which costs extra time)
<ogra> all the cmdline parsing can be dropped with the latest kernel
<ogra> which will also help hrw with the automatic serial console setup
<asac> ogra: so oem-config is running flash-kernel-installer?
<asac> or when is that done?
<ogra> upadet-initramfs is running flash-kernel --supported
<ogra> if that returns true it runs flash-kernel
<ogra> jasper has a trigger to rebuild the initramfs on deinstallation
<asac> ah ok and that is at end of removal
<asac> kk
<ogra> oem-config removes itself and tears jasper out
<ogra> since jasper has a hard dep on it
<asac> yeah got that
<ogra> flash-kernel-*installer* isnt used at all in this setup
<ogra> jasper_setup does that part
<ogra> (generating an initial boot.scr and creating flash-kernel.conf with the UBOOT_PART variable in it)
<ogra> flash-kernel will check if UBOOT_PART is set (it sources flash-kernel.conf by default if it exists) and will then write to NAND or to patition based on that value
<ogra> so that the old style is still supported for lucid installs
<asac> ogra: i am a bit unhappy with the logic about how uboot images are created and how the boot.scr etc. are done are spread around in the archive
<asac> assuming we will do uboot in future ... isnt there some potential to factor that out ?
<ogra> uboot images ? in jasper ?
<asac> ogra: well you create the boot.scr there ;)
<ogra> well, i could just replace root=UUID...
<asac> that logic is also in the image builders
<asac> yeah. why do you change the UUID?
<ogra> effectively i do the same flash-kernel-installer does
<ogra> because i want a plain ubuntu install
<ogra> ubuntu uses UUIDs
<asac> ogra: you could set the UUID in the .img, couldnt you?
<ogra> no
<asac> why not?
<ogra> then every install on the planet would have the same UUID
<asac> thats a problem? i dont think so ;)
<ogra> it is according to cjwatson
<ogra> he asked me to generate a unique one
<ogra> which is why i run tune2fs to create a new one and set that in the respective places
<ogra> the .img.bz2 doesnt use UUIDs at all
<ogra> it just uses root=/dev/mmcblk0p2 on the cmdline
<ogra> (which we need to change as soon as we support other setups than omap but thats not part of the current implementation)
<ogra> (though the code is ready to be changed if needed)
<ogra> (on cdimage.u.c)
<ogra> i need to create the boot.scr because i might have to use different load addresses for omap4 and because i want to detect the EDID at some point for setting the best resolution on the cmdline
<asac> ogra: so can we do somethning about the une-launcher spec
<ogra> asac, not sure yet, currently the user needs to select a different session in gdm
<asac> from what i can tell in linaor we could just screw this as we could produce "just" ubiquity ... and "just" efl images
<asac> ogra: is that good enough?
<ogra> not really
<asac> how about the jockey parts?
<ogra> i want autodetection
<ogra> i havent looked at jockey yet and until all preinstalled SD image parts are implemented i wont have time
<ogra> i dont like the idea of chaning ~/.dmrc though
<ogra> (/me is generally against fiddling with files in users homedirs)
<ogra> oh, i see you targeted lightweight panel for A2 in your spec
<ogra> that wont work :)
<ogra> we wont get anything from DX before A2
<ogra> (which is why lightweight panel is A3)
<GrueMaster> ogra: update on yesterday's image testing.  Seemed to work fine on my 16G class 4 card.  Some issues on my 8G class 4 card though.  It didn't actually resize, and instead dumped me down to busybox.
<ogra> ugh
<ogra> did you save the log ?
<GrueMaster> It had the root filesystem mounted under /root, which was odd, and instead of a jasper.log, I had /dev/.initramfs/jasper-tmp/ directory with no logs.
<ogra> /dev/.initramfs/jasper-tmp/ is fine
<ogra>  /root is the default dir where the rootfs gets mounted in initramfs
<ogra> the log should be saved on /root/var/log in this case
<GrueMaster> Ok, well it failed shortly after that.
<ogra> jasper_setup moves it now
<GrueMaster> I will retest today and look.
<ogra> great, thanks
<GrueMaster> I'm looking at my 8G SD card now (on the desktop) and not seeing a jasper.log.  Will run find.
<GrueMaster> nothing.
<ogra> weird
<GrueMaster> Found one on my 16G device, so it is at least attempting to copy.
<ogra> right, thats the default
<GrueMaster> As soon as I get setup again here at home, I'll retest some more (coffee first).
<ogra> yeah, no hurry
<ogra> all bits apart from flash-kernel are ready btw, the only thing we miss is the MIR for jasper
<hrw> flash-kernel...
<hrw> my bb is unable to update kernel
<ogra> hrw, why is that ?
<hrw> 10:34 < hrw> update-initramfs: Generating /boot/initrd.img-2.6.34-3-omap
<hrw> 10:34 < hrw> Cannot find mtd partition 'Kernel'
<hrw> 10:34 < hrw> root@beagle:~# cat /proc/mtd
<hrw> 10:34 < hrw> dev:    size   erasesize  name
<hrw> no mtd kernel modules loaded
<hrw> so flash not deteced
<ogra> not an ubuntu kernel
<ogra> :P
<hrw> it is one of maverick kernels
<ogra> its a leftover from lucid ... archive mess
<ogra> the omap3 kernel in maverick is a .35 one
<ogra> the metapackage was only fixed today to depend on the right kernel
<DanaG> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/594382
<ubot2> Launchpad bug 594382 in linux (Ubuntu Maverick) (and 1 other project) "Wake up daisy chain activation failed on omap3 (affects: 1) (heat: 8)" [Critical,Fix committed]
<amitk> ogra: does Touchbook work with Lucid now?
<ogra> amitk, nope
<amitk> ogra: kernel features missing?
<ogra> amitk, it kind of works with my hand rolled 2.6.32 kernel
<ogra> lots
<ogra> that "kind of" is, its not charging the battery
<amitk> ogra: ok, are there bugs for it?
<ogra> and there is no sound support, everything else with that kernel works
<ogra> only one
<ogra> amitk, and i really doubt we want to break the rest of omap3 for supporting touchbook
<ogra> Bug 581771
<ubot2> Launchpad bug 581771 in linux-ti-omap (Ubuntu) "omap3 dss2 touchbook patch missing in lucid kernel (affects: 1) (heat: 97)" [Undecided,New] https://launchpad.net/bugs/581771
<amitk> ogra: agreed, I'm checking with you to see if it would be feasible to support it in maverick
<ogra> there are a lot more patches missing, some of them are very intrusive and will likely break other omap3 HW
<amitk> but it looks like it will require non-mainlined patches to be applied
<ogra> right
<ogra> and even outdated ones
<ogra> i dont think anything has been ported to anything beyond .33 or .34
<amitk> ok, thanks
<ogra> amitk, if we could get the DSS2 patch in without breaking anything that would surely help a bit so people can debug etc without having to solder
<rsavoye> I thought the Touchbook was a repackaged Beagle board
<ogra> it roughly is
<amitk> ogra: hopefully mpoirier, cooloney or lag will get to that bug 581771
<ubot2> Launchpad bug 581771 in linux-ti-omap (Ubuntu) "omap3 dss2 touchbook patch missing in lucid kernel (affects: 1) (heat: 97)" [Undecided,New] https://launchpad.net/bugs/581771
<ogra> emphasis on roughly :)
<ogra> rsavoye, its a newly layed out SoC *based* on the beagle
<rsavoye> I was looking at one also... so it'd be nice if it worked :-)
<ogra> well, most of the important patches arent upstreamed
<rsavoye> are they in maverick though ? That's what I'd be running on it
<ogra> they arent
<ogra> maverick uses mainline 2.6.35 for omap3
<rsavoye> hum... bummer
<ogra> the touchbook patches are a) older and b) not mainlined
<ogra> the generic defconfig is in and the basic support but you wont i.e. have any display support
<ogra> (which means you need to solder an RS232 port for it since it doesnt have one)
<rsavoye> been there, done that... :-)
<rsavoye> but sounds useless for any development
<ogra> right, but thats not really the ubuntu philosopy :)
<ogra> it should just work :)
<ogra> if i find the time i'll provide hand-rolled images with a handmade custom kernel for maverick
<ogra> since i want to use it too ...
<rsavoye> I assume the Beagle board is the standard for ubuntu development then
<ogra> beagle or the upcoming panda
<rsavoye> ah, so if I did buy one, there'd be some support ? :-)
<rsavoye> I thought the Panda wasn't shipping yet
<prpplague> it isn't
<ogra> its not but ubuntu will run on it once it is :)
 * ogra will provide the first manually rolled panda images tomorrow btw 
<ogra> in case anyone is intrested, watch this space :)
<prpplague> ogra: dandy
<rsavoye> so even with your patches, there is no working display with the touchbook ?
<ogra> rsavoye, the kernel i rolled myself from the touchbook tgz for 2.6.32 has nearly everything working but battery charging ...
<ogra> and sound
<rsavoye> I can live without sound, but I think charging the battery is a good idea...
<ojn> just buy a new one
<ogra> rsavoye, http://dl.free.fr/getfile.pl?file=/0mYeCOWC is the download link for their tgz
<ogra> if you have the official angstrom image from their site you can charge under angstrom, then replace the SD and reboot to ubuntu, it actually survives 10h on one charge
<ogra> its just that you have to reboot and replace the SD every time to charge
<rsavoye> 10h ? nice!
<rsavoye> although swapping SD cards isn't too bad for the time being
<ogra> well, the SD is inside the case :)
<rsavoye> oh, ouch...
<ogra> you have to rip it apart every time
<ogra> its not to hard to take apart (no screws or anything) but its annoying
<rsavoye> sounds like it'd be good to keep it plugged in :-)
<ogra> well, doesnt help
<rsavoye> it doesn't run on AC ?
<ogra> it always pulls power through the battery
<ogra> at least it seem like, it might work on AC if the driver for the power regulating chip works
<ogra> if you use their shipped image it should be fine though, but you are stuck at 2.6.29 with that and they have a very very weird image setup (everything is a squashfs/aufs, no idea why)
<DanaG> Too bad the standard beagleboard didn't have the connectors in place already, for batteries.
<rsavoye> ogra: so it runs 10,04 but with an older kernel ?
<ogra> no
<ogra> unless you build your own kernel it will miss features
<rsavoye> ah...
<ogra> their image is based on 9.10
<ogra> i didnt manage to boot 10.04 with their kernel, upstart needs some features that entered after .29
<ogra> i wish they would properly upstream their patches, then it wouldnt be any prob
<ogra> anyway, out for today ...
 * ogra has to do his national duty and watch a soccer game on tv tonight ... and i'm out of beer !
<prpplague> ogra: out of beer? what kind of human are you? that is just plain disgusting
<GrueMaster> ogra: I'll fie a bug and assign you ownership.
<GrueMaster> s/fie/file
<DanaG> say, anyone know when there'll be pics of this "Panda"?
<DanaG> Or at least a list of specs?
<asac> ogra: did you ever get your alwaysinnovation touchsmartbook thing enabled?
<ogra_cmpc> asac, see backlog :P
<ogra_cmpc> asac, we talked about it for 1h
<ogra_cmpc> prpplague, fixed :)
<GrueMaster> ogra_cmpc: any idea on how to debug this issue I am seeing?  I have the 8G SD booting, jasper appears to work fine (found the log), but the system stops after mounting mmc0p2 on /root.
<prpplague> ogra_cmpc: what is fixed?
<ogra_cmpc> prpplague, the out of beer issue
<prpplague> DanaG: http://fc01.deviantart.net/fs31/f/2008/201/1/5/Panda_Board_by_elanamullaly.jpg
<prpplague> ogra_cmpc: ahh
<ogra_cmpc> GrueMaster, not really, so it resizes properly and also creates fstab etc ?
<GrueMaster> Yes
<ogra_cmpc> hmm
<ogra_cmpc> it should just move on, is it possible thats the MMC issue from before ?
<ogra_cmpc> (note that my images still use the .34 kernel)
<GrueMaster> No, the mmc issue would appear in dmesg, and the filesystem would be corrupt.
<GrueMaster> I'm aware of that.
<ogra_cmpc> no idea from the top of my head
<GrueMaster> Lian is building me a new .35 kernel with the daisy chain fix.
<ogra_cmpc> if /root is mounted and fstab is created in /root/etc/ there is no reason it should stop
<ogra_cmpc> yeah, i know
<GrueMaster> It doesn't happen on my 16G SD card.  Both are Kingston, class 4 SDHC cards.
<ogra_cmpc> that kernel isnt there yet though, i'll switch the image once its available
<ogra_cmpc> i only have kingston microSD 4G ones, i'll test with one tomorrowq
<GrueMaster> No, i meant lian is building me a test kernel now.  It will be uploaded to the pool on Friday.
<ogra_cmpc> ah
<GrueMaster> I'll continue smacking it around here.  Have to regenerate the boot.scr & add serial console output and some other modifications.
<ogra_cmpc> heh, prpplague thats a cute panda
<ogra_cmpc> GrueMaster, then oem-config will break
<prpplague> ogra_cmpc: actually i have no clue the site is blocked from inside TI, i think avr500 posted that
<GrueMaster> It has worked fine when I add console=ttyS2,115200 console=tty1
<ogra_cmpc> GrueMaster, input doesnt work iirc
<prpplague> DanaG: seriously though. i don't think are going to release specs and pics for a few more months
<GrueMaster> it does when you list a local console as well.
<ogra_cmpc> oh, i thought you wanted to run it completely on serial
<GrueMaster> besides, I am not even getting that far yet.  It dumps me at a busybox shell.
<ogra_cmpc> drop quiet from the cmdline
<ogra_cmpc> hmm, did i even set that ?
<GrueMaster> No it isn't set.
<ogra_cmpc> right
<ogra_cmpc> and it spills no error to the console ?
<ogra_cmpc> i think you can set some debug value on the cmdline that will spit out more info from the initramfs scripts
<GrueMaster> No errors (yet).
<GrueMaster> brb
<ogra_cmpc> i'll also add more logging to jasper_setup, currently the second script doesnt log at all
 * ogra_cmpc will do that tomorrow first thing
<GrueMaster> second script?
<ogra_cmpc> jasper_serup
<ogra_cmpc> *setup
<ogra_cmpc> first script is jasper_growroot living in scripts/local-premount
<ogra_cmpc> second script is jasper_setup living in scripts/local-bottom
<GrueMaster> found it.  I'll tear it apart and see if it is havng issues.
<ogra_cmpc> would be weird if it had and wouldnt have on the other SD
<ogra_cmpc> i could understand if the first script had issues because of different cards but the second one that only moves data around and creates files
<GrueMaster> I'm wondering if the remount line is actually working.
<ogra_cmpc> it works here
<GrueMaster> no, that isn't it.
<ogra_cmpc> (and apparently on your other card)
<GrueMaster> Thinking out loud.
<ogra_cmpc> yeah, good thing
<ogra_cmpc> but if the remount wouldnt work you would still boot
<ogra_cmpc> the stuff done by the second script isnt essential for moving on
<ogra_cmpc> only for rebooting (boot.scr) but it should still move without fstab and /etc/network/interfaces
<asac> ogra_cmpc: cheers (/me goes for lagavulin for the game ;))
<ogra_cmpc> heh
<GrueMaster> very odd.  Rebooting now brings up oem-config.  Something is not going through in the first boot.  Will continue investigating.  Enjoy the game & beer.
<ogra_cmpc> will do (starts in 15)
<ogra_cmpc> US and england already made it today
<armin76> asac: vuvuzela!
<DanaG> latest xkcd is fun.
<GrueMaster> mpoirier: ping
<mpoirier> yes.
<mpoirier> GrueMaster: ping
<GrueMaster> have you tested the kernel after making the daidy chain fix?
<mpoirier> the temporary fix, yes.
<GrueMaster> Did you get video out?
<mpoirier> ha....
<mpoirier> that is another issue.
<GrueMaster> I'm getting the following errors on boot:[    2.054840] omapfb omapfb: no displays
<GrueMaster> [    2.058654] omapfb omapfb: failed to setup omapfb
<GrueMaster> [    2.063476] omapfb: probe of omapfb failed with error -22
<mpoirier> plymouth core dumps...
<mpoirier> yes indeed.
<GrueMaster> No, they should be unrelated.  I get those on .34 as well.
<mpoirier> not related to daisy chain - was there since I joined the company.
<GrueMaster> Understood.
<mpoirier> yes, indeed.
#ubuntu-arm 2010-06-24
<robclark> GrueMaster: not sure which kernel you are on.. but one obvious thing to sanity check... some recent defconfig from kernel-omap4.git had VRAM defaulting to zero.. so if you didn't give some bootargs you wouldn't get any framebuffers
<robclark> you could try something along lines of: vram=8M omapfb.vram=0:8M
<robclark> (for example)
<GrueMaster> robclark: I'm using the same bootargs as I was for 2.6.34.  vram=12M omapfb.mode=dvi:1280x720MR-16@60.  And this is on the beagleboard (omap3).
<robclark> ahh.. ok.. that should be not the issue then
<GrueMaster> This is kernel 2.6.35-6.  It is scheduled to hit the pools on Friday.
<robclark> do you even get the penguin at bootup?   Or nothing at all on dvi?
<GrueMaster> Nothing on dvi.  See my error post a few lines back.
<GrueMaster> rebooting to 2.6.34 kernel is fine.
<robclark> hmm, is kernel config not enabling any DSS devices?
<robclark> I think it does not go thru this loop at all:  for_each_dss_dev(dssdev) { ... }
<robclark> make menuconfig, and then Drivers -> Graphics -> OMAP2/3/4... -> and then hopefully there is some DVI option
<GrueMaster> Not sure.  Let me check the output against 2.6.34
<GrueMaster> Maybe it has something to do with "# CONFIG_OMAP2_DSS_RFBI is not set"?  I haven't tweaked the kernel in several years (since 2.4.xx times).
<GrueMaster> But I did see that in the config.
<GrueMaster> nevermind.  same in 2.6.34
<GrueMaster> Interesting.  I'm reviewing my bootlogs from earlier 2.6.35 test kernels, and I am seeing the same error in 2.6.35-RC1 raw kernel (no ubuntuisms).
<GrueMaster> ogra_cmpc: What's the score?
<Martyn> My bamboo board was DOA
<Martyn> -sigh-
<GrueMaster> which one is that?
<ojn> AMCC 440EP eval board?
<NCommander> damn it, just missed Martyn
<Belvadi> any softkey pad application available for arm...
<ogra> NCommander, so your gobject-introspection "fix" ...
<NCommander> ogra: yes?
<ogra> NCommander, did you check the dependencies and what changed in them between 0.6.12-1 and 0.6.12-1ubuntu1 ?
<NCommander> ogra: dyfet did.
<ogra> since this is not a gobject-introspecion issue but an issue with any build dep
<ogra> i'd rather see us fixing the real issue than changing the code that didnt change before the breakage
<ogra> looking at the deps i'd suspect glib
<ogra> bison, flex and friends didnt change between the two uploads
<NCommander> ogra: we need gobject-introspection fixed, you've already said that, I'm glad to hunt for the actual cause of the breakage, but I'm happy to work around it
<NCommander> ogra: dyfet said he checked it
<ogra> i'm not sure it wont break it on all other arches
<NCommander> ogra: I threw it in a PPA, built on everything
<ogra> you are changing XML that hadnt changed
<NCommander> (devirtualized PPA)
<NCommander> I only changed the XML to reflect the changed vairable names in the C code
<ogra> yes, but does that change work on all other arches ?
 * ogra wouldnt even know how to verify that
<NCommander> ogra: I ran the test suite on all arches
<ogra> in any case something in a dep changed, just hacking variable definitions in the gobject code doesnt seem like an appropriate fix
<ogra> i'm not talking about the test suite
<ogra> but about the binaries using the code
<ogra> telepathy for example
<NCommander> ogra: I didn't change any code expect code used in the test suite
<ogra> was seb128 pulled into the discussion by dyfet as i asked ?
<NCommander> ogra: I didn't see any communication from dyfet to seb128. I was waiting for him to show up to pin ghim on desktop
<ogra> hmm, i asked dyfet a week ago at the meeting to discuss it with seb :/
<ogra> (and agin this week)
<hrw> morning
<Belvadi> dialpad application in ubuntu avaliable..
<ogra> NCommander, do you remember the former name of the "source" commnad in old u-boot ?
<ogra> seems enabling hush shell didnt get me source
<NCommander> ogra: TI's u-boot might predate that command being added
<ogra> its 1.1.4
<NCommander> Marvell was 1.3.4
<ogra> gah
<ogra> thats really bad
<NCommander> your trying to execute the boot.scr, right?
<ogra> yep
<NCommander> do imi *offset* where you loaded it
<NCommander> see if panda's u-boot recongizes it as a boot script
<ogra> PANDA # imi 0x80300000
<ogra> ## Checking Image at 80300000 ...
<ogra>    Image Name:   Ubuntu boot script
<ogra>    Image Type:   ARM Linux Script (uncompressed)
<ogra>    Data Size:    163 Bytes =  0.2 kB
<ogra>    Load Address: 00000000
<ogra>    Entry Point:  00000000
<ogra>    Verifying Checksum ... OK
<NCommander> hrm
<ogra> PANDA #
<ogra> yep
<NCommander> possible autoscr
<NCommander> that might have been the old command for source
<NCommander> (it shouldbe in help)_
<ogra> nope
<ogra> its not
<ogra> (in help)
<ogra> i see test and other hush commands
<NCommander> crap
<NCommander> its possible that its just not implemented
<NCommander> Which means we're screwed
<NCommander> (partially)
<ogra> i see "go" but that hangs x-loader if i run it
<NCommander> it wouldn't be super-difficult to backport a the necessary commands
<NCommander> go is used for jumping to an offset
<ogra> yeah
<NCommander> autoscr is there on blaze?
 * NCommander hasn't checked
<NCommander> (or source)
<ogra> hmm, gumstix uses 1.1.4 and has autoscr
<NCommander> sounds like something went horribly wrong
 * NCommander grabs the source
<ogra> aha ... i see (~CFG_CMD_AUTOSCRIPT...
<ogra> PANDA # help
<ogra> ?       - alias for 'help'
<ogra> autoscr - run script from memory
<ogra> I WIN !!!
<mpoirier> GrueMaster ?
<GrueMaster> mpoirier: pong.  Still waking up, though.
<mpoirier> GrueMaster: good morning.
<mpoirier> your beagle board, it is a C4 ?
<mpoirier> I assume so.
<GrueMaster> Yes.  Store bought, as it were.
<mpoirier> did you upgrade your MLO and u-boot ?
<mpoirier> or are they stock ?
<GrueMaster> I believe I am running what is on ogra's image.
<mpoirier> do me a favor please.
<mpoirier> boot the board (power cycle) and give me the date you get on the very first line that come up on the screen.
<mpoirier> mine is:
<mpoirier> Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
<GrueMaster> same
<GrueMaster> That's the xloader
<mpoirier> yes, indeed.
<GrueMaster>   
<mpoirier> please confirm that you have used the USB EHCI on this board.
<GrueMaster> Huh?
<mpoirier> the normal looking USB port, next to the SD card slot.
<GrueMaster> of course.  That's how I have keyboard, mouse, ethernet, etc.
<mpoirier> davidm set me a C4 two weeks ago and USB did not work off the box.
<mpoirier> Ok I'm thinking, hw failure happens...
<GrueMaster> I'm fully hooked up here.  Only thing not in use is the otg port.
<GrueMaster> and svideo.
<mpoirier> Yes, don't use OTG.
<mpoirier> so I purchase one from Sparkfun and got it yesterday...
<mpoirier> it too has a problem with USB.
<GrueMaster> I'm aware of that.
<mpoirier> that is interesting - aware of what ?
<mpoirier> USB problems with bb  ?
<GrueMaster> Bug #566645
<ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 2) (heat: 64)" [High,Confirmed] https://launchpad.net/bugs/566645
<mpoirier> indeed, OTG is not in yet.
<mpoirier> But both my C4 boards, USB EHCI is not responsive.
<mpoirier> I was wondering if you were seeing the same thing...
<GrueMaster> Are you running with a powered hub?
<davidm> mpoirier, two boards with fail sound funny, perhaps your USB hub is not working with the hardware?
<mpoirier> It does work when hooked up to the C2 board...
<GrueMaster> Where are you powering your board from?
<mpoirier> power supply, not OTG.
<GrueMaster> ok.
<mpoirier> I'm wondering if u-boot isn't doing something special to enable the port.
<mpoirier> Something I wouldn't have.
<mpoirier> two failure on two boards, this isn't right.
<GrueMaster> I have my system booting the uboot from nand when I am running lucid.  It is the stock uboot.  When I am running maverick, it runs a newer version.  Both work fine with USB.
<mpoirier> The maverick uboot, it is on SD card ?
<GrueMaster> yes.
<mpoirier> Please email it to me...
<rsavoye> is there another channel for non ARM ubuntu netbook issues ?
<GrueMaster> Actually, just pull down ogra's test image.  http://projects.gnome.org/NetworkManager/developers/
<GrueMaster> rsavoye: #ubuntu-mobile
<rsavoye> thanks
<GrueMaster> or #ubuntu-desktop may help
<rsavoye> I was trying to get a USB install to a Sylvania G netbook to work, it can't find vesa
<ogra> GrueMaster, #ubuntu-mobile is dead
<ogra> netbook issues go to #ubuntu-desktop or for the efl version to us
<rsavoye> it may be dead, but there is a pile of people
<ogra> yes, we're in the process of either closing it or finding a new adopter
<ogra> the ubuntu mobile team doesnt exist anymore
<rsavoye> ah... that;s right
<GrueMaster> mpoirier: if you have any kernel testing that needs to be done, just ping me and I can test in my environment.  I would like to test fixes to some of these critical  bugs as soon as they are available, instead of waiting for the next kernel bump.
<mpoirier> very well.
<GrueMaster> BTW, the daisy chain fix works well, thanks & kudos.
<amitk> was it just removing CPU_IDLE from the Kconfig?
<mpoirier> this is just a big hack and shouldn't be considered to be the real thing.
<mpoirier> removing CPU_IDLE just avoids touching the flaky code.
<GrueMaster> Sometimes it is things like this that need to be done to keep the rest of the teams moving forward while a real fix is pursued.
<mpoirier> I have no problem with doing that either..,,.
<GrueMaster> It enables people like me to find and report new and annoying bugs.  :P
<mpoirier> but the real fix is still eluding me.
<mpoirier> and all this time that I'm not fixing other problems...
<ogra> mpoirier, ask koen in #beagle, probably he knows about it and has a patch
<ogra> he is a great source of information if it comes to kernel issues with omap :)
<mpoirier> ogra: you seems to know something I don't...
<ogra> lag, what was your trick to make HDMI or DVI work on omap4 ?
<amitk> push it in harder?
 * ogra remembers you talked about that a while ago
<lag> It doesn't
<ogra> It doesn't ?
<lag> It doesn't work
<lag> FBAR
<ogra> neither of the ports ?
<lag> Neither
<lag> DVI isn't meant to work
<ogra> robclark, didnt you say there was a trick to make HDMI/DVI work on the panda ?
<lag> HDMI just doesn't
<lag> There was a hack to make it work with HDMI/DVI converter
<lag> But I haven't tried that, as I don't have the cable
<prpplague> lag: you hdmi isn't working?
<lag> Correct
<prpplague> lag: which kernel release are you using?
<prpplague> lag: L24.7 ?
<armin76> real men use serial
<prpplague> armin76: hehe indeed
<armin76> prpplague: gimme omap4!
<ogra> prpplague, we're all using the ubuntu kernel
<lag> Serial works like a peach
<ogra> prpplague, which should be based on something newer than L24.7 afaik
<ogra> lag, serial doesnt help with images :)
<robclark> ogra: I'm not sure if DVI is up yet.. HDMI works well (at least on the monitor that I have)
<robclark> for L24.7 kernel, you need some bootargs so you have more than 0MB for framebuffer..
<prpplague> the HDMI inteface can be used with a DVI monitor with no problems
<robclark> yup
 * armin76 tests :D
<robclark> fyi: vram=8M omapfb.vram=0:8M
<ogra> thats all ? no resolution ?
<prpplague> lag: most likely you need to allocate some mem for the framebuffer per robclark 's suggestion
 * ogra tries
<prpplague> ogra: for hdmi it will autodetect the best resolution
<ogra> sweet !
<prpplague> ogra: for dvi you will need to specify the mode and resolution
<ogra> yeah
<lag> Sounds good
<ogra> my monitor has both
<prpplague> lag: if you are using the hdmi but with a dvi monitor your will need to specific some additional bootargs
<lag> I'm not
<lag> I'm using real HDMI
<lag> Once my kernel is up again, I'll try those extra args
<lag> :)
<prpplague> lag: ahh ok
<lag> Could that be the source of the "SYNC_LOST_DIGIT" messages I receive?
<lag> They swap my system rendering it unusable
<lag> but 592295
<lag> Doh!
<lag> bug 592295
<ubot2> Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/592295
<ogra> omapfb omapfb: failed to allocate framebuffer
<ogra> omapfb omapfb: failed to allocate fbmem
<ogra> omapfb omapfb: failed to setup omapfb
<ogra> omapfb: probe of omapfb failed with error -12
<ogra> hmm
<robclark> ogra: someone was seeing that yesterday
<robclark> Can you post your .config?
<ogra> and i see the SYNC_LOST_DIGIT message too at the end of the boot
<prpplague> robclark: i was about to ask the same
<lag> ogra: One is fine
<lag> It's expected
<lag> 10,000 is not
<robclark> From looking at code, I think that error comes if the kernel is somehow built w/o any DSS drivers enabled..
<ogra> robclark, http://pastebin.com/HeBHjaAS
<robclark> ogra:  hmm.. that looks somewhat ok..  CONFIG_OMAP2_DSS_HDMI=y
<robclark> hmm
<ogra> the monitor is definately initialized but i dont see any output
<prpplague> ogra: do cat /dev/urandom > /dev/fb0
<ogra> i have no shell atm
<prpplague> ogra: oh
<robclark> actually, ogra, I think your error is different from one yesterday.
<prpplague> ogra: why not?
<lag> ogra: How many messages do you get?
<robclark> try change CONFIG_OMAP2_VRAM_SIZE=4 to CONFIG_OMAP2_VRAM_SIZE=8
<ogra> lag, only one
<lag> That's fine then
<lag> No problem
<robclark> 4mb is not sufficient for 1920x1080x4byte/pixel
<ogra> prpplague, because i dont have a rootfs atm :)
<prpplague> oh
<lag> 		/* When we enable digit output, we'll get an extra digit
<lag> 		 * sync lost interrupt, that we need to ignore */
<ogra> robclark, so it reads the EDID of my monitor and automatically takes the highest res. it finds ?
<prpplague> ogra: so how are suppose to know if the hdmi is working?
<prpplague> ogra: correct
<ogra> prpplague, kernel messages on tty0
<lag> first frame  as it takes long time to decode but it later recovers*/
 * lag tries again
<lag> first frame  as it takes long time to decode but it later recovers*/
<lag> Grr
<prpplague> ogra: you are trying to run the hdmi as the console?
<robclark> ogra..  yeah..  but it should reduce the framebuffer size if it doesn't have enough mem..
<lag> first frame  as it takes long time to decode but it later recovers*/
<ogra> prpplague, indeed
<prpplague> ahh
<robclark> so you should see some resolution like 1920x540
<lag> first frame  as it takes long time to decode but it later recovers*/
<robclark> but maybe after some limit it gives up at trying to resize the framebuffer
<lag> /*commenting below code as with 1080P Decode we see a sync lost digit for
<lag> first frame  as it takes long time to decode but it later recovers*/
<lag> Got it
<lag> Stupid leading /
<ogra> robclark, hmm, my monitor might not do such odd resolutions in HDMI mode
<robclark> hmm, ok.. that could be the issue I suppose
<prpplague> ogra: can you pastebin your bootlog?
<ogra> if i boot with serial console i can grab it, yes
<ogra> one sedc
<ogra> *sec
<ogra> http://paste.ubuntu.com/454514/
 * prpplague looks
<prpplague> ogra: edit your .config file, turn off DSI and set the number of framebuffers to 1
<prpplague> ogra: also turn on the omap2 fb debug support
<ogra> well, i wont compile any kernels now :)
 * ogra is busy working on images, but i'll file a bug for the kernel team to fix it
<prpplague> ogra: oh
<prpplague> ogra: is the kernel source for what you are using available somewhere?
<ogra> i usually dont touch kernels if i can avoid :)
<prpplague> ogra: ahh
<ogra> https://edge.launchpad.net/ubuntu/maverick/+source/linux-ti-omap4/2.6.34-900.1
 * prpplague looks
<ogra> cooloney maintains it, lag gives him a hand
 * prpplague downloads and builds
 * prpplague needs a brake from the mailing list flame wars
<ogra> heh
<prpplague> jkridner1: morning
<prpplague> ogra: i'll have a look at the build and test
<ogra> thanks
<hrw> hi prpplague
<prpplague> hrw: greetings
<hrw> ogra: why mem=463M?
<ogra> hrw, thats in the u-boot defaults, i just kept them
<prpplague> hrw: the blaze/sdp team were using that value, i never did get an answer for why
<ojn> prpplague: i thought it was for legacy reasons, to set memory aside for dspbridge crap?
<ojn> I ran our machines just fine without mem= on the bootargs
<prpplague> ojn: ahh, that might be true
<hrw> prpplague: maybe they had problem with second 512M?
<prpplague> hrw: the blaze/sdp doesn't have a second 512M
<hrw> thats why
<ojn> no
<ojn> u-boot passes the amount of memory in the proper atags, no need for bootargs.
<ogra> well, its in the panda u-boot defaults
<ojn> we had 1GB working too (well, 768MB, highmem support was busted back when I tried it last).
<ojn> ogra: Should be bug reported, probably.
<ogra> but i'll remove it in the ubuntu package if its not needed
<ogra> well, in ubuntu we use boot.scr everywhere to set bootargs so i dont really care
<prpplague> ojn: on which platform?
<ojn> prpplague: custom boards
<ojn> (4430-based)
<robclark> prpplague and all:  463M is the value for 512M boards..  some memory needs to be reserved for coprocessors
<robclark> in future, syslink will reserve this at boot time using normal kernel memory allocation APIs..
<robclark> but that isn't implemented yet
<prpplague> robclark: ahh dandy
<robclark> btw, is there already u-boot/x-load patches for 1gb panda?
<mpoirier> GrueMaster: where do I get ogra's test image ? The one you are testing with.
<ogra> mpoirier, people.canonical.com/~ogra/jasper/
<ogra> mpoirier, note that updating the kernel doesnt work automatically yet
<ogra> and that it uses .34 still
<hrw> ah.. toys
<mpoirier> i'm only interested in the u-boot.
<prpplague> robclark: no not yet
<mpoirier> will I find it in there ?
<GrueMaster> Oops.  Sorry about that.  wrong link in the copy buffer for some reason.
<prpplague> ogra: kernel building now
<GrueMaster> Use ogra's link.  There are only two files there.
<ogra> mpoirier, uboot is in the image
<mpoirier> ogra: ok thanks.
<GrueMaster> mpoirier: You can mount the boot partition with sudo mount cmdline-maverick-armel+omap3.img mnt/ -o loop,offset=$((32256))
<GrueMaster> Saves time from having to write the image to SD.
<mpoirier> I would have just mounted the image.
<hrw|gone> have a nice rest of day
<ogra> mpoirier, oh, i mis-read above, you want u-boot ?
<mpoirier> I just need uboot.
<ogra> https://edge.launchpad.net/ubuntu/+source/u-boot-omap3/2010.3git20100531-0ubuntu1/+build/1767190
<ogra> just dpkg -x the .deb
<mpoirier> ogra; thanks.
<mpoirier> ogra:  the cmdline-maverick-armel+omap3.img image, what format is it ?
<GrueMaster> It is a SD image.  2 partitions.
<ogra> its a two partition img to dd to the SD card
<mpoirier> yes, but if I want to mount it live on my file system...
<mpoirier> a simple mount -o loop fails.
<mpoirier> using "file" on the image yields:  x86 boot sector; partition 1: ID=0xc, active, starthead 1, startsector 63, 144522 sectors; partition 2: ID=0x83, starthead 0, startsector 144585, 867510 sectors, code offset 0x0
<mpoirier> haven't seen that before.
<GrueMaster> Then you need to find the starting byte of each partition (parted will give you this) and mount with -o loop,offset=<start byte>.
<prpplague> ogra: definetly some weirdness going on with that kernel soruce
<mpoirier> ogra: ok.
<ogra> prpplague, well, its an ubuntu kernel with the TI patches on top
 * prpplague digging into it
<ogra> prpplague, afaik sebjan maintains it on the TI side
<GrueMaster> mpoirier: I'll send you a link on how to do this.
<GrueMaster> http://wiki.edseek.com/guide:mount_loopback
<mpoirier> GrueMaster: I just got it with the offset command you sent me above.
<mpoirier> I get it now.
<prpplague> ogra: interesting, straight out of the box with the defconfig, the kernel fails to compile
<ogra> indeed
<ogra> you need to build it like a debian package
<ogra> it runs various scripts to assemble the different config snippets
<jkridner1> hi prpplague.  I should free up here shortly and can swing by if you let me know where you are at.  still don't have the LCD. :(
<prpplague> huh? you don't use the defconfigs?
<ogra> prpplague, no
<prpplague> jkridner1: E-2126 , just down from geralds office
<prpplague> hmm
<ogra> prpplague, there is an ubuntu (non arch specific) config and there is an arch specific one
<ogra> must be somewere in the debian dir, i guess soemone from the kernel team can explain it better than me
<ogra> to build it you definately need to run "fakeroot debian/rules <whatever target you want to build>"
<prpplague> ogra: i'll dig around and see what i can find
<ogra> debian/rules is the makefile
<prpplague> ogra: guess we need to know how to test the ubuntu kernels
<ogra> prpplague, we'll soon have daily images
<ogra> so you can just install the image and regulary upgrade the kernel
<prpplague> ogra: well i don't like not knowing, i just assumed ubuntu built the kernel just like the rest of the world, hehe
<prpplague> ogra: i mainly do kernel dev
<ogra> it builds it slightly similar to debian
<prpplague> ogra: so i need to be able to hack
<ogra> well, the kernel team maintains it in a git tree like any other kernel dev does :)
<ogra> just the build process is different since its wrapped in packaging stuff
<prpplague> i'm sure there is a doc somewhere that describes the process
<ogra> right
<ogra> prpplague, https://help.ubuntu.com/community/Kernel/Compile i think
 * prpplague looks
<ogra> "Build the kernel (when source is from git repository, or from apt-get source)"
<ogra> thats the section you want
<prpplague> yea, reading over that now
<ogra> you need beefy hardware though (we do not cross compile)
<prpplague> yea looks there are some "multi-boot" issues
<prpplague> testing
<prpplague> ok, here is the bit
<prpplague> ogra: they have the DPI picodlp enabled in the config
<ogra> ouch
<ogra> probably a blaze leftover
<ogra> lag, ^^^
<prpplague> ogra: so if you have that enabled along with the HDMI, you need to change the number of framebuffers to 2 instead of 1, and in addition you need to allocate enough memory for both, 16 is probably enough, but a safe value is 32
<ogra> lag, can you take care that cooloney gets that info ?
<mpoirier> GrueMaster: moving to ogra's u-boot fixed my USB EHCI issue - thanks.
<ogra> great :)
 * prpplague retests with the common config
<davidm> mpoirier, both boards are working now?
<GrueMaster> interesting.
<GrueMaster> Must be a u-boot<>kernel combination issue.  I haven't tried the new kernels on the old system.
<mpoirier> davidm
<prpplague> good lord that common image is giant
<mpoirier> davidm: both boards are working now.
<prpplague> ogra: yea looks like the same issue with the common config, they have 3 different dss drivers enabled, DSI, DPI and HDMI, but only have 2 framebuffers allocated
<prpplague> ogra: easiest is to just use 32MB for the framebuffers, that should work fine
<sebjan> prpplague: we want to have a single kernel image/defconfig for both blaze and panda, so we need to have picodlp activated, right? Are there changes to apply to the config according to you?
<prpplague> sebjan: assuming i am using the right config per the instructions, the vram needs to be increased to a min of 16, preferable to 32
<ogra_cmpc> well, we have enough ram, 32 should be doable
<sebjan> ... and in case we want to use the serial only ;), we can force a lower value in command line then, right?
<ogra_cmpc> no idea if there is a cmdline override :)
<prpplague> sebjan: correct
<ogra_cmpc> does the vram value override the kernel default ?
<prpplague> ogra_cmpc: on the command line it does
<prpplague> sebjan: i emailed you the config i am using
<ogra_cmpc> ah, great, so you only need to change boot.scr
<sebjan> prpplague: great thanks, I'll take this change
<prpplague> sebjan: np
#ubuntu-arm 2010-06-25
 * mozzwald is away: sleepytime
<hrw> morning
<ogra> oh, sweet i finally got screen output on the panda
<hrw> ogra: changed kernel or monitor?
<ogra> cmdline options :)
<ogra> adding the omapfb.vram option breaks it ... just setting vram to a high enough value gets me a screen
<hrw> ;)
<ogra> though the colors are wrong
<hrw> rgb mixed?
<ogra> no idea, the console font is blueish
 * ogra is curious why the buildlive call he just did on the image build server didnt explode yet
<ogra> since jasper is still in universe i would expect it to break
<ogra> but its running since 30min
<ogra> ndec, http://people.canonical.com/~ogra/jasper/cmdline-maverick-armel+omap3.img.bz2
<ogra> ndec, http://people.canonical.com/~ogra/jasper/
<davidm> persia, I'll need your help on the EULA stuff
<rsavoye> dumb question, does anyone know if the Beagle Board LCD2 touchscreen mounts firmly in the Acrylic case and works with Maverick ?
 * GrueMaster is not sure that the acrylic case has been maverick tested yet.
<GrueMaster> :P
<rsavoye> when I saw the words "expansion slot" I thought I'd make sure the LCD would work :-)
<rsavoye> btw, Lucid -netbook almost installed on a Sylvania G...
<ogra> cool
<rsavoye> the mouse didn't work, and the fonts were unreadable though. :-)
<hrw> ubuntu on beagleboard gives me fell of i486sx
<ogra> heh
<hrw> but some time passed since I used it with other distros
<ogra> hrw, improvements accepted ;)
<hrw> hrw@home:~/.apt-cross$ sudo apt-cross -a armel -S maverick -m http://ports.ubuntu.com/ubuntu-ports/ -i libc6-dev libgmp3-dev libmpfr-dev
<hrw> ops
<hrw> apt-cacher-ng helps
<davidm> mpoirier, please see bug #597904 it is a blocker for A2, so it must be fixed ASAP please
<ubot2> Launchpad bug 597904 in linux (Ubuntu Maverick) (and 1 other project) "No video on beagleboard with 2.6.35 kernels. (affects: 1) (heat: 10)" [Critical,New] https://launchpad.net/bugs/597904
<mpoirier> davidm: is thought deadline for alpha2 was today.
<davidm> So needs to be rush fixed ASAP
<mpoirier> davidm: can it be pushed to alpha3 ?
<davidm> No we miss all Alpha 2 if we don't have this
<davidm> Must have
<mpoirier> i will look at it but if it is like the SD card of the daisy chain, it won't happen.
<ogra> if some SD cards dont work it is fine, not booting isnt
<davidm> ogra, GrueMaster is there already a fix in the TI kernel for this?
<ogra> the whole system setup on first boot happens on screen
<ogra> davidm, i have no clue about the omap3 kernels especially not about whats in mainline and whats not
<davidm> ogra, OK
<ogra> we build from mainline now, before i could have looked in some ti tree
<ogra> but with maverick we use linus tree for omap3
<GrueMaster> davidm: I verified yesterday that the mmc issue still exists on the kernel Leann handrolled for me.
<GrueMaster> I only see it on class 2 SD cards though.
<ogra> which makes it non critical for now
<GrueMaster> right.
<slangasek> mpoirier: the milestone freeze for alpha milestones generally doesn't happen until Monday or Tuesday of the alpha, and in any event blocker bugs aren't bound by the freeze per se
<slangasek> mpoirier: though if the fix lands any later than Monday, the team will have a hard time getting images together in time for Thursday
#ubuntu-arm 2010-06-26
<DanaG> say, in "arm-none-linux-gnueabi", what is "none"?
<jo-erlend> I could use some help. I have an IGEPv2 board, which is based on a Cortex-A8 CPU. It has a SDHC card reader. I've formatted a 8GB SDHC card with Ext4, set the bootable flag, created a tar-file with rootstock which I extracted to the ext4 filesystem. It still won't boot. What am I doing wrong?
<DanaG> hmm, if IGEPv2 is like the Beagle, you need a fat16 (preferably) partition for the boot files.
<DanaG> uImage.
<DanaG> /dev/mmcblk0p1 should be fat16, and mmcblk0p2 should be ext4.
<jo-erlend> oh, ok. Can I put the entire root filesystem on a fat16 partition?
<tmzt> jo-erlend: not without loop image
<jo-erlend> then I'd only put the boot directory onto the fat partition and the rest on the ext-partition?
<tmzt> yeah
<tmzt> but that depends on the bootloader on your board
<tmzt> the omap3 mentioned has a bootloader capable of booting from fat, you may have to use nor or nand or some other method
<tmzt> I'm not familiar with your board
<jo-erlend> hmm.
#ubuntu-arm 2010-06-27
<markos_> hi, anyone knows of an asm instruction (or instructions) to find out the L1/L2 (well no ARM with L3 cache yet) cache sizes on ARM? Or some way to read it from the kernel?
<markos_> similar to cpuid on recent x86 cpus
<markos_> lool: I'm about to give up, no matter what I do, wanna-build just fails to even produce the database, you did mention an alternative a while ago, a gsoc project, got any more info on that?
<ssvb> markos_: the registers which can be used to get this information are described in ARM ARM, but they are not accessible from userspace
<ssvb> markos_: kernel provides some of the cpu specific information via /proc/cpuinfo and /proc/self/auxv
<markos_> ssvb: cpuinfo doesn't carry this info though, actually I thought of auxv, but it's not straightforward and I thought I'd ask first
<ssvb> markos_: yes, this information may be incomplete, for example auxv did not even report NEON availability before linux kernel 2.6.29
<ssvb> markos_: if you are really interested in having this information, pushing some patches to the kernel to get it may be useful
<ssvb> markos_: btw, http://pastebin.com/3rvXx68s
<markos_> hm, I guess it depends on the platform
<markos_> what kernel version?
<ssvb> 2.6.21-omap1
<markos_> strange, I get none of the cache info here (2.6.31.12.3-ER1-efikamx) on the imx515
<ssvb> looks like somebody is being lazy and is not keeping this code up to date :)
<lool> markos_: pkern was working on a python-based wanna-build replacement
<markos_> ssvb: still on x86 and ppc, L1/L2 cache info can be found on /sys/devices/system/cpu/cpu0/cache/index# etc
<markos_> ssvb: would be nice to have it work the same on arm also
<markos_> lool: anything published?
<lool> markos_: google "Debian Autobuilding Infrastructure Rewrite"; I don't know how complete the rewrite ended up being
<lool> markos_: Ping pkern or HE on #debian-devel@oftc?
<ssvb> markos_: I have only 'cpufreq' there, but not 'cache', anyway it is clearly a problem on the kernel side, preferably it should provide this information in a consistent way
<ssvb> markos_: alternatively it would be interesting if the kernel could just provide access to cpuid related registers (or emulate their behavior)
<ssvb> why do you need to know cache size?
<markos_> eigen library does block size configuration -or is able to do so- by matching matrix blocks according to the L1/L2/L3 cache sizes, it gets some extra % speed that way -at least on x86
<markos_> there's cpuid on x86 which gives that info -amongst others
<ssvb> a somewhat ugly solution would be to run a small benchmark to get this information in an experimental way
<markos_> that's too error prone
<ssvb> iirc, fftw does something like this
<ssvb> right, but in the worst case it will just impact performance, nothing else
<markos_> which is the point behind all this :)
<ssvb> are you going to bug kernel developers about providing this information?
<markos_> if it's possible, I can use it, if not, well, eigen is only a linear algebra library, running mini benchmarks at startup isn't going to be accepted by the authors anyway
<markos_> ssvb: I might, time permitting
<markos_> tbh, I've never filed a bug report on the kernel before, but there's always a first time :)
<markos_> the info is already available anyway
<markos_> first I have to setup this this autobuilder setup
<markos_> s/setup$/
<markos_> lool: I guess soyuz cannot be installed standalone...
<markos_> ?
<lool> markos_: No, but we're working exactly on that
<lool> markos_: Actually, according to the soyuz devs it's not that hard to run it standalone
<lool> markos_: What you will miss is the Launchpad API
<lool> and obviously the web UI
<lool> markos_: I'm not sure where the work related to splitting soyuz out is tracked; it should be in a blueprint but I'm not sure where
<lool> markos_: Ideally, ping james_w if you want to follow these discussions
#ubuntu-arm 2011-06-20
<Xofrats> hi, quick question, why does rootstock on karmic insist on qemu even when running under arm?
<ogra_> sigh, apachelogger had a boring sunday it seems
 * ogra_ wades through bugmail
<lilstevie> ogra: heh, any interesting bugs?
<ogra_> nah, just general noise
<lilstevie> damn
<lilstevie> you should see this weird bug I have had come up since switching to a newer kernel :p
<apachelogger> ^^
<ogra_> tell me
<apachelogger> ogra_: more like proper triage :P
<ogra_> heh, yeah
<lilstevie> the bootloader image is taking over, graphical corruption all round,
<ogra_> ouch
<lilstevie> basically in samsungs 2.6.35 sourcedrop the fbdev driver has been royally screwed
<ogra_> yeah, sounds bad
<lilstevie> my login screen is a few gdm elements overlayed over the bootsplash
<ogra_> did you try to roll back the driver ?
<lilstevie> not yet
<lilstevie> I will try that when I get back
<lilstevie> brb
<lilstevie> food
<Xofrats> Hey, either of you familiar with rootstock?
<Xofrats> I guess I killed the channel again
<ogra_> while i initially wrote rootstock i havent touched it in more than 12months
<Xofrats> Well, close enough... I had a sorta-generic question
<Xofrats> Is there a armel image that contains enough to run rootstock from a chroot setup?
<Xofrats> Because most of the references I see refer to qemu this or that
 * ogra_ has never run rootstock on arm ... and it wasnt originally created for that 
<Xofrats> I can't even apt-get rootstock on karmic because it fails on qemu
<ogra_> iirc someone patched it to be able to run natively though, but i have zero experience with that
<Xofrats> Hmmm....
<ogra_> you shouldnt run karmic anyway
<ogra_> its EOL
<Xofrats> I know, but that's the image I got to be able to run Ubuntu on an android phone
<Xofrats> Linux localhost 2.6.32.9 #1 Sun May 22 19:44:33 CDT 2011 armv7l GNU/Linux
<ogra_> what HW is that ?
<Xofrats> epic
<ogra_> ah, thats samsung, right ?
<hrw> htc
<Xofrats> Yeah
<hrw> sorry
<Xofrats> no. sammy
<Xofrats> evo is htc
<ogra_> lilstevie has some samsung experience ...
<Xofrats> k, good
<Xofrats> I want to also sorta-resurrect rhodbuntu for xda soon
<ogra_> if you want a barebone image, take the omap preinstalled netbook image, grab the content of the second partiton and touch /var/lib/oem-config/run
<Xofrats> hmm, k
<ogra_> tar it up and untar it on your phone
<Xofrats> well, there lies the issue
<ogra_> or if you want it more minimal you can du the same with the headless image
<Xofrats> this *is* my computer atm
<ogra_> *do
<Xofrats> so right now karmic is chroot'ed and running epic4 which lets me be here
<Xofrats> but I want to be able to create something a bit better
<lilstevie> which device?
<Xofrats> I just find it quite amusing that I can subsystem a true GNU/Linux on my phone
<Xofrats> epic 4g
<lilstevie> that is the same family as the i9000 isn't it
<Xofrats> yeah
<Xofrats> galaxys
<Xofrats> only one with a keyboard
<lilstevie> ok, if you give me a bit I will run through some of it with you, I have already gotten things working on the sgs i9000
<lilstevie> just no modem
<Xofrats> I don't need modem, I just nice chroot /data/local/ubuntu /bin/sh
<lilstevie> eh I don't chroot
<Xofrats> Let android handle the hw...
<lilstevie> chrooting is far from ideal, just fyi
<Xofrats> I know
<Xofrats> Trust me, I know
<lilstevie> heh
<lilstevie> I have a nice setup going, flash kernel and param with heimdall and throw the image on one of the SD cards
<ogra_> lilstevie, btw, how about providing your flash-kernel patch for upstream inclusion (or at least ubuntu inclusion)
<Xofrats> I just use an ext4 kernel and loopmount the ubuntu image
<lilstevie> ogra_: I dd
<ogra_> oh ?
<lilstevie> ogra_: the kernel is stored in its own block device that the bootloader reads
<lilstevie> a flash_kernel patch may help for easier updates including command line
<ogra_> yes
<lilstevie> I'm still trying to figure exactly how but there is a socket in one of the closed source modules that allows writing direct to the non-volatile stash that bootloader params are stored in
<Xofrats> how big is your sd image?
<lilstevie> my SD image is 2GB
<lilstevie> brb gotta do something so the mrs doesn't kill me
<Xofrats> The current "linux" image is woefully inadequate
<Xofrats> the guy that wrote the bootstrap script doesn't even know how to sed and cut
<Xofrats> I got it to the point where it doesn't whine about fs and partiion layouts
<Xofrats> but at least android uses the linux kernel to the point that you can chroot and run a gnu system under it
<lilstevie> back,
<lilstevie> I use an ubuntu initramfs in my kernels
<lilstevie> after playing round with the compression managed to get a natty initramfs to fit too :)
<Xofrats> nice
<ogra_> lilstevie, oh. you had compression issues ?
<Xofrats> kernel now supports lz right?
<lilstevie> ogra_: yeah the zImage was 8.3MB
<ogra_> lilstevie, what did you do ?
<ogra_> i have a similar prob on the ac100
<lilstevie> but the partition is just over 7
<lilstevie> I switched to lzma
<Xofrats> thought so
<Xofrats> lz is great except it's a memory hog
<ogra_> hmm, doesnt help here
 * ogra_ already tried all possible compression methods
<lilstevie> gzip gave me an 8.3MB kernel
<lilstevie> lzo gave me 10mb
<lilstevie> lzma is just fitting weighing in at 6.9MB
<Xofrats> everytime someone posts something in 7z I can't decompress half cuz the dictionary is too big
<lilstevie> ogra_: how big is your partition
<ogra_> 8M
<lilstevie> hmm
<lilstevie> why so big then?
<ogra_> but for a full fastboot boot.img
<lilstevie> do you need to mkboot
<ogra_> the kernel is 3.5M
<ogra_> so i only have 4.5 left
<lilstevie> the samsung bootloader takes a raw vmlinux
<lilstevie> or zImage
<ogra_> ah, lucky you
<ogra_> ac100 uses a fastboot img file to boot ... i need to pre-process kernel and initrd
<lilstevie> I also have a serial shell with the bootloader
<ogra_> using abootimg
<ogra_> no serial port here
<lilstevie> eugh, I am not looking forward to that with the transformer
<ogra_> so a console wouldnt help much
<ogra_> yep
<ogra_> well, should be easy
<lilstevie> heh yeah, going to be kernel level for most of it
<ogra_> i guess it shouldnt take more than one/two days to get a first cut image running
<lilstevie> yeah thats how long I give it
<lilstevie> it is being sent tomorrow,
<ogra_> properly integrated rather a week or two
<ogra_> (depending on the kernel)
<lilstevie> but when it gets here I forsee booting within the hour
<lilstevie> I am going to be getting on ASUS ass about GPL
<ogra_> the kernel source is there
<lilstevie> they still haven't released the 3.1 kernel source
<ogra_> question is how the nvidia bits are integrated
<lilstevie> much like the xoom
<lilstevie> from what I have looked over so far in the 3.0 source
<ogra_> if transformer uses nvec as badly as ac100 it will be really really bad to get the peripherials working
<lilstevie> yeah I hope not :/
<ogra_> they all need undocumented init codes from nvec here
<lilstevie> are nvidia willing to cooperate?
<ogra_> so for ac100 it took nearly 6 months to get that properly worked out
<lilstevie> I take it not
<ogra_> nvidia ?
<ogra_> lol
<lilstevie> heh well their SoC is horribly documented
<ogra_> i think the devs would love to ... but management doesnt care
<lilstevie> heh
<lilstevie> samsung are actually taking a big interest in OSS which has been a huge plus
<Xofrats> stevie: do you think using rootstock is the best way to create a new image?
<ogra_> just getting their 3D driver in a binry form like the x86 one would change the world
<lilstevie> I have been using the omap4 prebuilt
<Xofrats> didn't they just send a few 'pad to kernel hackers?
<Xofrats> hmm, k
<lilstevie> yeah they sent a 10.1 to supercurio
<Xofrats> and natty works on the galaxy?
<Xofrats> and I think karmic was the last one to support arm6 correct?
<hrw> yes
<hrw> (karmic)
<lilstevie> it is much harder galaxy s is armv7
<lilstevie> 'er
<lilstevie> shouldnt stop half way in :p
<lilstevie> galaxy s is an armv7 device, cortex-a8
<Xofrats> Well, gonna use natty on the epic
<lilstevie> ogra_: 3D drivers are something we wish for here too
<Xofrats> But I also want to do something similar for the msm7k2
<Xofrats> which is arm6
<ogra_> lilstevie, well, the nvidia ones exist ... but they are linked and built against unusable xorg versions
<Xofrats> memory might be an issue though
<ogra_> so you can onyl use them if you also replace half your rootfs
<lilstevie> ogra_: while I can try hijacking the tiomap SGX drivers my gpl-glue is horrible and doesn't support DRI
<lilstevie> ew
<ogra_> you should talk to jessebarkers team in #linaro :)
<lilstevie> why would they do that
<lilstevie> for the module?
<Xofrats> would omap4 be the right one for karmic too?
<lilstevie> I've been chipping away at patching in the samsung stuff to the DKMS but it has been a slow process
<ogra_> the module isnt the prob, the xerver is
<ogra_> i can roll a kernel that ignores all versioning info from that module
<ogra_> but i cant run userspace without the right xlibs
<lilstevie> well when I say I use the omap4 image, I use the rootfs, rip out all the omap stuff and replace with hummingbird modules and firmwares
<ogra_> dont use omap4 :)
<ogra_> use omap
<lilstevie> ah you mean for the ULP GeForce
<lilstevie> what is the difference
<ogra_> omap4 has the PPA bits
<lilstevie> ah
<ogra_> so you have a few pieces more to remove to get back to a clean image
<lilstevie> I used the omap4 image cause hardware wise it is closest, ie: same GPU :p
<ogra_> on omap you can just dpkg -l |grep omap and remove all the bits
<lilstevie> ah nice
<Xofrats> okay
<Xofrats> what's ppa, sorry
<lilstevie> Personal Package Archives
<Xofrats> k
 * ogra_ actually hopes someone from the nouveau people will develop some interest in tegra
<lilstevie> ogra_: I really hope that the keyboard dock for the transformer doesn't need undocumented shit implemented in nvec to work
<lilstevie> that would be a massive failure
<ogra_> well, that would be what i expect though :)
<ogra_> from nvidia
<Xofrats> how different is the omap prebuilt to say rootstock-based image?
<ogra_> it uses a diffrerent build system
<lilstevie> ogra_: lets just hope asus took a bit more control for their dock
<ogra_> we'll see
<Xofrats> any pro/cons to either, or am I being a n00b
<ogra_> well, prebuilt gives you a read made system, rootstock *creates* a system
<ogra_> and given that you cant run it natively apparently, i dodnt really see where you have choice ;)
<lilstevie> eugh, looking at the sources it appears the dock is interfaced through NVIDIA Tegra internal matrix keyboard controller
<Xofrats> yeah, true
<ogra_> sounds like nvec
<plm> Are there plans to support tegra?
<ogra_> no, but there will be an ac100 community image
<ogra_> and probably also one for the eeepad tarnsformer
<ogra_> *trans
<Xofrats> how much ram is considered decent for arm-based sytem?
<ogra_> there wont be official tegra support from ubuntu though
<ogra_> Xofrats, 512M works ... i wouldnt even start trying with anything less
<lilstevie> hopefully my eeepad arrives this week
<lilstevie> 512 is ok
<Xofrats> hmmm, ew...
<Xofrats> wonder how rhodbuntu got it working with 200
<lilstevie> I am actually thinking of cramfs
<ogra_> Xofrats, cutting out tons of stuff
<ogra_> Xofrats, my ac100 uses 130MB for teh desktop on start
<ogra_> as you can see you can indeed use that on 200M
<ogra_> just dont start any app ;)
<Xofrats> I guess
<Xofrats> But in this case it'll be sharing memory space with *ndr**d
<lilstevie> yeah I use about 150MB on boot with the tab
<ogra_> using a browser with 20tabs open, xchat with about 30 channels on several servers, a bunch of terminals and evolution via ssh -X from another machine i use 380M ram and 250M swap here
<Xofrats> 20 tabs...
<ogra_> according to htop
<plm> ogra_: why wont be official tegra support from ubuntu? any special subject?
<Xofrats> I don't need much for gui from ubuntu anyway
<ogra_> no collaboration with nvidia atm
<lilstevie> ogra_: k maybe it doesn't I am looking in the wrong config block
<Xofrats> tons of useful console/ncurses app to use
<Xofrats> strobe, ping -f...
<plm> ogra_: wow, nvidia is so close.. :-(
<Xofrats> oh wait, wrong hat *switches hat*
<ogra_> plm, but there are a bunch of community projects for specific devices
<ogra_> plm, so we will have community images on cdmiang for some
<ogra_> *cdimage
<plm> ogra_: yes, I know about OMAP3/4 of TI..
<ogra_> i.e. toshiba ac100 ... probably the transformer, likely the nook color
<plm> ogra_: like as pandaboard, bealge ans so one..
<ogra_> they are official images
<ogra_> panda and the omap3 ones are fully supported by canonical
<ogra_> the tegra2 ones wont be
<lilstevie> ogra_: how does one go about getting a community image on cdimage
<ogra_> lilstevie, we just work on documenting that
<plm> ogra_: yes.. I would like to use tegra3.. and I would like know if are a there (i not found) a community project for tegra3 like as are there with panda..
<ogra_> for now you need to work with a person from the cdimage team (or be in that team)
<lilstevie> ah ok
<ogra_> lilstevie, though it all starts with having a kernel package in universe
<ogra_> plm, i dont think you can get tegra3 HW aynwhere yet
<ogra_> so there is no community for it yet
<plm> ogra_: ok.. but not for tegra2 too :-(
<ogra_> well, for tegra2 the above applies
<lilstevie> ogra_: ah ok, well my galaxy kernel is nowhere near that standard yet
<ogra_> ac100 images will be there for oneiric
<ogra_> lilstevie, what standard ?
<ogra_> its universe
<lilstevie> ogra_: my standard
<plm> ogra_: above?
<ogra_> lilstevie, if it doesnt remove all your user data from the HDD and makes most devices work it should be enough
<plm> ogra_: what is that ac100 ?
<ogra_> indeed if you have a "wipe my disk" bug you ship, thats below any standard :)
<plm> ogra_: I'm looking for in https://wiki.ubuntu.com/ARM
<ogra_> plm, toshiba ac100 netbook
<ogra_> yeah, persia wanted to add a page for tegra/ac100 ... apparently thats not there yet
<Xofrats> Mine comes with "nuke from orbit" and locks onto my agps chip
<Xofrats> does that count?
<plm> ogra_: ok.. well.. notebook is so big.. I would like to use power of GPUs but in a little device.. like as omap with dsp...
<lilstevie> ogra_: my standard means it works and can be used
<ogra_> lilstevie, well, if it does that, roll a package from it :)
<lilstevie> by can be used I mean modem and all
<lilstevie> and modem is far from even close to booting
<lilstevie> ogra_: the more I look at the source for the eeepad the more it looks like it is going to be done in nvec
<Xofrats> anyway, thanks for the info, I'll prolly be back with more n00b q
<lilstevie> welcome back ogra
<jeremiah> w00t! The oneiric daily build from today is booting on the OMAP 4 pandaboard :)
<ogra_> funny, given that there was no build today
<ogra_> oh, wait, you mean headless
<jeremiah> ogra_: Yeah, the headless version. :)
<jeremiah> Still going through some filesystem checks at the moment.
<ogra_> yeah, netbook wouldnt be much fun atm
<ogra_> given that the whole USB stack seems to be screwed in the current kernel
<jeremiah> Ah.
<jeremiah> That sounds, um, painful.
<lool> ogra_: hey
<lool> ogra_: how much do you use qemu-system-arm with versatile kernels these days?
<ogra_> lool, me ?
<lool> ogra_: you
<ogra_> i havent used that since two releases iirc
<lool> Ok; thanks  :-)
<ogra_> rootstock still uses it though
<ogra_> should be ported to omap or some such
<lilstevie> heh
<noah1989> hi
<noah1989> where can i browse the packages available for ARM architectures?
<noah1989> packages.ubuntu.com seems to have amd64 and i386 only
<ogra_> launchpad
<ogra_> generally you can say though that the source package list doesnt differ between x86 and armel, apart from very few arch specific packages like bootloaders
<ogra_> http://qa.ubuntuwire.org/ftbfs/natty.html has a list of binaries that didnt build on arm
<ogra_> everything else is available on armel as well as on i386
<noah1989> ah.. that's fine
<jeremiah> http://pastie.org/2096114
<jeremiah> Hmm, OMAP 4 headless image hangs there ^^
<ogra_> how big is your SD ?
<ogra_> the actual write of the resizing happens after that line, it might take a moment with bigger SDs
<jeremiah> 8 gigs
<ogra_> (you should see the LEDs being busy though)
<jeremiah> Both LEDS are busy
<jeremiah> :)
<ogra_> good
<ogra_> then just give it time
<jeremiah> Will do.
<ogra_> lool, yre you planning to drop versatile completely or just the v7 patch ?
<lool> ogra_: drop it completely
<ogra_> good
<lool> ogra_: essentially, vexpress should be better in all respects
<ogra_> in aemu respects too ? :)
<lool> I'm using vexpress these days, and it's buggy, but I believe the same code is used for versatile, so it should be the same really
<ogra_> *qemu
<lool> Yes; AFAIK it's using the same QEMU drivers
<lool> for SD, fb etc.
<ogra_> ah, awesome
<lool> but it's not much usable sadly
<lool> the network corrupts or cuts some packets somehow
<ogra_> worse than versatile ?
<lool> and the SD stalls regularly
<lool> I don't think it's worse than versatile
<ogra_> k
<lool> oddly, using a Debian userspace makes things better
<lool> not perfect, but better
<lool> I think it's just an accident though
<ogra_> yeah, i heard the same for the ac100 port, people using debian have less kernel issues it seems
<jeremiah> heh, that reminds me. I want to get debian working on my AC 100
<ogra_> (we have a kernel bug that makes input devices die, apparently that shows only very rarely on debian userspace with the same kernel binary)
<ogra_> (and with similar userspace)
<ogra_> jeremiah, just bootstrap a rootfs :)
<jeremiah> Cool, I'll do that. :-)
<lilstevie> ogra_: actually something I haven't been able to get straight about the tegra2
<lilstevie> where does APX exist
<lilstevie> bootloader, or bootrom
<ogra_> APX ?
<lilstevie> the mode that nvflash talks to
<alex12> greetings all.  Anyone have a moment to help me out with an ubuntu 11.04 installation on beagleboard-xm rev C?
<ogra_> in the ac100 thats in rom i think
<lilstevie> hm cool, I am just wondering about flashing risk, etc. if I fuck a flash on the tab when it is doing the bootloader, I am pretty much left with jtag as my only option, other than taking it to samsung
<ogra_> well, if it is set up similar to the ac100 you cant brick it
<GrueMaster> alex12: what issues are you having?
<ogra_> even if i screw up the MMC completely i can always get it into flash mode and re-do everything
<lilstevie> ok thats what I wanted to hear
<lilstevie> I bricked my tab once, :/
<ogra_> thats why i think its in ROM
<hrw> lilstevie: define 'bricked'
<lilstevie> ogra_: ok, that tells me what I want to know
<lilstevie> hrw: as in it was a paper weight
<lilstevie> hrw: full definition of brick
<alex12> I used canonical's pre-built 11.04 image.  Followed instructions to replace uImage and the kernel on the sd-card.  Booted the bb-xm rev. c. and a.)colors are off (everything is red) b.) no mouse or keyboard response at the first set-up screen.  can't go anywhere.  any ideas?
<lilstevie> returned to samsung to fix
<GrueMaster> alex12: Which image?  Netbook or headless?
<alex12> netbook
<GrueMaster> hmmm.  Haven't heard of that issue offhand.  Unfortunately I don't have one of these newer boards to test with.
<alex12> okay thanks for your time.  i'm going to try the 10.10 pre-built now.
<hrw> lilstevie: nice
<lilstevie> hrw: nice that I am not misusing the term, or nice that the device can be permafucked
<lilstevie> ?
<noah1989> lilstevie: i think he meant "nice" how precisely you defined the term
<lilstevie> heh
<hrw> yes
<hrw> as lot of people say 'bricked' as 'had to reflash'
<lilstevie> heh soft-brick
<noah1989> the correct definition of "bricked" depends on the equipment that you have available
<noah1989> for example an AVR microcontroller can be bricked by disabling the ISP programming interface, but that's only for people who don't have a 12V parallel programmer and a soldering iron
<ogra_> so its not bricked :)
<ogra_> bricked for me means something you cant fix ... its a brick
<noah1989> well that depends on wether "you can't" means "you're unable" or "it's impossible"
<ogra_> the latter
<lilstevie> my tab required a new logic board
<hrw> bricked == have to use jtag or worse - for me
<lilstevie> hrw: agreed
<hrw> especially when I lack jtag at home ;D
<lilstevie> I define bricked as fubar'd
<lilstevie> yeah my jtag does not work on the tab
 * ogra_ is happy he doesnt have to work with HW you can actually brick atm
<ogra_> and i hope that wont change :)
<lilstevie> heh
<lilstevie> samsung screwed something with iROM by not giving a method of halting boot to get into a bootrom recovery
<ogra_> bitter
<alex12> did my bb-xm just die?  I have the 5V adapter (from digikey, recommended supply).  just powered on, all I'm getting is the D5 LED solid green, no other activity...
<GrueMaster> Do you have an SD plugged in?
<alex12> yes
<ogra_> sounds like bootloader or kernel screwup
<alex12> okay i'll reimage the SD card, thanks!
<rsalveti> lool: how much mem qemu currently supports for vexpress? 1gb?
<ogra_> thats what he wrote in the mail
<alex12> i'm using bb-xm demo image of ubuntu (netbook-minimal-11.04).  after doing an apt-get update, I used  'apt-get install ssh' to install the meta-package.  ubuntu was in the middle of it when DVI image just went dead... same thing happened the other evening when trying to install xfce.  any ideas why i'd lose video?
<ogra_> a bug ?
<ogra_> (would be my first idea)
<ogra_> :)
<lool> rsalveti: yes
<lool> alex12: could be a power issue too; if you're powering from USB for instance, driving a DVI device + USB + stuff is too much
<alex12> lool: thanks, i'll move a device off then
<alex12> rcn-ee: thanks for the bb-xm demo image, first time I've been able to get Ubuntu to come alive on my board =)
<rcn-ee_at_work> cool, your welcome alex12
<alex12> rcn-ee_at_work: so, any ideas why the canonical images don't run right on the -xM rev. C?  I know you've been developing the alternatives for quite a while now... canonical still can't keep up?  I followed all their instructions, replaced the kernel (which is presumably something similar to what you've done) but I cannot get it to boot.  =(  Why can't they get it straight?
<GrueMaster> alex12: Don't blame us.  We have a hard time when board revs change functionality and we aren't informed until users complain.  And we don't have them to test/debug.
<rcn-ee_at_work> alex12, the xM C kinda came out suddenly, i was luckly enough to get one early at a ti training, but by that time it was too late for ubuntu's natty.. the kernel's image was frozen..  with my images, i don't have that limiation..
<sveinse> Is it possible to run update-initramfs from within a chroot environment? I got "/bin/df: Warning: cannot read table of mounted file systems: No such file or directory"
<ogra_> yes, but you need to bind mount /dev from outside the chroot and proc and sys inside the chroot
<sveinse> Note The chroot is not for the same machine as the running machine
<ogra_> well, it still uses /dev/null and stuff
<sveinse> Interestingly the rootstock script mounts proc and devpts from outside the chroot
<ogra_> hmm ?
<sveinse> iirc that is
<ogra_> i dont think so
<ogra_> it should chroot
<ogra_> unless someone really mangled my original code
<sveinse> It has been changed
<sveinse> never the less, what significance are there concerning mounting proc and sys from the inside?
<ogra_> the scripts looks at files in there
<ogra_> *look
<sveinse> But there's no real difference between mounting proc before running chroot than mounting it afterwards, is there?
<ogra_> no
<sveinse> good
<ogra_> doesnt matter how you mount it, as long as it is populated inside the chroot when you run your command
<sveinse> yes. And in that context, the rootstock script only mounts proc and devpts, not dev
<sveinse> Wait a minute, isn't device nodes, like /dev/null, blk nodes, so they dont need /dev as mount to work, or am I misunderstanding?
<ogra_> null is a char device
<sveinse> yeah, but still a device node, so if it exists on the fs it will work. It don't need some mounted /dev
<ogra_> i dont know which devices update-initramfs needs
<ogra_> null was just an example, just mount it
<sveinse> Thanks
<sveinse> There were some talk some time ago about altering update-initramfs to suit uboot image file format. Has this been made?
<ogra_> surely not
<ogra_> update-initramfs shouldnt have anything to do with handling bootloader specific bits
<ogra_> thats the job of flash-kernel in ubuntu/debian
<ogra_> (on arm at least)
<sveinse> But some apt upgrade packages triggers update-initramfs which in turn needs to trigger uboot changes, right.
<ogra_> yes
<ogra_> so update-initramfs makes a call to flash-kernel
<ogra_> after it rolled the new initrd
<sveinse> does flash-kernel handle uSD cards as well?
<ogra_> it handles whatever was set up for your board in the flash-kernel code :)
<ogra_> flash-kernel is a pretty horrid script wheer every board cooks its own soup, even if that means to duplicate half the code
<sveinse> hmm. I see how flash-kernel is setup to be called from initram-fs. It's perhaps easier to just make my small little script to do this part
<ogra_> just add a patch to flash-kernel ...
<ogra_> and give it to me so i can include it in oneiric ;)
 * ogra_ needs to do some real life stuff now ... 
<sveinse> How should /etc/fstab look like on OMAP3? Mine is empty. (I refer to non-storage lines, like proc tmpfs etc.)
#ubuntu-arm 2011-06-21
<MrCurious> anyone here have bitbake skills?
<lilstevie> does anyone here actually have an eeepad transformer
<Daviey> NCommander (or anyone else): How is PXE support in uboot looking?
#ubuntu-arm 2011-06-22
<jcrigby> persia: ping?
<persia> jcrigby, Hey.
<jcrigby> persia, I need you to send the technical board an email to ask them to tweek permissions to the packages to which the DMB has granted me upload rights
<jcrigby> persia, or so I have been told
<persia> That never happened?  Ugh.  Sure, I'll take care of that today.
<jcrigby> persia, thanks!
<persia> Really what you need is for someone with the right permissions to run the correct LP API client script.
<persia> But yeah, my sending email will probably make that happen.
<jcrigby> or at least with the email I can ping a TB member on IRC to remind them
<persia> They're usually fairly good about that.
<persia> In the meantime, if you have some packages somewhere and just need a signature, I'm happy to push them.
<rsalveti> Daviey: jcrigby is working on pushing a new u-boot release in the following days
<rsalveti> that should cover PXE support
<rsalveti> at least the initial support
<rsalveti> jcrigby: still don't have the permission to push the packages?
<jcrigby> rsalveti, I'm hoping that that will be fixed in the morning.  If not I will ping some TB members
<rsalveti> jcrigby: cool
<rsalveti> jcrigby: as you're the u-boot maintainer from linaro side, are you ok releasing it at this thursday?
<rsalveti> iirc this is the same day the kernel team is tagging their tree
<jcrigby> rsalveti, yes I believe that is fine.  The core functionality works the USB related stuff seems to work for others but not me:)
<rsalveti> jcrigby: we can try to do some debugging on this next week
<jcrigby> rsalveti, sounds good.  I also sent some questions to some ti folks.  I got back a response from a third person asking for pointers to git trees which I provided.
<persia> jcrigby, rsalveti: Will that cover https://blueprints.launchpad.net/ubuntu/+spec/other-o-arm-uboot-tftp ?
<persia> Or does that spec need workitems, approval, etc.?
<rsalveti> persia: yup
<persia> Ah, cool!
<jcrigby> persia, at least for panda
<rsalveti> we may end up doing a hack session to try to also get it working for xM
<persia> jcrigby, Hrm?  Does linaro's u-boot implementation differ by board?
<rsalveti> but don't know the current status of the usb patches for xM
<rsalveti> persia: not tftp and pxe, but the usb and network driver
<rsalveti> that depends on the hardware
<persia> Aha!  So the functionality will be there, but drivers may not be there.
<jcrigby> persia, exactly
<persia> Could someone more knowledgeable update the spec description to indicate what is actually being implemented?
<rsalveti> persia: yeah, that's on my plate
<rsalveti> didn't do it yet because was busy with the unity and compiz work
<persia> Also, is there interest from other Linaro members to get their network or USB drivers into u-boot?
<jcrigby> persia, we may get omap3 working as well, it has usb working for storgage just not tested for networking yet
<persia> How about mx5 or one of the others?
<jcrigby> persia, not sure
<persia> Heh.  That's about what I expected :)
<rsalveti> that would be nice to check with the specific landing team
<persia> Do you guys want to check?  Do you want to give me names, and I'll ask folk?
<rsalveti> persia: https://wiki.linaro.org/LandingTeams
<persia> Heh.  OK.  I'll ask folk.
<persia> Please let me know when the spec is in shape, as I'll be pointing them there as I ask.
<rsalveti> persia: https://wiki.linaro.org/MeetTheTeam#Member_Services
<rsalveti> persia: just ping directly the landing team TLs
<persia> They already have all the context?
<rsalveti> probably not, usually they are mainly working on the kernel side
<persia> That's what I thought :)  I'll wait until the spec is clear, so I have something real to talk about.
<rsalveti> ok
<dhana013> Hi hello I want ubuntu 10.04 arm926 how to make from scratch
<dhana013> any one help me
<dhana013>  I want ubuntu 10.04 arm926
<dhana013> how to do it?
<dhana013> I am trying with rootstock
<infinity> dhana013: ARM926 is ARMv5, Ubuntu only supports ARMv7 at this point.
<infinity> dhana013: So, you either need to be prepared to replace the toolchain and literally rebuild the entire archive (ouch), use an older release that supported ARMv5, or perhaps use Debian?
<dhana013> thanks for u r information
<Daviey> rsalveti: super, thanks
<Spider-Pork> morning
<Spider-Pork> i am using ubuntu 11.04 headless on my pandaboard. I need a console on monitor+mouse+keyboard instead of 115200 serial. Any help?
<Spider-Pork> Need i to modify boot script?
<ogra_> it will fire up tty logins after the configuration is done
<ogra_> so if you can do your configuration on serial it should already do what you want after that
<Spider-Pork> i would to have console on my dvi-d external monitor instead serial terminal
<ogra_> if you actually *need* oem-config on a framebuffer you indeed need to modify the cmdline a bit
<Spider-Pork> ok, you mean the cmd line at the boot prompt?
<ogra_> but beyond that, only the first boot config actually requires serial in the default configuration
<ogra_> i mean you need to edits boot.scr of the virgin, unbooted image
<ogra_> *edit
<Spider-Pork> ok
<Spider-Pork> is there a guide to help this edit?
<ogra_> somewhere in the ubuntu wiki i think
<Spider-Pork> ok, thank you ogra_
<ogra_> look at the subpages of /ARM/OMAP on wiki.ubuntu.com
<ogra_> but if i were you i would just go with the default, do the first boot config on serial and then use the monitor
<Spider-Pork> sorry but i am just noob about these stuff. How can i use monitor after first boot?
<ogra_> there will be a login prompt on your screen, you just log in
<Spider-Pork> ehm, no there isn't
<ogra_> you already created the user and set the timezone etc ?
<Spider-Pork> yep the machine is running
<ogra_> did you reboot since ?
<Spider-Pork> yep
<ogra_> with the monitor plugged in ?
<Spider-Pork> and i see the boot menu on serial console
<Spider-Pork> yep
<ogra_> boot menu ?
<Spider-Pork> hit any key to stop auto-boot
<Spider-Pork> 3 2 1...
<ogra_> ah
<ogra_> so it boots to a login prompt on the serial console ?
<Spider-Pork> yep
<Spider-Pork> i see che serial config inside boot.script
<ogra_> ps ax|grep getty
<ogra_> do you see getty's running on the differnt tty's ?
<ogra_> it should list tty1 to 6
<Spider-Pork> ogra_: http://ideone.com/n7GoA
<ogra_> so there are login prompts running on your ttys
<ogra_> are you sure your monitor is connected correctly ?
<Spider-Pork> i think yes
<Spider-Pork> the monitor has dvi-d interface
<ogra_> well, there should be no reason that you dont see a login prompt on your screen
<Spider-Pork> so i'm using a dvi-d/hdmi A cable
<ogra_> and you connected to which socket ?
<Spider-Pork> the external one
<ogra_> on the panda, to which graphics port did you connect ?
<Spider-Pork> the external port
<Spider-Pork> there are two ports
<Spider-Pork> one near ethernet cable
<ogra_> there is a hdmi and a dvi one
<Spider-Pork> and one external
<ogra_> they are labeled
<Spider-Pork> dvi one
<ogra_> did you try the other one ?
<Spider-Pork> nope because the label says: DVI-D and i'm using a DVI-D cable
<Spider-Pork> i try
<Spider-Pork> now is working
<ogra_> :)
<Spider-Pork> thank you ogra_
<Spider-Pork> why?
<Spider-Pork> i followed the tag on the board
<Spider-Pork> nice thank you ogra_
<Spider-Pork> i saw inside boot script that the ram is limited to 512M
<Spider-Pork> why?
<ogra_> it isnt
<ogra_> check with free
<ogra_> there is a reserved memory area for the dicati engine
<ogra_> *ducati
<Spider-Pork> ah ok
<Spider-Pork> and ducati engine is?
<ogra_> starting at 512m
<ogra_> ducati does all the multimedia processing
<Spider-Pork> ah cool
<Spider-Pork> thank you
<ppisati> i like the ducati monster carbon black
 * ppisati hides...
<ppisati> :)
<ogra_> the one that MacSlow has ?
<ppisati> who?
<ogra_> MacSlow from the DX team
<ogra_> i think he drives one
<ppisati> http://en.wikipedia.org/wiki/File:Ducati_Monster_620_Dark.jpg
<ogra_> i think thats the one, not 100% sure
<ppisati> cool, i like it :)
<ppisati> ogra_: btw, any updates on the ac100 image?
<ppisati> ogra_: shall i bring mine to dublin? so you can see where the installatin fails?
<ogra_> just rolling a new kernel package
<ogra_> yes pleas
<ogra_> e
<ppisati> ok
<ogra_> what model was that ?
<ogra_> 10Z ?
<ppisati> wai
<ppisati> t
<ppisati> yep
<ogra_> sigh
<ppisati> uat?
<ogra_> ok, so its definitely a prob with that model
<ppisati> ouch
<ogra_> tobin has the same
<ppisati> and it fails in the same way
<ogra_> but he got a 10U now which works fine
<ppisati> plymouth fails and lalala
<ogra_> that we will see in dublin ;)
<ogra_> the plymouth messages are just cosmetic
<ogra_> you can ignore them
<ogra_> thats not the cause of the issue
<ppisati> ok
<ogra_> apparently the unpacked tarball is corrupt
<ppisati> ouch
<ogra_> so your rootfs isnt completely there
<ppisati> did you roll a new rootfs too?
<ogra_> that seems to only happen on that one model which is really weird
<ogra_> i will
<ppisati> ok
<ogra_> first the kernel needs to be up to date ... that takes a day
<ogra_> but i plan to have a newer natty image in place before the sprint and hopefully also a headles spin
<ppisati>  cool
<ppisati> a headless would be awesome
<ppisati> as a side note, there's a fix for the usb thing on omap
<ogra_> yup, i hear you
<ogra_> i thought that didnt work ?
<ppisati> there's a new one :)
<ppisati> actually 2 patches
<ppisati> but anyway
<ppisati> testing right now
<ppisati> works on omap4
<ppisati> trying omap3 now
<ppisati> and while it compiles, i think i'll grab some food
<ppisati> and now it breaks in new and unexpected ways... ohhhh...
<ogra_> joy !
<lugu> Hi! I am trying to port Ubuntu to an HTC device, but the audio driver neither support ALSA not OSS...
<lugu> it use a specific device /dev/msm_pcm_out ...
<lugu> do other ARM devices have exotic sound support?
<hrw> which htc device?
<brendand_> what does the pandaboard do with the led's if there's been a kernel panic?
<brendand_> heh, it's back now. everything froze for a while
<lilstevie> lugu: some do some don't depends on the Audio codec
<lilstevie> lugu: just out of interest what device
<dhana013> How to port ubuntu 9.10 for ARM926
<lilstevie> dhana013: that is a lot of work
<lilstevie> ARM926 is armv5 afaik
<lilstevie> which means compiling every last thing
<dhana013> I have tried with rootstock not working
<lilstevie> rootstock doesnt compile everything
<lilstevie> you need to get teh source for everything and compile
<dhana013> give any link
<lilstevie> not offhand
<lilstevie> personally I would just use debian
<lilstevie> it is a lot of work
<peteiow> Hello is there a chat room for new users please?
<persia> persia, Depending on your question, here may be fine.
 * persia fails tab completion
<lilstevie> persia: hehe I hate it when that happens,
<persia> "peteiow" < "persia", but apparently my client was processing the /part just at the moment I pressed <tab>, but before having printed it :)
<persia> Err, no, I'm completely wrong.  Still, shouldn't complete to myself :/
<lilstevie> heh I tabcomp with 2 chars so it would have for me
<lilstevie> but my client also completes to the last to talk for a given pattern
<persia> That's helpful.  Extra points if it also includes those who have already left the channel in the candidates.
<lilstevie> no extra points
<lilstevie> :(
<lilstevie> part and rejoin resets that person in the queue
<persia> (perhaps for some time (e.g. 300 seconds), with the timeout indefinitely extended when there is an outstanding highlight from that nick)
<persia> Oh, that makes it extra tricky for folk who bounce a lot.
<persia> (or netsplits)
<lilstevie> yeah :/
<persia> Oh, you might know: earlier apachelogger was asking about GLES drivers for i.MX53, and whether there were any available under terms that could allow them into multiverse.
<lilstevie> no idea, but a quick look at freescales site indicates that the drivers may be difficlt
<lilstevie> s/difficlt/difficult/
<persia> Yeah, that was my experience from the same look.
<persia> I can never keep track of which devices you're playing with, so I figured it was worth asking :)
<lilstevie> what is the stance on licencing for multiverse, needs to be canonical friendly, or is it maintainer of the package is responcible
<persia> Needs to be mirror-friendly.
<lilstevie> ah
<persia> Specifically, needs to allow redistribution without cost or explicit acceptance.
<lilstevie> that is fair enough
<lilstevie> as for the devices I am playing with, as a general rule, mainstream android devices
<persia> It's rather relaxed.  That said, be careful if you use software from there: some of it requires sending postcards to folk, some of it is non-commercial only, some can't be used in some countries, etc.
<lilstevie> ages ago it was the iphone
<persia> Oh, just retail stuff?  I thought you sometimes did development boards also.
<lilstevie> I don't get my hands on many dev boards these days :(
<persia> Prices keep dropping (although I'll admit I much prefer retail devices)
<lilstevie> yeah
<lilstevie> polish of retail devices is just that bit nicer
<lilstevie> even if I am bringing an unsupported os :p
<persia> They also stack and travel better.
<lilstevie> looking forward to my next target
<lilstevie> yeah that is true
<persia> What do you have planned?
<lilstevie> transformer
<persia> That's the one that turns into a robot?
<lilstevie> haha the one that turns into a netbook
<persia> Ah, so not http://mobilementalism.com/2007/09/04/motorola-transformer-phone/
<lilstevie> haha no,
<lilstevie> that thing looks cool though
<lilstevie> ASUS eeepad transformer
<persia> Oooh, nice.
<lilstevie> yeah :)
<lilstevie> should arrive soonish
<persia> Any chance that a kernel could be constructed that worked for both that and the ac100, or is too little autodetectable?
<lilstevie> probably a bit big
<persia> big meaning incompatible with the partitioning, or just extra megabytes?
<lilstevie> big meaning extra megabytes which arent able to be spared :(
<persia> What's the limitation there?
<lilstevie> ogra was saying as it is the natty initramfs does not fit due to the size limitations
<lilstevie> most android devices have a limitation of around 7-8MB
<persia> Oh, the partitioning.
<persia> We definitely need a way to safely and correctly repartition those, and apply a bootloader we can understand.
<persia> On my Dynabook, I have about 3GB wasted because of the restrictions, and having to maintain multiple kernel trees just makes it hard.
<lilstevie> well on these tegra devices it shouldn't be that horrible
<lilstevie> on my galaxy tab I had to tweak compression and rip things down
<lilstevie> but if I understand what APX mode is, it should be a bootrom level recovery mechanism
<lilstevie> opening the doors to porting uboot
<persia> Oh, excellent!
<lilstevie> I wouldnt dare for my tab though
<lilstevie> sbl is the lowest form of recovery
<lilstevie> well bedtime I think :)
<persia> Sleep well.
<lilstevie> I'll try :)
<lilstevie> have a good morning/day/afternoon/evening/night
<rsalveti> janimo: any idea already why firefox takes so much time to start on arm?
<cpearson> which version?
<rsalveti> cpearson: any version :-)
<rsalveti> cpearson: janimo had a bp to try to speed it up
<rsalveti> cpearson: the webm issue is related with thumb2 support
<rsalveti> built firefox 5 without thumb2 and I'm able to play youtube videos with html5 + webm
<rsalveti> reporting at bug 789198 now
<ubot2> Launchpad bug 789198 in firefox "Firefox crashes when attempting to play webm video OMAP4 Panda Board" [Medium,Triaged] https://launchpad.net/bugs/789198
<rsalveti> sorry, was supposed to be to chrisccoulson :-)
<chrisccoulson> rsalveti, thanks. i'm sure it was somebody in here who turned on thumb2 support ;)
<ogra_> it wasnt :P
<ogra_> doko turned it on :)
<hrw> have a nice day(s) - see you on friday
<ogra_> rsalveti, janimo has a spec to research that
<ogra_> (firefox startup time)
<rsalveti> ogra: chrisccoulson: was changed by bug 696895
<ubot2> Launchpad bug 696895 in xulrunner-2.0 "FTBFS on armel" [High,Fix released] https://launchpad.net/bugs/696895
<rsalveti> janimo probably added it
<ogra_> thats a quite old bug id
<ogra_> january, hmm
<rsalveti> not *that* old
<rsalveti> seems to affect only libvpx
<rsalveti> that is used when playing webm videos
<rsalveti> probably nobody ever tested it
<ogra_> so libvpx needs to learn thumb2 ?
<rsalveti> ogra: think so, but the problem is that firefox keeps it's own version of libvpx
<rsalveti> and link it against libxul (huge link)
<ogra_> oh fun
<rsalveti> chrisccoulson: will build against latest nightly and report the bug upstream
<rsalveti> ogra: chrisccoulson: should we disable thumb2 support for now? I can create the debdiff
<rsalveti> this will let people play youtube videos with webm support (html5)
<ogra_> if that doesnt cause an ftbfs again
<rsalveti> I believe it's important as we don't have proper flash support
 * ogra_ would love to use youtube on his ac100 :)
<rsalveti> ok, will create the debdiff and fire up a build at my ppa to see if it all goes well :-)
<sveinse> What is the difference between Ubuntu's 11.04 and Linaro's 11.05 ?
<charlie-tca> Linaro released a month later, since it wasn't ready in April
<sveinse> That's obvious, but what else is Linaro throwing into the box since they have their own release of it
<charlie-tca> !linaro
<ubot2> Factoid 'linaro' not found
#ubuntu-arm 2011-06-23
<srinuprasath> possible to port ubuntu 9.10 to the ARM926-arm v5 ?.....
<Martyn> Not really
<Martyn> you would have to recompile all the ports
<Martyn> not exactly an easy task
<Martyn> you may be better off using debian (although support for v5 will likely be dropped in the not too distant future)
<lilstevie> wow there have been a lot of people asking that latelt
<lilstevie> lately*
<lilstevie> wonder where all these new armv5 devices have come from
<Martyn> not new .. just Marvell
<Martyn> they are stuck at v5 with the PJ5 and PJ6 architecture
<ethics> hi all
<ethics> can ubuntu be ported in arm9
<Martyn> no
<Martyn> well not a 'flat no'
<Martyn> but a 'not without a hell of a lot of work'
<Martyn> since ubuntu (current) has been optimized to work with arm v7
<Martyn> so Cortex A8, Cortex A9, that sort of thing
<Martyn> you can go back and just use debian, however
<ethics> what work should be done to port ubuntu to arm9
<ethics> i have an application that works only with ubuntu 10.04. it works well with x86, now i want to port it in arm 9, is it possible
<ethics27> hi
<Martyn> ethics : You'd have to recompile all the ports repository
<Martyn> ethics: And many packages in 10.04/10.10/11.04 have been specifically tweaked to compile using ARM v7(a) and use thumb2 to compress the code
<ethics> ok
<ethics> how to recompile all the ports, sorry if it is silly
<infinity> You almost certainly don't want to, to be honest.
<infinity> Not unless you have a massive install base of ARMv5 hardware that you intend to support.
<infinity> Cause rebuilding the entire archive "for fun" is decidedly not actually fun.
<infinity> Wait, are we being trolled?
<infinity> lilstevie: I checked scrollback, it's not a suddenly popular question at all, it's come from 4 different nicks all in the same subnet. :P
<Martyn> Ah, well, there you go
<Martyn> ethics, well played.
<lilstevie> infinity: ah, someone is just not happy with the answer they are getting
<Spider-Pork> Hi. Is there a way to get sound working (input and output) on pandaboard with 11.04 headless omap4 version?
<srinuprasath> How to convert ubuntu 9.10 Instruction set version 7 to version 5 (ARM926)
<fairuz> ubuntu instruction set?
<fairuz> I think you mean ARMv7's instruction set?
<srinuprasath> not like that , We need to convert ubuntu 9.10 ARM version 7 to 5
<Spider-Pork> i get a loop error message from console
<Spider-Pork> [  730.415527] omapdss DISPC error: SYNC_LOST_DIGIT, disabling TV
<Spider-Pork> like while(1)
<srinuprasath> How to convert ubuntu 9.10 Instruction set version 7 to version 5 (ARM926)
<lilstevie> srinuprasath, ethics what ever name you are going for this time, there is no point in even trying
<jeremiah1> c
<lilstevie> jeremiah1: ?
<jeremiah1> :)
<srinuprasath> why ?
<lilstevie> we have been over this
<lilstevie> ogra_: I solved that fb issue I was having
<Spider-Pork> is there a way to get arecord working on pandaboard and ubuntu headless 11.04?
<Spider-Pork> I use arecord -Dplughw:0,1 recordtest00.wav . It records without errors but the sound is mute
<Spider-Pork> i enabled with amixer cset the AMIC_UL PDM Switch
<Spider-Pork> and moved MUX_UL11 to Mic0
<Spider-Pork> MUX_UL10 too
<ogra_> did you read the release notes ?
<ogra_> there is a link to an audio bug ... in there it is explained how to get UCM set up for recording
<Spider-Pork> ogra_: this link? https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/746023
<ubot2> Ubuntu bug 746023 in alsa-utils "No sound on omap4" [High,In progress]
<ogra_> yes
<Spider-Pork> thank you ogra_
<lilstevie> ogra_: it was some stupid bootloader thing, I was trying to avoid upgrading bootloaders cause it breaks my commandline param setter
<ogra_> ah
<lilstevie> updated the bootloader, and it works perfectly
<Spider-Pork> ogra_: i applyed the command line workaround
<Spider-Pork> but arecord still return no voice samples
<Spider-Pork> ah lol i'ma donkey
<Spider-Pork> This gets audio out working for me. Audio in is still not functional
<Spider-Pork> nice
#ubuntu-arm 2011-06-24
<NTU> LOL @ ubuntu on ARM!!
<infinity> ...
<infinity> That was constructive.
<lilstevie> infinity: its the little things
<persia> ericm|ubuntu, Good morning.  Quintasan was trying to compile imx-libs against linux-headers-2.6.35-1001-linaro-lt-mx53_2.6.35-1001.1_armel.deb based on guidance from http://boundarydevices.com/blogs/building-gstreamer-plugins-under-ubuntu  and ended up withhttp://paste.kde.org/86929/.  Do you happen to know of more modern (or working) instructions?
<ericm|ubuntu> persia, paulliu knows the detail - btw, can you let Quntasan send email to us, me and pualliu, thanks
<persia> I'll try to convince him.  Thanks for the pointer.
<ogra> soo, seems we have images again
<lilstevie> og?
<lilstevie> tabcomp fail :p
<ogra> and the oversizedness is caused by the fact that the images contain *all* langpacks
<lilstevie> oh dear
<lilstevie> so how does one go about getting a package in universe
<lilstevie> say a kernel
<ogra> you file a bug pointing to the package and then find a sponsor
<lilstevie> ok, sounds easy enough
<ogra> or you get it into debian ...
<ogra> which is the preferred way
<ogra> but might be hard in case of kernels
<lilstevie> would be hard in the case of my tab kernel
<ogra> in any case it would be better to have upload privileges
<ogra> going through sponsoring with a kernel is painful
<lilstevie> heh
<ogra> at least for followup changes and fixes
<lilstevie> yeah that is what I am not looking forward to, with the sponsor method that is
<ogra> neither will your sponsor
<ogra> uploading a 90M package for every change is annoying, finding sponsors for that will not be easy
<ogra> long term i would suggest to earn upload privs
<lilstevie> hm
<ogra> or have someone with these privs in your team that maintains the arch
<lilstevie> that sounds the hardest
<kunguz> Hi all, I have installed Ubuntu arm 11.04 on my beagleboard C3. The thing is usb devices attached to it works in the early stages of booting of the system. But when the booting finishes the usb devices stop working. Any ideas?
<lilstevie> I don't know anyone with upload privs
<lilstevie> ogra: the good news is though I am killing the last bug that affects basic usability since switching up to the new kernel
<ogra> what version are you on now ?
<lilstevie> 2.6.35.7
<ogra> oh, still ancient
<lilstevie> yeah
<lilstevie> but newer
<persia> Finding sponsors doesn't have to be that hard.  I'm almost always willing to sponsor kernel uploads to universe, for example.
<persia> kunguz, Maybe bug #784474?
<ubot2> Launchpad bug 784474 in linux-ti-omap "usb enumeration fail on beagleboard" [Undecided,New] https://launchpad.net/bugs/784474
<kunguz> ubot2: persia seems similar, thank you
<ubot2> kunguz: Error: I am only a bot, please don't think I'm intelligent :)
<kunguz> ubot2: but you are clever one :D
<ubot2> kunguz: Error: I am only a bot, please don't think I'm intelligent :)
<persia> kunguz, I'm not sure that's precisely the bug: it has a decent test scenario written up.  If you can't replicate precisely that way, it's always safest to search a bit more for a bug you can precisely replicate, or file a new one.
 * ogra ponders what to do with the images
<persia> What do you mean?
<ogra> We should have enough space to include all langpacks on the 1 GB armel desktop
<ogra> live images:
<ogra>  * /^language-pack-[^-]+$/ [armel]
<ogra>  * /^language-pack-gnome-[^-]+$/ [armel]
<ogra> that ...
<ogra> (paste from the live seed)
<ogra> seems lool added that back when we still rolled live images
<persia> Let them be oversized for a bit more.  In #ubuntu-devel there was some talk about sorting the internationalisation bit next week.
<ogra> well
<ogra> for live, yes
<persia> There's some reason to have *lots* of languages right now.
<ogra> for preinstalled we likely need some extra code
<ogra> and i dont really want 1G images
<persia> I suppose.
<persia> My suspicion is that the work on making sensible international images will end up reducing that substantially.
<lilstevie> persia: even my galaxy tab 7" image? :)
<persia> lilstevie, *especially* your galaxy tab image.  I would really like Ubuntu to support as many retail devices as we can.
<ogra> ++
<persia> But I'm not a kernel hacker, so all I can do is review other folks kernels, make sure they're packaged sanely, and help them get images from them.
<lilstevie> :)
<lilstevie> well I am within 24hours of a sane kernel
<lilstevie> :)
<persia> For packaging, I'd recommend starting from either jcrigby's scripts or linux-n900 (derived from those)., depending on which makes you more comfortable.
<ogra> persia, note that the hack above is armel only, no other arch ships all langpacks
<persia> I'm within 24 hours of my weekly "ignore IRC traffic for 20-30 hours" time, but I'd be happy to upload later in the weekend.
<lilstevie> tbh I will need a bit of help with the packaging, the only debs I have ever packed have been for apt on arm-darwin
<persia> ogra, So, we should undo that.  I'm still not tempted to undo it until we understand the i10n plan.
<ogra> well, i'm happy to go with the defaults all arches use
 * ogra drops the lines from the seed
<persia> If you want to have a seed commit today, I'm 100% in favour of doing anything to make armel less special in the seeds.
<persia> I just expect that we'll have to fiddle it again later.
<ogra> why ?
<ogra> we will inherit whatever desktop does
<persia> lilstevie, I *may* have time on Sunday, depending on your timezone, etc.  If not, I'll try to catch you as soon as I have time.
<lilstevie> :)
<persia> Because preinstall != live.
<lilstevie> well it is 8:15pm friday here :p
<persia> Ah, a *good* timezone :)
<lilstevie> :)
<ogra> persia, well, the only difference is casper vs jasper
<ogra> we use the live seed on preinstalled
<persia> So, yeah, there's a chance I'll have time Sunday evening then.
<ogra> seed change pushed
<ogra> lets see how much that saves
<ogra> i guess we should come out below 800M now
<persia> Given that there is a *new* method of doing internationalisation in the works, I'm expecting *both* jasper and casper to need adjustment, along with live-build configu.
<persia> But yeah, for the weekend, we can have smaller images.
<ogra> well, desktop will not go to bigger images for now
<persia> lilstevie, Be aware that the release manager has all sorts of requirements for generating images.  In practice, this typically means that if we get a kernel into the archive in one cycle, we can have proper images the *next* cycle.  That said, if your kernel is good enough, and there are testers, etc.., we may be able to work around that.
<ogra> so they will rather drop langs than add
<persia> It's changing.
<ogra> not yet
<persia> Stuffing bundles of langs into a single image may not be how it is done in the future.
<ogra> as i understood we still go for 700M in oneiric
<persia> And there is no way to have any idea about this until next week.
<lilstevie> persia: heh I don't think we will be working around that
<persia> Yes, oneiric images will be 700M.  Nonetheless, per-locale customisations are happening in a *completely* different way than in the past, and much more comprehensively, which likely has implications about how locale-specific code ends up in default images.
<persia> lilstevie, Fine by me, as long as you don't mind it being a remix for 11.10.
<ogra> i dont care about customizations :)
<ogra> only about the default image
<persia> If there are enough users, etc. then we can apply to have proper images for 12.04.
<persia> Yes.  Please read my last sentence again.
<lilstevie> persia: that said I always tend to understate my stuff
<lilstevie> persia: my problem is the lack of hardware support
<persia> lilstevie, It's a geographical limitation.  You're just following your peers.
<lilstevie> heh
<lilstevie> persia: well there already have been some testers just FYI
<lilstevie> on the utouch team
<persia> More folk always help, but we're going to need someone to commit to the milestone testing, which basically means being nearly continuously available (for respins) for ~3 days for each milestone release to ensure image quality.
<persia> And that usually requires user numbers in the 100s, unless one happens to get lucky and catch a great tester early.
<lilstevie> hm, well I don't know about 100s :/
<persia> Heh, yeah.  That's part of why it's sensible to start slowly.
<persia> If you make something great, and then you tell your users that someone has to volunteer to help test in order to continue, you'll either get a volunteer, or you'll have confirmation that there isn't enough interest.
<lilstevie> heh
<ogra> hmm
<ogra> so how do i make preinstalled images use the oem user
<ogra> should that be created at image build time or by jasper
<persia> By jasper.
<ogra> why ?
<persia> To parallel casper, and keep live-build config more similar.
<persia> (yes, there's messiness now, but I'd rather clean that up than add to it).
<ogra> well, do you see a reason why preinstalled images shouldnt have an oem user and oem-config enabled by default
<persia> Remastering.
<ogra> i actually think that code should move into the build process
<persia> For live also?
<ogra> no
<persia> OK.  Why should live and preinstall be different?
<ogra> well, for remastering its actually an advantage
<ogra> because they are totally different things by design
<ogra> preinstalled images will always have oem-config installed
<ogra> so why not enable it by default (including the user)
<ogra> wrt remastering ... if you dont use the jasper initrd, you are screwed today
<persia> Why?
<ogra> because jasper enables oem-config
<persia> I know of people who have extracted the rootfs from a preinstall, generated a *different* initrd, and used it on devices.
<ogra> i know of people trying to use our preinstalled rootfs as is but without initrd :)
<persia> Heh.
<ogra> if you only want the rootfs then you have to manually fiddle with it to get oem-config up
<lilstevie> I had to manually touch /var/lib/oem-config/run
<persia> So the basis of my argument is mostly "There should be no difference between live and preinstall".
<ogra> i.e. you have to do all the bits jasper does to the rootfs
<persia> But I can see the argument "There should be no difference between preinstall and the results of booting live and performing an orm install".
<ogra> jasper should *only* care about partitioning and resizing
<ogra> and the peripherial bits that includes like bootloader config and fstab creation etc
<ogra> i want to get all unrealted hacks out of the code
<persia> OK.  I can accept that.
<ogra> enabling oem-config is one
<persia> And jasper might end up going away completely, replaced by spices, or similar.
<ogra> and we dont even do it right atm
<persia> (or be the instrument of spice implementation)
<ogra> you will always need the resize on boot bit
<persia> Right.  You've convinced me.  oem-config should be enabled by live-build.
<ogra> which in turn means you will need to create fstab and bootloader config at the same time
<ogra> that cant be handled by seeds only the package can be pulled in or be omitted by seeds
<ogra> i dont expect jasper to go away as long as we have the resizing
<persia> Ah, and if jasper is pluggable, fstab can be generated dynamically, and bootloader config can be done by spice insertion to some conf.d.
<ogra> well, bootloader config is something that should better live in flash-kernel-installer ... but that will require more changes
<ogra> since its only available in udeb form atm
<persia> We could add it to oem-config.
<persia> Or, no, you need it earlier, don't you.
<ogra> no
<ogra> well
<ogra> yes
<ogra> heh
<ogra> tricky
<ogra> i need a change of the cmdline earlier
<ogra> not necessarily a full new setup of the bootloader
<persia> We already did the work to have a ubiquity controller for flash-kernel-installer, so it would be handy if we didn't need it until oem-config runs, but because we need it early, jasper has to do it.
<ogra> the actual setup could be done by oem-config
<ogra> but that wouldnt get rid of bootloader code in jasper
<persia> If we're going to have bootloader code in jasper, let's use flash-kernel.
<ogra> thats what it does ... just not for the setup
<ogra> i.e. the generation of config
<persia> flash-kernel-installer won't generate the config?
<ogra> flash-kernel-installer isnt existent in jasper
<ogra> i would have to pull it into the initrd
<persia> Not all of it.
<ogra> with a big penalty (lots of different bootloader deps)
<persia> So, the way ubiquity does it is to embed the flash-kernel source in the ubiquity source, and then copy flash-kernel-installer.postinst to somewhere useful when building the binary.
<ogra> by current design, all of it
<persia> It then calls that script to do the setup.
<ogra> i know how ubiquity works
<ogra> (i worked on that code too)
<persia> Can't we do the same thing for jasper?
<persia> And inject only the bootloader support demanded by the spice?
<ogra> yes, but to keep it generic you would have to pull all bootloader tools into the initrd
<ogra> that will get huge
<persia> Yeah: just refreshing both our memories to make sure we're talking about the same thing :)
<persia> We don't need generic at that point: this is what spices are supposed to do.
<persia> That's the entire point of the two-stage image build process.
<ogra> well, thats not how flash-kernel-installer is workigng currently
<ogra> so that would need some massive redesign
<persia> I thought that flash-kernel-installer simply assumed that everything was present, but then only called the bit it needed for the board it was using.
<ogra> modularization ... and support for initrd
<ogra> flash-kernel-installer *makes* everything present
<ogra> thats part of its job
<ogra> it chroots and installs the bits and pieces for the currently used arch
<persia> Yes, but that's the dependencies.  flash-kernel-installer.postinst doesn't do that on it's own, does it?
<ogra> which means you need support for *all* arches in the ship seed
<persia> And flash-kernel-installer.postinst is *designed* to run from an initrd (the d-i environment)
<persia> Why?
<ogra> flash-kernel-installer.postinst chroots and calls apt_install
<ogra> flash-kernel-installer.postinst is not designed to be run from an initrd
<ogra> it is designed to be run in d-i context
<persia> The d-i context *is* an initrd, but we stray :)
<ogra> it expects certain d-i copmponents to be there
<persia> It calls apt_install for *everything*, rather than just the currently-detected platform?
<ogra> no
<persia> Right.
<ogra> its doable but as i said in the beginning it takes a lot of changes
<persia> Ah. because in the preinstall context, we don't have a chroot.  Right.
<ogra> and essentially a complete redesign of flash-kernel-installer
<persia> Let's not do that.
<ogra> we do have a chroot
<ogra> from initrd
<persia> So, why do we need to change anything?
<persia> apt_install is a no-op if the package is already installed.
<ogra> if we want to use it out of context we need to change it
<ogra> apt_install doesnt *exist* in  non d-i initrds
<ogra> there are plenty of calls to d-i tools in the scripts
<ogra> you cant just dump it into an initrd
<ogra> it wouldnt run
<persia> Ah, so we'd end up embedding all sorts of things, essentially duplicating ubiquity, and we'd get all sorts of annoyed trying to maintain it.
<persia> Right.
<ogra> yeah
<ogra> so it would have to become more modular (so you only pull in the snippets you need at initrd generation time) and would need a layer that can switcfh between d-i tools and normal initrd binaires
<persia> So, we have flash-kernel available in the chroot, right?  And whatever bootloader support bits we need for the target?
<ogra> and you would need arch specific hooks in initramfs tools so you can select which bootloader tools go into the initrd
<persia> Oh, but that won't generate the initial configuration.
<ogra> right
<persia> No I don't.
<persia> I can control that by which packages I happen to have installed at initrd generation time.
<ogra> the first change of the cmdline is the bit
<ogra> for the actual final initrd we can actually use flash-kenrle-installer
 * persia wishes someone would port grub2 already, *again*
<ogra> *kernel
 * ogra doesnt :P
<persia> flash-kernel-installer, or flash-kernel?
<ogra> the former
<ogra> from oem-config
<persia> Oh, right.  Because that gives us a d-i context.
<ogra> right
<persia> So, really, we just need to be able to boot *this one time*.
<ogra> its only the jasper bits
<ogra> where i parse the cmdline and adjust it after resizing
<persia> So, I don't believe there's a generic way to change the commandline.
<persia> We've different requirements for different bootloaders.
<ogra> not generic, but pretty generic
<ogra> we currently support what, two bootloader variants in ubuntu ?
<ogra> u-boot and abootimg
<ogra> redboot is gone from teh achrive and from flash-kernel since a few days
<ogra> (and from d-i)
<persia> Yeah.  I have to add some of it back one of these days, if I ever get around to upgrading my netwalker (I kinda wish someone would come out with a satisfactory replacement I could just buy instead).
<persia> But what I'd add back for redboot is *completely different* from what was there, so that's not strictly relevant.
<Daviey> ogra: Do you know if PXE boot is likely going to be an option for next?
<persia> And there's the messiness for the Nokia devices, but that's something else.
<Daviey> (or anyone else)
<persia> Daviey, "next"?
<ogra> Daviey, the code is in our oneiric u-boot package
<ogra> Daviey, we'll run some tests next week
<persia> Daviey, You want to watch https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-o-uboot-pxe-support andhttps://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-o-uboot-initial-usb-tftp-support-panda
<persia> Supposedly, as part of those implementations, we'll end up with docs that describe how to enable PXE for arbitrary u-boots (needs device driver porting) as part of that delivery.
<ogra> persia, yeah, well, we largely dropped imx51
<ogra> and all bootloader code it had
<ogra> or better lool dropped i just nodded :)
<persia> Except for the netwalker, all the i.MX devices I have use u-boot.
<ogra> yup
<ogra> most future devices will use fastboot i suspect
<persia> Dunno.  u-boot has a lot of following, and Freescale supports it.
<ogra> if we cover these two we should be largely generic ;)
<persia> (plus, we *could* have grub2, and not have to worry about any of this mess)
<ogra> pfft
<ogra> unlikely that you get the vendors to support it
<Daviey> Ah lovely!
<ogra> took long enough to get most of them to u-boot
<Daviey> ogra / persia: we might be pestering you next week. :)
<ogra> we hope so !
<Daviey> Thanks! :)
<persia> Anyway, for supporting two bootloaders, should that be pluggable?
<persia> Have the bootloaders provide some file that, when jasper is installed, jasper uses to define *how* to change the cmdline?
<persia> That's likely more compatible with spices than jamming everything in jasper and hoping the initrd doesn't overflow.
<lool> I actually think we should consider grub as a third stage bootloader
<ogra> lool, what would be second stage ?
<persia> lool, I'd love to have a discussion about why we shouldn't use grub as *second* stage, but I really want to figure out the design for pre-oem-config booting first :)
<lilstevie> I'd love to see grub2 for arm
<persia> ogra, So, pluggable, or bundle-everything-in-the-initrd and hope we don't get too many bootloaders?
<ogra> persia, well, on the ac100 i have exactly 4M for the initrd
<persia> That's a good argument for pluggable :)
<ogra> every byte above makes the system oops
<persia> So we have /usr/share/jasper/bootloaders.d/*.conf, and we source that, and then call "fix_command_line()" ?
<ogra> something like that
<persia> Oh, right.  initrd.  Change the names :)
<persia> And then we add the magic file to abootimg and u-boot.
<ogra> right
<persia> So, here's the worry.  The magic file will end up in the initrd after jasper is purged.
<persia> Do we care that much?  They should be very small.
<ogra> why would it ?
<persia> Because it lives in the bootloader package.
<ogra> oem-config runs update-initramfs after jasper is removed
<persia> Right, but that won't remove the files from the bootloader packages.
<ogra> but the hoooks that would install it to the initrd
<ogra> s/it/them/
<ogra> the files live in the filesystem, but not in the initrd if no hook installs them
<persia> Aha, so it *would* be somewhere like /usr/share/jasper/... and then jasper would provide the hooks for initramfs-tools, which would be purged on jasper-purge, which would result in the magic files not being in the initrd when update-initramfs is called?
<ogra> well, in /usr/shar/initramfs-tools/hooks, but yeah
<persia> Well, the hooks go there, but the bootloader implementation files?
<ogra> the hooks define what ends up in the initrd
<persia> Yes.
<ogra> actually /usr/shar/initramfs-tools/hooks/jasper does
<persia> But in order to end up in the initrd, stuff has to be in the filesystem.
<ogra>  /usr/shar/initramfs-tools/hooks/jasper is part of the jasper package
<ogra> the bootloader config templates can come with the bootloader
<persia> And the bootloader packages need to deliver the implementations to the filesystem to ensure we don't have multiple (assuming we didn't spice the image to have multiple).
<ogra> right
<persia> Right.  I'm suggesting that the bootloader config templates should be installed to /usr/share/jasper/bootloaders/ or similar.
<ogra> but they wont end up in the initrd ever if /usr/shar/initramfs-tools/hooks/jasper is gone
<persia> Where jasper ships either an empty directory or a directory containing only .placeholder to support this.
<persia> Right, which is the correct behaviour.
 * ogra wishes he would find out why this 4M limit exists on the ac100
<persia> Insufficiently hackable bootloader.
<lilstevie> ogra: partition size?
<persia> lool, So, why wouldn't we want grub as second stage?  Wouldn't using it as third stage add ~8 seconds to boot time?
<lool> persia: I'm not sure where the 8 seconds are from
<lilstevie> ogra: is the ac100 fastboot?
<persia> Random guess on my part to load grub, detect time, timeout, and load the kernel.
<persia> lool, To put that another way, if we're loading grub2, why wouldn't we want that to be second-stage?
<lool> it's a bit of a complex story; we could discuss it next week if you like; first, you often need a SPL which just loads the real bootloader into the initialized RAM
<lool> then you need a bootloader which does good stuff, this could be grub; but we're already at the TPL
<persia> TPL?
<lool> invented that one just now for tertiary or third program loader  ;-)
<lool> SPL being secondary program loader
<persia> Right.
<lool> the second stage loader is hard for various reasons
<lool> first, it's extrenely device specific; it's hard to make it generic
<lool> second, it needs to be extremely small
<persia> So, for example, on beagle, we do ROM -> FPL (xloader) -> SPL (uboot) -> TPL (linux), right?
<lool> no, ROM is first stage
<lool> xloader is a SPL
<persia> Ah, OK.
<persia> So you want ROM -> (something) -> grub2 -> linux ?
<ogra> lilstevie, yeah
<lilstevie> ogra: wonder if it is bootloader related, or if it is partition size
<lilstevie> fastboot is a pita
<ogra> i'm pretty sure its bootloader related
<ogra> it seems to be related to the unpacked size
<lool> persia: that's right; the something could perhaps be UEFI related  :-)
<lilstevie> ogra: oh
<ogra> i.e. i can squeeze more into a bz2 or lzma initrd, but that will cause an oops
<persia> lool, Right.  We completely agree, but were previously using different nomenclature.
<lilstevie> ogra: so maybe its memory hole isnt big enough
<persia> I also want grub2 as TPL.
<ogra> lilstevie, right
<lool> persia: also, "something" might need to be in two pieces itself
<ogra> in *some* pieces :)
<lool> so grub 2 might be QPL or something  :-)
 * lool lunch
<lilstevie> ogra: FYI memory layout from bootloader is what was causing my issue too, turns out the drivers for 2.6.32 expected FB mem to be at 1 address and the new bootloader has the memory location offset a bit highre
<lilstevie> higher*
<persia> lool, I'd really prefer a less capable *something* than a split one.  For example, u-boot is often no longer used as SPL beause it has too many features to fit in the small memory barriers, but realistically most of those features aren't needed if handing off to grub2.  The same applies, only moreso, for UEFI.
<ogra> often used as ?
<ogra> u-boot *is* an SPL, no ?
<persia> ogra, For panda, it's TPL.  xloader is SPL.
<ogra> well, yeah
<ogra> for panda
<persia> (according to the nomenclature lool and I are using for this discussion)
<ogra> usually its SPL though
<ogra> omap is special since it doesnt fit enough into its rom apparently :)
<ogra> else x-loader would just live on the board
<ogra> preinstalled in rom
<persia> No.
<persia> x-loader is just a trimmed u-boot because u-boot can't all fit in the environment started by the ROM.
<ogra> thats what i said, just the other way round :)
<persia> But nearly *every* ROM boot code ends up just jumping to somewhere to do setup, and isn't nealy as complex as e.g. x-loader.
<ogra> in non omap boards that bit lives in rom
<persia> No.
<persia> So, ROM always just does a jump to somewhere after absolute minimum startup.
<persia> But ROM is *never* complicated.
<persia> (this is FPL).
<persia> Depending on the capability of the ROM, it *may* have enough of an environment to use u-boot as SPL, but it may not.
<ogra> rom inits ram, loads the BL and jumps to it
<ogra> in case of omap the initialized ram is to small
<persia> If one enables *all* the features in u-boot it's fairly easy to end up with needing something else as SPL.
<persia> hence the comment above '"something" might need to be in two pieces itself'
<ogra> i didnt debate that :)
<ogra> i just said that generally u-boot is SPL by design
<persia> My contention is that u-boot is an operating environment that neither knows nor cares where it's loaded.
<ogra> that we deal with the special case of omap doesnt change that fact
<persia> It could be PPL and be happy.
<persia> (rom -> uefi -> grub -> linux -> u-boot, for example)
<ogra> well
<ogra> you could: rom -> linux
<ogra> that doesnt make the kernel an SPL :)
<persia> Sure.
<persia> Yes it does.
<ogra> for that particular case, yeah
<ogra> but not generally
<persia> I don't happen to think it's a particularly *good* SPL today.  Needs *lots* of work.
<persia> But some folk use it that way.
<ogra> if you talk to linus you wont talk about his coll SPL
<ogra> *cool even
<persia> So, I agree that u-boot is often used as SPL.  I'm just arguing that there isn't anything about u-boot design that makes it especially suited for that role.
<ogra> apart from its design as SPL you mean ?
<ogra> *g*
<persia> I might, actually.  I happened to be discussing boot loaders last time I was in the same room as Linus (although not with him)
<ogra> thats something else
<persia> So, what about the u-boot design allows it to even *tell* in which layer it's running?
<ogra> you could discuss u-boot as rootfs with wolfgang
<persia> I believe it can't.
<ogra> wouldnt change its default purpose
<persia> So, I just looked at the u-boot design documentation.  It explicitly lists several different use cases, and completely fails to mention anywhere at which point it belongs in the boot process.
<persia> But I also don't care enough to keep banging on the difference between "some" and "any" in specific application to bootloader purposes any longer.
<persia> On the other hand, I completely fail to understand the point of x-loader: u-boot is claimed to support devices with 128K RAM.  Does OMAP really not have that much on startup?
<ogra> i think its half of it, not 100% sure
<persia> 64K!!!!!
<ogra> but even if you had 128 ...
<ogra> you would have to rip out many important features from u-boot to make it fit
<ogra> especially the hush shell support adds a lot
<persia> If I'm using u-boot as an SPL and loading a real boot loader (e.g. grub), that's fine :)
<ogra> without it we lose .scr support
<persia> That's fine.
<ogra> no, its not
<ogra> you would have to recompile to change the cdmline
<persia> Why not?  .scr support is just a dirty hack we tossed together because we didn't have a good bootloader.
<ogra> no
<persia> No you wouldn't, because your TPL would set it dynamically.
<ogra> its a design feature of u-boot
<ogra> nothing we put together at all
<ogra> we just use it
<persia> You and I are using different definitions of "we" here.
<ogra> we as people in this chatroom :)
<ogra> (awake or not)
<ogra> scr support comes from upstream
<ogra> anyway, your u-Ã¶boot would be pretty limited if you would have to fit it in 128k
<persia> I'm not willing to assert that nobody who occasionally follows #ubuntu-arm works on u-boot upstream, but we're off-point.
<persia> Right, which is *fine* if I'm using it as SPL.
<persia> As long as I have a capable TPL.
<ogra> define capable :)
<ogra> apparently linux isnt capable as TPL in the omap case
<ogra> as long as x-loader is needed to actually initialize subsystems like usb
<persia> Can detect attached bootable media, and dynamically generate command lines (perhaps based on on-disk configuration) to load QPL from that media.
<persia> The problem there is that x-loader isn't a good enough SPL to get things working.
<ogra> only if x-loader is your SPL :)
<ogra> wrong way round :)
<persia> Due to long history of using xloader + u-boot, bring-up patches were randomly distributed between the two.
<ogra> x-loader is abused for initializing bots the kernel should initialize
<ogra> *bits
<ogra> not two ... sadly three
<persia> So, every image should probably reinitialise everything.  Not doing so is likely a bug.
<ogra> x-loader, u-boot and kernel
<ogra> image ?
<persia> executable image that is loaded.  *PL.
<ogra> stage :)
<ogra> but you dont need to initialize everything ...
<persia> So, I accept that all FPLs must suck, by design.
<ogra> x-loader only needs ram and the device it pulls the bootloader from
<persia> I want my SPL to turn on all my hardware.
<ogra> which as i said above should actually be the job of the rom
<persia> I want my TPL to use that hardware to figure out how to boot.
<persia> And I want my QPL as my default operating environment.
<persia> I just don't happen to like the current SPL and TPL.
<lool> persia: Note that u-boot is being used increasingly as a SPL rather than the reverse -- but split in two stages
<ogra> they can be merged though
<persia> lool, Hrm?  So *both* SPL and TPL?
<lool> yes
<lool> with different configs
<persia> Right.
<persia> I should have said that u-boot is seeing increased use as a TPL, rather than saying it was seeing decreased use as SPL.
<lool> it takes some efforts to bring u-boot down to a size where it can be used as SPL
<lool> there are also various platform specific things which prevent it; secure boot is one example  :-/
 * persia vaguely wonders if the sequence "F, S, T, Q, P" has ever been used for cardinality before, considering that it doesn't match *anything*
<persia> How does secure boot prevent u-boot as SPL?  Can't one just sign some known perfect SPL u-boot?
<lool> there are many reasons; first, basing on u-boot has less advantages since other people can't necessarily deploy it
<persia> Or is it that the secure boot implementation must necessarily be the SPL?
<lool> second, the GPL is a problem for some people
<lool> third, the secure boot bits are often developed in R&D before considering u-boot
<persia> Oh, right.  Depending on the IP involved in the secure boot mechanism...
<persia> Now, you suggested UEFI as SPL: does that address any of these aside from the GPL issue?
<lool> persia: If you're interested, we've started some long term boot architecture discussion on the boot-architecture@llo list and on weekly calls
<persia> I'm interested, but I'm not sure I can dedicate that much time.  My opinions are mostly driven by user experience, but I think those are shared widely enough that repetition in that forum won't help.
<persia> Although I'm glad to know it's happening, and will likely browse the ML archives once in a whle.
<lool> So by UEFI I don't mean one specific implementation of it; we'd likely focus on tianocore ourselves for some boards, but each vendor could provide other compatible implementations
<lool> they could even be basaed on GRUB, albeit that's extremely unlikely
<persia> Heh, indeed.
<persia> From prior exposure, I just thought that UEFI tended to be large, which might cause some of the same issues as for u-boot as SPL.
<persia> Ah, so the goal of the boot architecture discussions is to have some spec that clearly separates IHV and OSV roles.  I *really* like that.
<persia> And I completely agree that it makes sense to *not* specify specific payloads, etc., but rather just specify how the payload is accessed.
<persia> s/specific/particular/
 * ogra sighs about firefox in oeniric
<ogra> oh, sweet
 * ogra likes software-center 
<lilstevie> ogra: ?
<ogra> i didnt know it asks you if it should add a new app you install to the launcher
<lilstevie> nice
<lilstevie> what about firefox?
<ogra> and while the app installs you can read reviews
<ogra> its slow, clunky and leaks memory
<ogra> i'm just installing chromium ;)
<lilstevie> heh
<lilstevie> I have been using chromium on my tab
<kunguz> After a while, my usb mouse stop working on ubuntu-arm installed on beagleboard c3, any suggestions?
<persia> kunguz, Is there anything associated with it stopping?  Anything in the syslog?  Changes in /dev/input/*, etc.?
<kunguz> persia: actually on the serial port, there is no output from beagleboard and I can not use any other device.
<kunguz> persia: I can check the mmc card on other computer for the syslog
<persia> kunguz, That sounds like a system freeze to me, rather than just the USB mouse stopping.  Why do you suspect the USB mouse?
<kunguz> persia: the same thing happend during the installation but the installation proceeded and completed with success
<kunguz> persia: for example if I wait long enough the system shows a blank screen saver
<persia> OK.  Do you have any other input devices (keyboard, etc.)?
<kunguz> persia: only mouse at this moment
<persia> Nothing happening on the serial port is normal.
<kunguz> and an unrecognised wireless adapter
<persia> Hrm.  Debugging one's only input device is tricky :)
<kunguz> persia:  now I am trying to reboot it only with an USB mouse attached.
<kunguz> persia: by the way I am using an usb hub
<kunguz> persia: so to say only devices attached are screen, an usb hub and an usb mouse.
<persia> That makes it more likely to work :)
<kunguz> and in my beagleboard it takes like 5 min. to open the whole system
<persia> Which image are you booting?
<kunguz> persia: http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz
<kunguz> this one
<persia> Ah.  The only reason I boot that on my beagle is to remove lots of stuff.  I really doesn't perform very well with that little RAM.
<persia> (I also have a C3)
<kunguz> persia: is there a lubuntu-arm available?
<persia> Try http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-headless-armel+omap.img.gz
<kunguz> persia: gnome is a bit too much for beagleboard
<kunguz> persia: what is this headless?
<persia> I don't know of such an image.  If you install headless, you can `apt-get install lubuntu-desktop`
<kunguz> persia: oh i see thank you very much
<persia> It's a minimal image, so you can install just the stuff you want.
<kunguz> persia: that looks nice, so I am trying it
<ogra> you better install the task though
<persia> Good luck.  I don't consider this to be a step towards debugging your USB mouse issue (if you have one), but I don't think we *can* usefully debug it with no keyboard and such sluggishness.
<ogra> sudo tasksel install ubuntu-desktop
<ogra> or so
<kunguz> ogra: task?
<persia> Or lubuntu-desktop, rather, in this case :)
<ogra> or that
<kunguz> ogra: ok I am trying
<persia> But I don't think lubuntu-desktop has a task for natty.
<persia> Better to use apt-get and install the metapackage in this special case.
<ogra> no, lubuntu was just added as a task today
<ogra> so its only in oneiric
<persia> Right.  The meta landed in maverick, I think.
<ogra> yep
<ogra> well, indeed, in this case the package is better
<persia> In general, it's better to use tasks.
<kunguz> persia: http://www.sudrap.org/paste/text/14408/ , that's what keeps happening when usb failes
<persia> Oh, excellent!
<persia> File a bug.  Be sure to include specifics about your hub and mouse.  lsusb -vv output is probably helpful.
<persia> When I have issues like that, I generally try to change my USB routing (move devices and hubs around, swap hubs, etc.).  That said, I've never seen that on my beagle, so it may be something different than the issue I work around.
<Spider-Pork> Hi, i've ubuntu 11.04 headless installed in my pandaboard. It can play correctly sound but if i record, the file will contain only mute sound. I know there is an issue about alsa, thre is a way to get arecord run correctly? Thank you
<Spider-Pork> I sownloaded and compiled latest stable packages of alsa
<Spider-Pork> *downloaded
<ogra> did you read the bug i pointed you to ?
<Spider-Pork> yep ogra
<ogra> so you are using an mp3 player as input ?
<ogra> and have enabled the Record verb ?
<ogra> as described in the bug
<ogra> and it still doesnt work ?
<Spider-Pork> sorry for paste
<Spider-Pork> sudo alsaucm set _verb HiFi sudo alsaucm set _verb Record sudo rm /var/lib/alsa/asound.state sudo reboot
<Spider-Pork> nope for mp3 player
<ogra> right, that enables all driver bits
<Spider-Pork> i do it now
<ogra> the input is wired as line in ... mics wont work
<Spider-Pork> ok thank you ogra
<Spider-Pork> i'll try with an mp3 player
<ogra> note that you might have overwritten alsa stuff with your self compiled stuff now
<Spider-Pork> and a male/male 3.5 cable
<Spider-Pork> ah
<ogra> so no guarantee it still works :)
<Spider-Pork> if it will not works with mp3 player i will reinstall from zero
<Spider-Pork> aplay sounds good
<Spider-Pork> ogra: is there some route must be enabled with alsamixer?
<Spider-Pork> to record i mean
<ogra> no
<Spider-Pork> ok
<ogra> the defaults should just work after you issued the two alsaucm commands
<Spider-Pork> ah ok
<ogra> they do for everyone else at least
<Spider-Pork> but maybe not for me
<ogra> though you said you are using headless, not sure how well that works without pulse in the loop
<Spider-Pork> ok
<ogra> we only test such stuff on the desktop/netbook images
<Spider-Pork> so maybe i can try to install pulse too
<Spider-Pork> pulse on your repo
<Spider-Pork> http://people.canonical.com/~ogra/natty-omap4-pulse/
<ogra> no
<ogra> thats outdated testing crap
<Spider-Pork> ah ok
<ogra> the pulse in the archive works just fine
<Spider-Pork> ok thank you ogra
<infinity> apachelogger: I hear you have an iMX53 Quickstart that does fancy things like boot?
<apachelogger> yes
<infinity> apachelogger: Did you use the provided Ubuntu-esque micro-SD from Freescale, or did you have to homebrew something to make it work?
<apachelogger> infinity: https://wiki.ubuntu.com/ARM/iMX53QuickStartBoard
<infinity> apachelogger: Yeah.  I've been pointed to that.  Was curious if anyone's booted one with the SD Freescale is now shipping.
<apachelogger> FWIW the default microsd image did not manage to bring up VGA for one reason or another
<infinity> apachelogger: But I guess I'll try the crazy homebrew method.
<apachelogger> I replicated the image and it worked
<apachelogger> which is also pretty simple
<apachelogger> just get the image tar.gz from freescale and follow the guide that is shipped inside the tar
<infinity> apachelogger: Not bringing up VGA, I'd be okay with, but the default image doesn't seem to give me serial either, so I have no way of knowing if it's doing... Anything.
<apachelogger> well, recreating the image definitely works
<infinity> Kay.
<apachelogger> infinity: http://i.imgur.com/WTJbh.jpg
<infinity> Where do I get this freescale tgz?  I only see linaro links on the wiki.
<apachelogger> that is running the ubuntu image
<apachelogger> infinity: freescale's quickstart board site
<apachelogger> there is a downloads section
<persia> apachelogger, So, one potential candidate for what is "wrong" with the 2.6.38 image is that the 2.6.35 kernel is a BSP kernel, and has *all* the patches, whereas the 2.6.38 kernel is a targeting-mainline kernel, and so doesn't have as many ugly hacks.
<apachelogger> persia: that adds kernel patch issues to the list of possible causes for not working EGL init :S
<persia> Indeed.  So, Quintasan was talking with paulliu about stuff, and paulliu is working on linux-linaro-lt-mx5, which is 2.6.35
<persia> But the shiny is linux-linaro-mx5, which is 2.6.38
<persia> The *lt* kernels aren't in Ubuntu, and aren't likely to be.
<apachelogger> persia: I see
#ubuntu-arm 2011-06-25
<Spider-Pork> Hi. If i boot for the first time the 11.04 netboot installer i can't see anything on my DVI monitor. Need i to modify the initial boot script?
<Spider-Pork> Morning ogra
<Spider-Pork> Still have no sound while recording with netboot 11.04
<Spider-Pork> using it as line-in and after had apply these commands https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/746023
<ubot2> Ubuntu bug 746023 in alsa-utils "No sound on omap4" [High,In progress]
#ubuntu-arm 2011-06-26
<MrCurious> (stk) :line disk installation timed out
<MrCurious> that look familiar to anyone?
<persia> lilstevie: Good evening.
<lilstevie> ,good evening persia
<persia> How did your aattempt to port the kernel go?
<lilstevie> oh that was done long ago :p
<lilstevie> it is fixing up the new kernel
<lilstevie> I am still fighting the bug :/
<persia> For the Galaxy?
<lilstevie> but I think it may have been evdev that was acting retarded, it was the natty alpha image and i didnt realize
<lilstevie> galaxy tab yeah
<persia> Oh, cool
<persia> Do you have time this ewvening to work on getting a package in for oneiric?
<lilstevie> yeah, just let me put the washing away :)
<persia> NO rush :)  Let me know.
<lilstevie> :)
<lilstevie> ok now lets see if with the new rootfs if the bug goes byebye
<persia> Heh
<persia> lilstevie: I Have to head away for a bit, but I'll be back shortly.
<lilstevie> persia: kk, well I will be up most of the night
<lilstevie> natty final preinstall seems to be a bit better overall
<persia> lilstevie: Oh, excellent.
<persia> so, for packaging it, Let's start from the linux-n900 source.
<lilstevie> persia: I will have to go with the how for now :) this is still being a pain, the new evdev doesn't like my touch driver at all :/
 * lilstevie is starting to wonder why he even bothered changing to the new kernel
<persia> Oh, annoying.
<persia> So, how works like this:
<persia> 1) get your kernel working
<persia> 2) stuff the source into a package with deba
<persia> err, debian.flavour/ and debian/ (look at linux-n900 for an example)
<lilstevie> ok
<persia> 3) Build, and fiddle the flavour bits until the result is clean
<persia> 4) upload
<lilstevie> upload anywhere specific?
<persia> No :)  Theoretically to Ubuntu, but since you still need a sponsor, anywhere from which the sponsor can pull for review works.
<lilstevie> heh :)
<persia> The sponsor will need the .dsc and tar.gz files.
<lilstevie> ok cool
<persia> But
<persia> But step 1 is the most important :)
<lilstevie> heh yeah I am wokring on solving these issues
<lilstevie> blah, this should be working
<persia> What doesn't work?
<lilstevie> evdev
<lilstevie> my beautiful touchscreen patch is not working like it should
<persia> Do you get propertties to xinput, or can you just not see the events in the first place?
<lilstevie> the cursor isnt moving
<lilstevie> but everything is as it should be with evtest
<persia> Right.  Does xinput --list-props show it as a mouse?
<persia> If evtest has the right output, the kernel stuff is very likely correct.
<lilstevie> heh it shoud be, it is the same result that I was getting under maverick
<persia> There wqas a bunch of touch stuff done for natty: I suspect that the issue is that it *is* being detected as touch.
<lilstevie> it is detected as a touch screen
<lilstevie> like it was under evdev in maverick
<lilstevie> cause it is a touch screen :p
<persia> And then it gets caught in the touch handler, and ends up not working like a mouse.
<persia> Which makes the pointer not move :)
<lilstevie> heh
<persia> So, My recommendartion would be to get the satck into the archive, file a bug.
<persia> Then we can bug the touch folks to eplain the stack and help us fix the bug :)
<lilstevie> I will talk to chase again I think
<lilstevie> this touch driver wouldn't even work if it wasn't for the touch team :D
<persia> cnd is definitely the right person :)
<persia> Good luck.
<lilstevie> they helped me figure out what i needed to do months ago :p
<lilstevie> when maverick was current
<lilstevie> heh, chase has been a great help with everything, natty is the problem here though :(
<persia> I don't knmow if we can fix natty, but oneiric is a real possibility.
<lilstevie> heh
<lilstevie> biggest thing is to find out what is broken :)
<persia> yeah
#ubuntu-arm 2012-06-18
<ndec> infinity: re: SGX for omap3/armhf. i don't know ;-(
<infinity> janimo: *poke*
<infinity> janimo: Any chance you'd have some Ubuntu time this week to look at why mono on armel is broken?  It's starting to hold up the world.
<i542> hello
<i542> i need some help, if a kind soul would spare a few minutes of their time :|
<i542> hey
<i542> oh well. have fun
<david64> Hi...is it possible to build a kernel for a PNA? I've seen some Windows CE devices wich ran on linux...i would like to use ubuntu, because i use ubuntu since version 5, but to be honest, i have no idea how to build a kernel remotly, and get it booting on a win CE device...although i know how to get into bios and how to flash the rom on that device
<alexmoldovan1> hello folks..
<alexmoldovan1> I have a quck question
<alexmoldovan1> after editing /boot/boot.script
<alexmoldovan1> do I have to run anything for the changes to be applied? like the equivalent of "grub-update" ?
<infinity> alexmoldovan1: flash-kernel
<TypoNAM> alexmoldovan1: flash-kernel I believe based off of: http://www.omappedia.com/wiki/Ubuntu_on_OMAP_FAQ#I_want_to_install_Ubuntu_on_external_USB_hard_disk_instead_of_sluggish_SD_card
<alexmoldovan1> infinity, TypoNAM thx..
<alexmoldovan1> ..rebooting
<alexmoldovan1> nice...now I can see boot messages and luks password prompt on my monitor instead of the serial console
<alexmoldovan1> :)
<cvanvliet> I am trying to do the netboot, following this, http://testcases.qa.ubuntu.com/Install/ARM/NetBoot
<cvanvliet> to get 12.04 armel
<cvanvliet> for an Overo, and it cannot find the ethernet devices
<infinity> cvanvliet: Which means, probably, that our kernel doesn't support your network device...
<cvanvliet> ok
<cvanvliet> I was fairly sure, but wanted to see if anything I was missing
<cvanvliet> thanks
<ndec> rsalveti: it would be nice to have robclark's xf86-video-omap in 12.10. we just noticed today that someone packaged it for debian/experimental. who can help on the ubuntu side?
<infinity> ndec: If it's in experimental, all we need to do is sync it.
<rsalveti> yup
<rsalveti> sync should be enough already
<infinity> ndec: Does it, like, work?
<infinity> ndec: I'm happy to sync it right now.
<infinity> Oh, I see a nice RC bug on it. :P
<infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671897
<ubot2> Debian bug 671897 in src:xf86-video-omap "xf86-video-omap: current binary segfaults, please update to fixed 0.3.0 release" [Grave,Open]
<infinity> Filed by the maintainer...
 * infinity scratches his head.
<infinity> Ahh, it's blocked by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667572
<ubot2> Debian bug 667572 in src:libdrm "libdrm: please provide OMAP API on armel and armhf" [Wishlist,Open]
<infinity> And that may be blocked by our kernel supporting the KMS bits correctly.
<robclark> yeah, you'll need to add --enable-expermental-omap-api (or something roughly like that) when building libdrm
<infinity> robclark: Plus making sure our kernel has the omap kms bits required.  Is that true in quantal?
<robclark> possibly you'll need the upstream omapdrm kernel stuff..
<robclark> so should be true in 3.4+
<ndec> any upstream since 3.3 would work.
<ndec> ah 3.4...
<robclark> I think an older version was backported for 3.2
<robclark> which is why 12.04 doesn't have it
<infinity> Right, don't care about 3.2...
<ndec> quantal will be 3.5...
<infinity> robclark: Can you verify that our 3.4 kernels in quantal actualy have the right CONFIG bits turned on?
<infinity> robclark: If not, filing kernel bugs would be helpful.  If so, then we can do nasty things to libdrm and such.
<robclark> perhaps.. can someone point me at the kernel for quantal?
<ndec> infinity: on our side we will work with the debian maintainer since we started our own package.
<ndec> robclark: it's the linaro kernel, so it does.
<infinity> ndec: The Debian maintainer seems to know what he's doing here, he's just waiting on the Debian kernel and libdrm to support what he needs.
<infinity> We can certainly move ahead of his packaging for now.
<robclark> ahh, ok.. then you are good
<infinity> ndec: eh?
<ndec> that's the same kernel we use for our releases.
<infinity> ndec: We don't use the Linaro kernel.
<ndec> infinity: yes, that's what I meant, we will get rid of our packages, and move to the 'upstream' one
<ndec> infinity: yes, you do. what else would you use?
<infinity> Our omap3 kernel is pure mainline, and our omap4 is the linaro LT sources, but with our configs.
<ndec> infinity: sure... that's what i call 'linaro kernel'
<infinity> Hence why I asked about the confics.
<infinity> configs*
<ndec> i see.
<ndec> you need DRM_OMAP.
<infinity> Is xf86-video-omap usable on all omap platforms (or, rather, the two we ship), or is it poorly named?
<ndec> that would be really good for us if you get that as early as possible on 12.10... it's a much better non accelerated X driver at least.
<ndec> infinity: robclark has tested it on beagle, iirc
<infinity> And omap4 as well?  Or just omap3?
<infinity> (This isn't clear to me)
<ndec> the only trick indeed is the experimental flag in libdrm, and the new package that results out of it.
<robclark> it is supposed to work on on beagle (although perhaps sans sgx stuff)..
<ndec> omap4 and omap5 is what we care about these days, so that work on them for sure.
<infinity> Mmkay.
<robclark> I probably test it more on o4/o5.. but it is intended to support o2+ (but I have no o2 hw, so essentially o3+)
<infinity> Yeah, we don't support any omap2 hardware anyway.
<robclark> right, I didn't think you'd mind too much if I don't test it on o2 :-P
<infinity> Right, so.  I don't have the time this week to own this.  The two best options would be to either file a bug on libdrm and assign it to me (and I'll deal with it later), or better yet, work with the Debian maintainer on getting the upstream stuff in good shape, and either sync when it is, or push it to me because Debian's blocking on something that doesn't affect us.
<rsalveti> well, if we got the 2d working fine on beagle it's good already
<rsalveti> the current beagle sgx driver is not supported anymore, because of the wrong X abi
<ndec> infinity: it's already upstream in libdrm.
<infinity> ndec: Yes, I know.  I meant "upstream" as in Debian here, not upstream upstream.
<ndec> argh.
<infinity> (But I'm happy to just do it directly in Ubuntu too)
<ndec> let me file a bug in LP for now...
<infinity> Since Debian looks like they'll do it eventually.
<infinity> And we can re-sync later.
<infinity> ndec: The bug helps, yes.  And assign it to me so it doesn't fall off my radar.  (~adconrad)
<infinity> Though, I expect one of you to bug me next week anyway. ;)
<ndec> infinity: oops. ubuntu only has 2.4.33 libdrm.
<ndec> robclark: do you know is 2.6.33 is 'enough'?
<infinity> 2.4.33 is what was in Debian when the maintainer filed the bug claiming that adding the configure flag would fix it.
<infinity> So...
<infinity> We'll see.
<infinity> Anyhow, I might get around to this "after hours", but if it's on work hours, it'll wait a little bit.  Busy week ahead.
<robclark> 2.4.33 is min required version
<infinity> robclark: Willing to trade after hours Ubuntu development for a Panda5.  Just sayin'.
<robclark> :-P
<robclark> you might want a slightly newer version if possible.. or at least there were a few things fixed..
 * robclark just looking at commit log
<robclark> will 12.10 use libdrm 2.4.36 (which doesn't exist yet, but I guess will soon)?
<infinity> I'm sure revving from .33 to .35 isn't rocket science.
<infinity> We can do that.
<infinity> And we can move to .36 when it releases, I'm sure.
<infinity> I'll talk to the desktop team about it.
<infinity> Put it all in the bug. :P
<robclark> in the nearish future, I was planning to push rotation support.. but that will introduce a dependency on some patches that went in after 2.6.35
<infinity> But I see no reason we wouldn't want the latest and shiniest, unless it breaks other drivers.
<robclark> libdrm is usually safe-ish to take a new version..
<infinity> Given the stable ABI, I sure hope it's safe. :P
<robclark> well, every now and then you get something like 'nouveau: pull in major libdrm rewrite' ;-)
<robclark> (but I didn't hear anyone complain so I guess it worked)
 * infinity smirks.
<ndec> infinity: i opened bug 1014879
<ubot2> Launchpad bug 1014879 in libdrm "Enable omap experimental support" [Undecided,New] https://launchpad.net/bugs/1014879
<infinity> ndec: Danke.
<ndec> i am not sure i can assign it to you, but i added you explicitely.
<ndec> thanks in advance, btw.
<infinity> I assigned it to myself, no worries.
<ndec> infinity: ok. thx. time out for me , bye ;-)
#ubuntu-arm 2012-06-19
<janimo> infinity, I'll make some time this week for arm/mono, not sure I can get to the bottom of it though
<ogra_> janimo, you mean you wont have it finished before the weekend ?!?!
<janimo> ogra_, yes. Poor users waiting to run banshee on raspberry pi will not have their pony
 * ogra_ shakes head .... 
<ogra_> especially the Pi people !
<janimo> ogra_, how's dejasperification progressing? Still on track for 12.10?
<ogra_> sure, livecd switch (apart from ac100 i think) is still in the plan
<ogra_> that makes jasper obsolete
<janimo> ok
<lilstevie> hm
<lilstevie> is there a blueprint on this change?
<ogra_> though infinity would liek to keep preinstalled functional ... not sure he wants to keep jaspÃ¼er around for that though
<janimo> why not for ac100? Makes even more sense there than on panda & co. Although it is extra work
<ogra_> right, its a matter of "does ogra find the time to work on it" :)
<ogra_> it works as is atm
<janimo> ogra_, btw any luck with the new ac100 3.1 kernel in quantal?
<ogra_> hmm, i might be running it, one sec, let me check
<janimo> I did not test with the armhf nvidia blobs
<ogra_> hmm, no i dont
 * ogra_ will test that later today
<lilstevie> I only ask about the dejasperfication cause I have just started working on hacking up d-i for the tf201
<ogra_> lilstevie, there are like ten specs for it for the last 4 releases or so :)
<lilstevie> hah
<ogra_> the current plan is to just switch to live images though
 * lilstevie has to admit that he doesn't go searching through launchpad very often
<ogra_> since we do that for everything (alternate is gone)
<ogra_> even server is a live image now
<lilstevie> ah
<lilstevie> well I was looking at live images, but from what I hear ubiquity does not support LVM yet
<ogra_> right, xnox is working on that
<lilstevie> yeah, I heard that is planned for 12.10
<ogra_> thats the prereq. for dropping alternate (and the reason they still existed for A1)
<lilstevie> fair enough
<lilstevie> cause I rely on it
<lilstevie> I split the partition that normally contains /data to retain the ability to boot android
<ogra_> right, if you have special setups or so, help xnox with testing his changes ;)
<lilstevie> works quite well
<lilstevie> but sure :)
<ogra_> he is usually in #ubuntu-devel
<lilstevie> just joined
<janimo> lilstevie, how do you boot both android and ubuntu?
<janimo> did you not repartition anything on the tf101 for ubuntu?
<lilstevie> on the tf101 I had the ability to repartition the whole device safely because of using nvflash
<lilstevie> we do not have the same luxuries on the tf201
<janimo> lilstevie, I thought the tf201 was the less restricted one?
<janimo> unlockable and all that
<lilstevie> unlockable but not unbrickable
<lilstevie> the bootloader unlock is nothing more than that
<Laney> can I dist-upgrade my shiny new panda from precise to quantal and expect it to still work afterwards? :-)
<ogra_> Laney, you tell us ;)
<ogra_> i doubt anyone has actively tested upgrading yet
<Laney> heh, might as well
 * ogra_ needs to clean a fan and will be offline for a while, disassembling HW
<Laney> ogra_: no good. hangs when booting the kernel :(
<ogra_> ah, sad, probably fallout of the new flash-kernel
<ogra_> how does it hang ? do you have a serial cable attached ?
<ogra_> (so you can see if the kernel gets loaded at all etc)
<cvanvliet> I am trying to make a 12.04 armel, I used qemu-debootstrap method, I get this , init: Failed to create pty - disabling logging for job
<Laney> ogra_: if you can tell me how to make it more verbose I will
<Laney> the last message I get is "Uncompressing Linux... done, booting the kernel."
<cvanvliet> this is on a gumstix Overo
<GrueMaster> Laney: You will need to edit your boot.scr file.  See http://wiki.ubuntu.com/ARM/EditBootscr
<Laney> GrueMaster: thanks, what do I need to add?
<GrueMaster> Add the "console=ttyO2" line, and remove the "quiet" part from the kernel boot parameters.
<Laney> ttyO2? Even if I already have serial working?
<GrueMaster> This tells the kernel to spew console messages to the serial console.
<Laney> ah
<GrueMaster> What you see now is from u-boot.
<Laney> also we were just talking in #ubuntu-desktop about DVI output on the desktop preinstalled image â do you know if that is supported and how to enable it if so?
<GrueMaster> What board?
<Laney> panda es
<GrueMaster> May need to muck with the kernel parameters.  I think there is info on the pandaboard wiki (non-Ubuntu).  See http://pandaboard.org
<Laney> OK I found something there. You think it will work?
<Laney> http://omappedia.org/wiki/PandaBoard_FAQ#How_do_I_enable_DVI_output.3F
<GrueMaster> By default, the HDMI port should work.  And if you use a DVI<>HDMI cable, you shouldn't have any problem.
<GrueMaster> I haven't tried using the dvi port.  Since I am no longer working on the project, I can only add help where I know how.
<Laney> I have HDMI<>DVI but there was no output
<Laney> nm, one problem at a time :-)
<GrueMaster> (and I think Intel is blocking that web link for some reason)
<Laney> "add this to your bootargs:
<Laney> omapdss.def_disp=dvi "
<GrueMaster> From what I know, the HDMI poirt is enabled by default in the 12.04 images, and should display on a DVI monitor just fine.  But I haven't tested it since ~Beta 1.
<GrueMaster> Beyond that, I can't help much.  Sorry.
<Laney> np
<GrueMaster> I have a panda ES at home, but I am not there, and when I am, I have little time for arm stuff anymore.
<cvanvliet> Laney, different board (overo), different setup, but we had trouble with anything other than 1024*768, don't know if that helps at all
<ronoc> ogra_, I got 6/1 odds, so I thought it was worth it...
<Laney> hey, quantal is working now!
<infinity> janimo: I may have the solution for mono/armel, I have my crack team of +1 guys implementing and testing it for me, so I don't have to. :P
<Laney> cvanvliet: It helps me feel less alone :P
<janimo> infinity, oh thanks :)
<infinity> janimo: (Looks like it's turning on ARMv6+ bits unconditionally because it's testing ASM on the buildd)
<cvanvliet> Laneu lol
<cvanvliet> grr
<infinity> janimo: Hence why it works in Debian (their buildds are armv5)
<janimo> infinity, good catch. So yet another case of assuming build arch = target arch
<infinity> janimo: Indeed.
<janimo> infinity, so I guess I can stop bootstraping armel chroots on armadaxp :) I was loath to dig out my panda from the drawer, the ac100 needs to be installed, scheat is down. Only after a while did I realise I have quad-cores at my disposal :)
<infinity> janimo: Some day, I would like you to look into VFP and HF on mono (remember that we're still building with vfp=none, wich is ridiculous), but that's less urgent than us just making it build at all. :P
<janimo> infinity, isn't VFP covered by upstream well? Or is this a "works for us (xamarin/android) and ubuntu has quirks" case too?
<infinity> janimo: I figure that'll be just enough distro work for you to remember you hate us, and go crying to Chris to never let me borrow you again. ;)
<janimo> I am not at all sad though we do not have mono in the default images anyomore :)
<infinity> janimo: And I'm not sure what the current state is.  I know Debian and Ubuntu both disable the VFP bits on both armel and armhf, and there must have been a reason...
<janimo> I am trying to do distro work (armadaxp kernel maint should qualify as that at this point), I just hate fixing the same type of bugs over and over again :(
<Laney> RAOF said he was going to look at HF on mono
<infinity> Well, I could find you new and exciting bugs.
<Laney> because it's currently terribly broken (no p/invoke) even though it does build
<infinity> Laney: THat's different.
<infinity> Laney: That's that it's broken in its current state, even without VFP/HF.
<Laney> yes
<Laney> I am saying that he might care to look at this too.
<infinity> Though, if he plans to turn on some HF ABI madness while sorting out popen, sure.
<GrueMaster> infinity: Is VFP supported by all SOC's?  iirc, either Marvel or Tegra didn't support it, so it was kept disabled.  I could be wrong.
<GrueMaster> (or are we only talking about mono?)
<infinity> GrueMaster: Every V7 SoC supports VPV3-D16, you're thinking of NEON, which Tegra2 doesn't have.
<GrueMaster> Ah, yea.  That was it.
<Mihai00> Salut, vorbeste cineva limba romana ?
<Mihai00> Salut, vorbeste cineva limba romana ?
<Mihai00> Salut, vorbeste cineva limba romana ?
<mythos> Mihai00, yeah! you, silly ;)
<Mihai00> u are funny...
<Mihai00> u know how to install ubuntu to android tablet?
<mythos> Mihai00, nope
<Mihai00> ok, thx
<mythos> no problem ;)
<mythos> Mihai00, but if you asked that question from the start, maybe someone read it earlier...
<GrueMaster> Mihai00: Depends on the tablet.  First, is it armv7 capable.  Second, do you have a way of installing a new kernel or modifying the boot sequence?  Best place to look for help on this is probably XDA Developers.
<mythos> Mihai00, see ;)
<GrueMaster> mythos is right.  Best to ask the question outright, than to pop into a room and say "I have a question".
<Mihai00> sorry .. my english is bad :|
<GrueMaster> The room's complex mind-reading AI is currently down, so you have to revert to manual typing.  :P
<GrueMaster> No problem.  So is mine (and I'm American).  :D
<mythos> Mihai00, do as best as you can. as long as it is in a way understandable, no one cares really
<Mihai00> tablet processor is Cortex a8
<Mihai00> Tablet :  Allview Alldro speed
<GrueMaster> Well, out of the box, Ubuntu doesn't have an image that will boot on it.  But since it is Cortex A8, the Ubuntu packages will run on it.  If you are up for the challenge, you can work on creating an image for it, or at least instructions for installing on it.
<GrueMaster> I haven't read the detailed specs on the system, so I can't tell you how hard it will be.  Booting and video out will be your biggest hurdles.
<Mihai00> ok thx
<GrueMaster> Looks like http://forum.xda-developers.com has some interest in it.
<GrueMaster> Google might turn up more results.
<GrueMaster> Neat little unit though.
<Mihai00> i looking here right now .. thx man
<steev> ah crud
<steev> GrueMaster: if he shows back up asking, point him to #arm-netbook, that's an Allwinner A10 chip, which is pretty much what the guys in there focus on (iirc, someone got ubuntu running on it)
<steev> (i actually have that tablet too, but i'm fine with running CM9 on it)
<GrueMaster> steev: Cool, will do.
<steev> they are pretty decent machines for the price
<GrueMaster> Meh.  I personally prefer the Nook Color/Tablet, but then this one does have HDMI out (Nook doesn't).
#ubuntu-arm 2012-06-20
<twb> Are beagles armv7?
<twb> (f17 arm was released recently and I was idly wondering what their minimum hw target was.)
<infinity> twb: Beagles are v7.
<infinity> twb: Their armhf port is v7-vfp-d16, same as ours.
<infinity> twb: However, theirs is binary incompatible, because they didn't sort out the cross-distro liker mess in time. :/
<twb> Hehe
<twb> Fortunately I can be idly curious because I don't have to babysit FC boxes anymore :-)
<ronoc> ogra_, ping
<ronoc> ogra_, pinga ring
<ogra_> ronoc, yo, sorry, had an early lunch
<ronoc> no worries
<ronoc> ogra_, timR is out now
<ronoc> ogra_, later when he comes back I'll do some introductions if you don't mind
<ogra_> fine, yeah
<ronoc> ogra_, thanks
<tim_> ogra_, ronoc, hi, just noticed this
<ronoc> hey tim_
<tim_> hey
<ronoc> ogra_, this is my mate tim_ i was speaking to you about
<ronoc> gumstix audio issues
<tim_> Hello ogra_!
<ronoc> tim_, do you have your notifications turned on
<tim_> not sure, don't ususally use IRC
<ronoc> tim_, when I write tim_ the icon on your panel should go blue or something
<ronoc> what client are you using
<ogra_> tim_, hey
<tim_> ogra_ hi!
<ogra_> so you got sound issues i heard
<tim_> yep should we switch to direct message?
<ogra_> nah, just keep it here
<tim_> ok
<tim_> I'm just about to run out I'm afraid
<tim_> I'll explain quickly
<tim_> I'm using 12.04 on gumstix boards
<ogra_> yep. connor said so
<ogra_> -n :)
<tim_> there is a driver called snd-soc-overo for the built in audio
<tim_> It works in openembedded I beleive
<tim_> I'm modprobling it and it is loading
<ogra_> right, do you see anything with "dmesg|tail" if you load it ?
<tim_> but no usable devices
<tim_> no I don't think so, I'll check that
<ogra_> and is there anything in /proc /asound ?
<tim_> Is it ok if I check that and get back to you in about 2 hours? just have to do something 1st
<ogra_> sadly we dont have amny gumstix users so we dont really get much feedback for that SoC
<tim_> you are in charge of soc audio?
<ogra_> i have meetings the whole afternoon so i wont be available much
<cvanvliet> tim, are you using armhf or armel?
<tim_> anytime in the next few days would be great
<tim_> armhf
<ogra_> no, i only care for images usually and for the arm port in general
<ogra_> but that often enough includes userspace audio fixes
<tim_> OK.. will report back in a bit, and thanks
<ogra_> cool, good luck :)
<tim_> ogra_, dmesg just says -  [  392.393524] overo SoC init
<tim_> ogra_, cat /proc/asound/cards says  --- no soundcards ---
<ogra_> hmm, then your driver probably either needs additional modules loaded ... or whats more likely (and happens often on arm) is that the driver only works properly if compiled in
<tim_> there are already a bunch of modules loaded
<tim_> snd_soc_core          111406  2 snd_soc_overo,snd_soc_twl4030
<tim_> is snd_soc_twl4030 supposed to load I wonder
<tim_> twl4030 is the chip that's being used
<tim_> and once I have loaded this once, it autoloads on reboot
<tim_> btw uname -a : Linux overo 3.2.0-23-omap #36-Ubuntu Tue Apr 10 20:24:21 UTC 2012 armv7l armv7l armv7l GNU/Linux
<GrueMaster> tim_: In my experience with the beagleXM and beagleboard (essentially the same SOC), the audio only worked when the drivers were built into the kernel.  You should try rebuilding the kernel with the twl4030 & overo drivers compiled in.
<GrueMaster> (I "used" to work on the audio stuff for these boards)
<tim_> Thanks!
<tim_> I believe these may actually be built into the kernel already? There don't seem to be any .ko files for them..
<GrueMaster> Hmmm.
<GrueMaster> Try "fgrep TWL4030 /boot/config-*"
<GrueMaster> See if they are.
<tim_> GrueMaster ok - this checks the kernel build flags? -  CONFIG_SND_SOC_TWL4030=m
<tim_> and CONFIG_SND_OMAP_SOC_OVERO=m
<GrueMaster> Yes.  And according to that, the driver is built as a module.
<tim_> I guess this means they aren't
<GrueMaster> Need to rebuild with those set to Y.
<tim_> Great! ok, this is going to take a bit of research..
<tim_> do you know if it needs both of them?
<cvanvliet> tim_, which gumstix have you got? (I have an IronStorm)
<GrueMaster> I think if you set one in the kernel config menu, it will flag the other, but I am not sure.  I would just enable both.
<tim_> I have airstorm and tide
<tim_> I believe they are all compatible with the same kernels?
<cvanvliet> I am a noob ;)
<GrueMaster> See http://bugs.launchpad.net/ubuntu/+source/linux/+bug/925094
<ubot2> Ubuntu bug 925094 in linux "No audio on omap (beagleXM) system" [Medium,Confirmed]
<GrueMaster> (I knew I had filed one - with the fix).
<tim_> OK this seems to be a similar issue alright
<tim_> At the end there is a post that says its a dependency issue?
<GrueMaster> Yea, I just saw that.  Can't test it though (not at home, and beaglexm is packed away since I have moved on).
<cvanvliet> tim, did you use a preinstalled ubuntu image, I think I tried it earlier and just sat there
<cvanvliet> Uncompressing Linux... done, booting the kernel
<tim_> I  used a preinstalled image yes
<cvanvliet> hmm, ok
<GrueMaster> cvanvliet: That sounds like a desktop image.  It requires video & keyboard.  You won't see much else on the serial port.
<tim_> I think the current one does that for me also
<ogra_> cvanvliet,  you want a server image for serial output
<cvanvliet> GrueMaster, it is set up with DVI, keyboard etc
<tim_> aha, I just tried loading snd-soc-omap and snd-soc-omap-mcbsp and the device has appeared!
<tim_> without rebuilding the kernel ;-)
<ogra_> congrats !
<tim_> now to check if there is sound
<GrueMaster> cool.  You can add the dependency to /etc/modprobe configs.
<cvanvliet> ogra, I actually want a desktop, but I can try the server image later
<cvanvliet> I actually want 12.04 armel, tbh
<ogra_> you cant install the desktop image if your screen doesnt work
<ogra_> and there are no armel images for 12.04
<cvanvliet> I know, I have been trying to make one
<cvanvliet> ogra, I am confused, there is a screen attached
<ogra_> right, but the dirver your kernel ships was only tested on beagleXM
<cvanvliet> ok
<ogra_> its a matter of luck if it works on different omap boards
<cvanvliet> thought that may be a the case
<cvanvliet> nice to have it confirmed
<cvanvliet> and when it worked for tim, I had hope
<ogra_> desktop images run the installer on the display ... so without working kernel driver you wont be able to install them
<cvanvliet> mine is a newer model, so every reason it may not work
<ogra_> thats why i said use the server image ... it is a minimal ubuntu install that runs completely on serial and also offers to install the desktop at the end if you want to
<cvanvliet> ahh ok,
<cvanvliet> ahh thanks
<cvanvliet> I can try that
<cvanvliet> although I need armel, having an armhf may help me figure out the armel
<ogra_> why do you want armel ?
<ogra_> it will be lots slower
<ogra_> (beyond the fact that nobody actually cares if it even works)
<cvanvliet> I need the SGX drivers
<ogra_> ah
<cvanvliet> this is for a business of mine
<cvanvliet> and we will use opengl for the graphics
<ogra_> you could ask over in #beagle if there are any people capable of re-rolling the binary driver at TI
<ogra_> thats essentially what was done for the omap4 hf driver
<cvanvliet> one of the guys asked someone here the other day,
<cvanvliet> and the answer was dunno :(
<ogra_> lovely
<cvanvliet> ndec, I think it was
<ogra_> yeah, he isnt working in the omap3 area i think
<tim_> I just tried to test the audio.. no audio
<ndec> hmm?
<cvanvliet> yeah it is quite hard, I feel like i will be using a below par system
<ogra_> ndec, omap3 SGX armhf
<tim_> I am aware that the mixer sometimes is preconfigured for no output
<cvanvliet> if I don't use armhf
<ndec> i don't do that ...
<ndec> i don't do OMAP3 SGX, neither armel, nor armhf
 * ogra_ thought so :)
<tim_> its a very complex mixer
<ogra_> tim_, yeah, thats the problem with bug 925094
<cvanvliet> ndec, sorry if I got that wrong, I thought it was you who responded
<ubot2> Launchpad bug 925094 in linux "No audio on omap (beagleXM) system" [Medium,Confirmed] https://launchpad.net/bugs/925094
<ogra_> if it was easy we would just have a UCM config already :)
<cvanvliet> so, accordingly with what tim_  is seeing, i will have audio issues as well , (i need to record sound)
<ogra_> likely, though for him the driver already works ... should just be a mixer issue now
<ogra_> if alsamixer actually shows the device and its rulers you are about 90% done
<cvanvliet> ogra , ok
<tim_> hmm, I have turned up every single bar in the mixer
<tim_> alsaplayer thinks its playing a wav
<tim_> but.. no audio
<ogra_> tim_, did you also unmute everything ?
<GrueMaster> iirc, the only way I got audio working on the beagle was to rebuild the kernel AND tweak the volume settings.  Hopefully you will get it working without rebuilding, but...
<tim_> I think I unmuted everything- if OO means on and MM means mute
<tim_> Gruemaster, did you also see a device but it didnt work until you rebuilt the kernel?
<GrueMaster> Yes.
<tim_> OK thats seems pretty clearcut..
<GrueMaster> It seems like the device doesn't power properly unless the driver initiallizes it during kernel init.  I don't know enough about the inner workings of the SOC code, but I would guess that the kernel initalization routine powers on devices that need it during boot, but not after.
<GrueMaster> On a PC, that's ok as there isn't as much device level power management, but on an SOC that is designed for low power cunsumption....
<GrueMaster> It's like the SOC needs hot plug support for on-die devices.
<GrueMaster> Of course, my assumptions could be wrong (it has happened before, once or twice).
<bradfa> GrueMaster, could the "disabling unused clocks" play into that at all? maybe the SoC is disabling the sound device clocks if it's not configured in kernel init
<GrueMaster> That might do it.  I'm not a hw designer though.  Maybe prpplague would know?
<prpplague> who summons the plague?
<GrueMaster> prpplague: question on the beagleboard/XM/overo Audio.  See scrollback.
<prpplague> yea it is possible that a clock is disabled
<prpplague> that is something that would take some debugging
<GrueMaster> Is there a way to enable it from user land?
<prpplague> one of the common issues the clock is disabled by mistake when another device enables their clocks
<prpplague> yea you can use devmem2 to enable most clocks, but without knowing what is enable/disabled, you'd be throwing darts in the dark
 * GrueMaster has done that with...interesting results.
<prpplague> GrueMaster: i'd bring this to the attention of mdp or tartarus over on #beagle, they'd be able to get to the bottom of it fairly quickly
<GrueMaster> Using real darts, of course.
<GrueMaster> tim_, bradfa, cvanvliet, there you go.  I have done what I can to help from here.
 * cvanvliet passes GrueMaster a beer
<tim_> haha thanks a million..
<janimo> lilstevie, no news on the tf101g front?
#ubuntu-arm 2012-06-21
<TheMuso> /c/c
<heathkid> trying firefox
<heathkid> just a sec
<heathkid> win explorer completely crashed
<heathkid> had to end process
<cvanvliet> infinity, I heard in #beagle, that there is talk at TI re SGX, omap3 armhf
<cvanvliet> they have it a copy internally
<infinity> cvanvliet: Snazzy.
<cvanvliet> who do we poke ;)
 * cvanvliet wants an LTS version of ubuntu, just as much as any speed increase
<infinity> cvanvliet: The poking would go to ndec and robclark, I assume, to get it released in the wild.  From there, we can probably hand-wavingly SRU it to precise.
<cvanvliet> s/poke/beg
<cvanvliet> if they are in the UK, I would certainly by them a beer ;)
<ndec> infinity: neither robclark nor me are doing any work on OMAP3.
<infinity> ndec: Fair enough.  Figured maybe that if there were shiny internal omap3 sgx builds, you guys might still be more in the know than, say, me.
<ndec> nope.
<infinity> Kay. :)
<ndec> i think #beagle is the better place to ask.
<cvanvliet> ndec, well for me it is about getting omap3 sgx into an ubuntu LTS, not just SGX
<cvanvliet> but thanks, I will pursue there
<ndec> the problem is armhf right? TI is doing SGX releases publicly for OMAP3, iirc.
<cvanvliet> yes
<cvanvliet> there is no roadblock here for me, it is just not how I want things :)
<cvanvliet> everyone is moving towards armhf, and we will be stuck on armel
<infinity> cvanvliet: If you can give me pointers to public omap3 sgx builds that will work on precise/armhf, I can drive getting them included in an SRU.
<cvanvliet> thanks
<ogra_> ndec, http://paste.ubuntu.com/1052388/ do you have any nice cpuinfo lines for me for omap4460 based blazes etc ?
<ndec> ogra_: I don't have it, but the source code says this: http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=blob;f=arch/arm/mach-omap2/board-4430sdp.c;h=b61d0ed718a013557c4c5affd555be7b01729447;hb=2c963fa702cb8bcc4eb3a580e05e3304df4911b2#l997
<lilstevie> ogra_: hardware line cardhu for tf201, and ofc cardhu development platform
<lilstevie> ogra_: nvidia-tegra ofc
<lilstevie> if you would like to add that one
<ogra_> lilstevie, i need the exact copy/paste please
<lilstevie> k sec
<ogra_> ndec, hmm, so there is no 4460 blaze ?
<lilstevie> http://paste.ubuntu.com/1052478
<ogra_> uuh, ok
<lilstevie> is there something you are looking for there that is missing?
 * ogra_ has never seen such a short HW string on arm yet
<lilstevie> heh
<lilstevie> tf101 is the same
<lilstevie> tf101 is ventana
<lilstevie> nothing extra
<ogra_> added both
<lilstevie> thanks :)
<ndec> ogra_: there are 4460 blaze, but they will use the same 'machine', so same output.
<ndec> like panda btw.
<ogra_> ok
<ogra_> yeah, well, if someone is insane enough to use a lucid kernel on his install or so, the old values would still match
<ogra_> (not that the driver would work though :P)
<ndec> ogra_: that said... if you want to be doing something with some forward thinking... you need to handle device tree as well.
<ndec> for DT, you will have 1 generic name for each CPU family. iirc
<ogra_> well, 80% of our HW detection tools on arm use cpuinfo
<ogra_> i wont have to care how it is populated
<ndec> ogra_: but the cpuinfo/machine info will be different on a panda which is booted with DT
<ogra_> oh, yeah, indeed
<hrw> ogra_: so now we have one rfc822 database in flash-kernel?
<ogra_> hrw, not sure if its rfc conform, but yeah, we have a DB
<ogra_> i think infinity planned to actually split out a -data package that has only the DB
<ndec> ogra_: if you look at that: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/mach-omap2/board-generic.c;h=20293465786701f8650e1377ea070c6eee536673;hb=bc259adc9b76f625fff0423df3ffb80a03802927
<ndec> you see that all OMAP4 will show up as "Generic OMAP4 (Flattened Device Tree)"
<ndec> and all OMAP5 will be "Generic OMAP5 (Flattened Device Tree)"
<ndec> etc...
<ogra_> right, but "OMAP4" would match all oamp4 devices still
<ogra_> even if i would have typed it right :P
<ndec> note that it will be a problem ... since not all OMAP4 will use the same pvr-omap4 ;-)
<ndec> 4430 and 4460 have the same GPU, 4470 have a different GPU.
<ogra_> for these we need a more specific matching then
<ndec> with conflicting libs in the user space
<hrw> 4470 got MP2 powervr?
<ndec> 4470 544, single core
<ogra_> for now the concept of having a line per supported SoC should be fine
<lilstevie> is that exported somewhere though
<ndec> OMAP5 is 544 MP2
<lilstevie> or visible from sysfs
<ndec> lilstevie: i don't know for now. we manage it 'by hand' for now, and don't have a clean solution yet.
<lilstevie> sure
 * XorA|gone wonders when PVR will catch up with the 1990s and have runtime detection
<lilstevie> heh
<lilstevie> the tegra driver does it
<ndec> lilstevie: how is it done on the tegra? 1 set of user space binary blobs that work on multiple h/w? or is it doing some symlinks tricks?
<lilstevie> 1 binary
<lilstevie> they have released platform tarballs for each development device, but the binaries work across devices just fine
<ndec> lilstevie: ok... we aren't there yet with PVR.
<lilstevie> fair enough
<lilstevie> it is all good having one binary, but five binaries that work would be better :p
<ndec> well, we have the binaries that work ;-)
<lilstevie> heh
<lilstevie> tegra ones are horrible
<lilstevie> the latest release is probably the best yet though
<lilstevie> :p
<janimo> ogra_, so did you test with current 3.1 kernel and graphics work with the latest nvidia drivers?
<janimo> if so the ac100-meta can also be bumped to make the 3.1 version the default
<ogra_> janimo, i think infinity did right after your upload anyway :)
<ogra_> and yes, a smoketest worked
<janimo> ogra_,  I thought so too, but I tried the installer yesterday and got 3.0,27
<ogra_> i havet used it for long though
<janimo> the installer crashed though
<ogra_> i dont think we have recent ac100 images for quantal yet
<janimo> ogra_, ah I missed they were dated May 30
<ogra_> http://cdimage.ubuntu.com/daily-preinstalled/current/ has images from may 30
<janimo> just saw they're under jun 18 or such
<ogra_> i fixed flash-kernel though, the next successfull build should have them
<janimo> ogra_, is this because the kernel will likely not boot?
<janimo> ogra_, good to know then
<ogra_> the kernel will likely need a console statement or so
<ogra_> in the bootargs
<ogra_> but i first want working images before i look into details
 * satellit_ testing TrimSlice -h 250 
<robclark> rsalveti, ogra_, we need precise on http://www.engadget.com/2012/06/21/hp-passport-1912nm-internet-monitor/  :-)
<robclark> actually you might even just be able to take an o4/panda image and boot it.. not sure, maybe there is a new board file, etc..
#ubuntu-arm 2012-06-22
<Tinti> hello, I am following the rootsock documentation in https://wiki.ubuntu.com/ARM/RootfsFromScratch is there  a new documentation? It is not working for precise 12.04 but I finally have succeed in building an image
<Tinti> if I could help anyone
<lilstevie> robclark: that is pretty awesome
<infinity> robclark: Only $259?  That makes it more cost-effective than a Panda with a monitor.  Not bad.
<TheMuso> Sounds cool./
<robclark> lilstevie, infinity, from what I understand it is running a sort of customized ubuntu 10.10 already.. but hopefully when they post the kernel the board support isn't too hard to forward port and get newer kernel and 12.04 running on it
<infinity> robclark: Hang a USB drive off the thing, and it would be a perfect devel kit to recommend to people.
<rsalveti> robclark: that's cool
<robclark> yup
<ojn> robclark, do you know if it's a 4430 or 4460? hard to argue with that price for something that has a monitor, etc.
<robclark> I think it is 4430
<heathkid> support for realtek USB wifi?
<robclark> http://h18000.www1.hp.com/products/quickspecs/14358_na/14358_na.HTML#Technical Specifications
<ojn> robclark, excellent, thanks!
<lilstevie> I kinda want one
<lilstevie> I also noticed that it has flash
<cvanvliet> Tinti, I am trying to do a 12.04 image for gumstix (armel), and got errors - Failed to create pty - disabling logging for job
<infinity> cvanvliet: Does your kernel have support for devpts?
<cvanvliet> I only compiled my first kernel  a few days ago, and am not great with kernel foo yet, wil check it
<cvanvliet> (what I did do was enable initramfs, and move init to / and it helped, but ended up in init being /bin/sh?)
<cvanvliet> bbs, thanks infinity
<cvanvliet> quick check -> yes, unix98 and bsd are both enabled
<infinity> Okay, but it sounds like you're doing some odd things with your initramfs...
<infinity> Are you creating it with update-initramfs?
<infinity> I mean, talk of moving init around and whatnot sounds a bit unconventional. :P
<cvanvliet> yes
<cvanvliet> infinity, I am mainly trying to learn, donât take anything I say as being correct
<infinity> Anyhow, I probably shouldn't get into this tonight, I need to sleep and be up early.
<cvanvliet> thanks
<infinity> But, yeah.  If you think you need to move init around, you're almost certainly doing something wrong elsewhere. ;)
<cvanvliet> I may have just seen something :/, let me try
<cvanvliet> thanks!
<ppisati> ogra_: we are going to stay with this kernel for omap4, sorry
<ppisati> ogra_: tilt-tracking is heavily based on linaro kernels
<ppisati> ogra_: and a rebase gave me all kinds of clashes
<ppisati> ogra_: after alpha2 is out, i'll start building a 3.5 kernel for omap4 (as the email on the ubuntu kernel ml stated)
<ogra_> damned
<ogra_> but ok
<ogra_> i guess then we cant really make A2
<ogra_> (with the display issues and the switch to full live images we wont have a way to install)
<ppisati> ogra_: it works for some monitors actually
<ogra_> i have tried three so far
<ogra_> none of them works
<ppisati> i dont' know what to tell
<ppisati> i've two here and they work
<ogra_> n othing to tell, ndec already said they completely reworked the graphics driver
<ogra_> we just need that code dump ....
<ndec> but we don't have it for 3.5
 * ndec checks ubuntu kernel list...
<ogra_> oh, i thought you said it was 3.5
<ppisati> nope
<ppisati> still 3.4 for them
<ogra_> my prob is that omap doesnt boot either
<ppisati> and it's actually 3.4 + a lot of stuff from linaro + ...
<ogra_> and ac100 doesnt build yet
<ppisati> a disaster! :)
<ndec> we have 'frozen' tilt-3.4 just today. so tilt-tracking will start tracking 3.5 any day now.
<ogra_> so we wont have any arm images for A2
<ppisati> wait wait
<ppisati> what's wrong with omap?
<ndec> however we (TI) will not spent a lot of energy on 3.5...
<ndec> so i am not sure which features will work in 3.5
<ogra_> ppisati, given that the QA team only has 5 weeks left to get their automated testing working, it is a desaster, there are no images yet for them to write scripts for
<ndec> yet
<ppisati> ndec: i know i know, we are going to use 3.5 upstream after alpha2 + cherry picks useful stuff from tilt
<ndec> it's likely that the TILT 3.5 won't get many more than what's in mainline already
<ndec> so ppisati what's the problem exactly?
<ppisati> ogra_: what's wrong with omap?
<ogra_> oopses all over the place
<ogra_> we didnt release it for A1 if you remember
<ppisati> ogra_: i've been testing it till an hour ago
<ndec> 3.4?
<ppisati> ndec: 3.5
<ndec> ah...
<ogra_> ndec, oopses -> omap3 ...
<ogra_> not omap4
<ndec> tilt-3.4 should be in quite a good shape on OMAP4 and 5.
<ndec> hum. omap3?
<ogra_> omap4 3.5 simply freaks out with the wlan device (demsg gets massively spammed) and doesnt detect any monitor here for me
<ogra_> err 3.4 that is ...
<ppisati> ogra_: me and ming were tracking down an mmc/fs issue in omap for 3.5
<ppisati> ogra_: but apart from that, kernel works here
<ogra_> ah
<ndec> we use wlan with 3.4-tilt with *precise* these days. and it seems to be working.
<ppisati> it seems it's an sd card problem with a late commit
<ogra_> ppisati, well, it didnt for A1 thats why it was decided to be dropped
<ppisati> ogra_: video wasn't working iirc
<ppisati> ogra_: anyway, let me check
<ogra_> and with the switch to full live images the XM install (with only 512M) wont be any fun anymore ... apart from fully relying on video
<ogra_> infinity, around ?
<ppisati> ogra_: i still believe we should enable serial console output by default
<ogra_> that wont help anymore
<ppisati> why?
<ogra_> we are just in the process to switch to full live images, serial wont gain you anything there
<ppisati> and how do we debug problems during installation?
<ogra_> (upstart doesnt enable serial by default so you wont have a login, quiet and splash are set as default so you wont get much kernel output)
<ogra_> oh, for debugging you just dump an uEnv.txt in place
<ogra_> with the cmdline you want
<ppisati> ogra_: so, i;m trying the daily image installation
<ppisati> ogra_: omap3 on a beagle xm
<ogra_> but that wont get you anywhere with a live image
<ogra_> since the installer doesnt run on serial
<ppisati> ogra_: i modifided boot.scr to have srial output
<ppisati> and it's X failing
<ogra_> right, you can just use uEnv.txt nowadays
<ogra_> no need for fiddling with mkimage etc
<ogra_> lucky you, for me it didnt boot (with A1 at least)
<ppisati> daily from today
<ppisati> so maybe we can fix it
<ogra_> yeah, but there werent any omap related changes, were there ?
<ppisati> eutehr something screwed in the kernel (omapfb&c)
<ppisati> well, we passed from 3.4 to 3.5
<ppisati> so, everything could have happened
<ogra_> ah, well, i'll try an omap image on monday, currently i'm focused to get omap4 live working
<ppisati> ok, let's do that
<ppisati> btw, can you get a new sd card and try an old P release on that panda?
<ogra_> why a new SD card ?
<ppisati> i wonder if video output is ok
<ppisati> or rewrite it, whatever
<ppisati> i mean, don't dump your installation
<ogra_> i teasted all pÃ¼anda images during precise development
<ogra_> well, all milestones
<ogra_> including the final reelase
<ogra_> there were no issues at all
<ogra_> (and you asked me to test the precise kernel when my A1 image didnt work if you remember)
<ogra_> downgrading to the precise kernel fixes everything here
<ppisati> ah, when was last time you had a working video kon that?
<ppisati> because
<ppisati> http://www.kernelhub.org/?msg=30802&p=2
<ppisati> there was a window of time
<ppisati> where you could destroy your video output
<ppisati> reboot
<cvanvliet> what are the differences between ubuntu and linaro ( particularly omap3 , SGX)
<ogra_> linaro takes snapshots of the ubuntu archive and rolls monthly images from them
<ogra_> on top of that they include their imporvements that will soon land in the ubuntu archive ...
<ogra_> they dont support their images though ... no security fixes updates etc
<ogra_> so you get an image with outdated (or the same) SW from the last ubuntu release but with added linaro sweetness on top (toolchain fixes, other kernels, bootloaders etc)
<cvanvliet> ok, that clears a lot up
<Tinti> hello ogra_ did you wrote rootstock tool?
<ogra_> Tinti, yes, but its dead since over a year now
<cvanvliet> was Tinti the gumstix guy earlier?
<Tinti> I saw, I want to start developing in linaro do you have any advices or tools that I should use?
<ogra_> ask in #linaro ? :)
<Tinti> cvanvliet, no I am Tinti for a long time :)
<cvanvliet> I think I jumped to conclusion
<cvanvliet> sorry long night :/
<Tinti> in fact I am there but I am not getting much things ... in fact I would like to get recommendations from you. probably you have switched from rootstock to something else right?
<ogra_> nope
<ogra_> rootstock was never actually used anywhere in ubuntu, it was just a script combining a lot of hacks
<ogra_> to roll a rootfs you can use live-build ... and i think there are a ton of linaro tools to create images
<ogra_> so best ask in linaro (we dont use these tools either in ubuntu, #linaro is a better place to ask about this)
<Tinti> yes there are, I was thinking in use it
<cvanvliet> are they any tutorials to get 12.04 armel up an running?
<ogra_> well, there are installation howtos for the official images
<Tinti> yeah thanks. I need to compile an environment for iMX51
<Tinti> I would like to do it from scratch in fact
<infinity> ogra_: Around now...
<cvanvliet> ogra, I have tried most of these (they all seem beagle based)?
<ogra_> infinity, so i will switch the crontab to roll live images for omap, omap4 and mx5 today
<ogra_> infinity, what do we do about preinstalled server ?
<Tinti> cvanvliet, I really would like to have this
<infinity> ogra_: We leave it as-is for now.
<ogra_> i dont want to introduce alternate again
<ogra_> ah, cool
<infinity> ogra_: If x86 server switches to live, we'll follow suit.
<ogra_> cvanvliet, right, they are either beagle, panda or freescale mx5 based
<cvanvliet> netboot, server image (armhf), build up form ubuntu core, qemu-debootstrap
<infinity> ogra_: Most sane server users install from d-i netboot anyway, regardless of the platform.
<cvanvliet> ogra I have a gumstix
<ogra_> infinity, they dont switch to live, they just use a squashfs in d-i
<Tinti> the tutorials seems to be old in fact no?
<Tinti> at least on wiki
<ogra_> right, server on omap or omap4 is mostly intresting as minimal dev image
<infinity> ogra_: That's a "live-style" install.
<ogra_> well, its still d-i
<infinity> ogra_: As in, no more installing packages.
<ogra_> :)
<ogra_> right
<infinity> ogra_: ubiquity is d-i.
<ogra_> pfft, yeah
<infinity> I see this as "text ubiquity". :P
<ogra_> k ... so i wont touch server ... thats good
<ogra_> wrt install speed live is pretty horrid btw
<ogra_> especially the partitioner takes like 5min after you clicked anything
<ogra_> my test install took about 90min until it failed in the bootloader install
<infinity> That seems odd.
<infinity> The 5m partitioner thing, I mean.
<infinity> I expect the copy to be slow, not much else.
<ogra_> thoguh i'm trying out the slowest HW combo i can atm
<infinity> Oh, installing to a USB stick?
<cvanvliet> ogra, the live installs ar armhf? I assume
<ogra_> i.e. installing to an SD in a cardreader as target
<ogra_> cvanvliet, everything is armhf
<ogra_> we dropped armel last release
<cvanvliet> yep
<cvanvliet> armel is dropped after precise ?
<ogra_> while the archive is still there it is currently largely unmaintained and we dont roll any images for that arch
<infinity> cvanvliet: We didn't ship armel images for precise either.
<infinity> cvanvliet: Just netboot images (which we still ship).
<cvanvliet> there is a core though
<ogra_> and its likely it will be completely dropped before final release
<cvanvliet> infinity, it wont find my ethernet
<ogra_> file a bug and ask for the NIC driver module to be included in the installer
<ogra_> (file it against linux and debian-installer)
<infinity> We might not have the driver at all, if this is an SoC we don't support.
<ogra_> gumstix ?
<ogra_> should all be in mainline
<infinity> Or a device.
<cvanvliet> ok
<cvanvliet> the base is a Tobi board
<ogra_> never heard of that
<cvanvliet> I have to reconsider somethings now (re support of armel)
<cvanvliet> wish they would just release the drivers for armhf
<ogra_> they will at some point, all distros are switching
<cvanvliet> I feel that way to, but, I am trying to find the best tools for use (this is for my business)
<ogra_> ppisati, hmm, https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001440.html only talks about a 3.4 tilt kernel
<infinity> cvanvliet: Just keep pestering people in #beagle until an sgx drop appears, and let me know? ;)
<cvanvliet> infinity, you will know within seconds
<cvanvliet> I may also try Imagination (the powervr guys)
<infinity> We have PVR on armhf.
<infinity> Err, for omap4, that is.
<ogra_> just not for the chip in the beagle
<infinity> YOu could just switch SoCs. :)
<cvanvliet> they are in the UK, and may have a symapthetic ear for a UK startup :p
<cvanvliet> sorta
<cvanvliet> that was my thinking above in my reconsider
<infinity> I suspect they won't do much for you.  Their licensees are the ones who are responsible for code drops.
<infinity> (In this case, TI)
<cvanvliet> ok
<ppisati> ogra_: it's a 3.4 + all linaro stuff
<ogra_> ah, k
<ppisati> ndec: AFAYK, FB_OMAP + DSS is enough to get decent video support for omap3, right?
<ppisati> ndec: and what about DRM_OMAP?
<ndec> well, i think robclark tested DRM_OMAP on beagle...
<ppisati> ndec: DRM_OMAP and FB_OMAP can't live together
<ndec> if that works, that's what we should be using i think...
<ogra_> ppisati, and very very likely three tons of commandline options you need to set to even see a single pixel :)
<cvanvliet> I may be wrong but omap4 is not industrial grade
<ogra_> if not five tons
<ogra_> (metric tons)
<infinity> cvanvliet: Define "industrial grade".
<ppisati> the problem is that, FB_OMAP i get /dev/fb, right?
<ppisati> while with DRM_OMAP do i need an external video driver? like pvr or what?
<ogra_> well, fb0
<ogra_> but yeh, that should be the difference
<cvanvliet> infinity, that was the answer I got form our supplier, only yesterday, I have to follow that up
<ogra_> (for details ask koen in #beagle ;) )
<robclark> w/ omapdrm you will get a /dev/fb0 as well.. and xf86-video-omap will work without pvr (but without accel)
<infinity> cvanvliet: I mean, what do you mean by "industrial grade".  Are you building life-and-death-critical systems, telco backbones...?
<ppisati> robclark: so, which one is better/the right one? DRM or FB_OMAP?
<ogra_> robclark, on omap3 ?
<infinity> cvanvliet: Or is it just about wanting "reliable parts"?  In which case, omap4 seems to be good enough for Amazon and HP (and many others).
<infinity> ogra_: He claims all the way back to omap2, though not tested. ;)
<ogra_> heh
<robclark> ogra_, it should work on omap3..  admittedly it gets tested more on omap4, but I'll fix bugs if there are any on omap3
<robclark> infinity, some of the o3 based parts (and other various parts) are avail in industrial package for harsh environments
<infinity> robclark: Ahh, kay.
<infinity> robclark: Again, I'm curious if that's actually what cvanvliet needs.
<cvanvliet> infinity, yeah our supplier is generally in that area, and we may be at a later point, but not right now.
<cvanvliet> but, they already haev a product, very similar to what we need
<cvanvliet> so we donât have the engineering costs
<cvanvliet> and we can tweak it a little
<cvanvliet> to suite our stuff, it is based on omap3 (igep boards)
<cvanvliet> infinity, it is more which is the easiest (and cheapest ) way for a self backed start up :)
<infinity> cvanvliet: Absolutely.  Build-your-own hardware isn't a sane way to startup, unless your business model is, in fact, designing hardware.
<cvanvliet> but our stuff is not life or death, that is for sure
<cvanvliet> so that is why I want 12.04, armel, SGX in omap3
<cvanvliet> we do a lot of 3d display
<infinity> cvanvliet: Check.  Well, we'd all prefer if we could make that be armhf (but until we see an sgx driver, meh), but there's certainly no one stopping you from using 12.04 armel.  It's not "officially supported", but it's not going away for 5y either.
<cvanvliet> i just need to get it going ;)
<cvanvliet> infinity, we make things like hawk-eye for sports
<infinity> cvanvliet: Sounds fun.
<cvanvliet> accelerometers, forceplates,  camera etc
<cvanvliet> starting in golf industry
<infinity> Sounds like an industry where price-point isn't dead critical, and omap4 might be viable.
<cvanvliet> yes
<infinity> (And I can't think insane durability is important either)
<infinity> Not that I'm recommending you start from scratch. :P
<GrueMaster> Depends on if you are hitting the device with a driver.
<cvanvliet> we have enough to do as it is
<infinity> Starting from scratch every 6 months leads to Duke Nukem Forever disease.
<GrueMaster> Most electronics don't take well to being clubbed.
 * ogra_ prefers hiting devices with wrenches
<cvanvliet> GrueMaster, Xbee plus arduino can fly 30 metres ;)
<cvanvliet> when gaffa tape breaks on a golf club :p
<GrueMaster> Heh
<ogra_> drivers look so new-rich ... wrenches are more "male" :)
<ppisati> uhm
<ppisati> is it normal for my board to use fbdev?
<ogra_> yes
<ppisati> well
<ogra_> on all arm boards
<ppisati> X says i'm having a 1280x720 display
<ppisati> but to me it looks like 640x480
<ogra_> (until we are installing SGX or whatever)
<ogra_> thats omap3 ?
<ppisati> yes
<ogra_> well, as i said, three tons of cdmline options
<ppisati> i'm using FB_OMAP here
<ppisati> with
<ppisati> vram=12M omapfb.mode=dvi:1280x720MR-16@60
<ppisati> isn'it enough?
<ppisati> and what do we use for our installer?
<ogra_> nothing
<ppisati> so how does it work?
<ogra_> we always asked the kernel team to set a proper default :P
<ppisati> uh?
<ogra_> and with the merge of omap in mainline that default should have been carried over
<ogra_> it likely wasnt though and we need to set a cmdline option again to get a proper mode
<ogra_> i remember in the first images we had omapfb.mode=dvi:1280x720MR-16@60
<ogra_> but i'm not even sure the option is still called like that
<rcn-ee> it is, just not for omapdrm/kms..
<GrueMaster> Note that the above setting is for wide screen.  Looked like crap on my 19" standard LCD monitors.
<ogra_> well, he built with FB_OMAP
<rcn-ee> yeap, so it should work. ;)
<ogra_> not DSS
<GrueMaster> I used 1280x1024.
<ppisati> so, in P we were using FB_OMAP
<ppisati> so, either we passed something in the cmdline
<ppisati> or i don't know
 * ppisati trying with a kernel with FB_OMAP
<rcn-ee> once it's up, can you access /proc/cmdline...
<ppisati> rcn-ee: talking about the installer
<rcn-ee> the older d-i? or the live-cd thing..
<ogra_> ogra@nusakan:~/branches/debian-cd$ grep omapfb tools/boot/quantal/post-boot-armhf+omap
<ogra_>     v_opts="vram=12M omapfb.mode=dvi:1280x720MR-16@60"
<ppisati> the one that we use with the preinstalled-omap image
<ogra_> ppisati, you are right, we do set it on omap3
<ppisati> ok, cool
<ogra_> probably needs some adjustments
<GrueMaster> Too bad it can't do autodetect.
<ogra_> i was promised autodetection for ages
<rcn-ee> it was set to that, since the default u-boot value was so small.. http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/omap3_beagle.h;hb=HEAD#l229
<ogra_> a bitz longe than i was promised unity 3d on arm (which only twook 2 years)
<rcn-ee> actually autodetection works pretty good with v3.3/3.4 (omapdrm/kms) on the beagle. ;)
<ogra_> "pretty good" ?
<ogra_> like every tenth time ? on every second board ?
<ogra_> or is it already reliable
<ppisati> rcn-ee: so, what's the difference between drm and fb_omap?
<rcn-ee> works on my 4-5 monitors.. (but until recently it wasn't stable enough to push to all users)
<rcn-ee> both use omapdss internally. ;)
<rcn-ee> ppisati, you better ask robclark, he wrote alot of the omapdrm/kms stuff.. i just enable/tweak it...
<ppisati> robclark: ^
<robclark> omapfb is using old fbdev driver infrastructure/interface..  omapdrm is using drm/kms..
<robclark> short version, w/ omapdrm you can get xrandr
<robclark> (and dri2, hotplug detection, etc)
<ogra_> well, if its stable i'm all for switching
<ppisati> robclark: any drawback?
<ppisati> btw, just compiled in fb_omap, X is up, but i don't have any output
<robclark> well.. omapdrm is newer... sometimes exposes some issues in omapdss, relies on monitors to have sane EDID (although more recently there is some drm bootargs added to allow reading EDID from firmware file to deal with broken monitors)
<ppisati> omapfb omapfb: no driver for display: dvi
<ppisati> uhm
<rcn-ee> ppisati, this is 3.4 or 3.5?
<ppisati> 3.5
<rcn-ee> ah, haven't figured that one out yet, it was broken in rc3 last tried, sorry..
<ppisati> rcn-ee: are you saying fb_omap is broken somehow?
<rcn-ee> with 3.5-rc3, it oppes'ed on my beagle_xm, and the display didn't come up, didn't dig into to much as i'm mostly on 3.4.x at the moment.. but the stuff for rc4 probally fixed that..
<ppisati> this time fb seems to be ok
<ppisati> fbcvt: 1280x720@60: CVT Name - .921M9-R
<ppisati> but i still get an ugly 640x480
<ppisati> any idea how to debug this?
<GrueMaster> ppisati: What does xdpyinfo thing the resolution is?  And does your monitor display the incoming signal info?
<rsalveti> ogra_: edid autodetection should work on omap3 just fine
<rsalveti> it was supported by upstream since 3.2 I believe
<rsalveti> if you're using omapfb with panel-dvi you should also get edid detection
<ppisati> rsalveti: panel-dvi?
<rsalveti> CONFIG_PANEL_DVI
<rsalveti> drivers/video/omap2/displays/panel-dvi.c
<rsalveti> this is based on an implementation I had for quite a while ago
<ppisati> rsalveti: it seems they killed it in 3.5
<ppisati> ls -la drivers/video/omap2/displays/*dvi* | wc -l
<ppisati> 0
<rsalveti> could be, let me check
<rsalveti> omapdrm should probably be replacing most of the stuff
<ppisati> trying that right now
<ppisati> PANEL_TFP410?
<ppisati> ok, it was renamed
<rsalveti> ppisati: yup
<ppisati> rsalveti: so i assume i need to change cmdline too
<ppisati> rsalveti: from omapfb.mode=dvi:1280x720MR-16@60 to omapfb.mode=tfp410:...
<ppisati> btw, enabling DRM_OMAP didn't give me any /dev/fb*, what's wrong?
<ppisati> robclark: ^
<robclark> ppisati, if using omapdrm, then omapfb.mode won't do anything.. but you also shouldn't need it..
<robclark> but possibly the kernel is not registering the platform device?
<rsalveti> ppisati: you don't need any cmdline for this panel as well
<ppisati> wait
 * robclark wonders what kernel we are talking about?
<ppisati> robclark: didn't you say that with DRM_OMAP we would get a /dev/fb, right?
<ppisati> robclark: foerget about the omapfb stuff, i'm testing DRM and FB_OMAP in parallel
<ppisati> 3.5rc3
<robclark> yes, you will..  but only if the driver is loaded (which it won't be if the device is not registered)
<robclark> if pure upstream kernel, there is one patch you need
<ppisati> robclark: it's pure upstream
<robclark> k, hang on
<ppisati> rsalveti: on the other hand, with FB_OMAP we always passed omapfb.etcetc
<rsalveti> ppisati: but it's not needed with this panel, afaik
<ppisati> rsalveti: uhm ok
<robclark> ppisati, http://permalink.gmane.org/gmane.linux.ports.arm.omap/77544
<ppisati> robclark: ack, i'll try
<ppisati> robclark: added your patch on top of 3.5rc3, got /dev/fb0 but still no output
<ppisati> anywa, i'm off for the day
<robclark> ppisati, I guess next step, turning on omapdss.debug=1 and possibly drm.debug=7 in bootargs and then start havign look at the log
<Pokinawa> hello people....
<Pokinawa> anyone here work at ARM? :P
#ubuntu-arm 2012-06-23
<Ghost0s> Hello :)
<Ghost0s> is there plans to get ubuntu work on arm proc
<gildean> Ghost0s: it has been working for quite some time, if you count powerpc-versions too
<Ghost0s> ?!
<gildean> !!
<Ghost0s> i dont undertand sorry
<gildean> which part?
<Ghost0s> it has been working for quite some time
<gildean> ehich part of that is unclear?
<Ghost0s> please i want to know if i canr run ubuntu on arm
<Ghost0s> if no is there plans to make it run on arm
<gildean> depends on the hardware and ubuntu version
<Ghost0s> armv7
<gildean> current version only works on armv7
<Ghost0s> no sorry arm v6
<gildean> then you either have to use and older ubuntu, or check out debian
<Ghost0s> what are those old ubuntu's
<Ghost0s> please
<Ghost0s> hello gildean can you help please
<gildean> Ghost0s: iirc maverick was the last one to support v6
<gildean> you could just google for yourself
<gildean> what device/board are you using exactly?
<Ghost0s> raspberry
<gildean> did you read the /topic ?
<Ghost0s> sorry but my progect consist of ubuntu
<Ghost0s> !!!
<gildean> well, i think i've seen someone say you might be able to run jaunty (9.04) on the pi
<gildean> but other than that, the only thing i can do is point towards debian
<Ghost0s> thanks but i found that ubuntu 11.04 work on arm v6
<Ghost0s> is it gooood
<gildean> well you'll have a hard time running a desktop on the pi, but something like a lightweight nodejs server might work
<gildean> or just any light server usage
<Ghost0s> no problem with pi
<Ghost0s> ?!
<gildean> i haven't heard anyone using ubuntu on the pi
<gildean> but it doesn't mean it can't be done
<gildean> you'll have to try for yourself
<gildean> good luck
<Ghost0s> ok thanks a lot man but i know raspberry but until now i dont understand what mean Pi
#ubuntu-arm 2012-06-24
<infinity> ogra_: Do you have a non-ES Panda that I could get you to install a natty kernel on for me to experiment with?
<infinity> janimo: Or you?
<infinity> GrueMaster: Or you, if you still have a bunch of hardware collecting dust.
<stgraber> infinity: I have one
<infinity> stgraber: \o/
<infinity> stgraber: Could you install a fresh natty headless on it and give me root?
<infinity> stgraber: And maybe attach a USB disk, so I don't go insane?
<infinity> stgraber: One way or another, I'm going to fix this &^#$% mono/armel thing.  But, after my last round of fixes, I can no longer break it on my PandaES. :/
<infinity> stgraber: (So, I'm blaming the natty kernel, until I can prove otherwise)
<stgraber> infinity: installing natty should be easy, finding a usb disk will be trickier ;)
<stgraber> the only usb storage I have around is my n900, not sure it's going to be a lot faster than the sdcard :)
<infinity> stgraber: If the SD is big enough to build mono on, that'll work, I suppose.
<infinity> stgraber: Unless you have an NFS server you could cut me a slice of.
<stgraber> sure, nfs is easy
<infinity> Anything's better than SD. ;)
<infinity> Some sort of tiny-magnets-over-IP would do.
 * infinity knew he shouldn't have given Andy his old Panda.
<stgraber> /dev/mapper/external-adam  3.7T   56G  3.5T   2% /data/external/adam
<stgraber> ^ should be enough for mono
<infinity> I should hope so.
<stgraber> infinity: got IPv6 over there?
<infinity> No, I live in the past.
<infinity> I should fix that.
<infinity> But not this evening.
<stgraber> ok, I'll have to do some old school natting then...
<infinity> Well, I could install that ghetto tunelling thingee.
<infinity> Whatever it's called...
<infinity> Right, miredo.
<infinity> I can do that.
<stgraber> ... waiting on sdcard ...
<infinity> Welcome to the life of an ARM porter.
<infinity> It's amazing how well you learn to multitask when you're always waiting on slow hardware.
<stgraber> now that we have PXE in uboot I should really just make a kernel + initrd that lets me boot from nbd :)
<infinity> That would work.  Not sure if natty would do that, though.
<infinity> precise should.
<infinity> (But I need natty today, so that doesn't help)
<stgraber> booting
<stgraber> infinity: getting nfs on the board and it'll be good to go
<infinity> stgraber: \o/
<stgraber> infinity: ssh ubuntu@sateda.stgraber.org -p 9922
<stgraber> infinity: you should have password less sudo working on it
<stgraber> infinity: and the nfs in /data
<stgraber> infinity: I didn't apply any update but I reboot tested the current install, so if you need you should be able to upgrade, reboot and get ssh working again :)
<infinity> stgraber: I'll be working in quantal chroots anyway, don't care if the base system is up-to-date, except for kernels.
<infinity> Though, yeah, updating the kernel to a newer natty one might happen. :)
<infinity> Dear NFS, 4294967294 might not be a valid UID, please to be checking your integer operations.
<stgraber> oh, fun...
<stgraber> infinity: looks like I was missing nfsvers=3
<infinity> stgraber: Oh, should I stop what I'm doing and let you remount?
<stgraber> infinity: yeah, I think it's best
<infinity> Go nuts.
<stgraber> infinity: fixed, uids look good now
<infinity> And now it's sticky!  Yay, giant tmp.
<infinity> (Not that I care)
<stgraber> infinity: is it? it's 777 but I don't see the sticky bit here
<infinity> Oh, that's just ls --color confusing me.
<infinity> The coloring for 777 and sticky are awfully similar.
<infinity> (But not identical, when I look closer)
<infinity> stgraber: Do you have a local mirror of ports?  ports.u.c seems a bit slow from your network.
<infinity> (I'll quit whining and just wait longer)
<stgraber> infinity: nope, not enough ARM hardware around to justify it... though that means it's getting into squid now, so will be fast next time I want to get a quantal armel chroot ;)
<infinity> Heh.
 * infinity notes that almost every computer in his house except two relies on ports.
 * infinity notes that it's also a bit nerdy to say "every computer except two", as if everyone has more than two...
<stgraber> infinity: as for speed, for some reason Canonical's network is badly routed tonight... let me see if I can fix that quickly
<infinity> stgraber: It's always badly-routed for me.  I bounce through a GRE tunnel in San Jose to "fix" it.
<infinity> stgraber: Which is just hilariously silly.
<stgraber> yeah, I'm trying to "fix" it by getting it over IPSEC to my server in Germany
<stgraber> much better! let me quickly apply that to ports now :)
<infinity> Your bad routing looks less crap than my bad routing.
<infinity> You at least get what looks like a clear path through L3.
<infinity> I end up deep in some reeeeeealy old as6809.net links in the Netherlands.
<stgraber> I guess teksavvy has some load issue with some of their IPv4 peers... The new "route" goes over IPv6 to Germany, then back over IPv4, that should workaround that problem.
<stgraber> hmm... looks like IS hasn't investigated that routing weirdness I've had for 2 weeks now in Germany...
<stgraber> basically, half of the Canonical subnet gets routed from Germany to the US (Boston IP) then back to London, increasing the latency quite a bit
<infinity> That's pretty fun...
<infinity> Also, I think you broke my routing mid-debootstrap.
<infinity> I just realised it's been downloading util-linux for the last few minutes.
<infinity> Oh well, squid should make a retry fast.
<infinity> Oh!
<infinity> Or you broke MY routing to YOU.
<infinity> Oh, no.
<infinity> It was the former.
<stgraber> yeah, I guess wget doesn't like the route changing in the middle of a download
<infinity> No, there's actually a bug open about that.
<infinity> wget seems to fail miserably at timing out.
<stgraber> infinity: routes from Germany => http://paste.ubuntu.com/1056968/ (at least it's "only" adding 80ms when going through the US)
<infinity> Haha.  Oops.
<infinity> I suspect that falls firmly in the "BGP is haaaard" bucket.
<stgraber> well, I'm not sure how Canonical's BGP is setup, but Boston should only announce the local subnet with a weight of 0 and bump the weight of the London subnets quite a bit to avoid that kind of weirdness
<infinity> Ideally, yes.
<infinity> But, for all the people who know how BGP works, it's remarkably rare to meet people who know how to implement it correctly.
<infinity> I consider it a minor miracle that the Internet mostly functions, most days.
<infinity> After having working for some T1 carriers.
<stgraber> hehe :)
<infinity> Maybe things have improved since I worked for PSInet in the late 90s, but man, it was a hilarious mess back then.
<infinity> And the revelation that routing is pretty much a massive exercise in trust was frightening.
<stgraber> well, I know most AS still allow all prefixes from their peers which leads to "interesting" things happening from time to time
<infinity> Which has led to fun foibles, like when Shaw advertised too broadly, and half of the traffic for the west coast of the US and Canada all jammed through one router in Vancouver.
<infinity> Turns out that was unpleasant.
<stgraber> at least people must have noticed pretty quickly :)
<infinity> Oh, we noticed in a hurry.
<gildean> it's really easy to mess up a whole network that relys on bgp
<infinity> As did MCI/UU, and a few others.
<infinity> The guy I talked to at Shaw's NOC said the phones lit up about 30 seconds after he answered my call.
<infinity> This is what happens, I suppose, when you let cable companies play on the Internets.
<infinity> It still shocks me how quickly Shaw went from "TV operator" to "operating one of the most reliable backbones in North America".
<infinity> But they still mess up peering on a regular basis.  Cause they're just that awesome.
<stgraber> :)
<gildean> infinity: and other isp's still peer with them?
<infinity> gildean: They're all idiots these days, from what I can tell.
<infinity> gildean: They've become much more forgiving. :P
<gildean> and i guess if they own enough actual cable, there's little choice
<infinity> The halcyon days of UUnet (err, MCI, err, Worldcomm, err, whoever they are now), PSInet, and Sprint owning 99% of the North American traffic and ruling with an iron fist are LOOOONG over.
<infinity> Honestly, if people are still willing to peer with Cogent, that's kinda proof that they'll peer with anyone who has customers.
<infinity> ... he says from a server sitting on a Cogent link (it's hard to argue with cheap).
<gildean> and these days it's quite easy to work around isp's routing problems, just open up a ipv6-tunnel
<gildean> as long as you got a point of precense somewhere near, it shouldn't rise the latency more than a couple of ms
<gildean> and the route to the pop actually works (and doesn't get bounced around)
<gildean> s/and/if
<stgraber> yeah, I quite like he.net for that ;) they have a pretty good network and a lot of points of presence so that's usually low latency too
<stgraber> though nowadays I've got native IPv6 pretty much everywhere (most of them still using HE.net for transit though)
<gildean> stgraber: no native ipv6 from my isp
<gildean> sucks balls
<gildean> i use a sixxs tunnel, they had a pop righ near to me
<gildean> ping to pop is about 13ms
<_raven> hi
<_raven> do you have some experience with linux on Raspberry PI?
<lilstevie> _raven: topic
<lilstevie> is there a armhf deb floating around yet for nvidia-tegra drivers?
<GrueMaster> infinity: Still need a panda?
<infinity> GrueMaster: Nope, stgraber hooked me up.
#ubuntu-arm 2013-06-17
<pelmen> Hello to everyone! I have a problem with Ubuntu 13.04 on an ARM device Samsung Galaxy Note 10.1. It just doesn't boot. I am creating rootfs with LinuxDeploy and self-compiled kernel was packaged in this Ubuntu chrooted with mkinitramfs and abootimg. The same recovery boots Debian and kali Linux, so I think it's an issue with init. Last message I see is about successfully mounting rootfs.
<pelmen> Anyone knows what's the problem?
<pelmen> It's the wrong channel or no one is here? :)
<chaitanyapramod> Hi, I got myself stuck while using Ubuntu Desktop on Nexus 7. Is this the right place to ask for help?
<user_> can someone tell me a quick and dirty method to use the raring bootimg with a new kernel or hack the initrd to not run installer?
<user_> trying to put a new zimage on nexus 7 ubuntu desktop
<user_> if I just replace the kernel in rootfs.tar.gz and reinstall will that work?
<user_> why is there a kernel in both places, bootimg and the rootfs
<user_> sure is quiet for 148 people in this channel
<user_> right then. I'll leave this mutual admiration society to it's own devices.  o/
#ubuntu-arm 2013-06-19
<mijk> hey
#ubuntu-arm 2013-06-20
<pelmen> Hello! Anyone here ready to help with booting?:)
<k1l_> pelmen: if you give alot more details people in here can try to help :)
<pelmen> I have once given but nobody answered for an hour, so it's second attempt :) I'm trying to boot ubuntu rootfs on Samsung Galaxy Note 10.1
<pelmen> Created from chroot an initramfs, incorporated to recovery, but when booting it gets stuck somewhere
<Mqax> hi all, i have a smartpad based on iMAPX210 processor (that should be an arm11 based) is possible to run ubuntu on it?
<pelmen> What is more, the same recovery boots debian rootfs
<Mqax> i didn't understand pelmen, are you speaking with me?
<vipzrx> hello
<vipzrx> $ tftp 192.168.10.38
<vipzrx> tftp> status
<vipzrx> Connected to 192.168.10.38.
<vipzrx> tftp> get test
<vipzrx> Transfer timed out.
<phh> cool.
<vipzrx>  http://paste.ubuntu.com/5783426/ the tftp error log
<vipzrx>  who can help me ?
<vipzrx> phh: hello
<benbloom> !ask | vipzrx
<ubot2> vipzrx: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<benbloom> can someone point me to info on how to change kernel parameters in uboot? I'd like to mount rootFS noatime and put /var/log in a ramdisk to prevent excessive wear on the micro SD card I'm using as rootFS
<infinity> benbloom: Is adding noatmie to the entry for / in /etc/fstab not good enough?
<benbloom> infinity: when I try 'sudo mount -o remount,noatime /' I get 'mount: / not mounted or bad option' my appropriate fstab entry is '/dev/mmcblk0p1   /   ext2   noatime,data=writeback   0   1' am I missing something basic here?
<dannf> benbloom: i don't think ext2 supports a data= mount option
<benbloom> interesting. i'll try without dannf
#ubuntu-arm 2013-06-21
<vipzrx> hello
<applejacks10101> whats the arm chip that ubuntu current supports?
#ubuntu-arm 2013-06-22
<JJG> anyone seen TypoNAM around ?
<clayjar> Hello. I wonder if this is the right place to ask this, but how do you resolve "AddScreen/ScreenInit failed for driver 0"  I've searched and could not come up with a resolution yet. Thanks for any help.
<clayjar> I'm trying to get X window manager to open on an ARM processor.  Running Ubuntu 13.04.
<clayjar> I've installed xserver-xorg-video-armsoc as well.
<clayjar> I'm not sure where I have to go or look to reconfigure... dpkg-reconfigure only seems to be applicable for x11-common.
<clayjar> Okay, found the answer at http://wiki.debian.org/InstallingDebianOn/Samsung/ARMChromebook.  Use the Xorg.conf snippet found there and create the file under /etc/X11/xorg.conf.
<clayjar> chao.
#ubuntu-arm 2013-06-23
<mijk> anyone use Ubuntu on their TF201?
<mijk> I'm getting conflicting guides on installing it
<mijk> nVidia has Tegra 3 drivers for Linux but some people are saying that it's only debugging
<mijk> linux as a whole, not the drivers
#ubuntu-arm 2014-06-16
<vroomfondel|2> list
<vroomfondel|2> sorry
#ubuntu-arm 2014-06-17
<victorp> ogra_, ping
<ogra_> victorp, yo
<victorp> ogra_, quick one what is the ppa to get the phablet screen shot script working in trusty?
<ogra_> victorp, phablet-tools from phablet-team ... the fix landed last night, not sure if the PPAs have been updated yet
<ogra_> bug 1327139 has a link to a branch with the fix, you can easily hack it in manually if the PPA doesnt have the new packages yet
<victorp> ogra_, oh, might be a different fix to what I was thinking :)
<victorp> I should set up the ppa anyway :)
<ogra_> yeah, unless you use utopic ;)
<thewisenerd> Hi, wanted to know if I could multiply a variable with a floating point number in the kernel?
<rahul_> Hii all
<rahul_>  i am try to install ffmpeg over ubuntu 14.041 on beagle bone
<rahul_> but getting error
<rahul_> any one here
<rahul_> http://bpaste.net/show/PHQe2fzvhn98z3lEhRNo/    these errors i am getting
#ubuntu-arm 2014-06-19
<yang> I received Utilite Computer, and I don't get any picture on TV, via HDMI-out ?
<yang> I assume that even if there is no OS installed on it, there should be a picutre via HDMI-out ?
<yang> How should I proceed ?
#ubuntu-arm 2014-06-20
<Frank__> I'm trying to build an ARM image to boot in QEMU
<Frank__> this page tells me to install 'linux-image-versatile' https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap#Kernel
<Frank__> Except that package only exists in lucid, not in precise
<Frank__> Which package do I need to install the latest kernel belonging to precise?
<Frank__> Someone in #ubuntu helpfully pointed out that the manual i'm following is outdated. Is there a newer one somewhereL
<Frank__> ?
#ubuntu-arm 2014-06-22
<dljacobs> How's everyone doing tonight?
<Bludot> Hello?
#ubuntu-arm 2015-06-15
<Martyn> Hey all.
#ubuntu-arm 2015-06-18
<awafaa> dannf: have you encountered http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346135.html ? I asked infinity but didn't realise he wasn't up to date kernel wise
<dannf> awafaa: i haven't , but i also haven't done much testing w/ post-3.19 kernels yet
<awafaa> dannf: ok thanks, hopefully we can get it fixed before you run into it then
<dannf> awafaa: yeah, well - at least the right people seem to be engaging
<dannf> on the thread
<awafaa> yup
<infinity> dannf: You were supposed to say "yeah, I test the tip of mainline every day, WTF man, your bugs suck".  I was counting on you here. ;)
#ubuntu-arm 2015-06-21
<jimcornette> ping ogra_
<jimcornette> do you know if the desktop for nexus 7 works on the nexus flo ?
<ShulginDeploy> Ð¿Ð¾Ð¼Ð»Ð³Ð¸ÑÐµ ÑÐ¾Ð±ÑÐ°ÑÑ ÑÐ´ÑÐ¾ Ð´Ð»Ñ huawei y220-u10 Ð½Ð° ubuntu trusty Ñ Ð¿Ð¾Ð´Ð´ÐµÑÐ¶ÐºÐ¾Ð¹ usb host mode
<ShulginDeploy> Ð¿Ð¾Ð¼Ð¾Ð³Ð¸ÑÐµ ÑÐ¾Ð±ÑÐ°ÑÑ Ð¸Ð»Ð¸ Ð¿Ð¾Ð´ÑÐºÐ°Ð¶Ð¸ÑÐµ Ð³Ð´Ðµ ÑÐºÐ°ÑÐ°ÑÑ usb Ð´ÑÐ¾Ð²Ð° Ð½Ð° arm7
<ShulginDeploy> hi. give me please link to usb tools for ubuntu trusty. my device is a Huawei y220
<ShulginDeploy> needs usb host mode for this device
#ubuntu-arm 2016-06-22
<marvin24> are there any debug packages for mesa available?
<marvin24> http://packages.ubuntu.com/source/xenial/mesa lists none
<marvin24> just asking 'cause the software renderer is crashing with "illegal instruction" on my cortex-a9 (without neon)
<lsodl9oq> hello
<lsodl9oq> myfather wants to doubuntu arm
<lsodl9oq> is there a link to downlaod nad install instructions for pi 3
<pekkari> I guess this might work https://wiki.ubuntu.com/ARM/RaspberryPi
<lsodl9oq> he Raspberry Pi 3 does not (yet) work with official Ubuntu images out of the box, but unofficial images are available.
<lsodl9oq> hello
<lsodl9oq> so whatis the meaning of unoffical ? iamges unsupported?? what is the disadvantage of using unofficial images??
<lsodl9oq> pekkari:
<pekkari> I guess so, actually it's stated in the very same link, that it's not officialy supported
<pekkari> or not directly
<lsodl9oq> pekkari: do u use arch arm?
<lsodl9oq> know how to operate it?
<lsodl9oq> arch desktop?
<pekkari> arch linux? at some extend, yes
<pekkari> I didn't heavily use it, but I did some experiments to complete the setup, and see what is the pros and cons of it
<lsodl9oq> ubuntu people generally dont use arch
<lsodl9oq> have you tried openbsd, what is your opinion on that pekkari
<pekkari> it depends in your own interest on knowing what are the components of a linux distribution, the philosophy behind it, and what it fits your usecase
<lsodl9oq> yes i was asking you
<pekkari> I used freebsd for some testing purposes
<lsodl9oq> who recommendd that to you?
<lsodl9oq> friends
<pekkari> knowing linux, it was a bit confusing, but it wasn't that difficult to try it
<lsodl9oq> dont get from where they know to use freebsd,netbs
<lsodl9oq> so you from bsd to linux, strang
<lsodl9oq> s/strang/strange
<pekkari> actually the opposite, I use linux heavily, but I can use freebsd as well
<pekkari> it wasn't a recommendation to use it, I just needed to create some freebsd setup, and I did it
#ubuntu-arm 2017-06-24
<jeromelanteri> hello, some people here know about odroid-xu4 support for mali GPU ?
#ubuntu-arm 2018-06-21
<genii> Hello. Just curious if anyone is running Ubuntu on a Qualcomm mobile development platform like https://developer.qualcomm.com/hardware/snapdragon-845-hdk and if so, how are you finding it so far?
#ubuntu-arm 2018-06-22
<ex-parrot> still keen to hear from anyone running Bionic on a Pi 3
<ex-parrot> I couldn't get HDMI audio working
#ubuntu-arm 2018-06-24
<George_> Hi. I'm trying to get Ubuntu to boot on my omap zoom2 but the leds are just green for a second and seems to boot loop. I don't have the debug board. Can anyone help me?
<tpw_rules> hey so i have ubuntu 16.04.4 for arm running on my odroid xu4. i did an apt update && upgrade and now update-initramfs is hung. Processing triggers for initramfs-tools (0.122ubuntu8.11) ... update-initramfs: Generating /boot/initrd.img-4.14.5-92 is what it has been doing all night. this morning i killed dpkg and ran dpkg --configure -a to restart it and it doesn't seem to be doing much better
<tpw_rules> update: it turned out to be a screwed up mount point somehow? a reboot fixed it
