#ubuntu-arm 2009-07-06
<high-rez> Any of you know the proper format is for setting the framebuffer mode on the beagleboard?  It seems there are three different formats, and I'm not sure which the ubuntu kernel prefers :|
<mcasadevall> L84Supper, there are known issues unfortunately; I've been working with KDE upstream to resolve them
<L84Supper> mcasedevall : good news
<mcasadevall> L84Supper, what are you currently trying to build?
<L84Supper> mcasedevall : I was going to try a few 2D graphics apps like Scribus, GIMP, Krita, Inkscape etc this week
<L84Supper> cairo and a few other libs use doubles vs float
<L84Supper> or so I've been warned
<ogra> high-rez, heh, since there is no ubuntu kernel for the beagelboard its really up to the third party kernel you use ...
<ogra> high-rez, http://elinux.org/BeagleBoardUbuntu has a link to properly maintained third party kernels and i would assume the u-boot settings used in the doc match the kernel
<dirk2> Just fyi: From running build-arm-rootfs script from http://people.ubuntu.com/~ogra/arm/build-arm-rootfs I get two error messages from created installer script within qemu arm:
<dirk2> http://pastebin.com/d6660cdde
<dirk2> But seems that installation finishes fine, though
<dirk2> ogra: From running build-arm-rootfs script from http://people.ubuntu.com/~ogra/arm/build-arm-rootfs I get two error messages from created installer script within qemu arm:
<dirk2> http://pastebin.com/d6660cdde
<dirk2> But seems that installation finishes fine, though
<ogra> so the script finishes ?
<dirk2> yes
<ogra> then its not critical
<dirk2> yes, but I just thought to mention it ;)
<ogra> if there are actual critical errors the script will die
<ogra> yeah, i know about both, thanks ... i'll drop the loopback call that iniscript was dropped at some point
<dirk2> ok, will drop loopback locally then, too
<ogra> the other warning is simply a nonused missing feature in the versatile kernel i rolled
<dirk2> ok, thanks
<ogra> the next generation of the script (called project-rootstock now) will use the packaged versatile kernel instaed
<dirk2> With http://people.ubuntu.com/~ogra/arm/build-arm-rootfs I built a ubuntu-minimal. Does this include xserver? I'm running it on Overo, and have console on LCD login.
<ogra> no, ubuntu-minimal doesntinclude any X bits
<ogra> it only installs the bare minimum to boot an ubuntu
<dirk2> ok, yes, login looks like this ;)
<dirk2> I have to install ubuntu-destop?
<dirk2> erm, desktop
<ogra> if you want an xserver just install the xorg package if you are lazy
<ogra> (that pulls in all possible video drivers though)
<ogra> indeed, if you want a full desktop install ubuntu-desktop
<dirk2> What's the easiest way for it having ubuntu-minimal already. I'm not sure if I can configure Overo for net access easily, so most probably the easiest way is via QEMU again?
<L84Supper> is Gnome or GTK in the plan for Ubuntu-arm?
<rjune_wrk> I would say that's likely. Ubuntu uses GNOME by default, and there is a Ubuntu Netbook Remix.
<bizkut> somebody already installed gnome desktop on shivaplug with USB lcd monitor
<ogra_> L84Supper, our live image for imx51 uses the standard ubuntu desktop
<ogra_> (the one we released in jaunty)
<Martyn> ogra : ICEing the Cortex-a9 kernel on PBX now :)
<Martyn> ogra : Turns out I can chainload redboot or u-boot from the ARM Monitor
<Martyn> so, either bootloader will work
<Martyn> although once I have UEFI running, that's going to be redundant
<ogra> lucky you
<Martyn> ogra : Lucky all of us
 * ogra pastes the famous lasts words of NCommander from #ubuntu-devel
<ogra> <NCommander> -rwxr-xr-x 1 mcasadevall mcasadevall 2.8G 2009-07-06 12:30 redboot.bin
<Martyn> if I can get this working fully, there's a better chance of getting Canonical interested
<Martyn> The -hell-?
<Martyn> what did he do to get redboot.bin up to 2Gb+?
<ogra> build it with the allowed toolchain
<NCommander> Martyn, don't try and build redboot with an arm-linux-gnueabi toolchain
<ogra> or one variant of the allowed ones we can currently use
<Martyn> Good lord
<Martyn> NCommander : But I have done so .. using the CodeSourcery chain...
<NCommander> M 2009-07-0
<NCommander> M 2009-07-0
<NCommander> er
<NCommander> -rwxr-xr-x 1 mcasadevall mcasadevall 497M 2009-07-06 12:35 redboot.bin
<NCommander> -rwxr-xr-x 1 mcasadevall mcasadevall 1.3M 2009-07-06 12:35 redboot.elf
<NCommander> I dunno what bugs me more
<NCommander> That the elf is 1.3M, or the binary is 397M
<NCommander> *497M
<Martyn> NCommander : -rwxr-xr-x 1 mbogo users 319022 2009-07-16 18:31 reboot.bin
<NCommander> Martyn, I can build the right toolchain with normal GCC, its just that isn't acceptable it seems
<Martyn> NCommander : That's more in line with my experience
<Martyn> Oop .. wrong binary
<Martyn> NCommander : -rwxr-xr-x 1 mbogo users 319022 2009-07-01 16:32 redboot_small.bin
 * Martyn hates not having cut and paste between parallels and OSX
<NCommander> yeah
<NCommander> Well
<NCommander> I wonder
<Martyn> but still, 300M+ is silly
<ogra> Martyn, our prob is that we're boud to the toolchain in the archive
<ogra> *bound
<NCommander> ogra, well, I might be able to build the toolchain we need out of the gcc-4.4 package with lool said would be an acceptable alternative if all else failed
<Martyn> ogra : Ouch
<NCommander> The question is does the 2.8GB redboot count as "all else failed" ;_)
<Martyn> ogra : The state of the eabi toolchain needs to be fixed
<Martyn> NCommander : I think so
<Martyn> NCommander : Something went very wrong there
<ogra> NCommander, depends if you really tried "all else"
<NCommander> Martyn, so you know the differences between the RTOS/baremetal toolchain, and the linux toolchain :-)?
<Martyn> NCommander : Some of the differences
<NCommander> Martyn, right, but you understand that its more or less near-impossible to build redboot with the normal linux one
<NCommander> (granted a massive universal size fluke)
<Martyn> NCommander : I'm not tasked to do toolchain fixes at my company until early Aug though
<Martyn> NCommander : I do, indeed.   That's why UEFI is more of a priority, and before it .. u-boot.
<Martyn> reboot is just going to have to be one of those intractable problems, or simply be left behind.
<NCommander> Martyn, ok, good, that makes sure I'm not mad
<Martyn> redboot rather
<NCommander> ^- ogra
<NCommander> Martyn, we managed to build redboot with an arm-linux-gnueabi toolchain in Jaunty by linking it against libc
<NCommander> obviously that was fragile, and now it broke :-)
<Martyn> Indeed
<Martyn> it really should be linked against ulibc
<NCommander> er
<NCommander> It shouldn't be linked against a C library
<NCommander> redboot is self-contained
<Martyn> if you're going to link it, use the smaller one
<ogra> we dont support ulibc
<Martyn> I know, I know
<Martyn> but you'll get a smaller build.
<ogra> th eonly minimal libc we have atm is klibc
<Martyn> oof
<NCommander> ogra, newlib :-P
<NCommander> Martyn, if we had a sane toolchain, the resulting binary won't import any symbols
<NCommander> the problem is glibc got stupid with the newest release, and started doing fun things w/ ELF files
<ogra> well, and newlib in the works which apparently gets you 3G redboots
<Martyn> Ick
<NCommander> ogra, er, that was glibc
<NCommander> newlib fails to link due to static protector
<Martyn> ogra : In order to suggest a UEFI boot chain for 9.10 .. is there still time to get it working to the point that I could make a case for it?
<Martyn> since UEFI/arm is almost done
<Martyn> Apple has put massive resources behind it.
 * NCommander sighs
<NCommander> -rwxr-xr-x 1 mcasadevall mcasadevall 603K 2009-07-06 12:47 redboot.bin
<NCommander> Its going the right size
<ogra> looks ok for a SD boot to me
<Martyn> Yep
<ogra> might be a bit big for flash ... which we dont use anyway
<Martyn> ogra : I do.
<ogra> in our image builds
 * Martyn only has 64K or 128K of NOR though
<ogra> we boot from SD and install to SD
<Martyn> so it's only big enough for u-boot
<NCommander> It doesn't boot though
<Martyn> ogra : One other question: How often does Canonical have a general meet-up to discuss the state and future releases of Ubuntu?
<ogra> its probably just slow beacuse its so overweight :)
<Martyn> 9.10, 10.x, etc...
<Martyn> Since the ARM side of things is certainly heating up.
<ogra> usually about a month to six weeks after the release
<ogra> definately
<Martyn> So 9.10 is already locked in?
<ogra> and i would love to see you at next UDS
<ogra> mostly, yes
<Martyn> I also want to be there.. so does my boss.
<Martyn> (wants me to be there)
<ogra> cool !
<Martyn> The problem is that we can't use Redboot.
<Martyn> it's useless on the server platform we're building, and excludes other hardware as well
<Martyn> I'm hoping to push UEFI
<NCommander> oooh
<ogra> our problem is that we dont have a sane u-boot yet
<NCommander> That's an improvement
<NCommander> The board powers on
<NCommander> But it doesn't print anything
<Martyn> ogra : What's broken in u-boot?
<Martyn> NCommander : Working with babbage2?
<ogra> misses features
<Martyn> ogra : Which ones are missing that are needed? (Since I am tasked with u-boot at the moment)
<NCommander> Martyn, sorta. Bababge2 requires redboot to do some voodoo to let it power on fully
<ogra> Martyn, i didnt review it yet, but lool wasnt impressed
<Martyn> ogra : current u-boot features I have working: Boot from NOR/NAND, boot from SD, ext2 filesystem suport, FAT filesystem support, network adapter (SMCxxxx) support, bootp, dhcp, tftp
<Martyn> I don't (yet) have USB support working since it's outside my project scope
<ogra> on B2 ?
<Martyn> In software sim for the Realview EB-Cortex A9
<Martyn> and Cortex-A8
<Martyn> (in uniprocessor and SMP)
<NCommander> ogra, er, can we publicly talk about that uboot?
<Martyn> I could trivially get it working on B2
<Martyn> NCommander : Although to bring B2 up, I have to do hardware voodoo to get various parts of the board up
<Martyn> also I don't (yet) have FB console support
<Martyn> so u-boot would only work on serial, which is annoying
<ogra> not more annoying than redboot
<NCommander> and loads easier to compile
<Martyn> No, but that's something that would be useful
<Martyn> Tell you what, why don't I spend tomorrow trying to get it running.
<Martyn> At worst, I waste 6-8 hours on the experiment
<ogra> sure ... put a shiny little dog on the framenuffer during init :)
<Martyn> ogra : The lack of INT13 is a pain
<ogra> ah, damned, someone had that idea before :)
<Martyn> For someone who is used to having BIOS video
<ogra> did you take a look at the beagle code ?
<ogra> they have at least a pic up early
<L84Supper> orga_ : ok, so there is support for OMAP and i.mx, what board is everyone using for i.mx development
<L84Supper> ?
<ogra> there is no support for OMAP
<Martyn> framebuffer costs a character bitmap table for ASCII, framebuffer init code, and either USB+keyboard stack(big) or raw USB keyboard stack(smaller)
<Martyn> there is no official support for OMAP
<ogra> right
<L84Supper> orga_ : hmm, somebody else mentioned OMAP
<Martyn> but that just requires a kernel change.  The bootloader might be flexible enough
<L84Supper> ok , just not official
<ogra> Martyn, i didnt say frambuffer console :) no need for an ascii table if you just dump a pic on the screen
<Martyn> OH!
<L84Supper> I'm going to try it on ARM 9
<Martyn> Heh, that's just useful to say that you entered the bootloader.
<ogra> the beagle just shows a fillscreen bitmap
<ogra> *full
<Martyn> I think pretty bootloader pictures are a waste
<L84Supper> Samsung S3C2440
<Martyn> One of my coworkers has the B2 all day, damnit
<ogra> steal it !
<Martyn> no, he's doing compiler optimization
 * ogra had to send his away to a colleague too :/
<Martyn> WAY more important than the work I'm doing
<ogra> not for me
<L84Supper> the netbook remix was great unless you had to configure something like networking on a 320x480 display
<ogra> tell him your work is more important for me, he should give you the B2 immediately ! :)
<Martyn> L84Supper : Don't get us started on Netremix
<L84Supper> you're sunk unless you can get panning going
<Martyn> ogra : LOL .. he's grumbling because I have access to the two PBX'es
<ogra> trade them ...
<Martyn> ogra : Even though he can't do any work on those until I get the kernel working
<ogra> who cares about PBX
<Martyn> I do.
<Martyn> those are the base platforms //all// Cortex A9 will be based on
<Martyn> even the NEC, Samsung, and other C-A9 based systems
<ogra> pfft ... thats the future ...
<L84Supper> my real only beef is the config screens not fitting vertically in the window so you have to guess at how many times you have to press "tab" to apply or cancel
 * ogra wants something that works *today* :)
<Martyn> ogra : And it's the future I live in .. so I that I can get U/ARM working on as many platforms as possible
<Martyn> C-A9 is where everything is going, and everything I'm working on is backportable.
<Martyn> (like UEFI)
<Martyn> L84Supper: Don't take this the wrong way, but that discussion really belongs in #ubuntu-devel
<Martyn> There's lots wrong with the remix, and grumbling about it (without fixing it yourself, or posting patches) is counterproductive
 * Martyn dances!   Kernel boot!
<ogra> note that its aimed at 1024x576 and wont be much more scalable downwards
<Martyn> It crashes hard after cpuidle .. but after three days, I finally have debug output.
<Martyn> WOOT
<Martyn> I might even get to init() today
<ogra> congrats
<ogra> now grab the B", quick !
<ogra> *B2
<Martyn> Cant :)
<Martyn> tomorrow, I have it
<ogra> :)
<Martyn> And I'll try getting u-boot working with a set of params
<L84Supper> Martyn : </beef>
<Martyn> I also should figure out a 'safe' u-boot set of parameters, so that someone can set one of user DIP switches to get a sane default setting
<L84Supper> what's the dev board for imx5?
<Martyn> since I already locked myself out of one development system by accidentally setting delay to 0
<Martyn> babbage/babbage2
<Martyn> i.mx51
<Martyn> and i.mx515 has another one
<armin76> lol
<L84Supper> Martyn : any idea where they are for sale?
<ogra> s/where/when/ :)
<suihkulokki> seems genesi has mx515 devboard orderable https://www.genesi-usa.com/store/details/4
<L84Supper> everything is open except for the closed graphics libs by PowerVR, I heard that Nokia was asking them to open up
<L84Supper> wow $750 for the dev board
<armin76> dev boards cost that or more
<L84Supper> sure I've spent thousands
 * ogra thinks 750 is rather mid-price 
<Martyn> $750 is very reasonable
<L84Supper> Genesi USA appears to be grasping for credibility
<Martyn> L84Supper: I >will< have 2D drivers for powerVR working by the end of Aug
<Martyn> L84Supper : 3D is being worked on by other people.
<ogra> and will be as nonfree as nvidia
<L84Supper> were still working on the first complete open source laptop, VIA vx855 still looks like it will be the first
<Martyn> ogra : The 2D drivers will be open and free.  Those are reverse engineered
<Martyn> ogra : The 3D drivers .. who knows.
<L84Supper> yes a pain
<ogra> Martyn, well, its equivalent to puolsbo on intel
<Martyn> ogra : Depends if the Finnish guys figure it out (PowerVR open source) before the the offical closed-source drivers gain traction
<Martyn> That genesi board looks pretty close to the babbage2
<Martyn> just about the same capabilities
<L84Supper> I wish that the genesi board had more RAM
<ogra> Martyn, not really, but to another one here on my desk :)
<ogra> not to say its 100% the same :)
<ogra> just differntly named
<ogra> so if you want to do ubuntu stuff, get such a board ;)
<L84Supper> they both look like the Freescale reference design
<suihkulokki> so many components on the PCB.. do they really intend to manage to make cheap designs around that?
<L84Supper> it's a kitchen sink board
<L84Supper> it also demos components by partners
<L84Supper> the netbooks will just have the imx soc , an EC, some glue and power supply
<L84Supper> wireless, bluetooth etc will be on separate plug-in modules
<suihkulokki> I would assume moving components to separate modules doesn't cut down costs
<L84Supper> it gives the ODM's flexibility for different models
<L84Supper> http://www.via.com.tw/en/initiatives/spearhead/surfboard_c855/index.jsp
<L84Supper> as an example
<L84Supper> can the Flash ROM be reprogrammed by software in-circuit or does it require a separate hardware device?
<L84Supper> on the babbage board
<L84Supper> if it may be done via software we can look at adding it to FlashRom
<Martyn> in-circuit
<Martyn> heck, even live from an OS
<ogra> ubuntu currently uses SD
<ogra> the flash on the B1 was to small to fit in the initramfs
<Martyn> It shouldn't have to live on that flash
<Martyn> but we should be able to boot from either the SD or an internal drive
<Martyn> I still say kernel chainloading is the way to go
<ogra> yeah
<ogra> no
<Martyn> why not?
 * ogra isnt a fan of kernel chainloading ...
<Martyn> Why?
<ogra> means you have to maintain a second kernel
<Martyn> the kernel itself is the ultimate BIOS
<Martyn> sure, but it's a tiny kernel
<ogra> still
<Martyn> no different than maintaining a bootchain
<Martyn> and you KNOW you will be able to flexibly boot
<Martyn> well, until we have UEFI .. that's one of the only ways I can think of to really get a flexible boot
<ogra> or HW vendors that agree on a standard :)
<L84Supper> Coreboot
<Martyn> coreboot on ARM = nonexistent
<L84Supper> yes, we've talked about it
<Martyn> it would take a LOT more work to get coreboot's stuff going
<L84Supper> well uboot handles the hardware init
<Martyn> okay back to work
 * ogra saw a coreboot demo at CELF 
<ogra> on a beagle
<L84Supper> was probably Peter
<L84Supper> is a boot drive chooser still missing?
<Martyn> what is the command to get a system to execute an ACPI suspend in linux?
<L84Supper> UEFI is another train wreck
<ogra> yeah, peter stuge i think
<L84Supper> yes , that him
<L84Supper> carebear in irc
<L84Supper> they were just at LinuxTag as well
<L84Supper> I'd stay with uboot and a chooser for boot location
<dirk2> ogra: I tried --seed lxde,gdm , this results in "E: Couldn't find package lxde,gdm"
#ubuntu-arm 2009-07-07
<nettolt> has anyone install ubuntu on a pxa270
<Martyn> you'll have some problems
<Martyn> the architecture is pre v5
<persia> Hrm?  I know people have installed jaunty on the Zauri, which are mostly pxa26x
<Martyn> right
<Martyn> v5's
<Martyn> 250's though, I'm not so sure of
<Martyn> did we compile for v4?
<persia> Never.  Biggest difference between debian armel and ubuntu armel
<Martyn> that's what I thought
<Martyn> so .. no, you can't get jaunty working on the pxa250
<Martyn> you can on any v5 processor with enough RAM
<persia> Well, assuming you're willing to play kernel games, sure.
<Martyn> yep
<Martyn> well, if it's not a babbage, you have to play kernel games
<Martyn> for now at least
<persia> Well, there's versatile.
<amitk> ogra: thanks for the new toy ;)
<amitk> ogra: what kernel have you flashed on the SD card? It shows 2.6.28.
<ogra> did i leave the SD in ?
<ogra> its the binary from the vendor
<ogra> good to hear it safely arrived :)
<ogra> amitk, btw: https://www.genesi-usa.com/store/details/4
<ogra> :)
<amitk> ogra: I've seen that somewhere ;)
<amitk> ogra: root login password?
<lool> amitk: How is stuff going with the imx51 kernel?  You just got B2 now IIUC
<ogra> he is trying to crack my password on the SD i left in the board ...
<ogra> probably to busy for kernel work, my personal stuff is more intresting :P
<ogra> lool, Martyn seems to just port his u-boot to the B2 btw ... it has a full feature set except USB booting
<lool> I didn't know kernel devs were looking at anything after "init started"  :)
<lool> ogra: But on which board does he have that?
<lool> The USB and SATA/PATA on the imx51 SoC need new drivers
<lool> (in Uboot)
<ogra> currently on a PBX board and i think a B1 ... he said he gets the B2 from his colleague today to port to it
<lool> Is PBX mx51 based?
<ogra> no
<ogra> cortex-a9
<ogra> MP board
<amitk> lool: yeah, just got the board and debugging the .31 kernel on it
<lool> ogra: So I don't think it really relates
<ogra> lool, well, he listed the feature and said it would have the same on the B2 if he's done
<ogra> *features
<ogra> he also said it would be trivial to backport it from the -a9 ot imx
<ogra> i can just state what he said... i'm not judging :)
<lool> We will see, but if it was hard for FSL it should be hard for him too  :)
<ogra> yeah, lets see
<ogra> but if we would get something that works before A3 i wouldnt mind to add it
<NCommander> lool, well, u-boot uses the kernel driver API; quite a few drivers are copy and paste
<NCommander> (from when I browsed the u-boot source code)
<NCommander> (its similiar to how GNU Hurd uses linux device drivers, except they use a 2.2 based API)
<NCommander> ^- ogra
<amitk> u-boot would be nice indeed
<NCommander> The only issue with u-boot ATM is that is doesn't compile with GCC 4.4
<ogra> so lets see how far martyn gets
<amitk> lets all send Martyn his favourite bag/box of caffeine ;)
<ogra> yeah :)
<NCommander> \o/
<NCommander> ^- to caffienated goodness
<NCommander> From what I've seen, getting u-boot up on a new board is pretty simple; you need to write an initialize stub, at least a serial port stub, and a few other stub functions. For the pxa series boards, its a bit over 1000 LoC
#ubuntu-arm 2009-07-08
<janrinze> hi
<janrinze> is there a way to get a armv7 version of Ubuntu 9.04?
<ogra> no
<ogra> well, there is but involves that you rebuild everything yourself
<janrinze> v6 then?
<ogra> right, karmic will be v6+vfp
<ogra> jaunty is v5 with some libs being vfp
<janrinze> ok. is there a repo for karmic?
<dirk2> janrinze: Do you know the "How does this differ from the work of mojo.handhelds.org " section of https://wiki.ubuntu.com/ARM FAQ ? Maybe mojo.handhelds.org can help you. Not sure, though
<ogra> ports.ubuntu.com
<janrinze> i have used mojo before.. on XScale.. but that only had armv5. maybe the latest ones have better support though.
<ogra> mojo has stopped with interpid
<ogra> and they use nonstandard architecture names for their packages
 * dirk2 learned again something ;)
<ogra> which makes it close to impossible to crossgrade from mojo to ubuntu
<janrinze> yep.. i noticed the activity at mojo had stopped..
<janrinze> i though because Ubuntu now started to support arm they move to the main ubuntu support activities.
<ogra> https://blueprints.launchpad.net/ubuntu/+spec/mobile-karmic-arm-cloud-builds might be instresting for you for a ful v7 rebuild
<janrinze> oops.. 'thought'
<ogra> *full
<ogra> but its still in the works
<janrinze> ogra: ok.. a bit too much for me a.t.m.
<ogra> well, karmic's userspace should work for you
<janrinze> so as far as i can see only OE/Angstrom does full armv7/armv6 builds
<ogra> see the rootfs from scratch wikipage from the topic if you want a rootfs
<janrinze> ogra: that will only prebuilt binaries, right?
<ogra> right, with jaunty we tried to support at least some of the debian architectures which forced us into v5 ... there is more v7 HW now so karmic does v6+
<ogra> that will only assemble a rootfs tgz from the archive
<janrinze> ogra: using debs with prebuilt binaries for armv6?
<ogra> yes
<janrinze> ogra: the script on the webpage will install jaunty, how to change that to get karmic?
<janrinze> just change 'echo "deb ${MIRROR} jaunty ${COMPONENTS}" >/etc/apt/sources.list' ?
<ogra> oh, sorry, right, i'm about to add a --dist option :) just change the two occurences of jaunty in it to karmic for now
<ogra> there is another line with jaunty
<janrinze> ok.
<janrinze> sed will be my friend ;-)
<janrinze> ogra: in karmic the arch is still armel?
<ogra> yes, that wont change
<janrinze> ok.. will that prevent karmic from running on XScale?
<ogra> not sure, i dont have any XScale HW
<janrinze> hmm.. will a dist-upgrade work with jaunty?
<ogra> sure
<janrinze> ok.. just added karmic to apt-sources
<janrinze> should i keep jaunty in the sources.list too?
<ogra> well, just make sure your jaunty is up to date with the latest upgrades
<janrinze> ok.
<ogra> before you dist-upgrade to karmic
<ogra> then you can just comment out jaunty
<janrinze> ok.
<janrinze> ogra: jaunty defaults to getting the imx51 linux headers. is there a OMAP3 package too?
<ogra> no
<janrinze> ok.
<ogra> there are third party packages for beagleboards
<ogra> http://elinux.org/BeagleBoardUbuntu
<ogra> not sure how much they help on XScale though
<janrinze> the XScale is not my concern a.t.m. was just curious.
<janrinze> i run on ubuntu jaunty the BB
<ogra> ah
<janrinze> i do have a XScale platform which i would like to upgrade one time ;-)
<janrinze> ok.. will do dist-upgrade now.
 * janrinze is making more coffee and starts thinking about what to do in the next 8 hours or so.
 * janrinze is still looking at the dist-upgrade progressing..
<janrinze> the only way to get gcc to compile inline NEON instructions is to use -mfpu=neon -mfloat-abi=softfp. Will that still be compatible with libraries such as libc?
#ubuntu-arm 2009-07-09
<lool> ogra: Do you remember what the ETA for 512m beagle was?
<ogra> still in speccing i think
<lool> How does that translate into dates?
<ogra> speccing means no dates at all
<ogra> but finding the requirements
 * ogra asks in #beagle
<ogra> lool, see #beagle ...
<lool> ogra: I'm about to place a beagleboard order; what do you recommend getting?
<ogra> the latest ... C4 ?
<lool> I mean aside of beagle
 * ogra isnt sure about the current version ... 
<lool> It just says C
<ogra> powered HUB, mini to normal USB adapter and a USB NIC
<lool> Ok; I'll confirm with #beagle folks
<ogra> if your monitor has a DVI input, an adapter cable HDMI->DVI
<JamieBennett> don't forget the serial stuff either, serial adaptor for the board, cable and maybe a gender changer
 * ogra totally wasnt aware revC has a real USB port
<lool> ogra: Ordered
 * ogra applauds
<lool> ogra: My monitor has DVI, VGA, and HDMI inputs
<ogra> seeing the revC i'm tempted to upgrade
<lool> JamieBennett: Thanks
<ogra> the 128M in mine really dont cut it, its just collecting dust
<ogra> but i just bought a new TV set and a HD cam ... i'll probably rather wait for the 512M version and let my account relax a bit
<lool> I opted not to wait "some months" for the 512m version; I have sponsoring for 300-400 USD for a gadget so I just used that
<kblin> it's a tough decision.. 256 megs would cover my use case just fine
<kblin> but I'd like to have real ethernet
<lool> ogra, NCommander: Can we move imx51 to Uboot now?  Should we?
<lool> It requires some debian-cd chqnges
<ogra> yes
<ogra> definately
<ogra> we need uboot support anyway in debian CD
<NCommander> lool, indeed, but I think we should probably aim that changeset for the A3 timeframe
<NCommander> er
<NCommander> A4
<NCommander> Unless we don't care about images for the A3 timeframe
<lool> NCommander: ogra is the FSL image guy now
<lool> Let's start with getting uboot-imx in first
<NCommander> lool, I'm looking at that right now. I'll probably have a candidate package in 24 hours
<lool> Cool
<ogra> given that we need uboot for both supported arches we should start changing dbein-cd asap and have a generic uboot-install in there both arches can use
<NCommander> (depends how long it takes to sort out debian/copyright, the package itself is trivial compared to redboot)
<ogra> *debian-cd
<ogra> which will make the subarch scripts quite small
<lool> ogra: That's a good ide
<lool> idea
<ogra> adding the other board later on should be trivial
<persia> Can uboot be smart enough to pick a kernel such that there could be only a single image?
<ogra> no
<lool> We could have an uboot-vfat-image tool and am uboot-pc-part-image tool or something
<persia> pity
<ogra> especially since we need different uboot binaries per board anyway
<ogra> so having a single kernel doesnt gain anything
<ogra> you still need two images
<ogra> well, it would gain us space on the build system disks, but thats it :)
<lool> NCommander, ogra: So uboot us a bit nicer to use and uses vfat instead of fis, but it lacks networking on mx51
<ogra> right
<lool> Why would we want uboot instead of redboot?  Ease of build?
<NCommander> lool, do we care?
<ogra> yes
<NCommander> THat's one big reason
<NCommander> no special cross-compiler
<NCommander> no 2.8GB redboot.bin ;-)
<ogra> ease of build possibility to get comunity people looking at bugs
<ogra> and /boot partitions
<NCommander> ugh
<NCommander> That just reminded me
<NCommander> ubiquity going to have to be taught to use an explicate /boot on imx51
<ogra> sure
<ogra> i'll care for that as soon as we have working images
<lool> ogra: You might want to add these tasks to the fsl images spec
<lool> ogra: As work items at least
<ogra> will do
<ogra> NCommander, i'm just going over the two desktop blueprints
<ogra> Packaging of uboot tools to allow userland manipulation: TODO
<ogra> can you please test if the current ones work ?
<ogra> we have uboot mainpulation tools in the archive already
<NCommander> ogra, sure, but I'll package the current u-boot first
<ogra> right
<ogra> just check if we can use the debian package or need changes once you have uboot ready
<lool> ogra: I reworded the work items slightly; wasn't sure for all of them
<lool> ogra: I think the livefs and image testing bits aren't very clear: this will happen at each milestone
<lool> ogra: How could we fix that?
<ogra> well, first of all we need an initial livefs ...
<ogra> the testing should go into a separate task at the end
<ogra> why kernel "udeb" ?
 * ogra doesnt really care about alternate
<lool> ogra: So you're saying that whenever you work on image building, you need the livefs to be built otherwise you can't work on image building
<ogra> well
<lool> ogra: But you might be working on image building at any time, right?
<ogra> yes, but the task there was rather about inital lives bringup
<lool> udeb > you need an udeb to get that vmlinuz file which you wget into the image
<ogra> i think rolling regular images somewhat implies that all bits are in place for tha
<ogra> t
<lool> We had a livefs for A1, but I'm not sure it helped anything except that
<ogra> so that falls globally under image testing and installation
<lool> Ok; I'll remove the extra item then
<ogra> its just an ongoing task
<lool> Perhaps add alpha 3, alpha 4 etc. lines if you think you want that
<ogra> nah, all prerequisites have to be in place for A3
<lool> Yeah I don't think ongoing tasks are useful to track progress of the implementation of a spec
<ogra> from then on its maintenance
<goshawk> hi
<goshawk> is ther a way to run ubuntu arm under qemy with the -nographic option?
<goshawk> if follow the ubuntuArm from scratch i've a qemu image
<goshawk> but if i run quit -nographic i just see the booting linux ..... and then nothing
<goshawk> any1?
<lool> goshawk: You need to pass a console= setting on the kernel cmdline
<goshawk> lool: can you give me an example?
<lool> something like http://people.ubuntu.com/~lool/qemu-buildd/run
<goshawk> console=/dev/tty0?
<goshawk> i'm running it on a remote server
<goshawk> under screen
<goshawk> i mean the screen program, with multiple termina
<goshawk> terminal
<lool> That doesn't matter
#ubuntu-arm 2009-07-10
<goshawk> hi
<goshawk> lool: can i disturb you?
<goshawk> lool: yesterday you told me to add console= to the command line
<goshawk> but should i add only "console=" or should i put something else after it?
<lool> goshawk: See the sample command line I pasted
<lool> goshawk: 20:44 < lool> something like http://people.ubuntu.com/~lool/qemu-buildd/run
<goshawk> wow
<goshawk> can i add it to the rootfromscratch page?
<goshawk> in the ubuntu wiki?
<goshawk> i surfed on google and a lot of people have troubles
<goshawk> with this console issue
<goshawk> it works!
<lool> goshawk: The rootfs from scratch page is about creating a rootfs not starting a qemu
<goshawk> thanks a lot lool!
<goshawk> lool: there is a section in starting qemu too
<goshawk> wait
<lool> goshawk: You're welcome to start a wiki page about qemu console options
<lool> goshawk: That's probably where you want to add the information then
<goshawk> lool: Using a qemu image
<goshawk> in https://wiki.ubuntu.com/ARM/RootfsFromScratch
<goshawk> yep
<goshawk> i want to add this info there :)
<lool> goshawk: Oh sure, that makes sense then
<lool> Only the console arg is missing actually
<goshawk> yes
<ogra> apart from the fact that rootfs from scrtch doesnt enable a serial console and the qemu command is supposed to run an SDL login
<goshawk> ogra: i was thinking to add... if you wanna run it in a console do bla bla bla
<ogra> can you add a completely new section with a proper qemu commandline as well as instructions how to ser up a serial tty ?
<goshawk> yep
<ogra> there is no serial tty configured by default
<ogra> though i was planning to att it in the next release of https://launchpad.net/project-rootstock :)
<goshawk> lool: there is a problem, after i see kernel message i just see "Freeing init memory: 136K" and nothing more, no login prompt
<ogra> thats what i meant :)
<lool> goshawk: -nographic only supports the serial console, not vts
<ogra> upstart isnt configured to start a serial tty
 * goshawk remember that in a debian he just added -nographic to an armel image and it worked... uhm
<goshawk> ogra: so upstart should start a serial tty for it to work
<ogra> right you need to edit the image
 * goshawk removes the -nographic option and takes the console= from lool
<ogra> see the /etc/event.d/ttyS0  in https://help.ubuntu.com/community/SerialConsoleHowto ... thats what you need to add
<lool> goshawk: Use alt-shift 3 to go to serial console
<goshawk> lool: thx, but i need to exit from the screen program, cuz alt-shift is got by its
<goshawk> ogra: uhm.. so the script to generate the image should add the SerialConsole which is in that page, isn't it?
<ogra> well or you loop mount the image and add it
<ogra> the next generation of the script (at https://launchpad.net/project-rootstock) will have an option for it
<goshawk> ogra: is it already implemented?
<ogra> nope
<goshawk> ok thanks for all the suggestions
<goshawk> now i gotta go
<goshawk> thanks again :)
<ogra> echo "start on runlevel 2" >/etc/event.d/ttyS0
<ogra> echo "start on runlevel 3" >>/etc/event.d/ttyS0
<ogra> echo "start on runlevel 4" >>/etc/event.d/ttyS0
<ogra> echo "start on runlevel 5" >>/etc/event.d/ttyS0
<ogra> echo "stop on runlevel 0" >>/etc/event.d/ttyS0
<ogra> echo "stop on runlevel 1" >>/etc/event.d/ttyS0
<ogra> echo "stop on runlevel 6" >>/etc/event.d/ttyS0
<ogra> echo "respawn" >>/etc/event.d/ttyS0
<ogra> echo "exec /sbin/getty 115200 ttyS0" >>/etc/event.d/ttyS0
<ogra> ^^^^
<ogra> add that between the "echo LANG=${NEWLOCALE} >>/etc/environment" and the first sed command
<ogra> then it will create /etc/event.d/ttyS0 by default on your next build
<goshawk> ah :)
<goshawk> good!
<goshawk> thx a lot ogra
<ogra> :)
<goshawk> ogra: what aobut editing /etc/inittab?
<goshawk> and add #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
<ogra> its just a quick hack ... project-rootstock will have it cleaner
<ogra> no
<ogra> there is no inittab in ubuntu since 6.06 anymore
<ogra> just add the above and you will have a serial tty
<goshawk> ah so the page about serial console is outdated
<ogra> no
<ogra> you read it to sloppy :)
<goshawk> --- Configuring inittab (Dapper and older) ---
<goshawk> sorry
<goshawk> i didn't read this line
<ogra> ;)
<goshawk> :)
<ogra> should be a proper header then it would be bold
<lool> Oh Debian has instructions to cross debootstrap too
<lool> http://wiki.debian.org/ArmEabiHowto didn't see these until now
 * goshawk creates a new image
<goshawk> lool: i used it before
<goshawk> is has networking configured too
<goshawk> on qemu
<goshawk> we were based on it on mer development
<ogra> is https://help.ubuntu.com/community/SerialConsoleHowto clearer now ?
<goshawk> ogra: thx, now it's better
<ogra> good ...
<ogra> the evil is that it needs a completely new section for karmic since yesterday
<ogra> so it will become more confusing
<goshawk> what happened yesterday?
<ogra> upstart changed completely
<goshawk> new upstart version?
<ogra> no more /etc/event.d
 * goshawk hopes it changed better
<lool> ogra: upstart is madness
<ogra> once it works as it should it will be sexy i guess
<Stskeeps> no more event.d? what does it use -then-?
<ogra> the years long transition is madness, i agree
<lool> /etc/init?  I'm not sure
<ogra>  /etc/init/
<ogra> and a new file format
<ogra> yes
<Stskeeps> lovely
<ogra> files have .conf suffixes now and the command syntax in them changed
<ogra> ogra@osiris:/var/build$ cat /etc/init/tty1.conf |grep -v ^#
<ogra> start on stopped rc RUNLEVEL=[2345]
<ogra> stop on runlevel [!2345]
<ogra> respawn
<ogra> exec /sbin/getty -8 38400 tty1
<goshawk> it's quite the same
<goshawk> time to add to the serial console page?
<ogra> well, even though i assume you only need to change the getty line it should be tested before being added to the wiki :)
<lool> ogra: I think uboot also supports ext2 (marvell's does); could we perhaps use that to avoid a separate /boot if the host is installed with ext2/3/4?
<ogra> well, we default to ext4
<lool> Yes
 * goshawk I: Unpacking the base system...
<ogra> is that ext2 backwards compatible ?
<ogra> like ext3 ?
 * ogra thought it wasnt
<goshawk> as far as i know there is a tool to switch from ext3 to ext4
<goshawk> but i've never used it
<ogra> yes, but can you mount etx4 as ext2 ?
<goshawk> dunno
<lool> ogra: I don't know
<goshawk> you can mount any ext2 or ext3 filesystem as ext4 without any changes
<goshawk> from google
<lool> ogra: But perhaps uboot logic will work with ext2+?
<ogra> no idea :)
<lool> ogra: Might be worth investigating for your fsl spec perhaps?
<ogra> http://www.plugcomputer.org/plugwiki/index.php/U-Boot_Quick_Reference#Load_kernel_.2Fboot.2FuImage.sheeva.20090319_from_ext2.2Fext3.2Fext4_filesystem_.28first_partition.29_on_USB_device
<ogra> sheva seems to be able to use ext4
<lool> ogra: I think we also want to find a way to allow upgrades from jaunty
<ogra> so it might be possible
<ogra> ugh, shudder
<ogra> that might get hairy
<ogra> replacing the botloader and all
<lool> I think we can manage with flash-kernel.conf being present or not
<ogra> we dont do that on x86
<lool> I don't think we want to replace it
<ogra> though grub1 will still work there
<ogra> oh, you want to boot .31 on B1 with old redboot ?
<ogra> hmm, i wonder if that will work
<lool> Yes
<lool> It depends whether the proto (which should be fairly stable) changed or not between 28 and 31
<lool> Dunno what broke between 26 and 28
<ogra> amitk, did you try booting .31 on B1 ?
<lool> ogra: Could you cleanup the whiteboard in https://bugs.launchpad.net/ubuntu/karmic/+source/banshee/+bug/391588
<ubot4> Launchpad bug 391588 in banshee "banshee fails to run on arm" [High,New]
<lool> release team meeting today
<ogra> you mean rip out the stuff from the description ?
<ogra> sure
<lool> ogra: Make it an attachment or something
<lool> ogra: Don't forget this stuff is copied on ALL emails
<lool> It would also be nice if you could get a new backtrace
<ogra> ripped out
<ogra> i'll attach the LVDS to my pegatron after lunch and try to get a proper backtrace together
<ogra> sadly you cant run banshee remotely ...
<ogra> dies becaue of dbus
<goshawk> well ogra, after the changes you told me
<goshawk> i built a new image
<goshawk> and booted with
<goshawk> sudo qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.28-versatile -cpu arm926 -hda qemu-armel-200907101210.img -m 256M -append "root=/dev/sda mem=256M" -nographic
<goshawk> still no login
<amitk> ogra: yes I did. Fail. But please feel free to try it again.
<goshawk> adding the console= settings from lool
<ogra> yeah, you need to tell the kernel to use a serial console
<lool> goshawk: Use graphics or setup a serial console
<lool> goshawk: Which upstart version in your image?
<goshawk> lool: wait i see in the log
<ogra> by default the script still builds jaunty
<lool> ogra: Are you still planning to deal with https://bugs.launchpad.net/bug-zapper/+bug/392094 ? I don't see an assignee, but if you don't intend to work on it that's fine
<ubot4> Launchpad bug 392094 in bug-zapper "needs search option for bugs a team is subscribed to" [Undecided,Confirmed]
<ogra> lool, i will, but its not on my high prio list
<goshawk> lool: yep it's jaunty version
<ogra> though given the babbage situation i might have a lot of spare time :P
<lool> ogra: Hmm you're assigned to the karmic task in https://bugs.launchpad.net/gnome-keyring/+bug/328167
<ubot4> Launchpad bug 328167 in gnome-keyring "[arm] gnome-keyring-daemon eating 100% CPU at login in Jaunty" [High,Fix released]
<ogra> right, i need to set up a jaunty on my B1
<ogra> its just a confirmation for upstream though
<ogra> not sure we need to target it to karmic
<lool> amitk, bjf_afk: Whenever you're updating imx51's udebs, could you please address https://bugs.launchpad.net/ubuntu/+source/linux/+bug/359049 ?
<ubot4> Launchpad bug 359049 in linux "imx51 udeb hardcodes linux version in vmlinuz binary name" [High,Won't fix]
 * goshawk creates a new image with --seed openssh-server since he can ping the last image but he can't connect.
<ogra> did the serial console not come up ?
<goshawk> ogra: no
<goshawk> same behaviour as before
<ogra> not even with proper console option?
<goshawk> neither with console=ttyAMA0 console=tty0
<goshawk> and -nographic of course
<ogra> console=ttyAMA0,115200n8
<goshawk> ok trying
<ogra> thats what the build script uses :)
<goshawk> yep i'm starting to see something more
<ogra> so if you see it building after "I: Switching to Virtual Machine for second stage processing" that should work
<goshawk> reeing init memory: 136K
<goshawk>  * Filesystem type 'fusectl' is not supported. Skipping mount.
<goshawk>  * Setting preliminary keymap..
<ogra> perfect
<goshawk> yep it's working
<goshawk> :)
<ogra> :)
<goshawk> well finally we have a working version ^__^
<lool> ogra: poke
<lool> ogra: I reviewed https://wiki.ubuntu.com/Specs/ArmelSubarchitectureImageBuilds and it looked ok
 * ogra falls over
<ogra> cjwatson gave his ok as well already, david approved it
<ogra> rootstock just grew a --serial and a --dist option
<ogra> :)
<NCommander> :-)
<ogra> hmm, i made 10 commits to the rootstock branchbut LP only gives me 7 points as top committer
 * ogra wonders how these numbers correlate
<ogra> hmm
<ogra> did anyone of us ever try to run wine on armel ?
<playya> sqrt(commits) + 4
<playya> should be impossible
<ogra> would be funny if it worked ...
<playya> because wine is x86 only
<ogra> to run office 2000 install ubuntu and wine on your arm device :)
<ogra> yeah, likely not working
<playya> maybe you can start a project: wine embedded
<ogra> why embedded ?
<ogra> we dont do any embedded stuff :)
<playya> or mobile, ...
 * ogra wishes that team name could be changed since a long time
<playya> if you want to run wine on arm the acronym fails ( wine is not an emulator)
<playya> you can ask sun to port virtaul box to arm
<ogra> nah, they would probably only give me qemu-sparc :P
<L84Supper> DEC had a x86 emulation layer for the Alpha's, if there was one for ARM cortex 8, the x86 apps would probably run about K6 speeds
#ubuntu-arm 2009-07-11
<goshawk> hi
<goshawk> ogra: ping
<goshawk> after the change we did yesterday
<goshawk> i don't see anything more than * Starting kernel log daemon...                                         [ OK ]
<goshawk>  * Starting OpenBSD Secure Shell server sshd                             [ OK ]
<DGMurdockIII> hi dose ubuntu support arm laptops/ netbooks
<goshawk> DGMurdockIII: yes
<DGMurdockIII> in ubuntu netbook remix
<goshawk> dunno
<goshawk> but i think yes
<goshawk> you just
<goshawk> install ubuntu in that arm
<goshawk> and install the same packages of ubuntu netbook remix
<goshawk> dunno if there are ready images for ubuntu netbook remix (arm version)
<goshawk> DGMurdockIII: have a look here https://wiki.ubuntu.com/ARM
<DGMurdockIII> hey so if i am working on a custom distro that based on ubuntu netbook remix distro is there a way i can add arm support easly
#ubuntu-arm 2009-07-12
<goshawk> ogra: hi
<goshawk> ogra: i'm playing with rootstock
<goshawk> I: Setting up serial tty in image
<goshawk> ./rootstock: 555: cannot create /tmp/tmp.QxQsDRVgaU/tmpmount/etc/init/ttyS0.conf: Directory nonexistent
<goshawk> i may have a patch for it soon
<goshawk> ogra: ping
<ogra> hey goshawk, thanks for the fix :)
<goshawk> ogra: thx to you, it was just a mkdir -p :P
<ogra> it wont save you though
<ogra> as i wrote in the branch review
<goshawk> yes :)
<goshawk> i saw
<goshawk> and i'm fixing thsi now
<goshawk> /bin/installer: line 60: reboot: command not found
<goshawk> it's in upstart-compat-sysv
<ogra> yeah
<goshawk> which seems to be not installed
<ogra> right, which is dead
<goshawk> so i forcedo to install it
<goshawk> (Reading database ... 10802 files and directories currently installed.)
<goshawk> Unpacking upstart-compat-sysv (from .../upstart-compat-sysv_0.3.10-2_armel.deb) ...
<goshawk> it's 30 mins
<goshawk> at 100%
<goshawk> in that position
<goshawk> i just added a apt-get install -y (Reading database ... 10802 files and directories currently installed.)
<goshawk> Unpacking upstart-compat-sysv (from .../upstart-compat-sysv_0.3.10-2_armel.deb) ...
<ogra> well, i'm not sure what this package needs from the old upstart
<goshawk> oops sorry
<goshawk> apt-get install -y upstart-compat-sysv
<ogra> the former upstart had tools and binaries scattered across multiple packages
<goshawk> well the problem is that reboot is not found
<goshawk> ah... understood
<ogra> the new one has everything in a single package
<ogra> startup-tasks system-services upstart-compat-sysv and upstart-logd will likely be needed additionally
<ogra> though ...
<ogra> it might be that udev gets a prob alongside if certain sockets from new upstart arent available
<goshawk> uhm.. let me see where is /sbin/reboot in karmic
<ogra> likely in upstart 0.6
<ogra> yeah, it is ... (on x86)
<goshawk> yep it's there
<ogra> https://edge.launchpad.net/ubuntu/+source/upstart/0.6.0-2/+build/1112005/+files/buildlog_ubuntu-karmic-armel.upstart_0.6.0-2_FAILEDTOBUILD.txt.gz
<ogra> thats the prob
<ogra> and by the looks of it its caused by a gcc bug
<goshawk> so.. the question is... when will upstart will be built?
<goshawk> ah!
<goshawk> wow!
<ogra> so it wil take a while to identify and fix i assume
<goshawk> ogra: it's nice to have the build daemon :)
<ogra> ah, well ... its not very helpful with its error messages in this case
<ogra> i only found the actual error by building upstart at home
<goshawk> uhm... it seems that test_node.c
<goshawk> did it kill cuz it hangS?
<ogra> no
<goshawk> Session terminated, killing shell...make: *** wait: No child processesmake[1]: *** [check-recursive] Terminated
<goshawk> Build killed with signal 15 after 150 minutes of inactivity
<ogra> gcc spills an error the log doesnt have
<goshawk> ah
<goshawk> ok, so i've to build by myself to see it
<ogra> tests/test_watch.c: In function âtest_newâ:
<ogra> tests/test_watch.c:590: internal compiler error: in df_ref_record, at df-scan.c:2845
<ogra> depending on what board i build t here i get different errors :/
<goshawk> :( that's very weird
<ogra> yes
<ogra> fun is though that the package is built in a way that it should finish building even if the tests fail
<ogra> and that actually works in a local build
<goshawk> can it be a problem related to gcc?
<ogra> the buildd lock up though and kills the process after 150min
<ogra> yes, very likely
<ogra> i will need to talk with our gcc maintainer tomorrow
<ogra> and with Keybuk who wrote upstart
<goshawk> ogra: it seems that gcc goes in loop for me
<goshawk> and it never exits
<goshawk> from compiling
<goshawk> (for the builder)
<goshawk> at home it gives - internal compiler error -
<ogra> right
<goshawk> ogra: does it hang after "internal compiler error"
<goshawk> ?
<ogra> no idea, a buildd admin might know
<goshawk> no i mean
<goshawk> at home
<ogra> it might hang before
<ogra> no, it doesnt hang at all
<goshawk> ah.. so it goes in the loop
<ogra> Â»upstartÂ« in Â»../upstart_0.6.0-3_armel.debÂ«.
<ogra> it rols a package
<goshawk> uhm
<goshawk> ok... time to go for me
<goshawk> exam tomorrow
<goshawk> see you
 * ogra files bug 398403
<ubot4> Launchpad bug 398403 in gcc-4.4 "gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error" [High,New] https://launchpad.net/bugs/398403
<Stskeeps> hmm, did you make the armv6+vfp switch in karmic yet?
<Stskeeps> as in, for gcc
<neure> hello
<neure> would someone be so kind and build a kernel for me to be used with qemu?)
<kblin> there's a kernel that works with qemu.. try the -versatile kernel
<neure> well
<neure> i'd need one with preempt
<neure> im using the versatile kernel already, but I have some slightly tricky application which would benefit from preempt kernel
<kblin> I see
<neure> or else, i wonder what all i need to be able to build the kernel myself?
<neure> can i just get the latest kernel and build it myself, or do I need to apply some patches?
<kblin> uh, good question.. it's been a while since I had to build a kernel myself
<kblin> but building for armel-versatile shouldn't be different than the normal procedure for building a kernel on ubuntu
<neure> well i need to crossbuild
<neure> i found http://www.emdebian.org/tools/crosstools.html
<neure> i wonder if apt-get install libc6-armel-cross libc6-dev-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi  gets me the right toolchain
<neure> i'll try :)
<neure> oh dear W: GPG error: http://www.emdebian.org lenny Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B5B7720097BB3B58
<neure> that looked too easy
<neure> can i get around that?
<neure> does ubuntu have crosstool packages?)
<neure> well i guess im going to try my luck with codesourcery toolchain then
<neure> http://www.nas-central.org/wiki/Setting_up_the_codesourcery_toolchain_for_X86_to_ARM9_cross_compiling
<neure> looks like pretty close what im doing
<neure> except im using vmware instead of virtualbox, but anyway :D
<neure> virtualbox bluescreened my macbook :(
<Martyn> I've had a very good run with the CodeSourcery toolchain
<Martyn> just remember you don't have NEON or good vfp support in the Lite version
<neure> well
<neure> im targeting for qemu
<Martyn> nod
<Martyn> there's also a good 4.2 and 4.4 toolchain set that supports armv5/6/7
<Martyn> I'm using CodeSourcery only because I'm developing for the Cortex-A9
<neure> uuh
<neure> i downloaded arm-2009q1-203-arm-none-linux-gnueabi.bin
<neure> it needs X11 huh
<neure> i dont have X11 :D
<neure> i dont event want one
<Martyn> Wait, needs x11?
<Martyn> why?
<Martyn> Wierd.
<neure> i suppose it has some graphical installer
<Martyn> Did you download that from silver.arm.com?
<Martyn> I'm trying to figure out which toolchain it's part of
<neure> from codesourcey
<neure> now i'll try this script http://www.nas-central.org/wiki/Setting_up_the_codesourcery_toolchain_for_X86_to_ARM9_cross_compiling
<neure> i wonder which kernel configuration to use for qemu
<Martyn-> There's a standard one
<Martyn-> make qemuconfig
<Martyn-> or something along those lines
<Martyn-> you'll find it in the kernel tree
<neure> how?
<neure> make qemuconfig didn't work
<neure> http://kernel.xc.net/search.cgi?string=qemu&version=2.6.30&arch=arm doesnt find much about qemu
<neure> oh dear
<neure> the kernel i compiled didn't start in qemu :/
<neure> would anyone have their kernel config?
<neure> hmm
<neure> <stdin>:1097:2: warning: #warning syscall fadvise64 not implemented
<neure> <stdin>:1265:2: warning: #warning syscall migrate_pages not implemented
<neure> <stdin>:1321:2: warning: #warning syscall pselect6 not implemented
<neure> <stdin>:1325:2: warning: #warning syscall ppoll not implemented
<neure> <stdin>:1365:2: warning: #warning syscall epoll_pwait not implemented
<neure> i wonder if that is anything to worry about
#ubuntu-arm 2010-07-12
<hrw> morgen
<furibondox> hello everybody
<furibondox> I'm trying to use rootstock on ubuntu lucid but I have a blocking problem...
<furibondox> anybody have a suggestion?
<furibondox> the error is: /usr/bin/rootstock: line 282:  6890 Segmentation fault      qemu-system-arm $QEMUOPTS -append "${APPEND}" > $QEMUFIFO 2>&1
<furibondox> it seems a problem related to qemu itself...
<furibondox> anybody use rootstock from ubuntu lucid?
<furibondox> anybody use rootstock with ubuntu lucid?
<vstehle> furibondox: You may want to report this into launchpad.
<furibondox> vstehle: I've just reported... https://bugs.launchpad.net/ubuntu/+source/rootstock/+bug/570588 (item 13)
<ubot2> Launchpad bug 570588 in rootstock (Ubuntu) (and 1 other project) "qemu-system-arm can not handle more than 256M in versatile machine mode using the -m option (affects: 2) (heat: 53)" [Undecided,Invalid]
<furibondox> I just would like to know if someone experienced the same behaviour and have found a solution/workaround...
<ogra> if you see the exact same bug, just revert your changes to the rootstock script
<furibondox> ogra: which change?
<ogra> furibondox, did you read the bug before commenting ?
<furibondox> yes
<ogra> its about someone who hacked his rootstock script to use 512M
<ogra> so revert that and it will work
<furibondox> I've also tried to use 512M changing the rootstock script but it fails again
<ogra> well, qemu cant use 512M
<ogra> thats what the bug is about
<furibondox> sorry ogra, I know that but I've read some bug report on google describing the same error but in different threads... and I took the 570588 to add a comment
<furibondox> may be is not the more approriate item opened
<ogra> well, if you changed the script to use 512M thats the bug, if you didnt, its not that bug and should be filed as a new one
<furibondox> I tell you my tests: 1) with 512M 2) with 256M 3) with more seeds 4) with only one seed
<furibondox> the result is the same
<ogra> and you are onyl using packaged versions of rootstock, qemu and friends ?
 * ogra knows that pleanty of people use rootstock under lucid and it works for them
<berco> ogra: just to let you know that your udev script worked fine in the end. Can't think I told you.
 * ogra hugs berco 
<ogra> perfect !
<furibondox> yes ogra, all my packages (qemu, rootstock, debootstrap etc) come from the lucid repository
<ogra> in your pm you used rootstock-native, thats definately not packaged
<furibondox> yes sorry... it was just a test...
<furibondox> ii  rootstock                                  0.1.99.3-0ubuntu1                               shellscript to create armel rootfs tarballs
<furibondox> May be there's something wrong with my command line?
<furibondox> sudo rootstock -f NGP --seed setserial,openssh-server,ubuntu-minimal -i 1G --serial ttyS2 --doswap --swapsize 256 --restore-package-cache
<ogra> setserial should be included in ubuntu-minimal, beyond that all looks fine
<ogra> and adding setserial shouldnt cause issues
<furibondox> ok
<furibondox> but, as far as you know, do you think that is a qemu problem or rootstock problem?
<furibondox> if you think that is a rootstock problem I can try to uninstall/re-install qemu and try again
<furibondox> what do you think?
<ogra> well, qemu segfaults
<ogra> its definately not a rootstock problam
<ogra> *problem
<furibondox> ok
<furibondox> I try to remove all and reinstall
<ukleinek> ogra: it's not long ago when I told you how to spell definitely :-)
<ogra> ukleinek, i blame the heat
 * ogra melts slowly
<ukleinek> ogra: so Berlin is hot, too?
<ogra> ukleinek, kassel here
<ogra> 28Â°C in my office, 36Â°C outside
<ukleinek> ogra: oh, Kassel, I thought you'd live in Berlin
<ukleinek> ogra: similar here
<ogra> i'd love to ... (who wants to live in kassel anyway)
<ukleinek> ogra: so why do you?
<amitk> b-----i------g house
<ogra> free living :)
<amitk> :-p
<ogra> no rent, solar heating system ... major cost factor :)
 * ukleinek has a solar heat here for free, too
<furibondox> ogra: I'm retring...
<rsalveti> morning
<rsalveti> hm, another qemu segfault
<rsalveti> interesting that this is happening with lucid
<rsalveti> ogra: was finally able to create the rootfs as user, but still have many issues to solve
<ogra> rsalveti, might be realted to amd64 systems
<ogra> rsalveti, good to hear :)
<rsalveti> first, fuseext2 is incredibly  unstable =\
<rsalveti> I can create the same image many times, just with 'ro', and get different results everytime
<rsalveti> lots of files get the wrong size and data
<rsalveti> so just after running the second stage, to be able to test, I mounted as loop, until we get this solved
<ogra> k
<rsalveti> ogra: but my biggest problem is the seg fault that I'm getting most of the time
<ogra> qemu segfault too ?
<rsalveti> ogra: yep :-(
<ogra> crap
<rsalveti> just after running the second stage
<ogra> x86 or amd64 ?
<rsalveti> amd64, this could be the issue
<ogra> yeah
<rsalveti> will try on x86 to see
<lag> sebjan: Ping
<rsalveti> ogra: see comment 54 on bug 532733
<ubot2> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 2 other projects) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 7) (dups: 1) (heat: 79)" [High,Incomplete] https://launchpad.net/bugs/532733
<ogra> rsalveti, that bug isnt about segfaults
<rsalveti> yeah, I know
<rsalveti> but many people reported about the segfault while trying to reproduce it
<ogra> that bug slowly turns into a mess :(
<rsalveti> that's why I posted there, cause it can be similar to what people was getting
<rsalveti> bug for sure, it's different
<ogra> the hang doesnt produce any segfaults at all
<rsalveti> ogra: are you using x86?
<ogra> upstream already refused to look at it because of the confusing comments
<ogra> yes
 * rsalveti wasn't able to get just the 'hang'
<rsalveti> oh, ok
<ogra> the hang only shows up if you install a big task like ubuntu-desktop or ubuntu-netbook
<ogra> dpkg hangs at some point
<rsalveti> ogra: yeah, but I'm getting the seg fault before that :-), but I'm using amd64
<ogra> your segfault seems userspace related
<rsalveti> will see with x86
<furibondox> ogra: same error: http://pastebin.ca/1898986 :-(
<rsalveti> furibondox: how are you calling rootstock?
<furibondox> sudo rootstock -f NGP --seed openssh-server,ubuntu-minimal -i 1G --serial ttyS2 --doswap --swapsize 256 --restore-package-cache
<furibondox> from ubuntu lucid
<furibondox> all packages (qemu, rootstock, etc...) came from the lucid repository
<rsalveti> furibondox: are you running on x86 or amd64?
<furibondox> x86
<rsalveti> furibondox: ok, can try to reproduce it here, but many people did run rootstock without this issue on lucid
<furibondox> the only unusual component is that my lucid x86 runs under vmware
<ogra> heh
<rsalveti> :-)
<ogra> thats probably something you should have told in the beginning :)
<ogra> not sure if qemu can run inside vmware
<rsalveti> yeah, could be the problem
<furibondox> some times ago I tested qemu inside vmware w/o problems
<ogra> i know qemu cant run inside a kvm instance
<ogra> or insice vbox
<ogra> *inside
<lool> ogra: uh?
<lool> I thought qemu could work just fine in kvm
<ogra> lool, can it now ?
<ogra> soren told me it cant
<lool> First time I heard it can't
<lool> You cant use qemu acceleration though
<ogra> so i never bothered to try to stack qemu instances
<ogra> hey asac
<lool> You can't run kvm in QEMU though
<asac> omg
<asac> the heat is on
<ogra> warm here, eh ?
 * ogra grins
<furibondox> ok... so your suggestion is to try within physical ubuntu installation, right?
<rsalveti> furibondox: yep, I'm trying it here on x86 with your command line
<ogra> if you have one around, i would suggest that
<furibondox> tnx rsalveti
<sebjan> lag: pong
 * ogra goes to find some icecream
<lag> sebjan: HI
<lag> Hi*
<lag> What's the latest with the Syslink driver?
<lag> Is it going to make our build?
<sebjan> I have tested with your last patch update, and could see that the modules where automatically loaded, as expected
<sebjan> we have no solution yet for the issues when it is built as modules. We may have to re-test with syslink v2 and debug on this version rather than on the current one
<furibondox> rsalveti: can you tell me if the building is finished without errors?
<rsalveti> furibondox: still going
<rsalveti> going to run the full vm now
<furibondox> ok
<lag> sebjan: Thanks for the update
<lag> sebjan: Do any of your chips have parallel ports?
<vstehle> lag: I don't think we have parallel ports in the OMAP per se, but it can be "emulated" with GPIO if needed.
<furibondox> rsalveti: is finished now?
<rsalveti> furibondox: not yet, but it's just finishing the full emulation part, no crash until now
<furibondox> good
<lool> ogra: Hey
<ogra> lool, yup
<lool> ogra: Do you folks intend to include x-loader + u-boot in omap pre-installer images?
<lool> *pre-installed
<ogra> yep
<lool> ogra: Ok; is this tracked in a bug/blueprint somewhere?
<ogra> err, sorry, was distracted
<ogra> we *do* already include both
<lag> vstehle: Thanks, but there's no need. The parport_pc driver is crashing your devices.
<ogra> lool, https://blueprints.edge.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap
<ogra> lool, "Change armel+omap debian-cd scripts to create a two partition image with first partition being vfat with proper bootloader setup"
<lool> ogra: Hmm
<ogra> lool, dailies are here: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ (still lacking web indicies, manifest and proper md5sum stuff, but its on teh list)
<lool> ogra: Yes, this didn't boot with qemu for me
 * ogra never tried it with qemu
<ogra> did you dd it to an SD card and ran qemu with it as hdd1 ?
<lool> ogra: My ports-dev PPA has an updated package
<ogra> you will definately need a real disk for it
<ogra> since it tries to expand to the full disk size, it wont work if it cant expand to have free diskspace
<ogra> we only leave 10M in the root partition that are eaten up ny the ext3fs journal
<ogra> s/ny/by/
<ogra> so even if you would get it to boot, it would need to be dd'ed to a bigger sized (i'd recommend 4G) image
<ogra> lool, your qemu is omap3 i guess, we only include the actual beagleboard MLO in the image atm
<lool> ogra: I did a bunzip2
<lool> and ran it with qemu -sd
<ogra> so if you dont strictly emulate a beagle that might be the prob
<lool> ogra: My QEMU boots the Angstrom beagleboard image somewhat
<lool> Well into kernel boot messages for instance
<ogra> and ours ? where does it stop ?
 * ogra is in the process of updating to x-loader 1.4.4 from 1.4.3 ... probably that helps
<ogra> i didnt touch the omap3 stuff since pre-A2 but it definately works on real HW
 * ogra focuses on omap4 atm
<ogra> lool, angstrom images are not partitioned, they are tarballs, no ?
<hrw> ogra: they are
<ogra> unless something changed significantly recently
<hrw> ogra: you mean 'narcissus' ones I assume
<ogra> hrw, no idea what lool used above for qemu tests
<hrw> neither do I
<ogra> i know for sure our images work on actual HW and i would have never gotten the idea to try one of them in qemu :)
<ogra> especially since its quite some hassle you have to do with the image sizing
<ogra> if you dont actually dd to an SD card
<lool> ogra: No, it's a partitioned SD card image
<lool> Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.sd-image-2GiB.img1  *           1           9       72261    c  W95 FAT32 (LBA)
<lool> Angstrom-Beagleboard-demo-image-glibc-ipk-2010.3-beagleboard.sd-image-2GiB.img2             10         240     1855507+  83  Linux
<ogra> where did you get that ?
<ogra> i only know the tarballs
<hrw> I know that OE can generate any type of image
<ogra> the partitioning seems to be identical to ours though
<ogra> and since we use the same code i bet it actually is :)
<ogra> so the only difference can be xloader or uboot if you dont get any serial output
<ogra> our omap3 x-loader package is still at 1.4.3 with the XM patches on top ... in 1.4.4 the XM patches are included, i'll update it this week
<ogra> lool, so try an image from the end of this week
<ogra> so we can exclude MLO here
<ogra> its my only explanation
<ogra> lool, you can also try to replace the binaries in the vfat and see
<rsalveti> furibondox: yep, no problem
<rsalveti> furibondox: same arguments
<rsalveti> furibondox: vmware can be your problem
<furibondox> thank you very much rsalveti
<rsalveti> np
<furibondox> I will try with a native ubuntu installation
<lool> ogra: I tried the image from yesterday evening
<ogra> lool, cant be, the livefs builder was broken since thu :)
<furibondox> rsalveti: I've a question... do you have tested with a lucid?
<lool> ogra: I grabbed the "current" image from yesterday
<lool> it might be a stale one
<ogra> lool, as i said above, i'll update x-loader-omap3 this week
<lool> ogra: Ok, thanks
<ogra> until then try to replace the binaries in our image witrh the angstrom ones
<ogra> and see if it boots then
<rsalveti> furibondox: yep
<ogra> our vfat is exactly 9 clinders and "W95 FAT32 (LBA)" so there shouldnt be a difference apart from MLO and uboot
<furibondox> rsalveti: can you also send me the output of a dpkg -l of your pc?
<rsalveti> furibondox: 10.04.1
<rsalveti> furibondox: sure, 1 sec
<furibondox> I leave my email in pm
 * ogra takes a break and hunts for more icecream
<rsalveti> furibondox: http://paste.ubuntu.com/462558/
<furibondox> tnx
<hrw> lag: did you got working screen finally on panda?
<lag> Nope
<lag> TI are working on it
<lag> I've been working on something else
<hrw> lag: maybe http://gitorious.org/pandaboard/kernel-omap4/blobs/L24.6_panda/drivers/video/omap2/dss/hdmi.c  will help you to find working hdmicode value
<ogra> or http://omappedia.org/wiki/Bootargs_for_enabling_display
<ogra> we had all that in the dicussing last week :)
<ogra> *discussion
<hrw> ;)
<lag> Finding a working hdmicode is not the issue
<ogra> right
<lag> When I use sysfs almost all of them work for me and my monitor
<lag> When I use the cmdline arguments, the best I can hope for is a fuzzy screen and an "out of range" message from my monitor
 * ogra just thinks its a matter of the right glasses
<ogra> they should just ship them with the boards ;)
<fjrivash> Hello, I am following these instructions to get a rootfs for ARM https://wiki.ubuntu.com/ARM/RootfsFromScratch, I compiled a kernel and generated a zImage, when I try to run qemu (as specified in the tutorial) I got a black screen, I tried adding -d options file.log at the end of the command to get the output but I got nothing, am I missing something?
<fjrivash> I changed the -cpu option for amr11mpcore,
<fjrivash> thanks in advanced :D
<ogra> fjrivash, for which release are you building your rootfs ?
<fjrivash> lucid
<ogra> wont run with arm11mpcore
<ogra> lucid is built for armv7
<ogra> arm11mpcore is an extended armv6 as i understand it
<fjrivash> ohhh I see.
<fjrivash> Yes it is compatible with armv6kz
<ogra> use the binary kernel from the tutorial
<fjrivash> well see : I did the first step of this section "Building a root filesystem image instead of a tarball" and after that compiled my own kernel and tried booting : it did not work. After that I got that image and is the same, that is why I am asking.
<fjrivash> is there a way to build a rootfs of a release wich support armv6 (or compatible) using rootstock?
<GrueMaster> fjrivash: Try using Karmic or Jaunty.
<GrueMaster> Otherwise you are kind of stuck with debian.
<ogra> karmic supports v6
<fjrivash> Ok. i will try with them :D great!. Thank you (both) very much :D
<fjrivash> I have been reading different documents about this topic and some of them says that you need to specify initrd in qemu command line, is it necessary?, I am not pretty sure about that, thanks in advanced again
<Apaisal> hello all
<rsalveti> ogra: hm, same seg fault on x86 =\
<rsalveti> will try to debug it now
<suihkulokki> lool: committed and pushed to gitorious
<htc>  I wana to do  same her   http://nexusonehacks.net/nexus-one-hacks/how-to-install-ubuntu-on-your-nexus-oneandroid/  whit another version of ubuntu but I don't know how  bullied an arm img of it it there any doc can help
<hrw|gone> htc: try karmic
<htc>  <hrw|gone> how
<hrw> htc: no idea, never played with chroot on mobile devices
<hrw> and I do not like idea of 'run ubuntu/debian/fedora/anyotherdistro in chroot and tell everyone that you run it'
<hrw> chroot is chroot... if people boot that distro then I will say that they managed to do something worthy
<htc> <hrw> no , what I want is the way to builded from scratch there is any doc can help
<hrw> htc: you rather want to get rootfs for ARM rather then start from scratch
<htc>  yep  like this exmple http://nexusonehacks.net/nexus-one-hacks/how-to-install-ubuntu-on-your-nexus-oneandroid/ in order to run it on an android device
<hrw> so use rootstock
<htc> like her https://wiki.ubuntu.com/ARM/RootfsFromScratch
<hrw> yes
<htc> I will need any thing else after I build the ARM img
<hrw> htc: ask nexusonehacks.net guy?
<hrw> hi prpplague
<prpplague> hrw: greetings earthling
<htc> ok  men I will
<htc> & tnx
<lool> ogra: is LP #589624 still an issue for you?
<ubot2> Launchpad bug 589624 in linux (Ubuntu) "[Maverick] omap flavour does not work on beagle XM board (affects: 1) (heat: 97)" [High,Triaged] https://launchpad.net/bugs/589624
<lool> suihkulokki: Thanks
<ogra_cmpc> lool, yes, thats the main reason why i update the x-loader package
<ogra_cmpc> lool, apparently it works on *some* XMs
<ogra_cmpc> i'm hoping updating x-loader makes it work on all
<ogra_cmpc> (recommendation from #beagle)
<ukleinek> npitre: thanks for your mails, great to have your support
<zumbi> yeah! mv sh*t /dev/null
<armin76> zumbi: what happened?
<zumbi> armin76: nothing! spain won, we are champions! congrats! :)
<zumbi> armin76: linus wants to remove defconfigs from arm and ppc, but ukleinek did a proposal (he did not like it, but it removes 200k lines of sh*t)
<ukleinek> zumbi: :-)
<ukleinek> user@host:/usr/bin$ ls sh*t
<ukleinek> showcfont  showfont
<zumbi> ukleinek: this is best than TV series anyway (also we have the hardfloat arm stuff) :)
<ukleinek> zumbi: your sentence doesn't make it through my natural language parser :-(
<zumbi> ukleinek: i meant that your thread at linux-arm@ is going to take long discussion (better to follow this thread than TV series - I have no TV at the moment -). We, as distro, also have long thread on having an arm hardfloat port, which it is involving upstream and it seems that lot of people is interested, but they need to workout mechanisms (on the upstream side)
<ukleinek> ah
<zumbi> ukleinek: It seems that it is time to put some order in the ARM trees (linux+rootfs)
<ukleinek> zumbi: there is definitly potential for more order, yes
<ukleinek> still, I leave for bed now and will recheck tomorrow for the outcome of the discussion
<zumbi> Sure, it'll take a while to put all bits in place
<zumbi> g'night! and congrats for the good job :)
<ukleinek> There is even potential for more code sharing across archs
<ukleinek> zumbi: It was easy and I don't consider it "good", it's just nice and the best thing that currently works.  My main concern is to be able to continue build testing until a better solution is implemented
<zumbi> ukleinek: sure, s,good,fast & effective, but you are the one that came up with the short term idea, for others to think on the long term one. :)
<ukleinek> zumbi: if you check the changes I did to the ns9xxx_defconfig you see it's actually an old idea
<ukleinek> This file was first reduced and then I added some symbols that I expected to be mainlined next
<zumbi> uhm.. haven't check the changes.. but i worked with ns9215
 * ukleinek is now really away
<zumbi> bye
<zumbi> i'll have a look
<npitre> ukleinek: no problem
<npitre> ukleinek: ... and it is in now ;-)
<zumbi> linus is fast! I like it :)
<zumbi> npitre: and rmk warns linus about adopting DT?
<zumbi> or did I misunderstood?
<npitre> zumbi: no, what RMK is refering to is not DT
<zumbi> ah! I was thrilled about it
<npitre> zumbi: we're working on various patches to eventually allow a single kernel binary to support multiple SOC families, and that is orthogonal to DT
<zumbi> but I guess both approaches target the same problem
<npitre> zumbi: not exactly
<npitre> zumbi:  DT is about how to provide info to the kernel so it can configure itself even for yet-to-exist boards
<npitre> zumbi: so DT will allow to reduce the per machine static configuration code
<npitre> zumbi: but DT cannot solve the much bigger issue of being able to compile together support for more than one SOC
<zumbi> which it is probably what RMK was talking about
#ubuntu-arm 2010-07-13
<ukleinek> zumbi: the story is over, Linus pulled :-)
<hrw> morning
<ogra> cooloney, urgh, please ship vmlinuz in the linux packages
<ogra> we use flash-kernel on all arm platforms to do special stuff to the binaries (i.e. running mkimage to create uImage)
<ogra> i dont want to special case flash-kernel for certain platforms
<ogra> cooloney, we need to create uInitrd anyway on each update-initramfs trigger so it makes no sense to ship uImage in the package (and we had that discussion before several times)
 * cooloney nods to ogra 
<cooloney> ogra: great, understand.
<ogra> :)
<lag> mythripk: Hi
<fjrivash> Hello, I created a rootfs using this command sudo rootstock --fqdn qemu-test --login qemu --password qemu -d karmic --notarball, I compiled a kernel in the standard way (make, make modules, make zImage) and try this command sudo qemu-system-arm -M versatipb -cpu arm11mpcore -kernel ./zImage -hda qemu-armel-201007121813.img -m 256 -append "root=/dev/sda rootwait", but I got just a black screen.
<fjrivash> thanks in advanced for any comment about this.
<fjrivash> other thing is : is this the right way to cross compile my kernel ? make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
<fjrivash> thanks again in advanced
<ogra> if you got a binary thats likely the right way :)
<ogra> i would suspect you are missing some console settings
<lag> fjrivash: Which board are you using?
<fjrivash> ogra, I got it after make zImage
<ogra> try with -nographic
<ogra> (on the qemu cmdline)
<ogra> that should at least show some kernel messages
<fjrivash> lag, a CNS3410 (it is an arm11mpcore which is compatible with armv6kz)
<fjrivash> ogra, thanks I will try it right now
<ogra> (note that you cant ctrl-c qemu then, you need to close the terminal to stop it)
<ogra> or kill it from another term
<fjrivash> jejejeje I see! it was so funny, I thought that was something else bad
<lag> Well done ogra
<fjrivash> ogra, I got nothing :S. it think it must be the kernel
<lag> I take it back ;)
<lag> Does qemu not have pre-boot messages
<lag> Similar to a bootloader?
<fjrivash> actually yesterday I built a new image using karmic. lag AFAIK you must install a bootloader if you want to use it to load a kernel image
<lag> Do you need one?
<lag> Or will qemu be the bootloader too?
<fjrivash> well to be honest I trying to avoid that. but it seems that I need one, for example u-boot
<lag> Ask ogra
<lag> ogra: Do you need a bootloader when you use qemu?
<fjrivash> lag thank you very much. :D
<ogra> lag, nope
<lag> Okay
<lag> I might install it and have a play
<sebjan> ogra: coming back to uImage creation - how to make update-initramfs generate the uImage? Is there a script to update in the kernel package or somewhere else?
<ogra> lag, i think you *can* use a bootloader ... i think lool does that in his qemu-maemo experiments, but specifying the kernel should be enough to get a booting system
<ogra> sebjan, flash-kernel does it
<ogra> sebjan, have a look at update-initramfs and the flash-kernel source
<ogra> sebjan, since my last update to flash-kernel that should happen automatically on ubuntu images
<ogra> for omap3 and 4 at least
<sebjan> ogra: it does not for our omap4 kernel packages at least, this is why I came up with this dirty hack :)
<fjrivash> ogra, lag thank you very much I will recompile the kernel because I think that is the problem, I will let you know
<ogra> sebjan, flash-kernel requires /etc/flash-kernel.conf on omap4 (thats created during first boot of the image)
<lag> fjrivash: Where did you get qemu-system-arm from?
<fjrivash> from repositories
<ogra> sebjan, and you need at least flash-kernel 2.28ubuntu2 for panda support
<fjrivash> actually I did a qemu-system-arm --cpu ? and there is an arm11mpcore support-
<ogra> sebjan, and also a /boot/boot.script file as input for the used boot.scr
<lag> It's not in my repository
<ogra> lag, qemu-kvm-extras
<lag> ogra: Thanks
<ogra> iirc
<ogra> rootstock pulls it in automatically
<ogra> together with qemu-arm-static
<ogra> for arm chroot handling
<fjrivash> that is right
<sebjan> ogra: ok, I was far from it :) thanks! Could you please send me an example flash-kernel.conf file?
<ogra> sebjan, UBOOT_PART=/dev/mmcblk0p1
<ogra> sebjan, thats all :)
<ogra> sebjan, flash-kernel only needs to know where the bootloader partition is (and you need the /boot/boot.script as input)
 * ogra takes a break
<sebjan> ogra: thanks!
<fjrivash> in which cases do I have to use a ramdisk?
<fjrivash> I mean I have read that you can specify a initrd in qemu command but I am not pretty sure if I need it.
<fjrivash> (figuring out)
<lag> lool: Ping
<lag> fjrivash: Did you build the kernel yourself?
<fjrivash> yes
<lag> fjrivash: Do this from the root of your kernel tree: "find . | grep vmlinuz"
<fjrivash> there is no vmlinuz, there is a zImage which is in a boot directory, I am compiling the kernel (again)
<fjrivash> the first time I got a zImage of 40mb
<lag> You must have debugging symbols turned on
<lag> And all your drivers built into the kernel
<lag> fjrivash: Use this: http://www.aurel32.net/info/debian_arm_qemu.php
<lag> And slowly supplement its components for your own
<lag> I've just tried one of my kernels, but it doesn't support omap out of the box
<fjrivash> mm I see. let me check that url.
<lag> mythripk: ping
<mythripk> yes lag
<lag> Good morning
<lag> Or afternoon where you are
<lag> How are you/
<lag> ?*
<fjrivash> I found this one http://wiki.debian.org/ArmEabiHowto which is based on that one lag but with new kernel images.
<mythripk> lag : ya good afternoon, fine  thank you , did you see the mail i sent on the code sequence for sysfs and bootargs
<lag> fjrivash: Good. Use that and slowly supplement its components for your own
<lag> mythripk: I did
<lag> mythripk: I am seeing some odd behaviour
<mythripk> ie ?
<fjrivash> lag thank you very much I am working on it right now, I will let you know.
<lool> lag: pong
<lag> mythripk: When the monitor goes to sleep after a time - when it wakes up, the setting have gone back to fuzzy
<mythripk> lag: even with the sysfs u mean
<lag> mythripk: So: Boot up -> Fuzzy | Use sysfs -> Good | Sleep-Wakeup -> Fuzzy
<lag> The board is still awake
<lag> It's just the monitor which is put to sleep
<mythripk> lag: with fuzzy you mean the out of range
<mythripk> lag: how do you get the display out of sleep , if you set fb black it would not go to sleep
<mythripk> lag: Ping ping echo "0" > /sys/class/graphics/fb0/blank this command would not suspend the TV .
<lag> mythripk: I get the display out of sleep by pressing the keyboard
<lag> mythripk: Yes, I mean 'out of range'
<lag> Why would I want to do that command?
<mythripk> lag: even with the out of range block  appearing at the centre , you can still see the commands ?
<lag> Yes
<mythripk> lag: That command will not blank the TV , ie the TV will not go to sleep
<mythripk> have you tried a different HDMI cable ?
<lag> I didn't use that command
<lag> That cable works fine on my Beagle
<mythripk> you could use that command in case you dont want the TV to sleep
<lag> We have to put our displays to sleep
<lag> We are an Operating System
<lag> Well a distribution
<mythripk> that is fine , you need not , that was just in case it was not expected.
<lag> That is not the problem
<lag> The problem is that it does it and it's not meant to
<lag> So needs fixing somehow
<lag> That is not the only odd behaviour
<lag> When you told me to boot with less arguments, it worked perfectly on start-up (with the cmdline args)
<lag> But on a subsistent boot it was 'out of range' again
<lag> With the same settings
<mythripk> one reason from your log i have seen is that there are too many bootargs and thus hdmimode is not effective , thus it is going to a wrong non desired setting
<lag> But I have reduced the number of bootargs
<lag> And the behaviour is the same
<mythripk> and now the timing is correctly set? can you pastebin the log since bootargs
<mythripk> because i dont see this behaviour on viewsonic or samsung TV that i have
<lag> They are not correctly set
<lag> It was, once
<lag> But on subsequent reboots they reverted to incorrect
<mythripk> ok , I have an RFC for autoboot of HDMI , i will be posting on OMAPPEDIA , that would atleast remove your bootargs problem
<lag> Can I follow that?
<mythripk> yes , Please
<lag> How?
<mythripk> lag:I will be putting it on http://omappedia.org/wiki/Display_Drivers_Domain_Wiki
<mythripk> once i'm done with sanity testing
<lool> lag: Hey you pinged me, I ponged, but then I didn't hear anything anymore?  :)
<mythripk> lag: But one confirmation , it is only in your LG make TV you are seeing this issue right , not in any other monitors
<lag> lool: Everything came alive at the same time - can you give me a minute please?
<lag> mythripk: I don't have any other monitors to test
<lag> mythripk: If you want to send me other monitors to test, I'd be more than happy to
<lag> lool: Do you use qemu to boot omap images?
<lool> lag: I do
<lool> lag: They need a bootloader on the images, and that apparently doesn't work with current Ubuntu images, but it should in theory work
<lool> lag: https://launchpad.net/~lool/+archive/ports-dev/+packages has maverick packages of qemu-maemo
<lag> lool: Okay, that explains a lot
<lool> lag: something like qemu-maemo-system-arm -M beagle -m 256 -sd ubuntu.img -serial stdio
<lool> That works more or less with Angstrom ATM, it boots well into the kernel, but then I get some divide by zero in the kernel which I didn't lookinto
<ogra> lool, hmm, we had that with the omap kernels too
<ogra> (division by zero errors)
<lag> Yes we did
<ogra> smells like a kernel prob, not like qemu
<lag> I can't remember what the cause was though?
 * ogra neither
<ogra> but i remember some oopses that had such an error in front of them
<lag> I think I had them when I tried to boot the XM with Lucid
<lool> I tried an older Angstrom kernel, I'd be surprized if it had divide by zero errors
 * ogra thinks he saw them together with the ureadahead OOMs too
<lool> Anyway
<lool> First thing with Ubuntu images would be understanding why it doesn't work in qemu-maemo
<lag> Ogra likes to blame everything on the kernel
<lag> It's an easy scapegoat
<ogra> indeed :)
<lag> :)
<lool> ogra: Let's just blame everything straight to lag then?
<ogra> lool, can only be the bootloader/x-loader
<lool> ogra: it could be the partition layout
 * lag == scapegoat No1
<ogra> lool, else you would at least see u-boot messages
<ogra> lool, we use the angstrom script to create our bootloader partition
<markos_> lool: fwiw, I've officially sent a request to rejoining Debian, I intend to work on the armelhf -or whatever it's called- in a much more official -or semi-official- way now
<markos_> no idea how long it takes, but it won't take as long as a full NM application
<lool> markos_: did you follow linaro-dev discussions?
<markos_> (this after reading most mails on linary and debian-arm lists)
<markos_> yes
<lool> About NOT doing a new port   :-)
<ogra> lool, well, the OE script which angstrom uses as well :)
<lool> markos_: I find the discussion very interesting, but I find it a hard sell for the bunch of people interested in working on the port
<markos_> still reading, haven't finished yet :)
<lool> markos_: I've personally written to zumbi to tell him I would like to semi-officially work on that port
<lool> as in, with my Debian hat on and on a best effort basis
<lool> but I expect to help as much as I can
<ogra> linaro goes debian ? :)
<markos_> well
<lool> Sure, we're not tightened to Ubuntu
<lool> we're helping all distros out there if we can and know how to
 * ogra was joking, i know that
<lool> But we're also splitting our time wisely   ;-)
<markos_> there is nothing to prevents us (Genesi) from working on an unofficial  hardfp port just as we are now, with no new port name, because on our cpu (a8), there is a lot to gain and it can give us a competitive advantage -and of course to others that choose to use our repository
<markos_> at the very least we can provide testing and patches for packages that fail to build for hardfp
<markos_> I'd really hope for a new port though
<markos_> it would make things easier -and- provide a new optimized port for newer cpus
<markos_> with no new port -regardless of the toolchain changes- it's guaranteed that performance will always be sub-optimal
<markos_> other arches don't have such a big problem
 * zumbi confirms lool's wanting to help on Debian port
<markos_> eg. on ppc, the abi is the same always, if someone wants more performance they can always install a -altivec version of the package -if available of course
<ogra> markos_, depends ... look at ubuntu, we still call what we have "armel" even though its totally not what you get in debian
<mythripk> lag: I shall send the link to the RFC to solve your bootargs problem , it would do an autodetect , but for your out of range problem i have contacted the hardware and power management folks i shall get back once i get a reply , as it doesnt appear to be a HDMI s/w issue.
<ogra> we could as well just default to hardfp
<zumbi> ogra: debian is upstream, linaro, ubuntu, mint, .. all of them will fork
<ogra> since we dont support any of the old CPUs anymore
<ogra> zumbi, indeed and its surely the better move to have what we have in ubuntu in our upstream already
<ogra> will save us a lot of work
<ogra> i'm just pointing out that armel != armel if you look at it today
<lag> mythripk: Thanks, I'll look forward to it
<ogra> and to be honest i'm not really lookinf forward to all the script changes we have to do based on a name change
<markos_> ogra: yes, that's exactly what I did as well, if I waited for toolchain fixes, I still wouldn't be able to test a single package :)
<hrw> 12:19 < ogra> lool, well, the OE script which angstrom uses as well :)
<hrw> ogra: thats ÃngstrÃ¶m script which is stored in OE repository
<hrw> ;D
<ogra> hrw, heh, well, whatever way you want it around, our boot partition is created the same way :)
<lag> sebjan: ping
<ogra> so it cant be poartitioning imho
<ogra> -o
<zumbi> ogra: so do you suggest 3 different "armel" flavours: debian, ubuntu and genesi's
<markos_> zumbi: if ubuntu decides to go hardfp themselves, there would be need for only 2
<ogra> zumbi, no, the opposite
<zumbi> ogra, ok, i misunderstood :)
<ogra> zumbi, if hardfp shows up in debian (and also uses our current defaults v7 etc) it would be the logical choice for me to switch ubuntu over
<ogra> zumbi, i'm just fearing all the script changes for scripts that look at $arch+$subarch we currently use in ubuntu
<lool> markos_: The point Mark is making is that they are other ways to rip (most?) of the benefit of hardfp, a new port adds permanent fragmentation though
<zumbi> ogra: but ubuntu will keep maintaining two different armel ports? or just one?
<ogra> zumbi, preferably just one optiomized for cortex-a8 and bigger
<lool> markos_: Costs such as doing the validation twice, or costs such as for ISVs trying to provide binaries are quite high
<ogra> zumbi, thats what our current armel already is
<lool> markos_: Consider that we don't have a flash plugin for 64-bits after all this time
<ogra> zumbi, for me it would just be a name change plus a different fpu
<markos_> lool: I don't see that as necessarily a bad thing, why should a router developer care for neon optimizations or vfp stuff that a desktop distro developer would insist upon?
<lool> markos_: flash might just land on arm soon, and now we will require two versions?
<markos_> and vice versa
<lool> markos_: Fragmentation
<lool> markos_: You might release an android phone build on vfp or non-vfp hardware
<lool> suddenly, you have to use a different stack
<lool> and people have to provide different native builds
<markos_> lool: by the time it arrives, lightspark might work on arm already and even surpass official flash
<markos_> important as it is, flash is not the driving force behind a distro
<lool> markos_: Eh it was just an example obviously
<markos_> lool: I'm not aware of any important non-free software that would act as a show-stopper, apart from flash
<hrw> lool: many android/winmo phones with armv6 cpu do not have vfp
<zumbi> lool: how much is codesourcery, ARM and linaro to make those compiler changes? -- are they worth it?
<ogra> lool, what ? you are not working on fixing a 64bit flash ?
<lool> markos_: Even for Debian, it means new buildd network, new images to validate, packages to change, the work will eventually be distributed on a bunch of DDs, but the sum of it is HUGE
<lool> hrw: precisely, thanks for mentionning it
<lool> markos_: Consider the market place use case
<lool> markos_: I ship an OS, and ISVs can offer apps for it
<hrw> lool: qualcomm msm armv6 cpus to be exact
<XorA> hrw: the msm72XX CPUs tend to lack VFP
<markos_> also, android is totally irrelevant to ubuntu/debian, they already have totally separate binaries
<lool> markos_: Suddenly, this OS might come in two incompatible flavors and ISVs have to provide builds for the two flavors and test the two
<markos_> and totally incompatible
<ogra> markos_, its not ... there are hacks that make android work in ubuntu
<ogra> not officially in the archive but you can use them
<markos_> exactly that, hacks, it even has a different libc
<lool> These are just example
<lool> I could have said MeeGo and made the same point
<markos_> I understand your point
<markos_> but in my experience, users will very rarely pick a package from another distro -eg. a meego user from an ubuntu netbook for example and try to make it work
<ogra> there might be a meego ubuntu image at some point, who knows
<lool> markos_: It's not about other distros, it's about ISVs
<markos_> so compatibility is not really important here, Adobe for example, will most likely have a single instance of most important distros and build on each one separately -I  don't know if that's the case, but I imagine it's a logical scenario
<lool> markos_: In Android, Maemo, MeeGo, Ubuntu, you get to add packages and software from ISVs
<ogra> and these users would surely want to be able to use all of the ubuntu archive on their systems
<lool> markos_: heck, that's even true for Ubuntu, vmware provides binary .debs
<lool> Or Adobe Acrobat Reader
<lool> or many others
<ogra> or flash :)
<lool> (that was covered already)
<markos_> yes I totally understand your point
 * ogra was referring to adobes flash package :)
<lool> markos_: Once you create the port, and you have a somewhat popular userbase
<lool> Debian derivatives will appear (probably including Ubuntu I'd guess)
<lool> and products will ship based on it
<lool> and the ARM world will be fragmented a bit more
<lool> So I'm /very/ split on this point
<markos_> my point is, if Adobe would provide the same package with just rebuilding it on the same hardware -and no other extra development- why should they not do that,
<lool> markos_: they need to port it, validate it twice etc.
<markos_> lool: ARM is way beyond unification :)
<lool> markos_: You think adobe flash would work without any tweaks on hradfloat calling conventions?  I bet not
<ogra> the opposite is the case thanks to linaro
<markos_> lool: it's the most fragmented architecture out there :
<lool> I bet upcoming ones have NEON opts and stuff
<markos_> lool: neon works just fine on hardfp
<lool> markos_: And fragmentation is the main issue, and initiatives like Linaro fight fragmentation towards consolidation
<lool> markos_: My point is, there is manual assembly in flash player, so they will have to adapt
<markos_> if done using pure asm, maybe, if done using C intrinsics, they most definitely not
<markos_> s/they/then
<lool> markos_: I think it's a large body of code with assembly, and has good chances of hitting the issue
<lool> markos_: In any case, I think the main problem is that the alternate plans being discussed are far away
<lool> markos_: Both because they need long developments and because they need a certain class of people (experienced toolchain devs)
<lool> markos_: So I currently suspect the port will happen by virtue of being atteinable now
<ogra> we could switch M+1 to hardfp in ubuntu and act as a testbed for debian
<ogra> debian would just have to take our armel defaults then
<ogra> and we would rename to armelfp in M+2
<ogra> without having to do more changes than renaming
<markos_> ogra: I could act as a testbed for Ubuntu myself, I could rebuild Maverick for example for hardfp and provide testing/patches
<markos_> my goal ofc would be to have a hardfp maverick build
<lool> ogra: "switch"
<ogra> well, we wont do a hardfp build in maverick but test results would surely be appreciated
<lool> ogra: you dont switch
<lool> it's binary incompatible
<ogra> lool, its a full rebuild, i'm aware of that
<lool> you can introduce a new port, deprecate armel, and them move to the hard-float one
<lool> ogra: No, it's incompatible
<lool> it's a new bootstrap
<lool> ogra: You can't "upgrade" to it
<ogra> oh, indeed
<lool> ogra: I think you need to read the debian-arm@ discussion
<ogra> lool, i do
<ogra> not extensively but i have read some of the thread
<markos_> brb
<ogra> lool, indeed we would have to make a cut, but we will become the best optimized v7 distro in the end so i dont think its a bad thing
<ogra> lool, what i wont do is maintain two arm arches
<lool> ogra: See that's the main issue
<lool> ogra: You dont want to maintain two arm arches
<lool> Nobody wants
<lool> well Debian is ready to start that
<ogra> debian does already, no ?
<ogra> they would get a third
<zumbi> debian is discussing it! not ready for anything, just Genesi is ready
<lool> but in practice, ARM Cortex-A class CPUs with VFP are the high-end ones, and many devices will ship with A-class CPUs without VFP, including phones and netbooks
<ogra> ir is the arm oabi port completely gone ?
<lool> ogra: Debian only has an armel port right now
<ogra> ah, i thought arm was still existing
<lool> That said, Ubuntu already excludes non-VFP hardware
<ogra> right
<ogra> for us its not such a big step apart from upgradeability
<sebjan> lag: pong
<markos_> lool: anything new reg. soyuz release as standalone?
<lool> markos_: I'm not tracking that personally, ping salgado on #linaro
<lool> .br time
<lag> sebjan: Good morning
<lag> Afternoon even - doesn't time fly?
<sebjan> lag: yes indeed :)
<lag> sebjan: Do you have any documentation you can send me for OMAP3 and OMAP4?
<lag> sebjan: A developer's manual or such
<lag> sebjan: Containing memory maps, register addresses and definitions etc
<sebjan> lag: the technical data manual for omap3 shall be available publicly...
<sebjan> lag: it is not out yet for omap4
<sebjan> lag: regarding the beagle, there seem to be good links here: http://elinux.org/BeagleBoard#Manuals_and_resources
<lag> But nothing for the XM?
<lag> Or Panda?
<lag> The two boards I own :D
<markos_> lool: does gcc-linaro include hardfp patches from CS? I'm pulling the 4.4 branch now to test
<sebjan> lag: I have never looked for the XM, if it exists, it shall be reference on the wiki? For panda, it will come when it is release ;) We shall have omap4 data manual soon I hope.
<lag> sebjan: Perhaps I need to be a little more specific
<lag> sebjan: Do you have the developers reference for the OMAP3630
<sebjan> lag: you shall ask this on the #linux-omap channel, they shall be able to provide you clear answers regarding public documentation and where to get it
<ogra> should be on ompazoom.org
<lag> Thanks sebjan
<ogra> (if it exists)
<lool> markos_: Yes
<ogra> though there is likely no XM docs yet since XM isnt sold yet
<lool> markos_: We're rolling a test tarball if that makes testing easier for you
<markos_> cool
<mythripk> lag: others:   http://omappedia.org/wiki/RFCs  please have a look at it and provide comments if you have any , it is for the Autodetect feature for HDMI
<ogra> mythripk, could it be a higher default than 640x480 or would that break on to many screens ?
<ogra> (800x600 would be a bit better for X driven distros)
<lag> mythripk: That system for RFC is weird
<ogra> mythripk, what also would be cool would be if custom_edid_timing could seed the available framebuffer modes (and xrandr)
<ogra> lag, you mean using powerpoint ... ? :)
<lag> Yeah
<lag> Naff!
<lag> ogra: My Maverick install falls into a initramfs shell
<ogra> did you fiddle with boot.scr ?
<ogra> manually i mean
<lag> Yep
<ogra> aha :P
<lag> It's the only way I can see the screen at all
<ogra> must be the kernels fault then *g*
<lag> Jerk
<ogra> did you update the system recently ?
<ogra> flash-kernel changed a bit and expects a clear text /boot/boot.script file as input now
<ogra> (which jasper now creates by default)
<lag> It's the current build from last week
<mythripk> ogra:  it would break many screens and the only compliant resolution is 640 480
<ogra> well, if you didnt upgrade and your root=UUID line in boot.scr is still correct i dont see how you could end up in a busybox
<ogra> mythripk, ok, no choice then i guess
<mythripk> but it would read EDID , and set it to the timing supported by TV
<ogra> lag, show me your boot.scr :)
<ogra> mythripk, right, i only think about the fallback default
<mythripk> so only reason why it would set 640 480 would be if EDID is not read correctly
<ogra> yeah
<mythripk> ogra,lag  , so does the design look ok ?
<ogra> yes, looks ok to me, did you look how the kms drivers do it btw ?
<ogra> i guess there is a lot overlap
<mythripk> kms?
<ogra> kernel mode setting
<ogra> it is what all distros use nowadays
<ogra> i'm pretty sure there is code that reads EDID in all of them
<mythripk> ogra , i shall have a look
<ogra> :)
<ogra> eventually we would like to have KMS working on omap4
 * ogra thinks robclark knows some background here 
<ogra> as i'm not a graphics guy and only scratch the surface of such technology
<robclark> gm mythripk, gm ogra
<ogra> heya, morning
<mythripk> gm rob, the discussion is on the redesing of HDMI edid for auto detect
<robclark> ahh
 * lag feels left out of robclark's gms
<mythripk> http://omappedia.org/wiki/RFCs
<ogra> robclark, i was just wondering if there isnt possible overlap with KMS stuff that could be used
<robclark> gm lag
<robclark> probably is
<lag> mg robclark :)
 * lag is happy now
<sumitsemwal> gm robclark, ogra :)
<ogra> heh, gm sumitsemwal
<sumitsemwal> gm amitk
<robclark> I suspect the gfx team will need some API for 3rd party display driver for KMS..   but I've not looked at their xf86-video driver yet..   so not sure the details of how it will work..
<robclark> (that is on my todo list for the week)
<ogra> robclark, no hurry, but its probably easier to steal there than reinventing the wheel :)
<robclark> indeed
 * robclark needs coffee
<robclark> mythripk: fwiw, I think we need somehow some callback when monitor is detected...
<robclark> I'm not sure if that would be exposed to userspace thru omapfb, or thru gfx driver..
<robclark> but somehow xserver needs to find out when you, for example, plugin 2nd monitor
<amitk> hey sumits! :)
<amitk> how are you doing?
<sumits> amitk: doing good! and you?
<amitk> sumits: I'm good. Good to see you on here :)
<sumits> amitk: been here, mostly silently though.
<amitk> sumits: I hope you've 'met' lag, mpoirier and cooloney who're spearheading the omap enablement efforts on the Ubuntu-side
<sumits> amitk: have met lag, [i think have met cooloney and mpoirier at UDS?]
<sumits> gm cooloney, mpoirier
<markos_> lool: the subarch/capabilities concept might be the right solution
<lool> markos_: Not here, no
<lool> It's an incompatible ABI, and that needs a new port
<markos_> here = ubuntu?
<lool> well unless we go for Mark's proposal
<markos_> or in this case?
<lool> markos_: No, here == hard float port
<lool> markos_: Happy to move to #linaro BTW
<markos_> oh I see you're discussing it there?
<markos_> or not.. anyway  I joined to actually follow what's going on
<lool> markos_: we're discussing many things there   ;-)
<lool> markos_: I just dont think the new armhf port is an Ubuntu problem right now
<markos_> it isn't
<lool> It's a Debian and Linaro topic mostly, so seemed sensible to move it over
<ogra> lool, x-loader 1.4.4 is uploaded, next successfull image build should have it (for your qemu testing)
<rsalveti> ogra: when opening armel related bugs, should just including Ubuntu armel porters and the tag armel be enough?
<ogra> lag, ^^^ can you test one of the next omap3 images on your XM too ?
<ogra> everything after 20100713 on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/
<lag> ogra: I can
<ogra> thanks
<ogra> just want to know if it regressed
<lool> ogra: Thanks
<ogra> GrueMaster, seems the kernel team added some fixes to urwadahead, might be that the OOMs are fixed
<ogra> *ureadahead
<GrueMaster> I'll test them when I get them.
<ogra> GrueMaster, https://bugs.edge.launchpad.net/ubuntu/+source/ureadahead/+bug/501715 smells like the father of ours :)
<ubot2> ogra: Error: Bug #501715 is private.
<ogra> huh ?
<ogra> it definately isnt
<ogra> rsalveti, so looking at your code i like most of it ...
<rsalveti> ogra: so, what you didn't like? :-)
<ogra> rsalveti, what i dont like is that you use genex2fs even if root is used
<ogra> better create an image, mount it and cp the contents
<rsalveti> ogra: I decided to try only genext2fs to have just a single solution, avoiding supporting two possible paths
<ogra> that will be much faster, genext2fs first allocates the full image size in ram
<ogra> so it eats tons of ram for bigger images
<rsalveti> ogra: yeah, I noticed that
<ogra> and gets very slow
<ogra> so in that case i think a second code path is a valid solution
<rsalveti> ogra: that's what I realized when testing here, I thought about moving back root to the old solution also, but didn't integrate into the code
<rsalveti> ogra: ok
<rsalveti> ogra: I can move the root path to the old solution again, np
<rsalveti> it's actually faster
<rsalveti> if you get 2,3 G image, it's *much* faster
<ogra> yeah
<rsalveti> ogra: that's fine, I can change it here
<rsalveti> ogra: any other comment?
<ogra> rsalveti, the rest looks ok
<rsalveti> ogra: nice, will move the root solution back to what we currently have for rootstock and send the link for you to review again
<ogra> great
<lag> <ogra> lag, ^^^ can you test one of the next omap3 images on your XM too ?
<lag> ogra: Crashes and burns
<ogra> lag, <ogra> everything after 20100713 on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/
<ogra> :P
<ogra> asac, i'm planning to add a call to "/usr/lib/gdm/gdm-set-default-session une-efl" to jasper (only if the .desktop file for that session exists) so that it always defaults to the 2D session if thats installed
<ogra> asac, any objections ?
<prpplague> ogra: is usbfs no longer available with ubuntu 10?
<ogra> prpplague, thats obsolete since two years or so ?!?
<lag> ogra?
<ogra> lag, i dont care about todays image :)
<prpplague> ogra: problem is openocd uses usbfs
<ogra> lag, only about future images, after 20100713
 * lag tuts
<ogra> prpplague, fix it to work with something more recent than 2.6.18 then :)
<ogra> (me is exaggerating, i dont know the exact version when usbfs vanished, but its quite a while ago)
<prpplague> hehe, or just use fedora, hehe
<lag> I've had OpenOCD work on later kernels than 2.6.18
<prpplague> lag: yes it works fine with later kernels, just needs to have usbfs turned on
 * prpplague can use openocd and usbfs with ubuntu 9
<lag> On the debugging machine?
<lag> prpplague: Do you have an openocd.cfg that works with OMAPx
<prpplague> lag: with omap3, yes, see the beagle openocd page on elinux
<lag> I don't know where these places are
<lag> Link!
<ogra> prpplague, heh, that means you used a non ubuntu kernel
<lag> Googled it
<ogra> so dont say you used usbfs with ubuntu 9 :)
<prpplague> ogra: i did a straight ubuntu install
<ogra> how, we only started supporting omap in lucid
<prpplague> ogra: hunh?
 * prpplague is refering to x86 ubuntu install
<ogra> ah
<ogra> i thought omap3
<prpplague> ogra: openocd is a jtag utility to debug ARM devices
<ogra> prpplague, if the ubuntu package doesnt work in ubuntu because of usbfs that definitely deserves a bug
<prpplague> hmm, don't know if there is an ubuntu package for it
 * prpplague looks
<ogra> there is a debian one since ages, so i'd expect the ubuntu package to exist as long
<prpplague> ogra: i'll have a look this evening, but from past experience the one that is usually included as package(for any distro) is usually way out of date
<ogra> Version: 0.3.1-1 on lucid
<lag> prpplague: My device's voltage is to high to work with OMAPx?
<lag> :(
<prpplague> lag: what jtag device do you have?
<lag> Amontec Tiny
<lag> 2.8v -> 5vv
<prpplague> ahh
<prpplague> lag: should have purchased a flyswatter, hehe
<prpplague> lag: *cough*
<lag> It wasn't about when I bought this
<lag> And dev-boards weren't so weak ;)
<prpplague> lag: actually i released the flyswatter before the amontec tiny was release
<lag> Really?
<prpplague> indeed
<lag> How long has the Flyswatter been around?
 * prpplague checks the actual dates
<lag> prpplague: Do you do work for?
<prpplague> lag: TinCanTools but i am currently contracted out to TI
<prpplague> lag: june 5, 2007 was the release date for the flyswatter
<lag> And for Amontec?
<lag> I think I've had it ~3-4 years
 * lag checks
<prpplague> the earliest entry i see is august of 2007
<prpplague> i know they had the amontec jtagkey but i didn't think they released the tiny until later
<prpplague> lag: ahh i stand corrected
<prpplague> lag: looks like the jtagkey-tiny was released in nov 2006
<davidm> lag, do you want a flyswatter?
<davidm> prpplague, do you think I can get a flyswatter by Thursday if I order today?
<prpplague> davidm: yea, should be able to
<davidm> OK thanks
<prpplague> davidm: it will ship today most likely
<prpplague> davidm: and since you are in the dfw are it should arrive pretty quick
<davidm> OK let me run this down, with my kernel folks and then I'll place an order if they want them
<prpplague> davidm: dandy
<prpplague> davidm: grab some trainer boards as well hehe
<davidm> I just got in a Zippy2 so that should be good
<davidm> lag, mpoirier do you need flyswatters?
<mpoirier> flyswatters ?
<ogra> to splat bugs :)
<davidm> http://www.tincantools.com/product.php?productid=16134
<davidm> Jtag for beagle
<mpoirier> haven't looked at it - hold on.
<robclark> prpplague / davidm:  chris or myself could probably carry to prague if shipping is not fast enough to reach you before you leave (just fyi)
<prpplague> davidm: make sure you order the BeagleBoard adapters as well
<davidm> prpplague, yea, it's in my shopping cart now, I'll commit if I get a go ahead from mpoirier and/or lag
<prpplague> okie dokie
<ogra> asac, did you see my ping above wrt default gdm session ?
<lag> I would love to have a Flyswatter
<lag> My Amontec Tiny is to manly for OMAP
 * ogra just uses bugspray
<prpplague> davidm: rusty at TCT is ready to ship your flyswatters when you are ready
<lag> davidm: Did you see my comment?
<davidm> lag nope
<prpplague> davidm: you get your flyswatters ordered?
<davidm> prpplague, the guys decided there was no rush so I'll place a standard order while I'm overseas and time delivery for my return.
<prpplague> davidm: ahh np
<loluengo> hi everyone!
<loluengo> hello
<loluengo> i have a noob question
<loluengo> does ubuntu on arm need somthing like a screen to work?
<loluengo> can i use it as an OS over a UART terminal?
<loluengo> (i mean a console-only system)
<GrueMaster> Yes, you can.  What hardware are you working with?
<loluengo> i haven't defined my hardware yet
<loluengo> but looking to get an evaluation kit for an ARM920T micro
<rsalveti> loluengo: just pay attention on what board you want to get if you want to test ubuntu on it
<GrueMaster> Just be aware that Ubuntu lucid+ images only support Armv7
<rsalveti> karmic supports armv5, if that's enough for you
<rsalveti> you can use openembedded if ubuntu doesn't run on your board, but it's quite different
<GrueMaster> Actually, karmic is armv6+vfp.
<loluengo> and how can i know which "V" is the board i'm looking?
<GrueMaster> The arm version.  If at all possible, I would recommend something with Cortex-A8 or A9 as they are the latest and will be the best supported.
<GrueMaster> What is your goal for this project?
<rsalveti> GrueMaster: oh, right
<rsalveti> and depending on the price the beagleboard could be the best choice for you
<rsalveti> it's fast, supported and not that expensive
<GrueMaster> That was going to be my suggestion as well, although personally I would wait for the BeagleXM.  Double the memory, faster, built in ethernet, some other features.
<GrueMaster> And not much more expensive.
<rsalveti> yeah, better option
<rsalveti> loluengo: you can get the correct arm version of your cpu at http://en.wikipedia.org/wiki/ARM_architecture
<rsalveti> take a look at the big table
<loluengo> ok
<loluengo> hmm i hadn't heard of BeagleBoard
<GrueMaster> It has been around for a while, so most of the kinks have been worked out.
<loluengo> what do you think of this board?
<loluengo> http://www.olimex.cl/product_info.php?products_id=207
<loluengo> is it a good one to get started with ubuntu on ARM?
<GrueMaster> It looks rather old.  200mhz?  32M sdram?
<GrueMaster> Checkout http://beagleboard.org
<loluengo> oh... i see
<rsalveti> loluengo: checkout beagleXM
<rsalveti> is much much better than this one :-)
<GrueMaster> Should be about the same cost (if I am translating the currency correctly).
<loluengo> the xm is usd 180 on digikey
<loluengo> but not available yet
<GrueMaster> It should be shipping sometime around EOM.
<loluengo> yes...
<loluengo> i think i'll wait for then
<loluengo> and then start trying ubuntu on ARM :D
<rsalveti> nice :-)
<loluengo> does anyone know the minimum system requirements for running ubuntu on arm?
<rsalveti> loluengo: lucid+ requires you an armv7
<rsalveti> and you should have at least 256 of ram, but 512 would be much better
<rsalveti> if you want the desktop experience (like netbook)
<loluengo> i just need a console
<loluengo> 256 mb of ram shouls be enough?
<loluengo> *should*
<rsalveti> yep
<rsalveti> I'm running ubuntu on my beagle with 128, but without graphic, just as a server
<loluengo> ok
<loluengo> and how much of flash memory do you use for the system image?
<rsalveti> for minimal I guess it goes around 256, but 512 would be the recommended one for a usable system
<rsalveti> but I'm running my beagle with external sd cards
<loluengo> aaa ok @rsalveti
<loluengo> you boot your system from the sd card?
<loluengo> and the ram, is on chip? or on board?
<rsalveti> loluengo: yep, the boot loader loads the kernel from the sd and put it as the root fs
#ubuntu-arm 2010-07-14
<Jefro1> Hi all - anyone got time to help me debug?  I'm trying to boot on the BeagleBoard using the a download from a few days ago.  It all looks right, but bootloader stops at "I2C:   ready"
<Jefro1> this is on a BB c4
<GrueMaster> Jefro1: Try holding the user button while you press reset.
<Jefro1> ok, thanks
<Jefro1> 1 sec
<Jefro1> same issue
<GrueMaster> Where did you get the image from?
<Jefro1> just checking that -
<Jefro1> I believe it came from http://cdimage.ubuntu.com/ports/releases/10.04/release/
<GrueMaster> Ah.
<GrueMaster> Have you imaged before?
<Jefro1> actually, I'm not sure - it is called "ubuntu-10.04-minimal-armel"
<Jefro1> I have worked with BB images before, but not ubuntu
<GrueMaster> Ok.  I don't believe I tested that one.  I mainly focus on the netbook images.
<Jefro1> does the netbook image work on the beagleboard?
<GrueMaster> Yes.  http://cdimage.ubuntu.com/ports/releases/lucid/release/ubuntu-10.04-netbook-armel+omap.img
<Jefro1> I'm giving a presentation at OSCON next week about Linux vs. BeagleBoard and would love to show Ubuntu.
<Jefro1> ok, thanks.  stupid user question - what do I do with a .img?  I'm used to having a source tree or a prebuilt kernel/rootfs
<GrueMaster> We are also reworking the image so that all you need to do is flash it to an SD card and boot.
<Jefro1> cool - I can mention that in the talk
<GrueMaster> For these images, you need to do "sudo dd bs=4096 if=<img file> of=<path to SD card>
<Jefro1> aha - you guys are two steps ahead of me.  :)
<GrueMaster> You can demo the new image if you like.  It is available at http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/maverick-preinstalled-netbook-armel+omap.img.bz2
<GrueMaster> For the 10.04 images, there is a how to at https://wiki.ubuntu.com/ARM/Beagle
<GrueMaster> Of course, this will change with Maverick.
<Jefro1> excellent, thanks - don't know why I hadn't seen that page
<GrueMaster> If you decide to test Maverick, there are a few issues currently.  Namely, you need a class 4 SD card of 4G or greater.  Also, it will not boot into the netbook launcher by default once you get to gdm.  You need to select the 2d desktop for it to work.
<Jefro1> no worries - my talk will be over by then :D
<Jefro1> at the moment I'd just like to get something to boot that looks like Ubuntu, to whet people's appetites.  I only have 40m for the talk, and will be covering several distros.
<GrueMaster> Wish I could watch.   But work is callig me in a different direction next week.
<GrueMaster> The 10.04 image will boot into a live image, similar to booting a live CD on x86.
<GrueMaster> It is a bit sluggish due to only 256M memory though.
<Jefro1> xM will be out in about a month...
<GrueMaster> That's the working theory.  :P
<Jefro1> heh, yes.
<Jefro1> whoa!  it's booting - awesome
<Jefro1> I was watching the console thinking "hmm, shouldn't it be..." and then noticed the monitor.  very slick.
<GrueMaster> Wait until you see it on a newer system.  :D
<Jefro1> I have an early xM here, maybe I'll try it.
<Jefro1> mine has memory issues, though.  shocking, I know.
<Jefro1> thanks very much for the help - this will be just fine for the demo
<GrueMaster> 10.04 doesn't boot on the xm.  And there is an issue with xloader on the current maverick image.
<GrueMaster> At least from what I'm told.
 * GrueMaster doesn't have an XM...yet.
<loluengo> hi Jefro1 GrueMaster
<loluengo> it's me again
<GrueMaster> hey.
<Jefro1> hi loluengo
<loluengo> i've all the afternoon if there exists a good and not so expensive JTAG emulator
<loluengo> which one do you use/recommend?
<GrueMaster> loluengo: Try the flyswatter for the beagleboard.
<loluengo> ok... i'll google for it
<GrueMaster> loluengo: http://tincantools.com/
 * GrueMaster wanders off to cook dinner.
<Jefro1> thanks GrueMaster
<loluengo> :O
<loluengo> tincantools is really great site!
<loluengo> i've fallen in love with it
<loluengo> xD
<loluengo> ok
<loluengo> i'm leaving....
<Jefro1> tincantools guys are fantastic
<Jefro1> have a good eve
<loluengo> i'm REALLY hungry
<loluengo> thanks for all support Jefro1!!
<loluengo> i hope to be soon back here ;)
<hrw> morning
<hrw> morning
<lag> mythripk2: Ping
<lag> Morning hrw
<mythripk2> lag: morning
<lag> mythripk2: Hi
<lag> mythripk2: Your patches won't apply
<mythripk2> lag:It is on top of our latest tree which has 2 other patch as well
<lag> Ah! That's not helpful for me :(
<lag> Are these other patches going to hit our tree any time soon?
<mythripk2> lag: I m not sure of that ,you have one of those patches , ie for AVI checksum
<lag> commit 67d286d8c1db33a11113bb22125343f9afb2c12d
<lag> Author: Mythri P K <mythripk@xxxxxx>
<lag> Date:   Tue Jun 1 10:28:58 2010 +0530
<lag>     Remove compiler warning from HDMI related patches
<mythripk2> I shall apply this on our old release and send you the  refreshed patch
<lag> That's the last commit on hdmi.c
<mythripk2> ok that is the old one  there are 3 patches after that , ok i shall update the patch on top of that and send you the refreshed patch
<lag> And that will have all the patches on?
<mythripk2> The refreshed patch will be for the autodetect
<lag> Okay
<lag> What do the other patches do? And do I need them?
<mythripk2> one patch is to replace the raw read and writes with GPIO , it will not affect the functionality
<lag> Okay
<mythripk2> and other one is AVI checksum which you definitely need and other one is for some audio clock issue which is not needed
<lag> I'm assuming you use git?
<mythripk2> yes
<lag> mythripk2: Are you going set me all of the patches?
<lag> ogra: How big does the SD card need to be for XM?
<hrw> lag: 4GB
<lag> DOh!
<lag> That'll explain it then
<hrw> I got hit by that with my BB
<hrw> lot of 2GB cards here
<lag> &%$*
<cooloney> lag: where can i find your patch to fix the  parport_pc oops
<cooloney> lag: i am going to test it.
<ogra> lag, >2G
<ogra> the filesystem is 1.4 plus we add a 512M swapfile
<sumitsemwal> lag: gm.
<lag> sumits: Good morning
<lag> cooloney: In my tree
<lag> mythripk2: ?
<mythripk2> lag: i shall send you 2 patch for the EDID redesign for autodetect
<mythripk2> i shall not send the other 2 that you dont need , if you think you need to pull you can take it from here : http://dev.omapzoom.org/?p=axelcx/kernel-display.git;a=shortlog;h=refs/heads/display-next
<mythripk2> lag: whats with this mythripk2??? :P
<lag> Can't you see your name?
<lag> You must have had a ghost nick at one point
<lag> And mythripk2 is your back-up nick
<lag> Is that correct?
<lag> <mythripk2> lag: whats with this mythripk2??? :P
<mythripk2> i only have mythripk as my nick
<lag> Look at my post
<lag> I see mythripk2
<lag> Type "/nick mythripk"
<lag> :D
<lag> There you go
<mythripk> ok ive mailed the refreshed patches
<lag> Thanking you
<fjrivash> Hello every one! :D
<lag> ogra: Have you tested Mythripk's patches yet?
<ogra> lag, are they in any binary kernel in the archive ?
<lag> Would you like me to compile you a kernel? :)
<ogra> or in any of cooloneys PPA packages ?
<lag> Nope
<ogra> sure, i would test it
 * ogra bzr pushes progress output support for the resizing function in jasper
<ogra> i hope that will look better now and people stop thinking the system hangs :)
<hrw> ;D
<ogra> i'm hot really sure how responsive it is on real SDs though
<ogra> i only tested on a 4G imagefile
<hrw> generate image so I will test it
<ogra> tomorrows daily should have it
<hrw> ok, remind me tomorrow then
<lag> ogra: http://people.canonical.com/~ljones/lp592295-maverick-omap4/
<lag> mythripk: ping
<mythripk> lag:yes
<mythripk> did u apply the patch ?
<lag> I have more information on my problem
<lag> I did
<mythripk> ok
<mythripk> so did it detect the timing ?
<lag> It doesn't make much difference to me, but it does get rid of the SYNC_LOST_DIGIT errors
<lag> Nope
<lag> But I know what's happening
<mythripk> can you paste the log ?
<lag> It can't handle my monitor when it enters power saving mode
<mythripk> you dont have to give any bootargs now , what do you mean by it cant handle ?
<lag> If I turn on my monitor _just_ before kernel boot (i.e. does not give the monitor enough time to go into power saving mode) then everything is fine
<lag> I still have to give bootargs
<lag> If I don't give bootargs, the monitor goes nuts
<lag> Big blocks of colour flashing on the screen
<mythripk> with the patch , it doest take any bootargs
<lag> With the patch, if I don't provide bootargs, the screen goes bonkers
<mythripk> did u apply the one tthat i mailed?  can you please paste the log ?
<lag> Yes, both
<lag> Okay
<lag> I need to give you two logs
<lag> Firstly when the monitor is _on_
<lag> Then when the monitor is in _power saving mode_
<mythripk> okies
<lag> Both with no args?
<mythripk> yes
<mythripk> both with no args
<lag> setenv bootargs vram=32M, omapfb.vram=0:8M console=tty2 console=ttyO2,115200n8 noinitrd mem=463M root=/dev/mmcblk0p2 rootwait ip=none; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000
<lag> FYI
<lag> I have to rebuild my card
<lag> It's saying "Bad Magic Number"
<mythripk> :) take your time
<lag> mythripk: This is with bootargs - monitor _on_ : http://paste.ubuntu.com/463491/
<lag> mythripk: This is without bootargs - monitor _on_ : http://paste.ubuntu.com/463493/
<lag> mythripk: This is without bootargs - monitor _power saving mode_ : http://paste.ubuntu.com/463494/
<lag> The first one works, the second and third do not
<mythripk> ya with first one it is selecting hdmi 720p mode , 2nd i see sync lost digit and 3rd one omapdss HDMI error: Failed to lock PLL
<lag> Yep
<rsalveti> morning
<rsalveti> ogra: can you take a look at the code again? I changed to support root the same way as before
<rsalveti> I also changed usage so we can update the man page easily
<ogra> devtmpfs.mount=0 needs to stay in the cmdline opts
<rsalveti> ouch, true, forgot that
<rsalveti> I removed that when testing as user, so I didn't need to worry about giving a nod list for genext2fs
<rsalveti> ogra: why this was added to cmdline in the past?
<ogra> because you end up without /dev/console and /dev/null in some situations
<ogra> looks good to merge, did you think of adding the necessary dependencies to the packaging ?
<ogra> fakeroot at least
<rsalveti> ogra: yep, will do the packaging later :-) have the changes here, but want to push some more fixes first
<rsalveti> so I can update the package only once, with probably a new small release
<ogra> k, just go ahead, looks good to me (and i'll send complaints your way anyway ;) )
<rsalveti> ogra: nice
<rsalveti> ogra: so, back to the devtmpfs.mount=0, should I just add this by default and request a default list of nods to be created by genext2fs?
<rsalveti> just need to see what are the minimum dev list, and put that at the code
<rsalveti> when root we don't need to worry about it
<ogra> just add it back to the cmdline and dont worry about it anymore
<ogra> it was for some combo of jaunty with lucid kernel iirc
<ogra> no need to create nodes
<rsalveti> ogra: oh ok, but with user that gives a kernel panic, afaik
<rsalveti> will test it here again
<rsalveti> because you can't create the nods unless you request genext2fs to do it
<ogra> oh, then make it conditional
<ogra> then we simply dont support --no-root with jaunty filesystems :P
<rsalveti> haha, easier :P
<rsalveti> nice, will change it here and push at trunk
<rsalveti> and move to the other fixes
<ogra> jaunty will be EOL when maverick releases anyway
<rsalveti> I believe that after fixing most of the bugs, and probably testing/fixing the gui we can release the 2.0
<rsalveti> try
<rsalveti> *true
<ogra> cool !
<mpoirier> ogra: I installed lucid UNR via netboot yesterday
<mpoirier> ogra: is it supposed to be a console login prompt via VGA or graphical prompt ?
<amitk> mpoirier: hope you are back in fighting fit condition :)
<amitk> mpoirier: there was question regarding the IGEPv2 board support in ubuntu. I believe you have one?
<mpoirier> I shipped the board to tgardner
<mpoirier> I didn't have time with all the issues we see on bb
<amitk> aah
<mpoirier> I whish I had time though...
<mpoirier> seems like a good little board.
<ogra> mpoirier, UNR is definately supposed to run a graphical session
<mpoirier> mine is surely not.
<mpoirier> GrueMaster told me to install netbook-launcher-efl
<mpoirier> any idea why it wasn't installed ?
<ogra> mpoirier, you selected the netbook task during task selection ?
<mpoirier> what other choices did i have ?
<ogra> tons
<ogra> its a very long list
<mpoirier> then I assume i did it wrong.
<ogra> it includes all tasks that are available in ubuntu
<ogra> which doc did you follow ?
<mpoirier> hold on.
<mpoirier> https://wiki.ubuntu.com/ARM/BeagleNetInstall
<mpoirier> it doesn't say anything about choosing the netbook option.
<ogra> well, during install you are asked for selecting a task
<ogra> that can be a LAMP server, an xfce desktop, or the ubuntu.netbook task
<ogra> ot one of the other 100 things you can choose there
<mpoirier> will I be fine after installing  netbook-launcher-efl or there will be other things missing ?
<ogra> *or
<ogra> there might be things missing
<ogra> you should have installed the ubuntu-netbook metapackage instead
<ogra> it will install netbook-launcher-efl along the other stuff
<mpoirier> ok, I'll install the  ubuntu-netbook
<ogra> that should give you everything you need
<mpoirier> I'll try thanks.
<ogra> (its what the task selection does as well)
<mpoirier> is there another wiki somewhere that describe (properly) how to install lucid UNR on bb ?
<ogra> just the std installer documentation
<GrueMaster> mpoirier: https://wiki.ubuntu.com/ARM/Beagle gives you the install options available.
<GrueMaster> For Lucid.
<ogra> GrueMaster, i think mpoirier was rather confused by debian-installer ... and i dont think we have any proper docs for the non graphical install anymore
<GrueMaster> yea, I can look into adding some in my spare time.
<GrueMaster> Right now, I have several karmic/lucid kernels to test.
<ogra> https://help.ubuntu.com/community/Installation has a ton of docs, but i dont see a step by setp guide for the alternate installer
<GrueMaster> I just wish there was a mirroring app that worked.  ubumirror sucks down everything we've ever created, and apt-mirror doesn't get enough to do an install.
<GrueMaster> And for me, installing from ports.ubuntu.com is painful.
<ogra> use approx :)
<ogra> it just cacches
<GrueMaster> approx?
<ogra> apt proxy
<GrueMaster> I have a local server that I want to use as a mirror for lucid & maverick armel only.
<ogra> you only very very rarely need a real mirror
<ogra> then install approx on there
<hrw> or apt-cacher-ng
<GrueMaster> My downloads from the main server are at best 100kps.
<hrw> 3MB/s here from ubuntu mirror
<ogra> it only downloads packages it doesnt have or which are outdated
<GrueMaster> same with apt-mirror.
<GrueMaster> Problem is when I need to do a net install.
<hrw> 724KB/s from ports. quite ok but caching helps for multi machines
<GrueMaster> I'll tinker with ubumirror.  Maybe I can get it to overlay on top of apt-mirror's pull with only dists that I select and ignore pool.
<GrueMaster> hrw: where are you?
<hrw> GrueMaster: Poland
<hrw> GrueMaster: 30/3Mbps connection at home
<GrueMaster> ports.ubuntu.com is in London.
<GrueMaster> I'm in the states.
<GrueMaster> The bottleneck is in the pipe between.
<hrw> us.ports.ubuntu.com would be nice
<ogra> no
<ogra> moving armel off the ports machine is the right solution
<GrueMaster> I can pull from a local mirror for x86 stuff at ~1.5M/s but there are no ports mirros.
<ogra> its an official arch ... so it should live on archive.u.c
<hrw> ogra: not before 11.10 probably
<ogra> i know asac was fighting for it when he still was in the mobile team
<GrueMaster> maybe bring it up at UDS-N.
<ogra> well, until then use approx or apt-cacher-ng
<ogra> i even use it over my n900 line sometimes
<GrueMaster> I'll read the docs on them.
<hrw> ok, have a nice rest of day
<mindlord> Hi, I'm having a problem creating a tarball with rootstock... aside from the required fqdn/username/password combo I've tried seeding lxde,gdm and just trying xubuntu-desktop, and I've tried 1GB and 1.5GB sizes... the result is the same every time... It gets to setting up libglade-2.0 and it just sits there indefinately. I've even run it overnight. Suggestions?
<mindlord> Oddly I've had success before with lxde,gdm and everything went peachy, but it doesn't work now... for some reason.
<mindlord> Correction- This library - Setting up libglade2-0 (1:2.6.4-1build1) ...
<rcn-ee> mindlord, lucid ?
<mindlord> rcn-ee: yes...
<rcn-ee> mindlord, bug 532733
<ubot2> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 2 other projects) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 7) (dups: 1) (heat: 79)" [High,Incomplete] https://launchpad.net/bugs/532733
<rsalveti> yep, probably this bug is the reason
<rsalveti> mindlord: with big images qemu gets stuck
<mindlord> drat.
<mindlord> I was hoping to get Ubuntu running on my Pandora.
<mindlord> The working image I created was on a machine that died suddenly.
<rcn-ee> two workarounds...  start with a simple rootstock image and apt-get what you need on real hardware, or use one of the native-rootstock patches floating around..
<mindlord> I could probably go the simple route fairly easily. It's just a matter of getting the wifi working.
<rsalveti> yep, easier
<mindlord> I guess I could always grab the packages I need and dump them on the card and dpkg them in afterwards.
<NCommander> mindlord: your better off trying a real basic set of packages (ubuntu-minimial/ubuntu-standard), then apt-get the rest on
<NCommander> you can use apt-move to move packages in-mass
<mindlord> Alright. worth a shot anyways... I'm not any progress as it is. :)
<mindlord> Thanks for the info.
<JaMa> cwillu_at_work: did you resolve your "unknown relocation: 3" problem in 2.6.35 kernel? I have the same with OE built kernels...
<cwillu_at_work> JaMa, there was some changes in 2.6.35 causing that
<cwillu_at_work> rcn-ee, what did you have to do to fix that?
<cwillu_at_work> JaMa, it's resolved, but rcn-ee did the work
<JaMa> cwillu_at_work: maybe this patch? http://www.spinics.net/lists/arm-kernel/msg89760.html
#ubuntu-arm 2010-07-15
<cwillu_at_work> rcn-ee, do you know if there was any zippy changes pulled in on rc4 or rc5?  I'm getting null pointer dereferences on most network activity on the zippy's ethernet
<rcn-ee> Hey cwillu_at_work i need to still rework the zippy patches that were in 2.6.34 they don't apply cleanly to 2.6.35 yet (and they fix a lot of problems)
<cwillu_at_work> ah, k
<cwillu_at_work> did .33 have working zippy2?
<pcacjr_at_home> does anyone know if ubuntu lucid works properly on the beagleboard C3 ?
<cwillu_at_work> pcacjr_at_home, as far as c3's work properly, yes
<pcacjr_at_home> cwillu_at_work, thanks mate
<cwillu_at_work> there's some remaining instability on the ehci port, although it can be managed
<rsalveti> pcacjr_at_home: yep :-)
<rsalveti> pcacjr_at_home: trying ubuntu now?
<pcacjr_at_home> rsalveti, yeah :-)
<cwillu_at_work> pssst, buddy, wanna try a btrfs root? :)
<pcacjr_at_home> rsalveti, afaik you used to install ubuntu lucid on that beagle you gave me
<pcacjr_at_home> rsalveti, right ?
<rsalveti> pcacjr_at_home: yep
<rsalveti> but that's not a c3, it's a b5 I believe
<pcacjr_at_home> rsalveti, great. so i'll give it a shot!
<pcacjr_at_home> thanks
<pcacjr_at_home> hm
<rsalveti> you can still try lucid, but will be very slow
<rsalveti> recommend you to try without gui
<pcacjr_at_home> ok then
<pcacjr_at_home> ;-)
<cwillu_at_work> the b's only had 128mb ram, right?
<rsalveti> yep
<rsalveti> and just the usb otg
<pcacjr_at_home> so no GUI though
<cwillu_at_work> it might be livable if you put swap on a usb disk
<cwillu_at_work> with gui, I mean
<pcacjr_at_home> cwillu_at_work, but it'll get slow though...
<pcacjr_at_home> anyways i don't even need GUI ;-)
<cwillu_at_work> pcacjr_at_home, it gets slow even with 256mb :p
<pcacjr_at_home> D'oh
<pcacjr_at_home> :-)
<rsalveti> if you don't need gui, then that's ok
<cwillu_at_work> depends entirely on your working set
<pcacjr_at_home> i see
<pcacjr_at_home> thanks folks
<rsalveti> rcn-ee: just to let you know that I pushed some commits at rootstock, and this will probably break your script and patches
<rsalveti> will look at other bugs tomorrow
<rsalveti> time to get some sleep now
<hrw> morning
<lag> Morning hrw
<lag> hrw: Do you remember the SD -110 error bug?
<hrw> timeout
<hrw> iirc
<lag> Was there a bug raised?
<hrw> I had that few years ago in Zaurus
<hrw> and at that time it ended with problematic card sent to RMK for checking on his hardwares. patches landed in kernel, card started working
<lag> I'm getting it on Beagle
<lag> It was a problem a few weeks ago
<lag> I think mpoirier was working on it
<lag> ogra: Can you remember if there was a bug report raised?
<lag> Found it: bug 591941
<ubot2> Launchpad bug 591941 in linux (Ubuntu Maverick) (and 1 other project) "SDHC card not recognized (affects: 2) (dups: 1) (heat: 135)" [High,In progress] https://launchpad.net/bugs/591941
<ogra> +  * Append ${SUBARCH:+-$SUBARCH} to LOG filename for consistency.
<ogra> +
<ogra> + -- LoÃ¯c Minier <loic.minier@ubuntu.com>  Wed, 02 Sep 2009 09:23:59 +0200
<ogra> lool, did you ever check what happened after that change ? ^^^
<cooloney> amitk: i am looking at tony's linux-omap tree, do you know which branch shall i take a look
<cooloney> amitk: if i wanna cherry pick some patches to enable panda in our Ubuntu master tree -omap flavor
 * ogra wonders why you want to do that
<ogra> it will work only half i guess and we have a properly working omap4 kernel on the omap4 images
<amitk> ogra: because I want a mainline-only version of omap4
<amitk> ogra: and because that is the future
<cooloney> ogra: i also wanna ask amitk that question.
<ogra> amitk, but what do we gain from it beyond confusion ?
<cooloney> amitk: i think we can build a pure mainline omap4 version for our panda boards.
<ogra> you wont be able to run the -omap images on -omap4 HW
<ogra> since the boorloaders differ
<cooloney> amitk: oh, sorry, not mainline, tony's upstream kernel
<ogra> and -omap4 images will always install the -omap4 kernel by default
<amitk> ogra: bootloader issue will be fixed upstream
<ogra> amitk, it cant
<amitk> ogra: I don't plan to use your images
<ogra> there are HW constraints you cant work around in SW
<ogra> it will only start working if DT is fully integrated
<hrw> multiomap kernels were omap2/3 only?
<ogra> and i'm not even sure about that for pandas vs blaze
<amitk> cooloney: Tony's for-next branch is usually the one (I see it has support for Panda)
<amitk> hrw: no, multiomap is omap2,3,4
 * ogra guesses omap4 support is very rudimentary
<amitk> ogra: I am not sure what the reach problem is with supporting panda with the mainline kernel?
<amitk> ogra: could you expand?
<ogra> amitk, 700 patches ?
<amitk> ogra: here is where you don't understand what I'm trying to do
<ogra> amitk, i doubt all the changes and patches we have on the current omap4 tree are in tonys branch
<ogra> so the omap4 support will suck in the -omap kernel
<amitk> ogra: I DONT CARE ABOUT YOUR DESKTOP IMAGE WITH ITS BELLS AND WHISTLES :)
<ogra> amitk, i understand that
<hrw> amitk: working serial is enough ;D
<amitk> ogra: DONT CARE from the POV of what I'm trying to achieve. I do care about it otherwise, great work :)
<ogra> but i fail to see any benefit before omap4 is properly integrated in -omap
<amitk> hrw: exactly
<cooloney> ogra: amitk just wanna a Ubuntu M 2.6.35 kernel which can supports omap4 hw
<ogra> amitk, what do you gain by that if you *only* have a serial console
<ogra> like you dont have MMC, USB, NIC or any other HW support
<cooloney> amitk: ok, i am looking at it
<amitk> ogra: that is where you are wrong. Mainline already supports basic omap4 features (uart, i2c, mmc).
<hrw> ogra: once you got omap4 usb you will have nic support
<ogra> stragne since not even our omap4 tree properly supports many of these
<amitk> ogra: It helps us with device tree work, as one example
<ogra> ah
<ogra> that was an answer i was looking for :)
<ogra> *some* kind of near future benefit :)
<amitk> ogra: for linaro purposes it doesn't have to work perfectly - that is what your omap4 image is for. Having a mainline-only version allows us to experiment
<amitk> so any development happening against mainline won't have to be thrown away
<ogra> amitk, right, i did see more benefit from merging the omap4 branch step by step, thats why i was wondering about having a second code path
<hrw> amitk: and we need pandas to have HW for tests
<ogra> hrw, arm team is happy to help
<ogra> if xyou need any verification that costs us just a "play around SD card" :)
<cooloney> amitk: just a quick look at for-next branch of tony's tree.
<amitk> ogra: we'll even supply dedicated SD cards for OMAP4 work ;)
<hrw> ogra: plug card, reboot, pastebinit serial output
<cooloney> it seems like tony merged several branches there and prepare it for next .36 merge window
<ogra> amitk, you mean you send me one ?
<ogra> cool !
<amitk> :)
<amitk> cooloney: right
<hrw> writing 1.7GB to SD card takes eons
<ogra> hrw, use a proper bs= value in dd
<ogra> speeds up a lot
<hrw> 20K is enough?
<amitk> bs=1M works for me
 * ogra uses 4k
<cooloney> i'd say the Panda board patch is the same from our -omap4 branch
<ogra> i found thats the fastest on my laptop
<hrw> ah you laptop users...
<hrw> I do dd from tmpfs to sd card
<ogra> well, builtin SD reader is unbeaten :)
<hrw> 77,698 s, 6,5 MB/s
<amitk> cooloney: in any case, please pull from tony's tree rather than -omap4 tree (so we have the commit id)
<hrw> ogra: my tower has builtin cf/sd/ms/something
<ogra> ah
<hrw> s/^7/27
<hrw> and I use usb one anyway ;D
 * ogra dislikes if his SD cards are named /dev/sdX 
<ogra> way to error prone if you have a /dev/sdX HDD
<cooloney> amitk: that's not very hard. i can do that. but i found several serial port patches for omap2/3/4
<hrw> I have sdh usually for sd card
<amitk> cooloney: do only the minimal necessary to get serial port on panda with master branch
<ogra> accidentially typo that tp /dev/sda and you have fun with restoring backups :)
<amitk> cooloney: it should only be 2-3 patches at most
<ogra> s/tp/to
<amitk> lunch time
<hrw> ogra: how to regenerate boot.scr?
<hrw> needed to change res
<ogra> do it from your desktop
<hrw> I know - need command
<ogra> copy it over, remove header, change cdmline and run mkimage
<ogra> ah
<hrw> got
<ogra> mkimage -A arm -T script -C none -n "Ubuntu boot script" -d <input file> boot.scr
<hrw> I2C:   ready
<hrw> and beagle stopped
<ogra> in the installed system there is /boot/boot.script ... change it there and run sudo flash-kernel
<hrw> ogra: http://hrw.pastebin.com/si5pstv6
<ogra> sounde like you use a wrong x-loader or u-boot
<hrw> I had 1.4.4 xloader before
<ogra> yeah, you dont use MLO from the card
<ogra> 1.4.4ss is thats in the archive
<hrw> ok, user button helped
<ogra> :)
<ogra> 1.4.4ss is needed for XM support
<ogra> so we default to that one
<hrw> http://hrw.pastebin.com/c6piMtqb
<ogra> huh ?
<ogra> reading /casper/uImage ?!?
<ogra> whats that !
<hrw> http://hrw.pastebin.com/hMJ9kSrH is printenv
<ogra> hrw, are you sure you used the shipped boot.scr from the SD vfat as a source ?
<hrw> yes
<ogra> printenv is ignored
<ogra> we only use boot.scr
<ogra> can you paste your original boot.scr ?
<hrw> sure moment
<hrw> http://hrw.pastebin.com/z0aTDHFk
<hrw> booted script from memory now
<hrw> it is resizing now
<ogra> that boot.scr doesnt have any /casper/uImage in it
<hrw> ogra: so it looks  like boot.scr was ignored
<ogra> oh, you had lucid installed before
<hrw> ogra: where is progressbar? I see "Resizing root filesystem please wait, this will take about ten minutes ..."
<ogra> below that you should see dots appearing after a while+
<hrw> ok
<ogra> not sure how long that takes, i did my tests for the code with an image file
<ogra> real SD might be slower
<hrw> ogra: btw - "Resizing root filesystem. Please wait, this will take about ten minutes ..." would be better
<hrw> ogra: 3x "sh: closing paren expected" and then there are dots shown
<ogra> i need to rephrase it anyway
<ogra> ouch
<ogra> damned
<hrw> ogra: would be nice to have [ 0/100% done] ........
<ogra> thats rather complex code
<hrw> ................shproblem\n...........shproblem\n........
<ogra> for now i'm happy to have *anything*
<ogra> yeah, thats busted
<hrw> ogra: do you know how many dots will be printed?
<ogra> yes
<ogra> still it needs a math function
<hrw> python has nice itertools
<ogra> currently i'm just using the output of resize2fs directly
<ogra> and i dont have much time to care for more
<ogra> no pythin in initramfs
<ogra> needs to be shell
<hrw> ogra: resize2fs with "-p" option?
<hrw> shproblem\n.....
<ogra> yeah
<hrw> 4th line of dots ended without shproblem
<hrw> and nothing now
<hrw> uf.
<hrw> [932] mounted ext3 rootfs
<ogra> http://paste.ubuntu.com/463956/ ... i dont see where a parenthesis is missing :/
<ogra> i dont see where "shproblem\n" could come from
<ogra> its a really dumb function that should parse the output 1:!
<ogra> *1:1
<ogra> hrw, if you are done i'd like to have /var/log/jasper.log from the system
<hrw> [1313] oom killer
<ogra> ureadahead ?
<ogra> or plymouthd ?
<hrw> and plymouth
<ogra> both are normal
<hrw> and udev shouts "no space left on device"
<ogra> and are hopefully fixed already (not uploaded yet)
<ogra> yeah, thats one i still have to resaerch
<ogra> it writes to a tmpfs
<ogra> and doesnt happen on second boot anymore
<ogra> i suspect its caused by ureadahead eating all ram
<hrw> ogra: how much time since boot to login? 1h or more?
<ogra> which will be fixed with next ureadahead upload
<ogra> 20min or so
<ogra> depends on the size of your SD
<ogra> the resizing actually takes 10min per 4G
<hrw> 4GB card
<ogra> right
<hrw> 1489 segfaiult
<ogra> i would have guessed so
<hrw> oops from kernel
<ogra> since you said you see the resizing msg at 11:57
<ogra> now its 12:20
<hrw> last sysfs: /sys/module/parport/initstate
<ogra> yeah, known and fixed already
<ogra> or in the process to be fixed
<ogra> lag is working on it
<hrw> fix commited but not fix released?
<ogra> cups forcefully loads parport_pc
<lag> What can I do you for?
<ogra> the module code needs fixing to not segfault
<lag> A have sent a patch upstream
<ogra> lag you are already doing :)
<ogra> hrw, any trace of oem-config already ?
<ogra> i know its not fast but you should see some X by now
<hrw> text console disappeared so maybe x11 tries to start
<ogra> ah, great
<hrw> got ugly x11 background
<ogra> heh
<hrw> looks like 3bit or few more
<ogra> you changed the display defaultsd
<hrw> from 1280x720 to 1280x800
<hrw> my monitor is 16:10
<ogra> should soon swithc to 24bit, the first one is 16
<ogra> right before oem-config shows up it switches over
<hrw> looks like mouse and keyboard were not detected in x11
<ogra> hmm
<ogra> C4 ?
<ogra> or your old C3
<hrw> C3 with working usb
<hrw> I used keyboard in text console to unblank monitor
 * ogra hasnt seen any kbd mouse issues in the maverick images on C4 yet
<ogra> wait a bit, its probably just busy with swapping
<hrw> ogra: how much ram omap3/4 needs to have to get normally working UNE? 2GB? 4GB?
<ogra> htop shows about 200M used usually
<ogra> we add a 512M swapfile
<ogra> so you should have >700M
<hrw> I would fetch/unpack/boot-to-x11/installirc/gettoirc/discusshere with angstrom/gnome in shorter time then I got here
<ogra> actually more like 160-180 used
<hrw> it took 35 minutes so far and still nothing usable
<ogra> well, its like 15 with omap4
<hrw> masacre
<ogra> omap3 is just something thats nice to have
<ogra> omap4 is the target arch we work for
 * hrw wants omap5 with 4GB ram and 20MB/s storage
<ogra> heh
<ogra> on omap4 only the resizing is slow and thats caused by the bad MMC driver
<hrw> bbc3 feels insanely slow when rootfs is on usb
<ogra> i have some hope that will be solved for final
<hrw> bbxm will give better behaviour due to more ram
<hrw> and faster cpu
<ogra> yeah, i'll still have to test that
<hrw> panda will again give faster cpu and more ram
<ogra> i havent had the time yet, i'll do some test installs at the sprint on XM
<hrw> my lcd just blanked out. touching keyboard does not bring it back
<ogra> while C3 and C4 should be "supported" i'd rather recommend a cmdline install for such users
<ogra> i.e. install lucid netinst image and dist upgrade to maverick
<hrw> may I reboot?
<ogra> hrw, try it, it should kick you into oem-config again
<ogra> mmc init;  fatload mmc 0 0x82000000 boot.scr; source 0x82000000
<ogra> for your uboot prompt :)
<hrw> bootscr got not loaded
<hrw> thx
<ogra> i'll provide a tool to blank NAND config for such cases
<ogra> so it falls back to defaults
<ogra> as soon as we have the NAND driver back in the lucid kernel
<hrw> got plymouth
<ogra> good
<ogra> i wonder if we should force a reboot after resizing
<ogra> though with screwed NAND that will be problematic
<ogra> but would be a) good to verify the new partition table works fine and b) likely be faster to bring up oem-config
<hrw>  plymouth disappeare
<hrw> got ugly x11
<ogra> mouse works ?
<hrw> nope
 * ogra blames the maverick kernel
<hrw> sorry, works but very slowly
<ogra> works for sure on C4
<ogra> phew
 * ogra blames I/O
<hrw> now works normally - probably oom killed something
<ogra> i guess it just swapped
<ogra> while reading from SD at the same time
<hrw> nicer background on screen (did not noticed when changed)
<hrw> o... language chooser
<hrw> but why 1280x720...
<hrw> it does not fit on screen ;(
<amitk> default cmdline param
<hrw> the bad part is that this is ubuntu - I need to wait to end of oem-config to get possibility to login on vt1 ;(
<ogra> hrw, jasper resets the resolution again, please file a bug that it should pick that up from an existing cmdline instead
<hrw> ogra: bug on jasper?
<ogra> hrw, not to the end, only to the end of the config tool
<ogra> hrw, jasper-initramfs
<ogra> hrw, you can switch to tty and log in once it started removing stuff
<amitk> jasper?
<ogra> hrw, how else than through something like oem-config would you set up the system ?
<ogra> amitk, yes
<amitk> what is it?
<ogra> amitk, the little brother of casper AKA the "douchebag ghost" :)
<ogra> amitk, it does the resizing of the rootfs partition and enables oem-config
<hrw> ogra: oem-config has to fight against other processes to get some spare ram
<ogra> and sets up fstab
<hrw> press "Next", wait minute or two...
<ogra> hrw, yes, its not fast
<amitk> huh! and it is run on every install?
<ogra> amitk, on first boot
<amitk> aah I see, i missed the keywork: oem-config
<ogra> oem-config == ubiquity witout partitioner
<ogra> jasper does the partitioning step
<amitk> ogra: when are we getting preinstalled images for arm this cycle?
<hrw> amitk: we have them
<ogra> amitk, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/
<ogra> since some weeks :)
<amitk> nice!
 * amitk hugs ogra
<hrw> amitk: you need 1.5h to get omap3 pass first boot
<ogra> amitk, but they are no fun on beagle
<amitk> why?
<ogra> they are great on panda though
<amitk> they are not really pre-installed?
<ogra> amitk, resize2fs is slow, it swaps a lot for oem-config (which runs under X)
<hrw> amitk: because they suxx if you do not have 1GB ram and 20MB/s read/write from rootfs
<ogra> hrw, nonsense
<ogra> 512M are plenty
<ogra> i expect the XM to be nearly as good as panda
<hrw> but 256M is definitelly far far far far too small
<ogra> agreed
<hrw> and I have 128MB beagleboard somewhere...
<amitk> ogra: seems like my definition of a pre-installed image differs from what is provided. Why does it need to resize?
<ogra> if i find the time i'll do preinstalled cmdline images
<amitk> or rather, what?
<ogra> amitk, because users dont want to download 4G
<ogra> the rootfs is as small as possible on that image
<ogra> and gets expanded to the full size of the SD
<ogra> so it doesnt matter what SD card you use
<hrw> ogra: Bug #605831
<ubot2> Launchpad bug 605831 in jasper-initramfs (Ubuntu) "[omap3] Resolution should be taken from /proc/cmdline if provided (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/605831
<ogra> thanks
<amitk> eeeks
<ogra> amitk, ??
<hrw> amitk: but do not use card larger then 4GB - you will wait too long
<amitk> the uncompression of rootfs
<ogra> amitk, not uncompression
<ogra> its just resizing
<ogra> to use up all the spare space on the SD
<ogra> amitk, a simple resize2fs
<amitk> ogra: ok, and no chance of a 4G image for people that have the BW?
<hrw> ScheiÃe
<ogra> amitk, no, that would be a waste
<amitk> this feels like 2 steps froward and 3 steps back
<ogra> amitk, why
<hrw> creation of users should be before 'configuring keyboard'
<ogra> hrw, complain at the ubiquity maintainers
<amitk> because it still takes 2 hrs to get ubuntu on a beagle
<ogra> not my area :)
<ogra> amitk, it takes 15min on a panda
<amitk> ogra: which only 3 people have in this world outside TI :)
<ogra> amitk, its not the design of jasper that makes the beagle slow
<ogra> amitk, or the design of the image
<amitk> i understand it is the IO
<ogra> amitk, its the fact that beagle is to slow for a desktop image
<ogra> its not even the IO
<ogra> IO is fine for cmdline images
<amitk> ogra: so you're saying it is memory-bound?
<XorA> heh ubuntu got too fat for the beagle :-)
<ogra> the fact that we dont special case omap43 images but build the same image for omap3 and 4 is what hits us
<amitk> XorA: it would seems so
<ogra> if we would provide cmdline images for omap3 that would be fine
<ogra> but the XM will be as good as the panda here
<ogra> so just for Cx boards i wont trash the netbook image
<ogra> if i find the time to hack them up i'll provide special cmdline Cx images
<amitk> ogra: wouldn't it be easier to partitions the SD card to use up the extra space?
<ogra> if i dont, people have to live with that on Cx boards
<ogra> amitk, surely faster but error prone
<amitk> ogra: and some magic with aufs to unionise them
<ogra> eeek !
<amitk> lol
<ogra> amitk, the prob is that i would need separate partitions for /tmp and the like
<ogra> its not as easy as it seems
<ogra> and the ten mins for the resizing are really not the prob
<ogra> the prob is oem-config and the X session
<amitk> ogra: IMHO, they are. It doesn't make for a great 1st experience
<amitk> even the 10mins
<amitk> on an OMAP4 board that nobody has
<ogra> amitk, partitioning in ubiquity is a lot slower
<ogra> like 20min on the C4
<ogra> so i dont let that argument count
<ogra> the lucid install takes over 2h
<ogra> having a 10min resize action at bootup is really not a biggie
<amitk> ogra: ok, let me restate my problem (I've been bitching out this for a long time, almost 2 years, you already know that)
<ogra> having oem-config running for >1h is though
<ogra> but thats improvable due to using a cmdline image
<hrw> re
<ogra> or at least oem-config in cmdline mode
<ogra> (which is ugly but a possibility for C4 boards)
<amitk> ogra: I want an image that I can dd onto a SD card (make assumptions of 4G card!), insert it in beagle and see it boot ubuntu. In under 5 mins.
<ogra> amitk, go to linaro :P
<ogra> though you have to manually partition the card etc
<amitk> ogra: why? the dd image should take care of it. Make it a fixed 4G image
<ogra> i wont maker assumptions and i wont get allowance to spend 32G on the builder machine for kubuntu and ubuntu images
<ogra> why would i waste the space on an 8 or 16G card ?
<hrw> ogra: provide tarballs of rootfs
<ogra> hrw, thats not what ubuntu does ... go to linaro for such stuff
<hrw> so I/amitk will grab tarball, unpack to card and boot
<ogra> that all was discussed to an extend at UDS
<hrw> kk
<ogra> its a bit late to change an implemented spec now :P
<amitk> *sigh*
 * amitk prepares to wait another year
<XorA> problem with UDS was 99% of people couldnt get that embedded != smaller PC
<ogra> the choice we had was eithet debian-installer/ubiquity with a 2h installation or the current setp
<hrw> so ubuntu requires: bbxm, igep2/512M, panda, blaze, touchbook/512M and nothing smaller
<ogra> XorA, ubuntu doesnt do embedded
<ogra> XorA, thats linaro
<XorA> Linaro didnt exist then (apart from in the worlds worst kept secret)
<ogra> hrw, if i dont provide cmdline images
<amitk> I wonder if lool is interested in investigating this in Linaro
<ogra> XorA, linaro did exist ... just not the name
<hrw> I would not call beagleboard embedded - I have more embedded hardware
<ogra> XorA, in fact the arm team wasnt allowed to have its own track at UDS because of linaro
<hrw> XorA: there were Linaro meetings during uds
<XorA> hrw: I know, but I didnt have an NDA that allowed me to know about them
<XorA> even though I did
<ogra> XorA, they were just called differently
<ogra> XorA, all arm tracks at that UDS were linaro tracks
<ogra> next UDS we'll have linaro and arm tracks and you will notice the difference between the approaches
<ogra> ubuntu-arm is to bring ubuntu images onto arm devices that are powerful enough to run ubuntu
<ogra> linaro is to make that restriction go away some day ;)
<XorA> bah all this division makes my head hurt :-)
<ogra> linaro does upstram and core work ... ubuntu-arm just operates in the limitations of ubuntu
<ogra> if you look at the min reqs for installinf ubuntu on a PC, the same restrictions apply for ubuntu.arm for example
<ogra> i.e. 384M and 600MHz or so
<ogra> and a GL capable videocard
<ogra> at least for the maverick netbook release
<hrw> ogra: so omap3/4 does not fit - no 3d driver in ubuntu
<ogra> none of these restrictions apply to linaro
<hrw> linaro req armv7
<ogra> and linaro works on getting ubuntu off these restrictions
<XorA> hrw: they have a GL capable GFX card, ogra didnt say he needed drivers :-)
<hrw> XorA: ah... right ;D
<ogra> XorA, we'll have drivers at some point
<XorA> GLES drivers yes
<ogra> for sure for the panda ... and likely also for the beagle
<XorA> they are on my desk at the moment
<ogra> right
<hrw> X11 just died here
<ogra> linaros job is it to improve ubuntu in a way that it can run with these drivers
<hrw> 1h23 minutes so far
<ogra> like making clutter/unity work
<XorA> clutter works :-)
<ogra> or like making it work in less ram
<ogra> amitk, give me a resize tool that operates faster than 10min per 4G
<ogra> amitk, then you wont have to wait for another year ;)
<ogra> or s/year/release/
<hrw> ogra: will isntaller work if card will be in usb card reader?
<amitk> ogra: it is probably worth an extension to ext4 fs to treat sparse files in a special way
<ogra> hrw, only if the device manes persist
<ogra> *names
<hrw> ogra: so it is hardcoded to /dev/mmcblk0*?
<ogra> amitk, we use ext3 ctrrently
<ogra> hrw, yes, atm
<hrw> sux
<ogra> hrw, patches accespted
<hrw> my SD card does 14MB/s in beagle usb
<ogra> hrw, jasper can handle it, asac patched it to use usb, you will need the SD to boot though
<ogra> thats tricky
<hrw> ogra: boot from sd is easy. plug card, uboot reads kernel/initrd, unplug card, plug into card reader
<ogra> inbetween initramfs died
<hrw> ogra: unplug card *before* 'bootm'
<ogra> you can indeed do that
<ogra> but where would bootm come from then ?
<hrw> resize would be much faster
<ogra> in any automated way
<hrw> ogra: did I said 'automated'?
<ogra> note that we cant use NAND
<ogra> XM, panda, blaze all dont have NAND
<hrw> installing fbset on beagle = 5 minutes
<hrw> including 1s to fetch package
<ogra> right, thats something linaro can do
<ogra> swithc to fbset if you like
<ogra> i'm restricted to debian-installer functionallity which means wither to run debian-installer, ubiquity or oem-config
<ogra> *either
 * ogra gets tired of that discussion
<ogra> we wont switch to something like fbset, we cant use amitk'S approach of using a fixed size image since it will not speed up oem-config, all discussions around the topic are moot
<ogra> and i can only point out again that resizing isnt the slow part on the C4
<hrw> now I have x11 with nice 80's X pointer and nice background
<hrw> time to reboot
<ogra> hrw, at gdm ?
<hrw> I choosed to autologin
<ogra> ah
<ogra> which jasper version do you have installed
<hrw> safer when keyboard will not work
<hrw> ogra: the one which was in 'current' image
<hrw> will tell more after reboot
<ogra> (and please complain to the desktop team for forcefully using unity without even checking if there is GL support)
<ogra> hrw, also i still need the jasper log :)
<hrw> ogra: can I just ignore fact that I had someting on BB? I prefer to use it headless
<ogra> sure
<ogra> just install openssh-server
<hrw> and enable autogetty
<ogra> btw, japer 0.12 has a fix for the enforced unity session
<ogra> if you have an older one, edit ~/.dmrc
<Taalas> Does anyone know any documentation for getting ubuntu installed for i.MX25 from Freescale? I googled a lot but couldn't find anything.
<ogra> desktop team ignores all non GL systems
<hrw> Taalas: you need 9.10 for it
<hrw> no.. 9.04
<ogra> and your own kernel/bootloader
<ogra> right, 9.04
<hrw> 9.10 require i.mx3x
<hrw> I **need** to enable serial console
<hrw> boot takes eons without anything other then moving dots in plymouth
<Taalas> I have Ubuntu 9.04 on my dev pc but I want to get Ubuntu on the i.MX25. Is there any possibility. For BeagleBoard I found some documentation which is working properly. But want it on i.MX25.
<ogra> hrw, edit /boot/boot.script, run flash-kernel to change boot options
<hrw> ok
<ogra> Taalas, get a properly built kernel and bootloader setup, then see the channel topic for rolling a rootfs
<hrw> argh... solaris machine which I used by serial terminal in 1995 was faster then beagleboard...
 * ogra wonders why 
<amitk> Taalas: there is no out-of-box support for i.MX25 in ubuntu. You'll have to get your own kernel/bootloader and you could use the old 9.04 version of ubuntu on arm to create a rootfs
<hrw> I enter "hrw" as login and half minute to get password prompt...
<ogra> fun
<ogra> lovely IO
<Taalas> Oh perfect. Thank you for this. I will work through the documentation.
<ogra> hrw, check if bootchart is installed, could be that the desktop team put it into the default seed :P
<ogra> that will nearly grind your system to a halt
<hrw> there is
<ogra> heh
<ogra> uninstall it
<hrw> at least 'dpkg -l' lists is but I cant see status
<ogra> ls /var/log/bootchart
<hrw> I have about 8-10 chars outside of left frame of monitor
<ogra> see if it captured
<hrw> moment... I/O
<ogra> and also check the processlist
<hrw> dpkg --purge bootchart needs 20 minutes
<ogra> there might be other crap running you dont really want
<ogra> erm, you still have autologin enabled ?
<ogra> it will likely still try to start unity
<hrw> ogra: so can you check on panda (as it is a bit faster) what crap needs to be dropped and drop it from arm images?
<ogra> sudo service gdm stop
<hrw> sudo stop gdm
<ogra> hrw, thats on my list
<ogra> i havent touched the session stuff at all yet
<ogra> waiting for the DX team to provide the new minimal panel
<ogra> then i'll start shuffling seeds
<hrw> eglibc cross build with all tests/chaeck/binary generation will end sooner then I will get bb working
<ogra> heh
<hrw> and eglibc tests needs eons
<ogra> dont complain about alpha software !
<ogra> :)
<hrw> yep.. golden rule of ubuntu
<hrw> install last release if you want to complain
<ogra> the 2D session will be a lot lighter once i have removed everything we dont need
<ogra> prob is that we still need to ship the unity session
<hrw> but last release complains usually can go directly to /dev/null because devel release changes too much
<ogra> we dont have a per subarch seed possibility and omap4 will use unity on the panda
<hrw> complaining to dev release ends with "this is dev release, do not complain"
<ogra> right
<ogra> do not complain, file bugs :)
<hrw> so as a developer I have to use maverick but as a user I need lucid.
 * ogra uses lucid everywhere 
<ogra> apart from the dev boards i work with
<hrw> ogra: I used sid since it was created
<hrw> and it was better to use then maverick^Wubuntu-devel
<ogra> sure
<ogra> ubuntu development works differently than debian development
<hrw> I know
<hrw> lets get beta versions of everything, get it more or less working and pray^Whope for official stable releases before release
<ogra> ans long as you develop features that are working acrtoss package sets it will always be more broken until a certain point
<hrw> anyway - I have a board in basement which has 250KB/s rootfs
<ogra> using the dev version of ubuntu after feature freeze is usually ok
<ogra> i tend to wait until then to upgrade my systems
<ogra> anyway
 * ogra takes a break
<ogra> and if you have the jasper.log at some point i'll try to find out why you had the weird output during resize
<amitk> hrw: ubuntu is also a lot more aggressive wrt to the kind of changes in the core (e.g. rework of the entire boot sequence, plymouth, upstart, etc.)
<amitk> debian takes a long time to get these (for good reasons, btw)
<lool> ogra: The log file changes had been backed out
<lool> Because they needed synchronisation in 3 places
<lool> ogra: If these were pushed again, yes, I expect they need adaptations in other places
<lool> amitk: I'd be happy to discuss image formats; asac did more work on this though; I'd like to understand how we stand nowadays, cause I was a bit at a loss with both our Ubuntu and Linaro images; I'd like to dig a bit deeper into this
<asac> lool: amitk: whats the discussion on formats?
<amitk> asac: pre-installed images for beagle, etc.
<asac> amitk: want to have a call on that?
<amitk> asac: IMHO, what is being provided in maverick doesn't give a good first experience to users
<hrw> enough is enough!
<amitk> asac: sure, mumble?
<hrw> time to hack rootfs on desktop
<asac> amitk: yes. can we do that in 1h?
<amitk> asac: sure, ping me
<asac> will do
<hrw> bootchartd and gdm killed from rootfs, card plugged into BB, boot
<hrw> plymouth oom again
<ogra_cmpc> lool, well, it was syncronized in the other direction ... subarh is only added to the dir now, slangasek made that change,k what i was wondering was if you had ever tested that change, it cant have worked in lucid
<ogra_cmpc> -k
<ogra_cmpc> amitk, in linaro you dont have such images
<amitk> ogra_cmpc: I'm pushing for them there too ;)
<ogra_cmpc> so you wont have the resizing
<ogra_cmpc> ah
<amitk> I don't like our single minded devotion to 'installation' for everything. debian-installer is just not suitable for some devices.
<ogra_cmpc> amitk, note though that you need to repartition the SD on boot in any case no matter if you resize or not
<amitk> why?
<ogra_cmpc> amitk, because of the CHS restriction x-loader/u-boot put on us
<amitk> (I don't understand the science behind our installer, but it seems like rocket science)
<ogra_cmpc> that needs to be adjusted to the actual values of the card to be proper
<ppearse> Can anyone point me at a list of ARM boards supported by the maverick kernel?
<amitk> ogra_cmpc: can't that be handled before we let the user dd the image?
<ogra_cmpc> our installer is all built around dpkg which enfoces the debconf database on us to which the installer is a frontend (among other things it is)
<ogra_cmpc> amitk, no, becuse the CHS value for an img file might totally differ from the physical setup of an SD card
<amitk> mdz was talking about how the package manager we have currently is not suitable for distributing everything. Perhaps now is the time ;)
<amitk> ogra_cmpc: even if we make severe assumption e.g. 4Gb SDHC card only?
<ogra_cmpc> well, you would have to give that value in bytes :)
<ogra_cmpc> 4GB isnt the point, the CHS value is attached to the exact size of the card
<amitk> ogra_cmpc: sounds like some that can be programtically detected and programmed before we dd an image.
<amitk> *something
<ogra_cmpc> it will work but you will have a) an unclean partition table b) if the user ever touches the partition table your system will not boot anymore
<amitk> but it will only take 5 minutes to redo it vs. 1.5hrs currently :)
<ogra_cmpc> amitk, 1.5h ??
<amitk> hrw's numbers
<ogra_cmpc> amitk, how do you come to that value
<ogra_cmpc> *resizing* takes 10min
<amitk> I haven't tried the pre-installed image yet
<ogra_cmpc> per 4G
<ogra_cmpc> i was talking about resizing and partitioning above
<hrw> amitk: 1.5h takes installation process. resizing ~10 minutes
<ogra_cmpc> you are talking about oem-config slowness
<amitk> I don't even want that
<amitk> why do we want to configure usernames and timezones in that extremely slow way
<ogra_cmpc> amitk, we dont
<ogra_cmpc> amitk, on omap4 its a few min
<ogra_cmpc> amitk, for omap3 we could switch to the cmdline version of OEM config
<ogra_cmpc> amitk, but the final truth is that you simply do not want to use such a netbook image on HW like the C4
<ogra_cmpc> i havent tested it yet but i'm pretty sure it will work similar well on the Xm as on the panda
<amitk> ogra_cmpc: yet we provide those images :)
<ogra_cmpc> amitk, we also provide minimal spec for running ubuntu on HW
<lool> ogra_cmpc: Would you have a list of boards which are supported in maverick right now?
<ogra_cmpc> the C4 simply doesnt match these specs
<lool> ogra_cmpc: This is for ppearse
<ogra_cmpc> lool, all beagles above rev B. (not fun with Cx but works as you can see in the dicssion above), and panda ... for final we plan blaze through changing the bootloader in the omap4 image, and we're about to anble dove images again
<ogra_cmpc> lool, if you have an requirement for more omap3 boards, tell me and i'll look what i can do
<ogra_cmpc> *enable
<asac> ogra_cmpc: available?
<ogra_cmpc> asac, for a call ?
<ogra_cmpc> one sec
<asac> ogra_cmpc: yep ... i will call you in 5 ;)
<asac> we need to sync on something :-
<asac> P
<ppearse> ogra_cmpc:Thanx
<lool> ogra_cmpc: thanks
<lool> ogra_cmpc: I think IGEPv2 would be nice
<ogra> lool, i'll check if it needs anything special then (bootloader/kernel)
<amitk> ogra_cmpc: rtg is on it
<ogra> yep, i know
<Taalas> I created a rootfs with rootstock and my i.MX25 is booting into the system and now I have the login prompt on the LCD Touchscreen. But neither I can get a prompt on my serial console nor a keyboard plugged into the usb port is working. Anybody knows how to go on?
<Taalas> I used following parameters to get it work sudo rootstock --fqdn imx25 --login hctm --password temppwd --imagesize 4G --seed build-essential, openssh-server, tsconf, ssh --dist jaunty --serial ttyS0
<Taalas> also connecting via ssh is not working. The ethernet device is up
<ukleinek> Taalas: --serial ttymxc0 maybe?
<GrueMaster> Also, I don't think you want spaces in the --seed list.
<Taalas> Hmm that might be the reason why the image size isn't increasing after I added some seeds...
<Taalas> Ok rebuilding it one more time.
<awayfar> Hey everyone.  I am involved in a good deal of native ubuntu compilation on the ARM, and I was wondering if anyone had suggestions for a multi-CPU ARM board I could use as a build machine.  Right now I'm compiling on my actual target, and would like to speed up the process as much as possible while sticking to the native arch.
<GrueMaster> Haven't heard of any on the market as a released product yet.  TI Omap4 should be out in the near future, nVidia tegra is available on a limited developer basis (1 per, haven't heard of how well it works).  Don't know off hand of others that have public announcements.
<lool> awayfar: Depends of your budget
<lool> awayfar: I think the versatile express boards are nice, but they are really expensive
<hrw> lool: A9 ones?
<lool> the dove ones were nice in theory, but the early ones I got were unstable, I don't know if that's fixed, nor whether these are publicly available
<ukleinek> awayfar: /me likes http://www.qnap.com/pro_detail_feature.asp?p_id=127
<lool> hrw: Yes
<lool> ukleinek: armv5 though
<lool> awayfar: that's a good question, what architecture baseline do you need?
<hrw> awayfar: which cpu/board you target?
<lool> Death by a hundreds replies
<hrw> we flooded his input buffers
<awayfar> Wow, THANKS for all the replies!
<awayfar> I read slow ;)
<hrw> awayfar: now your time to answer ;D
<awayfar> My budget is negotiable, since this is a corporate project, and my absolute ideal board would be multiple A9/OMAP4.
<awayfar> My target is an OMAP4
<hrw> awayfar: ok
<hrw> pandaboard is not on market yet, no idea about blaze
<lool> awayfar: OMAP4 isn't really widely available yet; versatile express has quad A9 + 1 GB of RAM, so quite a nice starting point
<hrw> and good for build machine
<hrw> hi prpplague dmart
<prpplague> hrw: greetings earthling
<awayfar> hrw: That sounds great.  Now, for a not-so-bright question; If I were to install Ubuntu on an A9, is that close enough to the OMAP4 to maintain compatibility?  I know the OMAP4 uses the A9, but I may as well ask...
<lool> awayfar: What compatibility are you after?
<GrueMaster> Everything but the kernel "should" work.
<Taalas> ukleinek and GrueMaster thanks for your help. Worked out perfect
<GrueMaster> Taalas: Good to hear.
<orbarron> gm all
<awayfar> All, thanks for the information.  I spoke with prpplague offline, and he helped sort me out.  Thanks again!
<lool> ogra: Don't think https://bugs.launchpad.net/bugs/605972 is armel (it's jasper), right?
<ubot2> Launchpad bug 605972 in jasper-initramfs (Ubuntu) "Need to set hostname to ubuntu during first boot. (affects: 1) (heat: 8)" [Medium,New]
<GrueMaster> lool: It is jasper-initramfs.  Since it is only used on omap (currently) I tagged it as armel.
<lool> It would be nice to keep the list of ubuntu-armel/armel bugs identical to the bugs specific to armel
<GrueMaster> Anyways, the tag would have been put there by apport if I had filed using it.
<lool> Yes, but I remove it when it's not armel specific
<lool> Not a big deal, but since random other people (cough Linaro) will look at ARM bugs, I'd like them not to see jasper bugs
<GrueMaster> If this bug can be shown to be reproducible on other architectures, I'll agree.  Until then, if it is seen on armel first, it gets tagged on armel.  Just following bug posting procedures laid out to me from earlier cycles.
<GrueMaster> https://wiki.ubuntu.com/MobileTeam/BugWorkflow
<ukleinek> Taalas: you're welcome
#ubuntu-arm 2010-07-16
<prpplague> jayabharath: don't you ever go home?
<hrw> morning
<GrueMaster> Already?  I really wish I could go to sleep, but I leave for the airport in 3 hours.
<hrw> GrueMaster: trip to Prague?
<lool> Prague is the hot place to be!
<hrw> 33Â°C there today
<Taalas> I have a iMX25 with Ubuntu installed. How can I get the touchscreen working? ts_calibrate throws following message: "ts_open: No such file or directory"
<ukleinek> Taalas: which file does ts_open try to open?
<hrw> Taalas: and /proc/bus/input/devices lists ts device at all?
<lag> sebjan: Sorry if I've asked this before (if I did, I've forgotten the answer)
<lag> sebjan: Do _any_ of the OMAP chips have Parallel Ports?
<lag> Either ISA or PCI?
<sebjan> lag: hi! I would not speak about all omap chips, as there are many variants. I am not aware of such ports.
<sebjan> lag: you could maybe ask this question on #linux-omap?
<lag> I can :)
<lag> And have
<cooloney_> #linux-omap
<Taalas> ukleinek: I don't know. Where can I see it?
<ukleinek> Taalas: ask strace
<Taalas> hrw: /proc/bus/input/devices lists 2 devices. One is named N: Name="mxckpd" the other N: Name="imx_adc_ts"
<hrw> Taalas: did you ever used tslib tools before?
<GrueMaster> hrw: yea, Prague.
<hrw> so imx_adc_ts is your touchscreen. check which /dev/input/event it got
<cooloney> ogra: i tried to turn off swap in the kernel. then one of the oops is gone
<hrw> tslib is easy
<ogra> cooloney, so it apparently cant handle swapfiles properly
<Taalas> hrw: I never used tslib before. The Handler is event1
<cooloney> ogra: i think swap is required for you Ubuntu system, right?
<hrw> Taalas: TSDEVICE=/dev/input/event1 ts_calibrate
<ogra> cooloney, well, at least with so low memory
<cooloney> ogra: https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/605739
<ubot2> Launchpad bug 605739 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: Bad page state in process swapper pfn:94d23 (affects: 1) (heat: 6)" [High,In progress]
<cooloney> ogra: so currently, we are using a swapfile in SD card, how about a swap partition?
<ogra> cooloney, tricky but doable
<Taalas> ukleinek: strace tells /dev/touchscreen/ucb1x00 is not found
<ogra> cooloney, though its still a bug
<Taalas> hrw: same error
<ogra> cooloney, swapfiles work fine on other ubuntu arches
<cooloney> ogra: but without swap, i saw several memory allocation fails when i was trying apt-get dist-upgrade on the board
<ogra> sounds more like a general memory prob with the kernel
<Taalas> The folder /dev/touchscreen is not existing
<cooloney> ogra: maybe, i need more investigation.
<cooloney> but i think 512M memory is OK for Ubuntu on omap4,
<cooloney> although i found the system sometime is quite slow
<ogra> cooloney, yes, something is wrong, it got a lot slower between two image tests i did
<ogra> cooloney, but that also happened on omap3 so i suspect thats rather userapce
<ogra> i'll resarch and fix that at the sprint
<cooloney> ogra: got it. i assume is my SD card's problem.
<ogra> no, we all see it on different SD cards
<cooloney> sometimes my SD card cannot be recognized by my PC
<ogra> there is definately something not acting as it should
<hrw> Taalas: /dev/touchscreen never existed - maybe ltib (or whatever you used before) created it
<cooloney> ogra: ok, cool.
<ogra> the MMC driver on the panda *has* some speed issues though
<ogra> but thats not alone the reason for the slowness
<Taalas> I created my rootfs with rootstock
<hrw> Taalas: so use strace to check why it does not work
<hrw> Taalas: check permissions etc
<lag> amitk: Hi
<amitk> lag: hola!
<lag> Hey amitk
<lag> Do you have the ability to search though the kernel mailing list?
<amitk> lag: LKML?
<lag> linux-kernel@vger.kernel.org
<amitk> yes, why?
<amitk> Did Google go bankrupt? ;)
<cooloney> lol
<amitk> http://lkml.indiana.edu/hypermail/linux/kernel/
<amitk> http://marc.info/?l=linux-kernel
 * amitk subscribes to lkml through gmail to use search
<hrw> lag: gmane ;)
<lag> amitk: Search for - Stop ARM boards crashing when CUPS is loaded
<amitk> http://marc.info/?l=linux-kernel&w=2&r=1&s=Stop+ARM+boards+crashing+when+CUPS+is+lo&q=b
<amitk> lag: ^^ I see your comment there
<lag> apw: Mentioned that Lenaro may have the funding to make the LK better in this way
<amitk> lag, are you pitching a project for Linaro? :)
 * apw referred to the 'platformisation' of things like the paralellel port driver ...
<lag> Maybe :)
<lag> apw: Yep
<lag> Similar to the work that was undertaken on the serial driver a little while ago
<lag> Mentioned by Russle
<lag> Mentioned by Russell
<lag> :)
<amitk> lag: This is unlikely to be a priority for Linaro (parallel port is not an interface that many people care about anymore). You might try pitching it to to GregKH for his Linux drivers project.
<amitk> some student wanting to get their feet wet might want to dive into it
<lag> Okay, I'll ping him an email explaining
<amitk> lag: I'll ask around in Linaro, but don't expect too much.
<lag> No problem, thanks
<lag> Can I mention Linaro in an email to Greg and Russell?
<lag> I'm assuming I can if I can mention them here
<amitk> lag: mention Linaro in what context?
<lag> "I've put in a pitch for Linaro to complete the work, however, this is unlikely .... <blar>
<lag> "I was wondering if you'd be interested ... <blar>
<lag> amitk: --^
<lag> Hi mythripk
<amitk> lag: sure, but TBH this isn't the kind of work Linaro is geared for. I can almost certainly say that no machine ships with parallel ports anymore (on any platform). So just ask Greg if he knows anybody who might be interested in taking on this challenge
<lag> amitk: np
<hrw> amitk: parport_pc is not only LPT1:
<hrw> parport_serial which handles multi port PCI serial cards depends on parport_pc
<hrw> there are ARM boards with PCI slots...
<amitk> hrw: interesting. But are these modern boards?
<hrw> I know that pcie multi i/o cards also exists. and pcie is present in modern arms too
<hrw> amitk: intel ixp4xx had pci but it is xscale
<amitk> hrw: that is not really an architecture linaro cares about, is it? The discussion here is whether this is something that is a blocker for Linaro. There are ARM boards doing all sorts of things, but Linaro only cares about a small percentage of those
<lag> amitk: Is it worth mentioning that you suggested to email Greg? I.e. does he know who you are by name?
<hrw> I would just disable parport_pc from default configs
<lag> hrw: Check the kernel-team mailing list
<amitk> lag: you're being too formal about this (intros and references) :) And no, I'm not that famous ;)
<lag> One must be professional :)
<ogra> which one ?
<hrw> lag: did not found 'parport' in last 3 months
<lag> hrw: Are you searching in subject lines or main body?
<lag> hrw: Search for "Stop ARM boards crashing when CUPS is loaded"
<hrw> found
<lag> :)
<hrw> !ARCH_OMAP one
<ubot2> Factoid 'ARCH_OMAP one' not found
<lag> Yup
<ogra> lag, cooloney-afk, "omap_device: mmci-omap-hs0: new worst case deactivate latency 0: 30517" any idea what that cound mean ?
<ogra> i wonder if thats the reason for the SD slowness
<lag> Slow read?
<ogra> i get that on the console if fsck runs before resizing the filesystem
<ogra> (on panda)
<lag> It's not a kernel message
<lag> Wait
<lag> Sorry
<lag> 1 min
<ogra> it must be kernel or a driver
<lag> ogra: That's just wake-up latency
<lag> ogra: It's putting the card to sleep - saving power
<ogra> while writing to it ?
<ogra> wow
<lag> Yeah, that doesn't sound good
<ogra> it appears immediately after fsck starts
<lag> Are you sure it't not _after_ it finishes?
<ogra> yes
<ogra> printf "Checking filesystem before resizing..."
<ogra> /sbin/e2fsck -fy /dev/${DISK}${SEP}2 >>${LOG} 2>&1
<ogra> echo "[done]"
<ogra> thats the code
<ogra> it appears between the ... and done
<ogra> immediately after the printf was run
<lag> And in the ${LOG}?
<ogra> so either while e2fsck runs or right before it starts
<ogra> still waiting for the resizing to finish
<ogra> i'll grab the log but usually there is just plain e2fsck babbling
<ogra> lag, http://paste.ubuntu.com/464486/ nothing special from e2fsck
<lag> do cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
<ogra> hrm
<ogra> i have no user on that system yet
<ogra> that will take a while
<lag> I don't think that messages is an issue
<lag> It's just showing you the worst case latency of the MMC card
<lag> Once it's awake, it's awake
<lag> How slow is e2fsck?
<ogra> takes around a minute
<ogra> probably two
<ogra> (1.5G filesystem)
<ogra> overall the SD I/O seems to be way to slow though
<ogra> lag, no cpufreq at all
<lag> Hold on
<ogra> (in another note i tried to run iotop yesterday and it seems we're missing config options for it to work)
<lag> Which board is this?
<ogra> panda
<lag> From initramfs?
<ogra> yep
<lag> How can I replicate?
<lag> mythripk: ping
<ogra> grab a recent preinstalled image
<ogra> and i can give you a uInitrd to replace on the SD card with the jasper changes
<lag> I'm still having monitor issues
<ogra> just change the shipped boot.scr and use a serial console for that
<mythripk> lag: That is in the PSM mode and when it is on ,it is working fine with the patch right ?
<lag> Mythripk: Yes
<lag> Is the delay in the correct place?
<lag> Is it long enough?
<lag> ogra: Okay
<mythripk> i have sent a single clean patch with this i was not able to reproduce the on/off issue
<ogra> lag, http://people.canonical.com/~ogra/uInitrd
<lag> ogra: debconf: DbDriver "config": could not write /var/cache/debconf/config.dat-new: No space left on device
<lag> On a 16GB SD - WTF?
<ogra> that was with a fresh image and you only added the console entry to the existing boot.scr ?
<ogra> (it didnt resize, thus the no space message)
<lag> I had to mkimage it again
<lag> But yes
<lag> Fresh image, only the boot.scr changed to add console
<ogra> looks to me like the image is already configured
<lag> It was brand-spanking
<ogra> hmm
<lag> I dd'ed myself
<ogra> can you check if 7var/loga7jasper.log exsists in the foorfs ?
<ogra> *rootfs
<ogra> gah
<ogra>  /var/log/jasper.log
<lag> Nope
<lag> No consle
<lag> console*
<ogra> on your PC
<ogra> just mount the Sd
<ogra> the resizer only doesnt run if root=UUID= is set on the cmdline
<mythripk> lag: can you try and let me know
<ogra> and thats set by the second part of jasper
<lag> mythripk: Doing it right now
<lag> mythripk: Monitor entered PSM/on/PSM/on ...
<lag> mythripk: You want the log?
<lag> mythripk: http://paste.ubuntu.com/464515/
<mythripk> lag:looking at the log give me a min
<lag> ogra: /var/log/jasper.log is missing
<ogra> lag, very weird
<lag> ogra: I haven't used your initrd yet
<lag> The only thing I changed was the boot.scr
<ogra> my initrd just adds more output to jasper
<ogra> apart from that it shoudl be identical to whats on the image
<lag> So why isn't it resizing then?
<ogra> no idea
<ogra> and hard to say without log
<lag> Are there any other logs which may help?
<ogra> nope, its all in initramfs, nothing logs there by default
<ogra> it works fine here with the latest image and my hacked initramfs
<ogra> as well as with the shipped one
<mythripk> lag: did you try with debug today and with debug prints it works is it
<lag> Not yet
<lag> Wait one
<lag> Yes, it works fine with debug on
<lag> ogra: http://paste.ubuntu.com/464520/
<ogra> lag, how long did it sit between line 243 and 244 ?
<ogra> should be like 30min for a 16G card
<lag> Nowhere near that
<ogra> so resizing failed for an unknown reason
<lag> How do I debug?
<ogra> you cant
<ogra> well, you could use break=premount and try to run jasper_growroot manually
<ogra> or use break=bottom and inspect /dev/.initramfs/jasper.log
<ogra> but i doubt you will get much info from that
<lag> Well I need to fix it
<lag> So I need somewhere to start
<ogra> right, on a fresh image break=bottom and checking /dev/.initramfs/jasper.log is probably the best
<lag> Does growroot have a -vvv setting?
<ogra> heh, its a script
<lag> Okay
<lag> I'll hack the script
<ogra> depends how good you are with ed :)
<ogra> there is no editor in the initramfs
<lag> I'll mount it on my PC
<ogra> you mount the initramfs ?
<ogra> :)
<lag> Is that where the script is/
<lag> ?
<ogra> yes
<ogra> thats why making or testing changes is so hard
<ogra> or debugging
<ogra> all commands called by jasper redirect their output to jasper.log though, if you boot with a break= statement you can at least cat that file from the busybox prompt
<lool> Folks, do you know why we don't have ddebs for armel ATM?
<hrw> what are ddebs?
<ogra> lool, no idea
<ogra> lool, ask pitti ?
<ogra> i think he fiddled with pkgbinarymangler
<lag> ogra:
<lag> (initramfs) ls /dev/.initramfs
<lag> bootchart.pid
<lag> ..
<ogra> where did you break ?
<lag> break=bottom
<ogra> try premount
<lag> Do I have to reflash?
<ogra> bottom might be to late ... the script in local-bottom has a mv command for the log
<ogra> yes
<lag> Oh no, I tried premount
<lag> Should I try bottom?
<ogra> whats the last you see on the screen ?
<ogra> did it run local-premount already ?
<lag> device-mapper: ioctl: 4.17.0-ioctl (2010-03-05) initialised: dm-devel@redhat.com
<ogra> or only init-premount
<lag> udev: starting version 151
<lag> omap_device: mmci-omap-hs.0: new worst case deactivate latency 0: 30517
<lag> Begin: Loading essential drivers ... Btrfs loaded
<lag> device-mapper: uevent: version 1.0.3
<lag> device-mapper: ioctl: 4.17.0-ioctl (2010-03-05) initialised: dm-devel@redhat.com
<lag> done.
<lag> Spawning shell within the initramfs
<ogra> k
<lag> So?
<lag> Now what?
<ogra> sh /scripts/local-premount/jasper_growroot
<ogra> sh shouldnt be necessary though
<ogra> then check for the log again
<lag> (initramfs) sh /scripts/local-premount/jasper_growroot
<lag> scripts/local-premount/jasper_growroot: line 104: syntax error: /255/63/512
<lag> Oooooooooooooooooooooooo
<ogra> hmm, seems the mmc isnt there
<ogra> check /dev if mmcblk0 exists
<ogra> you probably need to break later
<lag> Doh!
<lag> My bad
<lag> Wait one
<lag> Resizing root fiomap_device: mmci-omap-hs.0: new worst case deactivate latency 0: 30517
<lag> lesystem please wait, this will take about ten minutes ...
<lag> (initramfs)
<ogra> heh, thats it ?
<ogra> it should have taken 10mins :)
<ogra> well, check for jasper.log
<lag> http://paste.ubuntu.com/464529/
<ogra> weird
<ogra> given that e2fsck just ran before
 * ogra has no idea how that could happen
<lag> Well learn ;)
<lag> This is userspace :)
<ogra> well, that would mean that something in your FS is dirty
<ogra> which cant be
<lag> It's a new dd
<ogra> resize2fs is the next line after e2fsck ... the disk isnt mounted so there is no way it could get dirty again after it was just checked
<lag> Anything else I can try?
<ogra> not really
<ogra> i have no clue why your SD appears dirty right after e2fsck -fy
<ogra> thats technically impossible
<ogra> you could try the same with the other uInitrd
<lag> With your one?
<ogra> but i doubt it will change much about the fact that either e2fsck or resize2fs cant handle your Sd properly
<ogra> yes, with mine
<ogra> you dont happen to have it mounted manually or some such ?
<lag> ogra: I flash the card and put it in the Panda
<lag> ogra: I do nothing else
<ogra> right, but there is no technical explanation for that error
<lag> ogra: It must do something, cause it trashes the boot partition
<ogra> trashes in what way ?
<lag> Won't mount on my PC any more
<ogra> like you issue mount /dev/mmcblk0p1 /mnt and get an error ?
<ogra> or how does that manifest ?
 * ogra quickly makes some coffee before the call
<lag> It does mount
<lag> It just doesn't auto mount
<ogra> thats how its supposed to be :)
<ogra> it shouldnt show on your desktop or in places or automount
<ogra> mount it manually if you need to manipulate it
<ogra> lag, when the repartitioning happens the vfat partition gets recreated and gets a label added that udev explicitly ignores
<lag> k
<lag> So it gets that far
<ogra> it runs the whole stuff apart from resizing
<lag> Seemingly so
<ogra> i'm pretty sure even the jasper_setup script from local-bottom runs fine
<ogra> i could add a force to resize2fs but that scares me a bit
<ogra> it might ignore if the FS is dirty
<ogra> not sure what checks -f disables i know it doesnt drop all of them
<lag> Well it can't be any worse than it already is
<ogra> indeed
<ogra> let me roll you another uInitrd with -f
<lag> k
<ogra> http://people.canonical.com/~ogra/uInitrd
<ogra> try that one on a fresh dd'ed card
 * ogra takes a break 
<ogra> lag, any change ?
<ogra> lag, did you have any luck with the other uInitrd ?
<XorA|gone> hmm, is there any 4430 SDP compatible images?
<XorA|gone> maverick ones
<ogra> only for panda
 * XorA|gone suspects has destroyed image trying to upgrade :-)
<ogra> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
<XorA|gone> oh no, just too a long time for ext3 recovery
<lag> ogra: How do I know if the resize has completed correctly?
<lag> (initramfs) sh /scripts/local-premount/jasper_growroot
<lag>  mmcblk0: p1 p2
<lag> Resizing root filesystem please wait, this will take about ten minutes ...
<lag> (initramfs)
<ogra> check jasper.log
<ogra> but for my hand rolled initramfs thats not enough output
<ogra> so i guess it died again
<lag> http://paste.ubuntu.com/464598/
<ogra> sigh
<lag> Fix it
<ogra> buy a better SD :P
<lag> bug 373409
<ubot2> Launchpad bug 373409 in gparted (Ubuntu) (and 1 other project) "resize2fs doesn't notice the partition was fsck'ed (affects: 1) (heat: 13)" [Undecided,Confirmed] https://launchpad.net/bugs/373409
<lag> It's a Kingston
<ogra> gparted ?
<ogra> lol
 * lag shrugs
<ogra> lag, hmm
<ogra> we actually set the clock to last mount time in omap
<ogra> so that such a broken clock setting cant interfere with mounting
<ogra> hmm
 * ogra has an ugly idea but one that will surely fix it
 * ogra rolls a new test initrd
<lag> (initramfs) /sbin/resize2fs /dev/mmcblk0p2
<lag> resize2fs 1.41.12 (17-May-2010)
<lag> ext2fs_check_mount_point: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/mmcblk0p2 is mounted.
<ogra> lag, http://people.canonical.com/~ogra/uInitrd updated, i bet it works now
<lag> What did you do?
<ogra> i mount/unmount it once before e2fsck runs :)
<lag> Okay
<ogra> just to confirm its the same
<ogra> if its the same bug it should have a new last mounted timestamp and stop complaining
<lag> k
<ogra> indeed thats not the right solution
<lag> Did you see the output of my /sbin/resize2fs /dev/mmcblk0p2
<ogra> your jasper.log you mean ?
<ogra> oh, i missed the lines above
<ogra> dont worry, the script creates an mtab
<ogra> and removes it at the end again
<ogra> you would have to do the same if you want to run it manually ... just link /proc/mounts to it
<lag> k
#ubuntu-arm 2010-07-17
<cwillu_at_work> rcn-ee, poke poke
<cwillu_at_work> I have more information on my memory leak I mentioned to you a while ago
<cwillu_at_work> rcn-ee, specifically, the ethernet on the zippy is implicated:  I get a massive and increasing number of 2kb slab allocations, until the system can no longer allocated anything
<cwillu_at_work> er, allocate
<cwillu_at_work> if I disconnect the network cable, the allocations stop
#ubuntu-arm 2010-07-18
<Mead> hello
<Mead> I just got a cheap netbook with a ARM processor and am interested in replacing windows CE with linux.  Anyone have some advice or resources that could be helpful?
<rcn-ee> cwillu_at_work, weird.. is this with 2.6.35-rc5-dl6?  there is a couple patches micrel has tried pushing but unsucessful..
<cwillu> rcn-ee, this is 2.6.33 up to 2.6.34;  2.6.35 may or may not have the same issue, can't tell due to a null pointer dereference I get on any significant network activity
<cwillu> I've tried the most recent -35rc, still unable to use it
<cwillu> however, knowing where to look now, I can determine if a kernel has the problem in a couple minutes, rather than the two day test I needed before
<cwillu> specifically, increasing size-2048 allocations
<cwillu> rcn-ee, how easy would it be to roll a 2.6.35 and/or a 2.6.34 minus the ks8851 patches?
<cwillu> rcn-ee, also, did you see my comments in #beagle?  I put more information there
<cwillu> I have to run again right away, but I'll be back in about 2 hours
<cwillu> rcn-ee, also, I can provide you remote access to the board if that would be useful
<rcn-ee> weird...  2.6.35-rc6-dl5 will be without the ks8851 patches..
<rcn-ee> my zippy2 is at work, so i'll test it monday...  do you have a test pattern i can confirm and then send to my contacts at micrel?
<cwillu> rcn-ee, "slabtop -s s", watch the size-2048 entry
<cwillu> network interface should be up and connected to a network, haven't tested if it depends on actual activity yet though
<cwillu> (i'll check that tonight)
<rcn-ee> that's still bad if leaks with no connection..
<cwillu> I know, but it might narrow things down if it requires activity
<cwillu> you should see another allocation every second or so
<cwillu> the problems become really noticeable when there's ~20,000 allocations in that slab
<cwillu> i.e., oom's even though there's lots of memory available, etc
<cwillu> (because the memory gets fragmented, hence my asking about the defrag patches before :p)
<cwillu> okay, gotta go, I'll ping you when I get back
<rcn-ee> okay later.. i'll keep an eye out..
<cwillu_at_work> rcn-ee, back
<JaMa> cwillu_at_work, rcn-ee: can you please point me to patches used to fix "unknown rellocations" in 2.6.35-rc*?
<cwillu_at_work> JaMa, you might have missed him by about 5\ hours
<JaMa> I can find out, if you point me to repo where it's fixed..
<cwillu_at_work> later 2.6.35 builds from http://rcn-ee.net/deb/lucid/
<cwillu_at_work> it'll either be in the patch file (among other things), or it's already in mainline git
<JaMa> thanks
<JaMa> ok found it
<cwillu_at_work> rcn-ee, building from your 2.6.35-devel with the micrel patches disabled still results in the null pointer
<cwillu_at_work> going to try again against 2.6.34
<cwillu_at_work> rcn-ee, looks like that null pointer thing is purely a 2.6.35 thing, of which you may or may not be aware
<cwillu_at_work> checking for the memory leak under 2.6.34 right now, with micrel patches disabled
<cwillu_at_work> rcn-ee, ... and the verdict is nack
<cwillu_at_work> I'll run it over night (need to go to bed anyway :p)
<cwillu_at_work> slabtop -s s is showing a consistent increase in allocations to the size-2048 pool, and the usual rate
<cwillu_at_work> rcn-ee, send me your id_rsa.pub, I'll set you up so you can log into the beagle images I'm making if you want
<cwillu_at_work> cwillu@cwillu.com
<cwillu_at_work> hmm, actually, there's a flicker of hope
<cwillu_at_work> I guess I should give the box a couple minutes to calm down
<cwillu_at_work> it _seems_ to be holding at around 230-250
<cwillu_at_work> so I'll let you know in a few hours (i.e., when I wake up and check :p) if it's increased from that
<cwillu_at_work> I was seeing values in the 20,000's,
<cwillu_at_work> so if it stays under a thousand for a day or so, I'll be satisfied that disabling the micrel patchset eliminates the behaviour
<cwillu_at_work> might even be able to convince me to bisect it :p
<cwillu_at_work> ...
<cwillu_at_work> (I'll still check tomorrow, but it appears to still be climbing, maybe a little less consistently than before, or I might not have noticed the bumping around before)
<cwillu_at_work> it's up at 450 now
<cwillu> rcn-ee, koen on #beagle mentioned that there was some patches on the linux-omap mailing list for a micrel memory leak
#ubuntu-arm 2011-07-11
<MrCurious> hah! google.com/+ interactive tour blew up my X session on ubuntu 11.04 pandaboard :)
<MrCurious> google + will blow your mind (or your embedded systems mind)
<lilstevie> is anyone around that can tell me how the initial boot stuff works with the preinstalled image
<lilstevie> with my device I found nvflash to have a 4GB filesize upload restriction
<persia> Maybe.  What part don't you understand?
<lilstevie> well, 1 is triggering it on another device
<lilstevie> 2 is a bit more difficult to explain
<persia> Another device?  Do you mean different partitions?
<persia> (or rather, different /dev/ nodes)
<lilstevie> no I mean the transformer rather than panda
<lilstevie> :p
<lilstevie> I upload an ext4 image
<lilstevie> which does not take up all the room it is allocated
<persia> Ah, so you want to resize the filesystem on first boot?
<persia> Doesn't the transformer have significant internal flash?
<lilstevie> yeah 16 or 32
<lilstevie> but I am trying to retain enough for the android system to co-exist
<persia> Heh, OK.  Ubuntu requires 4GB, and 8 or more is recommended.
<lilstevie> well my current image is 4.2GB
<persia> Is the transformer capable of booting from alternate media (e.g. SD)?
<lilstevie> which is nvflashes max upload
<lilstevie> yeah it can, but emmc is soooooo much faster :)
<lilstevie> its like an F1 next to a smart
<persia> That's fine.
<infinity> Sure, but slow installation media isn't the end of the world.
<lilstevie> ah installation media :p
<persia> In cases where it is possible to boot off removable media OR internal storage, you don't want to do what is done with the panda.
<lilstevie> I see
<persia> Instead you want to cause booting off the SD to perform an install to the internal media
<lilstevie> actually that would be better
<persia> (and you want to give the user choices to set up dual-boot or completely reformat and just run Ubuntu).
<lilstevie> providing everyone has ÂµSD
<persia> infinity, Were you ever pointed to the branch for that tarball installer ogra wrote?
<lilstevie> yeah that does sound nicely
<lilstevie> nicer*
<infinity> persia: Nope, but we'll get it all public RSN.
<persia> Oh well.
<infinity> persia: Especially since it'll find its way into an official image soon. :P
<persia> lilstevie, So, there exists an installer that does precisely what you want.  Unfortunately, it's not being developed transparently, so you have to wait, or reinvent the wheel :(
<lilstevie> eh :(
<infinity> (Not that you have to wait long, mind you)
<lilstevie> I am not reinventing something when it does not need to be
<lilstevie> infinity: define not that long :)
<infinity> There's no reason it's not public except a bit of laziness.  We have the technology to fix that.
<persia> I'm not sure there is a technical solution to ogra being lazy, really.
<lilstevie> heh
<infinity> Like, you're not waiting for weeks/months on process or anything, just waiting hours/days on people being poked sufficiently violently.
<lilstevie> heh
 * persia has been waiting months
<lilstevie> well it would make things easier
<infinity> persia: I poke harder.
<lilstevie> flash kernel, insert SDCard, make the choises
<persia> True.  I've only tried cajoling, shaming, and bribing.
<lilstevie> does this installer have the option for a virtual keyboard
<infinity> Sharp sticks.
<StevenK> Bribery doesn't work
<infinity> lilstevie: Virtual keyboard is mostly up to your FS image, not the installer.
<persia> lilstevie, From my experience with my dynabook, it's more 1) tell the bootloader to boot from SD, 2) insert SD card, 3) make the choices.
<infinity> lilstevie: Well, "installer" here meaning "tiny initramfs shim".
<persia> Kernel should come from the archive.
<persia> StevenK, It's worked for me many a time.  Corruption and graft are rife.
<lilstevie> infinity: heh, cause that is somethign of a must for me, while the dock is there, it is not always going to be
<lilstevie> some people don't own the keyboard dock
<infinity> lilstevie: I'll keep that in mind as I generalise this.  Since I suspect that virtual keyboards and early boot will NOT get along.
<infinity> lilstevie: We might want to generalise something for phone-like hardware interrupt hooks.
<persia> lilstevie, Aren't there some function buttons on the tablet?
<infinity> (things like "press the home button to select installation to media X", etc)
<lilstevie> persia: power, vol-up vol-down
<persia> We can work with that.
<lilstevie> hc devices have no other GPIO buttons
<infinity> Yeah, if there's any hardware button at all, we can do clever things.
<lilstevie> I have a bit more to work with on the SGT
<persia> vol-up/vol-down to select.  Power to choose.  Hold power for hard-reset.
<lilstevie> I have that plus a touchstrip
<infinity> For some value of "we" that won't be me, unless I have devices to muck with.  But I could proof-of-concept the idea on my N900 or G1 or something.
<persia> Do you have a working kernel for that?  I'd *really* like to upload it.
<persia> infinity, If you can get something working for the n900, the kubuntu-mobile folk would love you.
<lilstevie> persia: for which ?
<persia> They've a wiki page with all sorts of annoying mucking about currently.
<persia> lilstevie, SGT.
<persia> We were talking about it a couple weeks ago, and you ran into a touchscreen issue, and I hadn't heard from you since.
<lilstevie> persia: oh the issue is much bigger than we though
<infinity> persia: My N900 is pretty much Just Another armel Buildd right now, so yeah, I'm happy to screw with it as a dev device again.
<lilstevie> 2.6.32 is the only kernel with a working tsp at the moment, and one of the utouch team has found a bug
<persia> apachelogger, Notice the volunteer for the installer work above
<lilstevie> but I have been a little preoccupied with the transformer for the time being
<persia> Oh, annoying.  Can I have a kernel with broken touchscreen?
<persia> We can call that a bug, and fix it later, but we can't fix not having a package once the freezes start.
<infinity> Real men ssh to their tablets and phones anyway
<infinity> Touchscreens are for the weak.
<infinity> (Is the above pretty much proof of all the Maemo work I did for Nokia?)
<lilstevie> persia: heh, well bug on which
<lilstevie> persia: cause both of them are kinda working
<lilstevie> 2.6.35 has a weird issue where clicks are not being interpretted correctly
<persia> lilstevie, So, we upload linux-sgt 2.6.35+, and we file a bug "Touchscreen driver is broken".
<lilstevie> and 2.6.32 is duplicating the touch frame
<infinity> There was a 2 month period or so where neither the hardware OR on-screen keyboards worked on the N9 prototypes. :P
<StevenK> infinity: Which gave you what, ssh?
<persia> infinity, Isn't that why one has bluetooth?
<lilstevie> persia: sure then I can upload one :)
<infinity> StevenK: SSH and serial.
<persia> lilstevie, That would be lovely!  Put it anywhere, and I'll dig through it for packaging stuff, and stick it in the archive.
<lilstevie> persia: source or binary
<lilstevie> and we need to mark 2 major bugs :)
<persia> Source.  Preferably packaged source :)
<persia> That's fine.  Once it's in the archive, we just report them to LP.
<infinity> persia: How do you pair a bluetooth keyboard with a host you can't talk to? ;)
<lilstevie> 1) TSP, 2) Temp broken command line
<persia> infinity, agressive udev rule.
<lilstevie> persia: well I have te source up on github if that helps
<infinity> persia: I imagine the GUI folks probably pulled such tricks.  I don't touch UI anyway, so whatever.  Serial/SSH are less hassle than poking phones anyway.
<persia> Well, kinda.  Are you up for packaging it, or do you need someone else to help with that?
<lilstevie> well I have only packed for butchered apt before
<lilstevie> so I would need some help :)
<persia> infinity, You are my favourite flavour of luddite :)
 * persia tries to find jcrigby's handy kernel packaging instructions
<infinity> persia: Have you seen how I use computers?  Heck, even my mobile phone is pretty much just a mobile terminal emulator.
<lilstevie> do I need to strip the .gitignores?
<infinity> persia: X exists to multiplex terminals.  That's it.
<persia> infinity, I've seen you use GUI browsers :p
<persia> lilstevie, https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel
<persia> It's not absolutely perfect, but it will get you 95% of the way there.
<infinity> persia: I blame that on the fact that HTML5 and Flash and other fancy crap is pretty painful in lftp/w3m/lynx/etc.
<persia> If you want a comparison source, take a look at the linux-n900 package: I tweaked a few bits there.
<persia> infinity, You just haven't configured your MIME handlers properly then.
<infinity> Heh.
<persia> lilstevie, Actually, please ignore the hints to add ccache in that HOWTO: I forgot to clear that, and my first upload FTBFS.
<lilstevie> heh ok
<infinity> If any of the free swf reader libraries were actually usable, I'd totally waste a weekend writing an aalib frontend.
<persia> Why aalib?
<persia> No reason you can't spawn a useful viewer
 * persia fondly remembers web surfing with twm and no internal browser handlers
<infinity> Ahh, but if I want to live my life entirely in terminals.
<lilstevie> persia: thanks, will get on to that soon :)
<persia> There are any number of terminals that can show bitmaps...
<persia> lilstevie, If you get stuck or run out of time, let me know, and I'll see what I can do from your git tree.
<infinity> Well, I guess with framebuffers being the norm these days.  In my mind, I still live in a "terminal = text mode" world.
<infinity> Even if that's almost never true anymore.
<persia> But I'd rather if you have time to learn it, as I'd be counting on you to maintain it :)
<lilstevie> persia: :) no problems
<persia> Cool.  Two more kernels queued :)
<persia> Now if only there were documentation on how to create an image with arbitrary kernels and extra driver bits from a published rootfs...
 * infinity glares.
<infinity> We'll get there.
<persia> We're not in a terrible hurry.  The kernels need a preview cycle before any of the product managers are supposed to request an image anyway.
<persia> (sometimes people work around that, but it involves bribing the release managers, and it's just easier to wait a few extra months).
<lilstevie> heh
<infinity> I accept pie.
<infinity> And peanut butter cookies.
<infinity> I've been trying to get someone to send me homemade peanut butter cookies for months.
<lilstevie> I'll accept a job
<lilstevie> :p
<infinity> I'll give you a job baking me cookies.  That's some corporate synergy right there.
<lilstevie> hah
 * persia suggests http://www.simplesimonpies.com/ as preferred pie provisioners
<infinity> persia: They don't have pumpkin.
 * micahg wishes -pie and arm would get along
<persia> infinity, You failed to specify
<infinity> micahg: We have Top Men working on that bug, apparently.
 * persia has lost the site for delivery of peanut butter cookies, unfortunately :(
 * micahg wonders if giving infinity pie will get me -pie on arm :)
<Martyn> persia : Delivery .. of .. wha?
<Martyn> persia : Sign me up.
 * Martyn is busy putting in even _more_ patches to u-boot
<Martyn> to allow loading configs from disk, with menu
<Martyn> approaching syslinux capability now
<Martyn> syslinux levels of capability rather
<persia> Martyn, We've a temporary issue: simplesimonpies apparently doesn't carry pumpkin, which means we aren't actually arranging a delivery just now.
<Martyn> poo
<persia> Martyn, Did you see jcrigby's proposal for the configuration file?  He had something that would allow one u-boot compilation per SoC, rather than per-board (at least in theory).
<infinity> Not to mention pecan-coconut being an abomination.
<Martyn> I did ..
<Martyn> persia : It's a ways off though
<Martyn> infinity : coconut creme, equally so
<persia> Hrm?  I thought it was RSN, for a unified OMAP u-boot.
<infinity> persia: I didn't get the impression that it was THAT soon when we chatted about it in Dublin.
<infinity> persia: Just a definite "working-toward" thing.
<infinity> Which beats "it's on the TODO".
<Martyn> yep
<Martyn> it _might_ be ready, just after Oneric
<rsalveti> GrueMaster: mahmoh: found the issue with pxe
<rsalveti> is a bug at the device tree support at u-boot
<Martyn> rsalveti: Issue?
<Martyn> rsalveti: *perk*
<persia> rsalveti, Nice!
<Martyn> what happened?
<jcrigby> rsalveti, you are my hero!
<persia> Martyn, I'm reminded: do you have network and usb gadget drivers for u-boot for your devices?
<Martyn> network, yes
<Martyn> USB, no (we don't do USB)
<persia> Heh, if there's no port, there's no need for the driver.
<persia> But if you don't do USB, how do you handle KVM?
<Martyn> Well, in-theory- I guess you could put a USB device on a PCIe bus .. but .. um .. yea
<rsalveti> jcrigby: hey!
<Martyn> persia : We have our own built-in management CPU
<rsalveti> the issue is kind of stupid
<Martyn> persia : Where we're going .. we don't need .. keyboards: )
<persia> Martyn, So only VKVM via IPMI?
<Martyn> SOL, yep
<Martyn> all out of band
<persia> Ah, that works.
<rsalveti> jcrigby: common/cmd_pxecfg.c, check function label_boot
<Martyn> rsalveti : Looking here too
<rsalveti> jcrigby: in the end it tries to set the agv[3]
<rsalveti> bootm_argv[3] = getenv("fdtaddr");
<rsalveti> and later call do_bootm(NULL, 0, 4, bootm_argv);
<rsalveti> so argc is always 4
<persia> Most of the implementations I've seen in the past end up wiring something that looks like PS/2 or USB to the HW, but if you don't need that, more power to you (or rather more power saved, really).
<rsalveti> even when argv[3] is NULL
<rsalveti> so later on u-boot things the ftd file is there, because argc > 3
<rsalveti> and tries to use it, and boom, seg fault
<persia> Aha!
<lilstevie> so, transformer is wifi capable now, but this is far from optimal
<Martyn> rsalveti : Oops..
<lilstevie> needs a full network block in the wpa_supplicant
<lilstevie> no scanning
<rsalveti> Martyn: :-)
<Martyn> rsalveti : Make sure you tell jason.hobbs@calxeda.com
<Martyn> we'll fix it ...
<rsalveti> Martyn: sure, cooking a patch now
<Martyn> plus it means we need to patch the upstream, again .. *sigh*
 * Martyn is on the trail of getting rid of pre-baked configs in configuration.h now
<Martyn> since, if everything works according to plan, you'll be able to load the configuration and environment in u-boot from -- an AHCI device (FAT/EXT2,3,4), off the network, off some local flash ...
<Martyn> instead of having it all baked in
<Martyn> leaving the only thing needing to be baked in .. the order of where to search
<persia> Why?
<persia> Create a menu that lists the various (detected) options, and whilst it is scanning them, waits for the user to select the preferred one.
<persia> if the user completely fails to be paying attention, then fall back to a predetermined order once the scan is complete.
<mahmoh> rsalveti: when you have a u-boot with a patched pxe please ping me
<rsalveti> mahmoh: in a minute :-)
<Martyn> persia : Chicken and egg problem
<persia> Martyn, Why?
<Martyn> persia : Because even with a timeout, you need to have -some- indication of where to look first
<Martyn> since the u-boot environment is coming from there, and not from configuration.h
<persia> Martyn, So, as you're doing device discovery, you're prepared to accept an interrupt from console input.  If an interrupt is received, you wait for the user to confirm the list before proceeding.  If no interrupt is received, you go ahead with your prebaked order.
<Martyn> persia : Also, u-boot doesn't do detection
<Martyn> persia : At least, not _yet_ it doesn't
<persia> Fix the yet :p
<Martyn> it only detects what you tell it to :)
<Martyn> yes yes yes
<Martyn> But I'll attack this one (large) problem at a time
<mahmoh> rsalveti: in a min.?  I was hoping tmw ;)
<Martyn> if I try to patch too much at once, Wolfgang will have kittens
<rsalveti> haha
<mahmoh> lol
<persia> Martyn, So, short term: you tell it to detect foo, bar, baz, and quux in a predetermined order for your hardware.
<persia> Then you start constructing a menu whilst it's doing that.
<persia> And if the user does something, you let them reorder the sequence before starting the selected config.
<persia> If the user is too slow, you proceed with your initial intentions.
<Martyn> Yep, that's more or less what's in store
<Martyn> although the menu generation code is brand-spanking new
<Martyn> and it's really designed to handle PXE stuff
<Martyn> however, things are progressing nicely
<persia> Ah, good.  Your initial announcement made me think it was just going to check foo, bar, baz, and quux in compile-time order, and boot the config found first.
<Martyn> persia : Well that's what _will_ happen in the first pass
<persia> (which config might include a menu, etc.)
<persia> Awwww.....
<Martyn> however, from whatever source it finds first, it will load the menu
<Martyn> and so it's not any worse than, say, syslinux booting from EXT2, or a CD, or whatever
<Martyn> And thanks to the AHCI support, it just may .. MAY .. be possible for me to boot a CD on ARM .. wouldn't that be something?
<Martyn> Just in time for the whole CD technology to go obsolete, of course .. but .. :)
<infinity> I'm going to pretend you didn't say that.
<persia> I suppose.  Can't we do that today with EHCI and USB CD drives?
<infinity> If someone asks me for ARM ISOs, I intend to stuff my fingers in my ears and scream "la la la, I can't hear you".
<rsalveti> mahmoh: http://people.canonical.com/~rsalveti/pxe/3/u-boot.bin
<Martyn> infinity : I -promise- you the format of an ARM CD will be something simple and sane
<persia> infinity, There is a reason why the provided images on cdimage.ubuntu.com are supposed to be less than 700MB compressed.
<persia> infinity, Something about tradeshows and pressing costs...
<Martyn> infinity : Such that you won't have to bend your tools
<infinity> Martyn: Good, I don't like bending my tool.
<infinity> Err.
<Martyn> infinity: But ARM is a good place to break clean away from CD's
<persia> Martyn, they have already been warped beyond recognition, in ways that may significantly improve the situation for other architectures.
<Martyn> infinity: There is absolutely NO reason that we shouldn't be booting from good, standard 1G memory sticks
<infinity> Martyn: Yeah, I tend to boot from USB or SD on all my non-ARM hardware too.
<Martyn> I have put in an order for 500 ubuntu, oneric logo'ed usb keys for Orlando to give away
<persia> Martyn, trade shows...pressing costs...
<infinity> (But in that case, it often involves pretending it's a CD, which is VILE)
<Martyn> infinity: It shouldn't ... at least not on ARM
<Martyn> infinity : AFAIK, the ARM installer is nothing more than the standard net installer really..
<persia> infinity, Hrm?  Even most of my powerpcs can boot from USB if I glower at them enough.
<Martyn> bunch of seeds and a repository .. which is a far easier layout than the usual CD layout
<Martyn> no ISO9660 to worry about
<infinity> persia: I was pointing a finger at x86 in that case.  PPC is much saner, as are all the arches that grew up in the UNIX world.
<persia> Martyn, So, there are *four* installers currently provided (well, three and the one expected later this week).
<Martyn> yeah, noticed that
<persia> infinity, I don't believe I have any remaining x86 devices that can't boot USB, but then I'm kinda rough on hardware.
 * Martyn got his hands on a Nufront machine .. cute laptop, but FLIMSY
<Martyn> someone out there MUST be making a better laptop with the Cortex A9
<persia> Martyn, All of them are based on debian-installer in one way or another.  We have the base d-i environment (sometimes called "alternate" or "netboot"), the ubiquity wrapper for running it in a live environment, jasper which does just enough to launch oem-config, another d-i wrapper, and another initramfs shim (yet to be named), which again does just enough to run oem-config (at least, as last I heard it described).
<Martyn> Although I did see a Kal-El based prototype here in Austin that -was- seeeeexxxy ... looked like a thin thinkpad .. ran 2Ghz, had 3Gb of RAM
<rsalveti> mahmoh: let me know if it works for you
<rsalveti> jcrigby: just sent you the patch
<Martyn> had one hell of a pretty screen (1400x900) too
<rsalveti> Martyn: also included jason
<Martyn> thanks!
<Martyn> he'll get to it tomorrow when he gets into work
 * Martyn is doing OpenMPI work this weekend
<Martyn> making sure the whole OpenMPI set works ..
<rsalveti> great, panda booted with PXE :-)
<rsalveti> and working fine
<Martyn> then I need to convince all -you- folks to compile and put OpenMPI 1.5.3 into the repository
<rsalveti> awesome
<rsalveti> jcrigby: then we just need to fix the mac address problem with panda
<Martyn> rsalveti : Awesome...
<Martyn> rsalveti : Doesn
<rsalveti> and it'll be done :-)
<Martyn> Doesn't the panda use a USB adapter?
<Martyn> so you have to get USB up first, then the network adapter, then get all the PXE stuff up?   Ever fun.
<rsalveti> Martyn: it uses smsc95xx, usb hub and usb eth
<Martyn> yeah.. thought so
<rsalveti> the kernel is setting a unique mac address using the die id
<mahmoh> rsalveti: small problem
<rsalveti> we just need to use the same code at u-boot
<Martyn> I'll be -much- happier when more SoC vendors get off their asses and integrate a NIC right into the AMBA bus like we do
<rsalveti> mahmoh: didn't work?
<mahmoh> rsalveti: it works, now I have more work to do!  I was hoping for a few days off ;)
<mahmoh> rsalveti: want a bug for it?
<rsalveti> mahmoh: ;-)
<Martyn> Buah-ha-ha-ha!
<rsalveti> mahmoh: don't need, just sent the patch to jcrigby
<mahmoh> rsalveti: ok but we should track the work ...
<rsalveti> hm, maybe a bug to update the package before the 07 release...
<rsalveti> mahmoh: yeah, please fill a bug :-)
<persia> Bah.  Filing bugs is for when you *don't have the fix ready.
<rsalveti> then we can patch the package
<rsalveti> and properly track it
<mahmoh> rsalveti: against lp:u-boot?
<rsalveti> mahmoh: against package u-boot-linaro
<rsalveti> you can also link at u-boot-linaro project
<rsalveti> mahmoh: let me know the number and I'll take care of it
<mahmoh> shortly
<mahmoh> rsalveti: u-boot-linaro ?
<rsalveti> mahmoh: yup
<mahmoh> rsalveti: I'll file it there then you can add the other one?
<rsalveti> mahmoh: sure
<mahmoh> sweet, thx
<Martyn> rsalveti : Hey, mail me the patch as well -- martin@calxeda.com
<rsalveti> Martyn: sure, 1 sec
<Martyn> (yeah, different style address to everyone else ... early hire hath it's privs ... and besides, who wants to type martin.bogomolni@ all day?)
<rsalveti> Martyn: sent
<Martyn> danke
<mahmoh> rsalveti: is this panda specific?  I'm guessing not.
<rsalveti> mahmoh: nops
<rsalveti> but you'll only find this issue if you build with CONFIG_OF_LIBFDT
<mahmoh> rsalveti: all yours, thx all!  https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/808612
<ubot2> Ubuntu bug 808612 in u-boot-linaro "pxe fails after loading kernel and initrd" [Undecided,New]
<rsalveti> mahmoh: great, thanks
<mahmoh> np
<mahmoh> nighty, nite
<mahmoh> and good work, I appreciate it (everyone)
<stm__> hi all
<stm__> can any one point me how to build a rootfs using rootstock for custom kernel
<stm__> iam following steps mentioned at here to build rootfs
<stm__> http://elinux.org/BeagleBoardUbuntu
<stm__> i have a doubt in
<lag> stm__: For which board?
<stm__> sudo ./rootstock --fqdn omap --login ubuntu --password temppwd --imagesize 2G \ --seed wget,nano,linux-firmware,wireless-tools,usbutils --dist natty --serial ttyO2 \ --components "main universe multiverse" \ --kernel-image http://rcn-ee.net/deb/natty/v2.6.39-x1/linux-image-2.6.39-x1_1.0natty_armel.deb
<stm__> pandaboard
<stm__> what changes i have to do in the above command
<stm__> i have bulded uimage
<lag> I don't think you need to make any changes?
<lag> What's wrong with the image that's produced?
<stm__> of xenomai patched kernel 2.6.37.6
<stm__> no , i have to build rootfs for the custom kernel
<stm__> which patched with xenomai alreay
<stm__> how should i use that kernl to build the rootfs
<lag> stm__: Sorry, I didn't know you replied
<lag> stm__: Please use my nick when replying
<stm__> ok
<lag> stm__: The rootfs is not built for the kernel
<lag> stm__: Once you have a rootfs you can just install a new kernel into it and it'll just work
<lag> stm__: Is your kernel in *.deb or uImage form?
<stm__> lag: mkdir /tmp/xeno cd /tmp/xeno wget http://www.codesourcery.com/sgpp/lite/arm/portal/package7851/public/arm-none-linux-gnueabi/arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 tar -xvjf arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 export PATH=/tmp/xeno/arm-2010.09/bin:$PATH git clone --depth 1 git://git.xenomai.org/xenomai-2.5.git git clone --depth 1 --branch for-ipipe-2.6.37-arm git://git.xeno
<stm__> lag: this is the procedure i got the patched kernel and
<stm__> builded u Image
<stm__> lag: how should i build the rootfs using this uImage
<lag> stm__: You don't
<lag> stm__: I'm assuming you're using an SD card?
<stm__> lag: yes
<stm__> iam using sdcard
<lag> Mount the SD card
<stm__> Llag: i placed uImage and mlo and uboot.bin in fat16 partion
<stm__> sorry
<lag> That's it then
<stm__> lag
<lag> Boot it
<lag> All you have to do is replace the uImage with your own kernel
<stm__> placed modules on ext partion
<lag> Great
<lag> Done - boot it
<stm__> lag: its not booting
<lag> Then there's a problem with the kernel
<lag> Or u-boot
<lag> Does u-boot boot?
<stm__> if dide not use update initramfs then its givng me root partion is not mounted
<stm__> u-boot
<lag> Paste me your output
<stm__> lag: if i done update initramfs
<lag> @ paste.ubuntu.com
<stm__> ok
<stm__> lag:http://paste.ubuntu.com/641780/
<lag> stm__: Can you paste your u-boot variables (printenv)
<lag> stm__: Did you back-up the old kernel? Does that still work?
<stm__> lag: yes i backuped
<stm__> In:    serial                                                                    Out:   serial                                                                    Err:   serial                                                                    Hit any key to stop autoboot:  0                                                 Panda # printenv                                                                 bootcmd=if mmc init ${mmcdev}
<stm__> sorry
<stm__> bootcmd=if mmc init ${mmcdev}; then if run loadbootscript; then run bootscript;i bootdelay=3
<stm__> bootcmd=if mmc init ${mmcdev}; then if run loadbootscript; then run bootscript;i bootdelay=3                                                                      baudrate=115200                                                                  loadaddr=0x82000000                                                              console=ttyS2,115200n8                                                           usbtty=cdc_acm
<stm__>          mmcdev=1                                                                         mmcroot=/dev/mmcblk0p2 rw                                                        mmcrootfstype=ext3 rootwait
<stm__> lag: here is the printenv
<stm__> http://paste.ubuntu.com/641786/
<stm__> the board booting up with the old kernel nd with  this bootargs
<lag> It may just be a serial issue
<stm__> you mean ttyO2
<lag> In your rootstock command you had ttyO2, whereas in u-boot is says ttyS2
<lag> The kernel could actually be running just fine
<stm__> lag: but the rootstock created images or configs related to kernel 2.6.38.
<stm__> but my kernel is 2.6.37.6
<stm__> i have tried changing in bootscr file
<stm__> ttyo2
<stm__> Is this might be because of configs the boot program uses during booting
<lag> Mount the card again and provide me with `ls /etc/init`
<lag> From <mnt_point>/rootfs/
<lag> stm__: It's not ttyo2, it's ttyO2
<stm__> lag:yes
<stm__> lag: http://paste.ubuntu.com/641802/
<stm__> the init contails different configs
<lag> Are you sure this is the rootfs you built with rootstock
<lag> Unless I am mistaken, you are missing the serial init script
<lag> I see tty[1,2,3,4,5,6], but no ttyO1
<lag> stm__: Paste me your boot.scr
<lag> stm__: And try issuing this in u-boot: setenv console ttyO2,115200n8
<lag> Then type boot
<stm__> lag: ok
<stm__> lag: http://paste.ubuntu.com/641839/
<stm__> here is the log
<stm__> it seems i have some problem
<stm__> i can able to login through console
<lag> Did you change the boot.scr?
<stm__> lag: no actually last time i used the mlo and uboot.bin from ubuntu10.10 builin binaries
<stm__> but now i canged the mlo and uboot.bin
<lag> Well for some reason your boot.scr is no longer being successfully read
<stm__> i mean i builded mlo and uboot.bin
<stm__> lag: how should i know that the problem
<brendand> does anyone know if a simple USB stick would suffice to alleviate the performance issues associated with using SD as the main storage on the pandaboard?
<lag> It's hard to judge
<brendand> i.e. is the problem with flash or SD
<lag> Firstly make sure it's still there and readable
<lag> And that you haven't change it in any way
<brendand> i don't actually need that much storage space but would rather not have all the lag
<stm__> lag: how can i make the initrd.img-2.6.38-8-omap to uinitrd
<lag> http://elinux.org/BeagleBoardUbuntu#U-Boot_uImage_and_uInitrd
<lag> stm__: Google really is your friend
<stm__> hmm . iam sorry
<persia> brendand, It depends on the USB stick.  There are USB sticks that are faster than some SD cards, but flash connected to USB isn't that different from flash connected to MMC connected to USB, and there's plenty of USB sticks that are implemented as USB to MMC to flash anyway (I have at least one where you can see the microSD through the plastic, but it's firmly glued in).
<brendand> persia - that's a whole can of worms
<persia> brendand, The big win with rotary disks or fast SSD is twofold: 1) they tend to have cache RAM, often with advanced precaching algorithms, and 2) they tend to be turned for non-sequential reads.
<persia> Whereas most flash is tuned for sequential reads, as the presumed use cases are things like "store media", "stream media", "transfer some files", etc.
<brendand> persia - from a previous life i'm all too aware of that :)
<brendand> i once tested a 32GB Panasonic SDHC card which was designed for HD camcorders
<brendand> but when you tried random access operations on it...
<persia> Then you understand precisely why running an operating system from SD isn't precisely fast.
<brendand> yes
<brendand> so i guess my safest bet is a proper usb rotary disk drive
<persia> Or fast SSD, if you have some extras laying about :)
<brendand> i don't want to spend $100 for 1TB of storage i don't need
<brendand> that seems to be the smallest you can get in most shops these days
<brendand> probably looking online might do it
<mahmoh> brendand: what board are you using?
<brendand> mahmoh - panda
<andreas_bos1> hallo zusammen
<persia> Good morning.
<LPhas> hello, is there a way to INSTALL ubuntu on a pandaboard using a small (<=2gb) sdcard for boot and a USB pendrive for root? i manage to do it with archlinux and gentoo but i can't figure a way to do it with ubuntu
<mahmoh> LPhas: yes, you can specify your root=/dev/sda2   or similar on the kernel command line (assuming you have your root fs on the the first USB stick attached/detected) or install to the USB stick
<LPhas> mahmoh, ok i know how to boot with root on a usb stick, but i don't know how install root on a usb stick
<persia> LPhas, The documentation for that is not yet ready (as we're just finishing making it simple).
<LPhas> i do not have any sdcard > 2gb
<mahmoh> LPhas: you can use the new netinstaller for the insall,
<mahmoh> install
<LPhas> mahmoh, let see
<mahmoh> or you can copy what you have over to the USB stick
<persia> Be aware that the netinstaller is only available for the development release right now: if you want a production install, you'll want the store&copy solution.
<LPhas> mahmoh, were can i find the netinstaller image for omap4?
<mahmoh> LPhas: http://ports.ubuntu.com/ubuntu-ports/dists/oneiric/main/installer-armel/current/images/omap4/netboot/    from  https://wiki.ubuntu.com/ARM/OMAP
<mahmoh> LPhas: note the partitioning caveat!
<LPhas> yep reading it
<LPhas> how do i use these images? i guess that uInitrd, uImage, boot.scr goes on the usual boot partition
<LPhas> but the boot.img* file where it goes?
<mahmoh> LPhas: boot.img contains the all of them, if you're using then separately you won't need them
<LPhas> ook
<mahmoh> ^them^it
<LPhas> so basically i put the files in the boot partition in the sdcard, plug the usb stick, start installation and install / on sdcard
<LPhas> ehm on usb
<LPhas> but if i must put these files on the sdcard
<LPhas> and then repartition sdcard
<LPhas> i mean.. this sound strange
<mahmoh> LPhas: install / on USB stick, no?  The quickest way would be to just copy the partition you have over to the USB stick, it depends on what your goal is I guess?
<persia> LPhas, You can partition the SD card *first*, and then copy in the files you need.  This avoids repartioning.
<mahmoh> LPhas: you'll be using the SD card to boot (like a bios) then handing over the root fs to the kernel on the USB stick
<persia> Um, no.
<LPhas> mahmoh, yeah, this i get and it's basically what i do with gentoo
<persia> If we're looking at a BIOS model, it's bios+bootflash accelerator.
<LPhas> it's the installation process that bothers me
<LPhas> well, let make some experiments, i will be back
<mahmoh> LPhas: good luck
<mahmoh> persia: excuse my sloppy example ;)
<persia> Excused.  I just think it's important to be correct when drawing parallels, as the details can cause confusion later.
<persia> Err.  s/correct/precise/ (yes, I'm guilty too)
<mahmoh> persia: fair
<LPhas> isn't there something missing? like MLO?
<mahmoh> you can use the same one that's already on your SD
<LPhas> the one i just deleted?
<persia> LPhas, good catch.  There's one in the boot.img files (just loop-mount one).
<mahmoh> oops
<LPhas> (na, joking i made a backup)
<persia> NCommander, Any reason not to expose MLO as an available netboot download option?
<mahmoh> LPhas: people claim that if you don't write the MLO first to a clean boot partition it may not boot, fyi
<ogra_> persia, not really, beyond "we have never done it before"
<LPhas> also u-boot.bin
<ogra_> yeah
<ogra_> can you file a bug against debian-installer ?
<persia> ogra_, That's because most of the netinst targets have SPL in flash, and we rely on vendor SPL.
<ogra_> persia, nope, thats just because we always built mini isos in the past and sold them as netinst ;)
<ogra_> with the exception of versatile where we only wanted a kernel :)
<LPhas> to use the img* instead is ony dd if=img of=device ?
<ogra_> yes
<LPhas> the installer look a beutyful
<LPhas> beautyful
<persia> ogra_, Erm, no.  See http://ports.ubuntu.com/ubuntu-ports/dists/oneiric/main/installer-powerpc/current/images/powerpc/netboot/
<persia> That has kernel, initrd, and yaboot.
<persia> But it *doesn't* have OF.
<LPhas> mahmoh, ok now i'm officially confused. i'm at this point http://img233.imageshack.us/i/screenshot2fy.png/
<LPhas> now i think that the correct way of doying it is to create a partition for / on the usb stick
<LPhas> and a partition for /boot on the SDcard
<persia> LPhas, You want /boot on USB as well: there's a utility called flash-kernel that will extract stuff from /boot and stick it in the FAT partition on the SD card.
<ogra_> persia, i'm tsalking about arm
<persia> (well, you could also put /boot on *another* partition on the SD card, if you prefer, but that's just for fun)
<LPhas> persia, ok and i'm supposed to run it when?
<persia> LPhas, The installer will run it automatically as part of the install, and it will be run automatically whenever you install a new kernel.
<LPhas> ok
<mahmoh> LPhas: so yo don't have to have boot separate though, just make sure you create a fat32 partition on the MMC/SD and make that bootable too
<LPhas> oh
<persia> ogra_, Architecture doesn't matter.  Even for ARM targets where we use vendor SPL, the current stuff is fine.
<LPhas> so the note about partitioning in the guide refers to that
<mahmoh> and I assume you have sda #2 as  /  since I cannot see it
<persia> ogra_, And for targets for *any other* architecture where we wanted to use our SPL, we'd need to do the same.
<LPhas> and i have to create a separate /boot partition on the usb drive or can i just do only one partition for / (and another for swap maybe)
<persia> LPhas, You can get by with just the one partition if you like.
<ogra_> still, i was referring to arm and the fact that we never provided actual netboot images
<mahmoh> swap is a nice thing on the USB stick if you don't mind the usage
<persia> ogra_, Wasn't there some netboot images that worked with Freescale redboot for the Babbage?
<LPhas> i can buy another 8gb card for 4 euros
<ogra_> persia, yes, mini isos
<persia> Swap on flash is bad for the flash, whether it's USB or not.
<ogra_> same goes for omap3
<persia> For omap3, I thought we always wanted our own u-boot.
<persia> Anyway, if we used vendor SPL on the babbage, then the ancillary files would have worked without needing to be the mini ISO.
<ogra_> we have (had) mini isos for beagle
<ogra_> in lucid ...
<persia> Yes, but those contained the SPL.
<LPhas> "No mount point is assigned for the fat32 file system in partition #1" and this message should means that i've done correctly, am i right?
<persia> LPhas, Yes.
 * mahmoh1 has personality problems for 60 mins ...
 * persia waits for bzr
<rsalveti> mahmoh1: were you able to test the netboot image with pxe?
<mahmoh1> rsalveti: yes, booted and installed fine with a tweek - we'll need to setup kernel_ram and initrd_ram addresses manually for now unless you specify it in the boot.scr or uEnv.txt - I'll throw in a bug for it
<mahmoh1> tweak
<rsalveti> mahmoh1: I believe it should be fine to have that values as default at boot cmdline for panda
<mahmoh1> rsalveti: yeah, all the other boot options have addresses assigned, I think it was an oversight
<rsalveti> mahmoh1: yeah, open a bug, and we'll see what to do :-)
<mahmoh1> but that's the only thing I think needs changing
<LPhas> what's the default video driver used by ubuntu in omap4?
<mahmoh1> thx
<persia> Anyone have any suggestions for descriptions for MLO and u-boot.bin?
<LPhas> persia, x-boot image, u-boot image?
<ogra_> first stage bootloader and second stage bootloader ?
<persia> LPhas, The default is just framebuffer.  TI has a PPA with powervr drivers that many people use.
<persia> LPhas, Not very informative, but maybe :)
<mahmoh1> rsalveti: panda specific bug? u-boot-linaro-panda?
<LPhas> xboot image (second stage bootloader), u-boot image (first stage bootloader)
<rsalveti> mahmoh1: u-boot-linaro package :-)
<persia> ogra_, The issue there is that there is too much terminology using that structure.  The "S" in SPL stands for "second", but that's MLO.
<mahmoh1> ack
<rsalveti> but yeah, specific to panda
<LPhas> persia, powervr are the closed source driver, am i correct?
<ogra_> persia, well, if you call hard wired ROM code FPL indeed
<persia> LPhas, Yes.
<persia> ogra_, Most folk seem to do so.  I'm in agreement with you, but then I don't come from an embedded background.
<ogra_> (which i wouldnt)
<ogra_> well, i cant make up better descriptions :)
<LPhas> is there a repository with binary omap-gstreamer that you know about?
<ogra_> not for natty
<ogra_> unless TI recently uploaded something
<LPhas> ogra_, can i compile from sources i guess
<LPhas> my whole point would be have pandaboard playback hd video with gstreamer
<mahmoh1> rsalveti: https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/808815   thx
<ubot2> Ubuntu bug 808815 in u-boot-linaro "pxe missing kernel_ram and initrd_ram defaults" [Undecided,New]
 * persia decides to go with "Mini Loader for OMAP Beagle" and "Universal Bootloader for OMAP Beagle" (switching Beagle/Panda when I get to that file)
<ogra_> persia, http://omappedia.org/wiki/Bootloader_Project
<ogra_> what would "mini loader" mean ?
<persia> That's apparently what "MLO" abbreviates.
<ogra_> no
<ogra_> its Mmc LOader
<persia> Your internet has a different selection of wild guesses than mine.
<persia> Ah, cool.  I'll use that.
<LPhas> persia, i would mention uboot and xboot in the description, when a first got my hands on the pandaboard one thing i didn't figure out in the first momento was "what *CENSORED* is uboot?"
<ogra_> persia, according to the doc above x-loader is 1st stage by their definition
<persia> I know.  Didn't I say there was wild inconsistency in the nomenclature?
<ogra_> well, its conform with my assumption, no inconsistency at all :)
<mahmoh1> bbib
<persia> ogra_, The issue is that there is the IPL, SPL, TPL, QPL, PPL, HPL sequence, which implies cardinality which fails to match your and my prior understanding of bootloaders.
 * persia sadly watches bzr push 73K at 9kB/s for a 3019 character patch
<persia> Or maybe it's lying, as that ought to have been done by now :(
<LPhas> who did design the ascii installer for the omap4 netinstall? he's a genius
<LPhas> i love it
<persia> LPhas, The Debian Installer team.
<LPhas> oh, i don't love it anymore
<LPhas> it was a short infatuation
<persia> What happened?
<LPhas> i don't like debian :p
<persia> Well, Ubuntu is heavily based on Debian: I hope your dislike doesn't translate (and maybe that we can erode some of it).
<LPhas> yeah, ubuntu is basically debian, but they are intended for different porpuses. even if ubuntu is not my favourite distribution i can manage to live with it (an i used and loved it heavily in the past) but debian i can't stand it
<persia> Intended for different purposes?
<LPhas> yeah i mean
<LPhas> as i see it, ubuntu is intended mainly for desktop/workstations
<LPhas> while debian is mainly used for servers
<LPhas> when i go for "software selection" should i include also "basic ubuntu server" or if i install "ubuntu desktop" there's no need for that?
<GrueMaster> Nah, more like Debian is geared towards the hacker and Ubuntu is geared more towards the user.
<GrueMaster> What are you going to do with your install?  That should give you a direction on what task to select.
<LPhas> GrueMaster, mmh i don't really share your point of view. there are more "hackish" distribution like gentoo (urgh) or archlinux (which i prefer)
<GrueMaster> They're just different styles of hackish.  Fedora could also count in that list.
<LPhas> well, my goal is to have a working x installation possibily with a minimal window manager but also GNOME will be fine where i can run some gstreamer/python application
<LPhas> as easily as possible
<LPhas> so a full ubuntu installation is fine at the moment
<GrueMaster> Then select Ubuntu Desktop or one of the other desktop environments.
<LPhas> only that?
<persia> Hrm.  Ubuntu offers a server product, of which many folk are fairly proud (and any number of folks run Debian as desktop)
<GrueMaster> yes.  Just be aware that the more you select, the more of a chance it will fail due to pool churn.
<LPhas> well... it failed
<LPhas> persia, yep i know of ubuntu server, but it's really not my kind of server. (while i bet it has some advantages depends on what you do)
<GrueMaster> Probably dependency issues.  I've been seeing that since Alpha 2.
<LPhas> GrueMaster, so do you think should i try?
<LPhas> can i install "basic ubuntu server" and then add gnome-desktop later?
<GrueMaster> Give it a try, but don't get your hopes up.  It is installing oneiric after all.
<LPhas> "oneiric"?
<GrueMaster> You should be able to install ubuntu server.  YOu could also not select anything here (I recommend openssh-server as a minimum).  This will give you a minimal install and you can always add from there.
<LPhas> let's try
<GrueMaster> oneiric is the currently "in development" release.
<LPhas> ok
<GrueMaster> I'm not sure that the netinstall could be preseeded to pull from natty instead (but it would be nice).
<LPhas> yeah, unstable is always quite.. unstable
<LPhas> at least it was when i was using ubuntu years ago
<GrueMaster> On arm it is more so due to the length of time it takes to rebuild dependencies.
<LPhas> is it longer? why?
<GrueMaster> We hope to get a cluster of pandas online soon to help with that.  Right now, we only have a small handfull of single core 512M systems doing builds.
<LPhas> GrueMaster, can't you just use cross compilers?
<GrueMaster> Not really.  They can be hit or miss.  And a lot of packages have post-build test suites to verify the builds.
<LPhas> mmh i see
<LPhas> isn't possible to use cross compilers to compile the packages and move the post-build test on the actual hardware/emulated enviroment? that would be cool
<GrueMaster> And painful.  You would have to break up the build process, rewrite make files, bundle up partially completed builds, etc.
<LPhas> i see that
<GrueMaster> The reason for the poor hardware in the buildd pool is simply due to availability.  Panda is the first dual core system that was widely available.
<GrueMaster> And economical.
<LPhas> i see
<LPhas> so are you actually working in canonical?
<LPhas> (if i may ask)
<GrueMaster> Yes.  I am the QA guy for the arm releases.  But I also do some hackery on the side, when time allows.
<LPhas> that's really cool
<GrueMaster> I used to do alsa development for Intel HD Audio based systems.
<LPhas> i'we always wanted to meet a canonical guy to say "good work guys, you changed the way that linux is"
<GrueMaster> Heh, thanks.  Glad to hear you like our work.
<LPhas> one might like more hackish distros for himself, but only stupids can't appreciate the marvelous fact that you put a ubuntu cd (usb stick) and 30 minutes later you have a fully functioning linux based workstation with basically no effort
<topfs2> I'll +1 that. Was annoyed at the direction natty took until I started using oneiric, regained my trust right there :)
<GrueMaster> Part of my unofficial testing is to see if my mom can install and use it.  So far, so good.
<topfs2> (the +1 was for the "good work .." part btw :) )
<topfs2> haha, I Like the mom test :)
<LPhas> still, seems that the installer didn't worked
<LPhas> it completed successfully but it won't boot
<topfs2> I do that constantly with xbmc also, if I can picture my mom using it its simple enough
<LPhas> i don't have output on the serial console
<GrueMaster> LPhas: YOu are using the netboot installer?
<LPhas> yep
<topfs2> for the record I installed ubuntu on my ex's moms computer a while back and she loved it so much more than windows :) soemthing I found quite a lot of fun
<GrueMaster> Hmmm.  I'll have to check it to make sure it is setting up a serial console properly after boot.
<LPhas> well, there's no output at all, neither from the bootloader
<LPhas> so problem is "before the boot"
<GrueMaster> Not even any u-boot test?
<LPhas> not even
<GrueMaster> *text
<LPhas> not a single bit on the serial
<LPhas> not a blink from the led
<GrueMaster> Hmm.  I heard there may be a problem with the board not rebooting after install.  Try just hitting reset and see if it comes up.
<LPhas> nope
<LPhas> that's quite strange because apparently there are u-boot.bin MLO uImage uInitrd on the partition of the sdcard
<LPhas> also boot.scr
<GrueMaster> Yes, but if the kernel doesn't actually reboot the system after install, they won't come up.
<LPhas> yeah but i rebooted the pandaboard
<GrueMaster> Reset does nothing?
<GrueMaster> Can you check to see if the boot flag is enabled on the SD fat partition?
<GrueMaster> Also check the partition type.
<LPhas> reset does nothing
<LPhas> for the boot flag give me some minute
<LPhas> the only sd-enabled system i have is a mac
<LPhas> and fdisk on osx is quite different
<LPhas> mmh, i wrote a boot flag on the partition
<LPhas> but stil won't boot
<GrueMaster> Hmmm.
<LPhas> i can see two things running parted
<LPhas> ehm fdisk
<LPhas> /dev/sdb1   *        2048      141311       69632    b  W95 FAT32
<GrueMaster> Unfortunately, I am still ramping up hardware wise.  I will look into this later today, after I run to the store and get some external drive enclosures.  I have drives, just no enclosures.  :(
<LPhas> the first is that the partition doesn't start from sector 0
<GrueMaster> That is one problem.  The other is the partition needs to be type c.
<LPhas> "type c"?
<GrueMaster> LBA
<LPhas> oh
<LPhas> well ok, i can manage to fix this i think
<GrueMaster> Which version of the installer did you copy down?
<LPhas> boot.img-fat-serial this i think
<LPhas> on the guide they say that the partition should be 75 MiB
<LPhas> should it be precisely this amount?
<LPhas> cause i have a nice script that automatically partition the sdcard for the pandaboard
<LPhas> but the boot partition is lik 66mib
<GrueMaster> No, it can be as low as 20M, but 40-70 is recommended as flash-kernel backs up the old kernels.
<persia> GrueMaster, Ncommander wrote that there was a bug which required the FAT partition to be 72MiB at https://wiki.ubuntu.com/ARM/OMAP : is this only conservative advice?
<GrueMaster> persia: That is soley based on my recommendation from what the preinst images use.
<persia> Heh.  And now my understanding is complete :)
<GrueMaster> I haven't had a chance to figure out a definitive size.
<GrueMaster> But based on kernel and initrd sizes, we could probably go down to 40M.
<persia> That'd cover about 5 updates?
<GrueMaster> flash kernel only stores current & 1 previous version.
<persia> In that case, I suspect we might be able to get down to ~30, but yeah, it's complicated (and widely depends on what one has in the initramfs)
<GrueMaster> Not sure if we care about old versions of MLO and u-boot.bin.
<persia> Personally, I think those are even more critical.
<persia> If you don't have a working kernel, but you have a working bootloader, you can fuss about.
<persia> If you don't have a working bootloader, your device is bricked, unless you happen to have a device with the bootloader on removable media, or some other way to update he bootloader (e.g. via USB gadget).
<GrueMaster> On panda's, it is easy enough to change out the bootloader, either by pulling the SD and overwriting it on a PC (or Mac), or by booting a custom kernel via usbboot.  We just don't happen to provide the custom kernel.
<persia> ogra_, infinity: you guys fiddle with image stuff more than I: would one of you review https://code.launchpad.net/~persia/debian-installer/publish-omap-spl/+merge/67575 ?
<persia> GrueMaster, Right.  My concern is about architecture for consumer devices.  Anything we do that presumes a development board needs to be redone later if we expect to have our software delivered retail.
<GrueMaster> I'm less worried there, as we don't release alpha or beta software to retail channels usually.
<GrueMaster> And for the x-loader & u-boot, they are usually tested heavily before release.
<GrueMaster> Besides, most retail products have special partitions for each, usually just big enough to hold one copy with a little room to grow.
<persia> And as long as we have flash-kernel not overwrite them (and don't install our versions in those images), we ought be safe.
<persia> Of course, if our reputation grows enough that retail folk *want* our bootloaders, then the picture gets more complicated.
<LPhas> heh the mighty script worked
<GrueMaster> LPhas: Cool.
<LPhas> hail to that crazy gentoist who, probably waiting hours to compile gnome, wrote it
<GrueMaster> heh
<LPhas> now should i try to install ubuntu-desktop?
<LPhas> at least i could give you the precise error if it's a dependency problem
<GrueMaster> Sure.  Try "sudo apt-get install ubuntu-desktop".
<persia> `sudo apt-get ubuntu-desktop^` may have slightly different results (and more closely matches what would be in a default desktop install image).
<LPhas> http://hpaste.org/48952 and tht;s your error
<persia> Note the '^', used to distinguish a task from a package.
<GrueMaster> LPhas: The error you are seeing is similar to what I had last friday, but with different packages.  This is good, in that it means the buildds are still churning and not failing to build a package.
<GrueMaster> Sucks in that there is no frozen packages to pull from.
<LPhas> GrueMaster, is there another metapackage for another desktop manager (not kde please, no kde) maybe xfce
<GrueMaster> Not sure.  I think so.
<GrueMaster> KDE is (was) horribly broken on arm last cycle.  While I prefer it on x86, it had serious arm specific issues.
<LPhas> KDE is horribly broken everywhere :p
<GrueMaster> But I think the kde dev's have been working on those.
<GrueMaster> Depends on point of view.  A lot of people were upset with 4.0 and how nothing worked.  They don't fully realize that 4.0 was a development release to enable devs to port their 3.5 apps over.
<LPhas> yeah, just kidding
<LPhas> well, after installing xinit, startx works
<LPhas> that's a start
<GrueMaster> Cool.
<GrueMaster> Should be able to get lxde or xfde to install.
<LPhas> lwm would be enough
<LPhas> now i've to get the closed source video driver work
<LPhas> and get a decent resolution
<GrueMaster> What resolution do you have now?
<persia> LPhas, If you like LXDE, try installing lubuntu-desktop: it's a prepared environment based on LXDE for Ubuntu.
<GrueMaster> That should be up to the frame buffer.
<LPhas> switching to pvr-omap4 have i just to install it and hal handles all the stuff or is there some configuration to alter in xorg?
<persia> LPhas, It ought be all autodetected.
<LPhas> that's cool
<mahmoh> persia: init is running 100% and I cannot figure out why, who can I ping to take a look at it?
<persia> You could file a bug.
<Daviey> mahmoh: have you tried killing it? :)
<persia> You could try attaching strace to upstart to see if it tells you anything useful.
<persia> Daviey, That just reboots.
<mahmoh> HUP
<Daviey> persia: incorrect... try killing init.
<mahmoh> yeah, that's the plan but I'm outsourcing it ;)
<mahmoh> Daviey: yeah, but I want to know why first ;)
<persia> Daviey, The behaviour changed?  It meant "reboot" for a long time.
<LPhas> mmh not sure but it seems to have worked
<persia> Oh, interesting.  It doesn't appear to do anything I can detect (nor log anything anywhere I tend to look)
<LPhas> still the resolution is still VGA
<LPhas> well, time to go
<Daviey> persia: i suspect it's one of the upstart changes.
<mahmoh> I could just ask it to dump a trace, hmmm
<LPhas> thank you guy, you were wonderful, i owe you a beer
<LPhas> see you
<persia> Daviey, I suspect so, as something called "sysvinit" ought behave like a proper System V init :)
<Daviey> lol
<ogra_> who uses that anyway
<persia> ogra_, I did, for > 20 years.
<ogra_> stop living in the past then :)
<persia> Yeah, well.  I'm learning.
<ogra_> persia, your merge looks fine apart from the broken changelog
<persia> So, when it takes over an hour for bzr to push 3019 bytes to LP, other folk sometimes push their own branches.
<ogra_> yeah
<persia> I'm not willing to wait another hour to fix that: I can send a patch somewhere *OR* someone else can fix the changelog.
<mahmoh> persia: ping, here's one for you, tried getting a kernel crash but no output to the serial for panda - any ideas why or why not?
<persia> You had working serial console right before the crash?
<persia> (also, best to ask questions generally: even if you think I am likely to answer, someone else may answer sooner, and they might also be more well informed)
<mahmoh> yes, ttyO2
<mahmoh> boot info. goes to the console just fine
<infinity> Are you sure you're experiencing a kernel crash?
<infinity> Hardware lockups != Kernel crashes.  And the former will, for pretty obvious reasons, give you no output.
<mahmoh> manually caused it to get the stack (or tried to at least), yes
<fredim> hello, I need to get ubuntu 10.04 preinstalled for beagle
<infinity> Oh.
<persia> fredim, Such an image was not produced (or if it was, it was a short-lived tech demo image).
<persia> fredim, Could you use 10.10 or 11.04?  Alternately, would you be able to do an install from a bare rootfs?
<persia> mahmoh, Hrm.  Dunno.  Check the kernel config: maybe it isn't set to dump to console when it crashes.
<fredim> persia, xibo client (http://wiki.xibo.org.uk/wiki/Install_Guide_NET_Client) not suported ubuntu >= 10.10
<mahmoh> persia: thx
<persia> fredim, So, I think you're not going to end up with a nice solution.  My memory is that there were still isses with the .NET stack for armel in lucid, plus there don't seem to be images for OMAP3 for lucid.
<mahmoh> CONFIG_CMDLINE="console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootwait mem=1G"
<persia> So, you get a choice between creating your own mess, and hoping it works, potentially with support from xibo, *or* using a newer release which is known to work (11.04 finally had decent .NET support for armel), but that isn't supposed by xibo.
<persia> mahmoh, Not that config: /proc/config (and no, I don't know which options govern where to dump kcrashdumps)
<mahmoh> it's the same (?)
<persia> Err.  Sorry.  /boot/config
<persia> Well, that should match /proc/config
<mahmoh> right, they happen to be identical (haven't upgraded since install)
<persia> Your entry matches /proc/cmdline
<mahmoh> all the same
<infinity> persia: http://cdimage.ubuntu.com/ports/releases/10.04/release/ seems to disagree with you about there having been "no images" (though none were what you'd call "preinstalled", I imagine) for lucid/omap, but your argument about mono not actually working back then probably stands anyway. :P
<mahmoh> ttyO2
<persia> Sure.  I'm just saying that I have never heard of someone seeing a kernel crash dump on serial with an Ubuntu kernel, so I'm unsure if the kernel is configured to deliver those.
<persia> infinity, Ah, thanks for finding that.  I forgot that we didn't drop the "ports" designation for cdimage until maverick.
<mahmoh> I've seen plenty, but I think it was turned on ... let me go ask
<persia> fredim, ^^ has desktop and server images for omap.  No idea if the .NET support is good enough for xibo.
<persia> mahmoh, IF you *usually* get crashdumps, but just not in this case, then I'm inclined to agree with infinity that it's probably a fault rather than a crash
<fredim> Thanks, persia!   I'll see what I can do
<persia> fredim, Sorry for my confusion.  Thank infinity.
<mahmoh> I think it has to be turned on so we're ok
<persia> Ah, good.  That behaviour is sane.
<persia> How does one turn it on and off?
<mahmoh> "dmesg -n 8"  increasing logging which in turn dumps to console, resetting to 4 turns it back off again
<mahmoh> rsalveti: I'm trying the latest (your dev release from yesterday - "U-Boot 2011.06-dirty (Jul 11 2011 - 01:31:39)" on my old board and when I try usb start I get "scanning bus for devices... The request port(2) is not configured" then the board resets and I get X-Loader again (1.5.0 Jun 28 2011) - any ideas?
<mahmoh> do I have to update the X-Loader?
<rsalveti> mahmoh: which x-loader are you using?
<rsalveti> mahmoh: was it working before with the same board?
<rsalveti> mahmoh: if you grab current x-loader and u-boot-linaro binaries from the packages, it should work same way as before
<mahmoh> rsalveti: I'll update it and try it tomorrow (I'm not near the board right now) but the x-loader must change too?  if so, then that's probably what did it
<rsalveti> mahmoh: not if you got it working before
<mahmoh> rsalveti: that part I don't know, I'll find out tmw though ;)
<rsalveti> GrueMaster: mahmoh: bug 809015
<ubot2> Launchpad bug 809015 in u-boot-linaro "u-boot lacks unique mac address on Pandaboard while netbooting" [Low,Confirmed] https://launchpad.net/bugs/809015
<persia> rsalveti, Thanks for getting that logged and assigned.  Does this mean anything in terms of delivery timing expectations?
<rsalveti> persia: linaro 11.07, end of this month
<persia> Wonderful!  Thank you very much.
<persia> Is this the super solution for all vendors, or just taking the code from the omap kernel and putting it in u-boot as a stop-gap?
<rsalveti> persia: for now we want the same solution for omap 4 as we have at the kernel
<rsalveti> persia: to be a stop-gap and having a fully functional u-boot with tftp + pxe
<rsalveti> that can be used by the release
<persia> Heh, yeah, that makes sense.
<rsalveti> but we should also start the discussion for the generic vendor solution, sure
<persia> What's the best way to start that discussion?  I liked wookey's proposal, but it probably ought be formalised somehow.
<rsalveti> linaro boot architecture + u-boot m-l I'd say
<persia> wookey, Would you be up for summarising your proposal there?  Would you prefer that I try to paraphrase it to start the discussion?
<wookey> which proposal are we talking about?
<wookey> I'm having a big fght with mercurial on a server right now
<persia> wookey, The proposal about what bitfields made sense for pregenerated MAC addresses for deficient hardware.
<wookey> ah. I see
<wookey> persia: feel free to paraphrase - It was just an idea (from some dim memory of doing this on LART circa 2003)
<wookey> and DVCS officially does my head in OK?
<persia> wookey, Heh, OK.  I seem to remember something like 4 bytes for vendor, 2 bytes for board, and the rest based on a detectable identifier on the system.  Does that sound like a roughly accurate paraphrase?
<persia> DVCS is best experienced when *someone else* is the server admin :)
<wookey> I was thinking PCI ID for vendor - that's only 2 bytes IIRC
<wookey> or ethernet ID if you prefer
 * persia reads the media access control address specification
<wookey> and one byte for board ID ought to be enough
<wookey> the whole thing is only 48 bits - 6bytes IIRC
<persia> Right.  Three bytes for "Organisationally Unique Identifier", some of which are reserved for special purposes, and 3 bytes for the NIC.
<persia> Looking at the spec, I think it's 1 bit for "unicast", 1 bit for "This is a locally administered address", 6 bits for board ID, and 16 bits for vendor ID.  Then 24 bits for the specific device.
<persia> Does that seem wide enough?  Do we expect more than 127 deficient boards from the same vendor in medium time?
<persia> Err, 64
<persia> Oh, nifty.  The IEEE Registration Authority only delivers 12 bits for vendor ID, including the reserved bits, so 10 bits in practice.
<mahmoh> rsalveti: thx! ( persia too )
#ubuntu-arm 2011-07-12
 * persia had nothing to do with it
<mahmoh> persia: you did twist arms during the sprint though ;)
<mahmoh> gently
<persia> Is anyone especially attached to Headless/omap3, now that we have server images?
<persia> Oh, nevermind.  I'm reading the wiki page wrong.  the answer has apparently been "no" for some time.
<lilstevie> ogra_, you about?
<Openfree`> about arm assemble constraint,  "USAT r0, #7, r5"  => should I use "i" for value #7 ? seems not correct..
<Openfree`> usat Rd, #sat, Rm , #sat should be 0-31 value for arm, what should be the constraint? "i" not the right
<Spider-Pork> morning
<LPhas> hello everyone
<ogra_> oh my
<ogra_> http://www.fedora.org/
<LPhas> hello, i got a problem. i installed ubuntu-arm on a pandaboard using the netinstall package as "ubuntu server". then i installed xinit and startx worked, in VGA resolution with framebuffer, then i installed pvr-omap4 (without rebooting)and startx kept working in VGA resolution. today i rebooted my pandaboard and now i get this http://hpaste.org/48969
<ogra_> looks like you are missing bits on either the kernel or X side
<LPhas> well
<LPhas> i solved it with touch ~/.Xauthority ( O_O )
<ogra_> oh, so it works fine now ?
 * ogra_ hasnt used xinit in years
<LPhas> right, you are ubuntu user :p
<Spider-Pork> ogra_: do you remember my problem with audio input and ubuntu headless?
<Spider-Pork> I solved it
<ogra_> well, i only work with what we ship :)
<Spider-Pork> it works correctly on headless too
<LPhas> well. "works fine" but i still get vga resolution
<LPhas> and i'm not sure it's using pvr_omap4 instead of framebuffer
<ogra_> smells like the driver isnt getting the correct EDID data
<ogra_> Spider-Pork, how did you solve it ?
<Spider-Pork> well, I installed ubuntu headless
<Spider-Pork> then alsa and pulseaudio
<ogra_> yeah, these bits are indeed missing in headless :)
<Spider-Pork> then applyed the two commands in the bugfix page
<Spider-Pork> HiFi and Record
<ogra_> right
<Spider-Pork> then i booted into ubuntu netbook and stored in a file the amixer configurations with alsactl store
<ogra_> erm
<Spider-Pork> then rebooted with ubuntu headless, copyed in the config file and restored it with alsactl resotre
<Spider-Pork> *restore
<ogra_> that happens automatically and you wouldnt need to boot into netbook
<ogra_> a simple alsactl store would have sufficed
<Spider-Pork> store what?
<ogra_> but alsa calls that on every shutdown anyway
<Spider-Pork> on my headless there wasn't alsa configurations
<ogra_> so theoretically a reboot should have done the same
<ogra_> if you have alsa-utils installed at least
<Spider-Pork> i used the netbook alsa configurations (that is correctly working with audio line-in)
<Spider-Pork> no wait
<ogra_> /var/lib/alsa/asound.state holds the mixer states between bootzs
<ogra_> it is re-written on every shutdown with the currently applied mixer settings
<Spider-Pork> my ubuntu netbook is corretly working, my ubuntu headless wasn't
<ogra_> right, then there was something still missing
<Spider-Pork> yep
<ogra_> but you shouldnt need to copy data
<Spider-Pork> ah
<ogra_> removing /var/lib/alsa/asound.state and calling alsactl store should get you what you need
<Spider-Pork> ok i'll try it :)
<ogra_> i think it is mentioned in the bug by tobin (GrueMaster)
<Spider-Pork> i solved it with the power of the noobs
<ogra_> well, it works for you :)
<Spider-Pork> use the power, noob
<ogra_> would just be good to find a way that doesnt need a second machine ;)
<ogra_> for people having the same issue
<Spider-Pork> yep
<Spider-Pork> i will test it
<ogra_> if you found a way, please comment on the bug :)
<Spider-Pork> yep
<LPhas> http://comments.gmane.org/gmane.comp.embedded.pandaboard/754 i'm looking at this guide, i installed pvr_omap4 and other pvr packages but i don't have neither omap_gpu module nor pvrsrvinit am i missing something?
<Spider-Pork> the community helped me, so i will do the same :)
<ogra_> LPhas, did it compile the modules with dkms on next reboot after installing the package ?
<ogra_> you should just install the graphics metapackage
<ogra_> ubuntu-omap4-extras-graphics
<ogra_> from https://launchpad.net/~tiomap-dev/+archive/release indeed
<LPhas> ogra_, i installed it, but i did'nt manually compile nothing
<ogra_> not you, the system should autocompile
<ogra_> well, the package actually :)
<LPhas> well it seems to me that it compiled stuff
<LPhas> i recall it used kernel headers
<LPhas> should i remove/reinstall it?
<ogra_> ARGH
<ogra_> who pointed you to that guide
<ogra_> thats super broken
<ogra_> just adding the ppa and installing the meatapackage will suffice
<ogra_> if you did any of the manual steps in there its doubtful that your system still functions the way it was intended (with all the automatisms)
<LPhas> google
<LPhas> and no, i didn't do any manual step
<ogra_> well, wait for robher clark or rsalveti to get up ... they are both pvr specialists
<ogra_> err
<ogra_> robher, sorry, that wasnt for you
 * ogra_ curses autocompletion
<ogra_> i meant robclark
<LPhas> ok thx
<ogra_> you were also using headless, right
<ogra_> ?
<LPhas> headless==?
<ogra_> server
<LPhas> mh yeah
<ogra_> oh, wait, and you are using oneiric ?
<LPhas> ubuntu-desktop failed to install due to dependencies problems
<LPhas> mmh where oneiric was like "development version" something like that?
<ogra_> yes
<LPhas> yep
<ogra_> lsb_release -a
<ogra_> that should tell you
<ogra_> i dont think anyone toucvhed pvr for oneiric yet
<LPhas> yep, oneiric
<ogra_> so its a matter of luck if it works at all
<LPhas> but hey, i would be more than happy to use a more stable version
<ogra_> natty should just work
<LPhas> mh
<LPhas> but i need to install it from netinstall image
<LPhas> cause i don't have a 4gb sdcard
<ogra_> netinstall is still pretty young ...
<ogra_> you could use headless and then install the netbook task
<LPhas> uhm
<LPhas> headless will fit on the 2gb sdcard? and the i'd have to move / on the usb stick
<LPhas> manually
<ogra_> headless should fit on 1GB
<ogra_> at least if you dont use it much beyond doing the basic config before copying to USB
<LPhas> heh, let's do some dd work to save the current system and have a try
<lilstevie> ogra_,  I have a few questions for you when you have a moment
<alemariusnexus> Hi. Has anybody else experienced problems with the PowerVR SGX GLES2 driver on Natty lately?
<rsalveti> what kind of issues? panda or beagle?
<alemariusnexus> Pandaboard. It seems that the depth buffer is screwed up: http://noend-rpg.de/users/alemariusnexus/error.png vs. http://noend-rpg.de/users/alemariusnexus/correct.png
<alemariusnexus> I don't have problems on my desktop computer, and PVRFrame (the PowerVR GLES "emulator") doesn't show this error, too
<alemariusnexus> It might be a problem in my application. But since it appears on my Pandaboard only and since I can't imagine what kind of error in my application could cause this, I suspect it might be a driver problem (also, I had another problem which is very likely to be a driver bug in a Qt program)
<LPhas> using the installer in headless img for omap4/pandaboard, everyhing is messy, is there a dimension of the serial console i've to use to see it correctly?
<LPhas> like this http://imageshack.us/photo/my-images/197/screenshot3gv.png/
<brendand> LPhas - a lot of sort of question mark characters?
<LPhas> yeah, there are a lot of question mark charters, a lot of misplaced charters and generally the layout is broken
<LPhas> meh, i'd really like to have a way to install a stable version with the netinstaller
<LPhas> i mean, shouldn't be only matter of writing the proper apt configuration file?
<mahmoh> is anyone else seeing init @100% after heavy IO loads? 2.6.38-1309 #14 on panda?
<mahmoh> PS. running threaded IO
<fredim> Someone used ubuntu-arm on Mini6410?
<persia> fredim, The processor on that board can't run Ubuntu.  Debian should run nicely on that.
<Martyn> Fixed OpenMPI upstream.   1.5.4 release imminent
<Martyn> Also getting a source deb pulled together in debian...
<persia> 1.5.4!  My, we're a bit out of date for that.
<lilstevie> persia: I haven't forgotten about that package btw, just been a bit busy
<persia> lilstevie, Totally understood.
<persia> lilstevie, Based on https://wiki.ubuntu.com/OneiricReleaseSchedule, we have until 11th August, although I'd like to try for a bit sooner, just to have time to be sure we make that deadline.
<persia> Also, I'll not be around so much 22 July to 1 August (although someone else may also be able to sponsor), so my personal timing goals aremore complicated.
<Martyn> persia : The reason we're so far behind, is that until 1.5.2, there was no ARM support
<Martyn> and the ARM tarball was broken (missing files) until just now, since the ARM maintainer was building from SVN
<Martyn> so now it's getting fixed, and it should all work nicely for 1.5.4.  I'm testing daily
<lilstevie> persia: well if we need to get something done https://github.com/lilstevie/samsung-kernel-tab/commits/GT-P1000-gingerbread/
<persia> And the other architectures are all sufficiently well supported with 1.4.3?
<lilstevie> persia: but that does have big bugs
<Martyn> Sort of
<Martyn> it's considered the "stable" release
<lilstevie> I haven't sync'd for a bit
<Martyn> but it's missing features that are becoming important to users of OpenMPI ... 1.5.3 is mainline in Sid right now
<Martyn> so it's probably time to move Ubuntu server up to 1.5.3 as well, and make sure to provide an alternatives config
<persia> lilstevie, If you haven't found time by next week, I'll try to find time for first packaging and upload of that, directly from git.  If you find time, and we can publish a *working* kernel where you understand the packaging, that's considerably preferable.
<Martyn> well, 1.5.4 rather
<lilstevie> persia: :)
<persia> Martyn, Hrm?  My rmadison tells me sid has 1.4.3-2.1
<Martyn> Hmmm .. I've been working with the guys to make the .dsc ...
<persia> http://packages.qa.debian.org/o/openmpi.html
<Martyn> maybe they are waiting for 1.5.4?
<Martyn> yes, I see
<persia> They're probably waiting, indeed.
<Martyn> Mrrf.
<Martyn> 1.4.x series, though 'stable' is also ludicrously behind in features
<Martyn> and 1.6.x won't be out for a long while..
<Martyn> this is the old odd/even kernel problem...
<persia> Well, it's a stable/unstable thing.
<persia> Lots of folks do that in ways that don't appear so obvious in version numbers.
<persia> But there's no reason we can't put it in oneiric, if we had some volunteer who would continue to make sure it works for 18 months (hint)
<Martyn> *chuckle*  Yes, I kno
<Martyn> I just need to finish packaging it up
<persia> Sylvestre is also an Ubuntu dev, so you probably want to get it into Experimental, and sync from there if he agrees, just to avoid potential checksum mismatches later.
<LPhas> any idea on why i get this http://imageshack.us/photo/my-images/36/screenshot4ag.png/ in installing ubuntu headless?
<LPhas> could be some minicom settings?
<GrueMaster> Not off hand.  The settings look ok, from what I see on the bottom of the screen.
<GrueMaster> Can you run screen on your system?  If so, try this:  screen <serial port> 115200
<GrueMaster> I.e. screen /dev/ttyUSB0 115200
<infinity> LPhas: Minicom is a lousy terminal emulator, nothing new there.  As GrueMaster says, try screen.
<LPhas> well, with screen i get only gibberish
<LPhas> oh, no, ok it seems working right now
<LPhas> lol what is that? wait i'll make a screenshot
<LPhas> http://imageshack.us/photo/my-images/15/screenshot5hc.png/ this is with screen
<GrueMaster> I have never seen that before.  You have something strange going on, possibly with your serial port.
<LPhas> that's quite strange because with minicom that part of the boot is fine
<LPhas> and also yesterday the ubuntu netinstall was fine
<LPhas> and yet, you were right
<LPhas> i changed usb port for my serial/usb adapter and now is fine with screen O_O
<LPhas> computer science is weird
<GrueMaster> Could be a data flow issue.  I have seen weird things happen with one hub vs a different one, both are USB 2.0
<LPhas> GrueMaster, true
<LPhas> still, it's a pity that there isn't a netinstall for stable
<GrueMaster> There may be a way to do it.  I am going to test a method today (once I get all these new usb enclosures filled and online).
<LPhas> phas@panda:~$ sudo
<LPhas> sudo: must be setuid root
<LPhas> that's strange
<LPhas> well ok i probably lost some permission while moving on usb duh
<GrueMaster> How did you do the move from SD to USB?
<LPhas> sudo mv
<LPhas> well
<LPhas> sudo cp -r
<LPhas> but i should have fixed
<LPhas> i just activated root in /etc/shadow and fixed permissions on /usr/bin/sudo
<GrueMaster> I usually do: sudo su;tar -cf - . | (cd <target> ; tar -xvf -)
<GrueMaster> It also has the benefit of one thread doing reads and the other doing writes.
<LPhas> makes sense
<LPhas> next time i'll try it
<LPhas> or if permissions problems starts to get an issue
<LPhas> actually the only problems seems to be that i get
<LPhas> Processing triggers for man-db ...
<LPhas> fopen: Permission denied
<LPhas> on aptitude ugrade
<LPhas> ouch, is this normal? http://hpaste.org/48974
<GrueMaster> The find error is normal.
<LPhas> ok
<GrueMaster> Not that it is right, just happens all the time.
<LPhas> eheh
<GrueMaster> Well, if you were expecting perfection, you should have used...hrm.  Nevermind.
<GrueMaster> :P
<LPhas> i used everything else that run on pandaboard
<LPhas> so what i expect here from ubuntu-arm is a miracle :p
<GrueMaster> I'm trying, but am still stuck on that whole wine from water issue.
<GrueMaster> Priorities.
<LPhas> there are probably powders for that
<GrueMaster> Just don't expect good things to happen if you spray your system with Miracle Grow.
<GrueMaster> (sadly I have heard of people doing much stupider things).
<LPhas> what's Miracle Grow?
<GrueMaster> Some plant food sold in stores in the US to make plants grow faster.
<LPhas> oh i see
<LPhas> aaand ok, we are at the point where startx starts in framebuffer with VGA resolution
<GrueMaster> Hrm.  Can you install read-edid?
<LPhas> read-edid?
<LPhas> but i still haven't install pvr-omap4
<LPhas> i'm about to try
<GrueMaster> Don't need it.
<LPhas> uhm
<GrueMaster> This will see what the edid data is coming from the monitor.
<LPhas> where "monitor" is a television
<LPhas> (starting to run out of monitors here)
<GrueMaster> heh.  I know the feeling.  That's why I have an HDMI switch.
<LPhas> heh, my monitor has some hdmi ports
<LPhas> but it's painful to switch
<LPhas> that's weird
<LPhas> i installed read-edid
<LPhas> and i have parse-edid as an executable
<LPhas> but i can't find get-edid
<GrueMaster> hmmm.  Not finding edid on my system.  Should be at /sys/devices/omapdss/display0/edid.  Use "cat /sys/devices/omapdss/display0/edid | parse-edid"
<LPhas> mmh i can't file an edid file in  /sys/devices/omapdss/display0/
<GrueMaster> Hrm.  Wonder if it got left out of the kernel.  Shouldn't have been.
<LPhas> mmh wait a second here
<LPhas> # Booting kernel from Legacy Image at 80000000 ..
<LPhas> is it normal that he says "Legacy Image"?
<GrueMaster> yes.
<LPhas> ik
<LPhas> ok
<LPhas> well, let's try another monitor/hdmi cable
<LPhas> lol
<LPhas> it was the usb cable
<GrueMaster> usb cable?
<LPhas> hdmi cable
<LPhas> stupid hdmi cable
<GrueMaster> oh.  ok.
<LPhas> that's weird too
<LPhas> a hdmi cable that let you use only vga resolution
<LPhas> now should i try to  install pvr_omap4 from the ti repository right?
<GrueMaster> It was probably not getting the edid signal.
<LPhas> yep
<GrueMaster> Go for it.
<LPhas> should i use TI OMAP release PPA or TI OMAP trunk PPA
<GrueMaster> Not sure.   Probably trunk, but I don;'t know which has the latest stuff.
<persia> "trunk" probably has newer stuff, but "release" probably has stuff TI thinks is release-worthy.
<persia> For oneiric, "trunk" is probably best: when the underlying environment isn't stable, expecting stable add-ons is dreaming.
<LPhas> GrueMaster, i think i've got it, gg
<GrueMaster> cool
<LPhas> just this two errors bothers me
<LPhas> (EE) AIGLX: reverting to software rendering
<LPhas> (EE) Keyboard: Couldn't open mtdev device
<LPhas> if they do mean something
<GrueMaster> Unless it isn't working, I would ignore those.  I think they are for multi-touch.
<GrueMaster> Not sure.
<LPhas> now the last omap4-related matter is to get omap-gstreamer work
<LPhas> is it in the ti ppa that you know?
<persia> There have been some gstreamers in the TI PPA.  I'm not sure if any of them are compatible with oneiric.
<LPhas> i'm not on oneiric
<LPhas> i switchet to nanny
<persia> Oh, heh.  In that case, there's likely to be something.
<LPhas> basically i look for the hardware decoding support for h264
<persia> If there isn't, the uploader of the maverick version is very likely to be lurking around in this channel, and may respond to a ping.
<LPhas> i saw that there's a gstreamer_h264
<LPhas> and the usual gstreamer h264 plugin is in good
<persia> This is probably what you want :)
<LPhas> so it may be it
<LPhas> thx guys, i think that it's tyme to bothers #gstreamers guys
<mahmoh> so I'm seeing init consume 100% cpu on panda while/after running IO and threaded IO tests (PTS)
<GrueMaster> Installing phoronix now on 2 systems (third is still imaging from netinst).
<persia> mahmoh, Is there some spinning job spewing to /var/log/syslog?  When you strace init, what is it doing?
<mahmoh> haven't checked that but I'll add it to the list
<cmagina> persia: i've run strace on it and it is looping, waiting for something
<cmagina> persia: if you watch its process state, you can actually see it go to sleep between checks
<GrueMaster> Well, this can certainly pose a problem.  I have two panda systems with identical mac addresses.  Sigh.
<GrueMaster> And as a result, my dhcp server has assigned them the same IP address.
<mahmoh> set the ethaddr in uEnv.txt or boot.scr
<GrueMaster> yep.
<mahmoh> actually, once you boot the linux kernel you should have unique macs
<GrueMaster> Nope.
<GrueMaster> Both systems have been powercycled since netinstall finished.
<mahmoh> unless both your boards came from the same die?
<GrueMaster> u-boot is hardwired for the same mac.
<GrueMaster> Definitely not same die.  One is ea1, the other is a1.
<mahmoh> the u-boot mac is 00:02:03... yours should not be that once booted
<GrueMaster> Hrm.  Then something isn't right in my world.
<GrueMaster> I can log into each independently via serial console, but that has limits (not to mention that my serial console is being upgraded).
<GrueMaster> But they both show the same mac/ip.
<mahmoh> what's the mac?
<GrueMaster> 2e:40:70:f0:12:06
<persia> cmagina, Could you paste one or two repetitions of the strace?
<mahmoh> so mine both start with 2E:40:.... but diverge from there, odd
<cmagina> persia: i wish i could, but apparently i failed to record it.  on a good note, mahmoh has been able to preproduce this, so we can get one as soon as he hits it again
<mahmoh> cmagina: persia: I'll reproduce.  If it appears to be a problem, where should the bug land?  kernel, init, server-arm?
<persia> I can't say without a bit more information.  I'd guess upstart, but that's a completely uninformed guess at this point.
<persia> The 'init' executable is provided by upstart, which ought only do job processing.  It may be that some job is spinning, in which case the job provider is at fault.  It may be that upstart is spinning internally, in which caes it's a bug in upstart.
<persia> It may be that some kernel interface changed and something that is supposed to be a wait in userspace has converted to a poll (unlikely), which would make it a kernel issue.
<persia> Most likely is that something else is spinning, and making N requests of init, which upstart is trying to service, making it look like upstart is at fault.
<mahmoh> and why do I see a bunch of "omapdss DISPC error: timeout waiting for EVSYNC", is that just an artifact of the panda-usb connectivity?
<GrueMaster> that is the fb driver whining.  Safe to ignore.
<cmagina> looking through the logs i gathered from mahmoh recent repro, i noticed that the pts tests were hung
<persia> It's bug #781318
<ubot2> Launchpad bug 781318 in linux-ti-omap4 "omapdss DISPC error: timeout waiting for EVSYNC" [Medium,Confirmed] https://launchpad.net/bugs/781318
<cmagina> [31200.956817] INFO: task tiotest:1615 blocked for more than 120 seconds.
<GrueMaster> Or bug 758486
<ubot2> Launchpad bug 758486 in linux-ti-omap4 "omapdss DISPC error on Panda platform" [Medium,New] https://launchpad.net/bugs/758486
<persia> There's a chance that this could be driving odd stuff in udev, which could in turn be spinning upstart, but this is very unlikely, as more folk would see the problem.
<mahmoh> yeah but it's annoying on the server iamge
<mahmoh> iamge
<mahmoh> image
<persia> GrueMaster, I thought 781318 was it being noisy as headless, and 758486 was about failure to resume from suspend cleanly.
<GrueMaster> Read the bug reports.
<persia> I did.
<GrueMaster> This is a simple matter of someone filing a duplicate bug.
<persia> Are they duplicates?  The messages are different.
<mahmoh> rsalveti: GrueMaster: I've also confirmed I can load and run from a USB memstick (fatload usb 0 ..., root=/dev/sda2)
<mahmoh> rsalveti: ^ with your patch u-boot, I have to validate the package version [soon[
<mahmoh> ]
<GrueMaster> persia: Only slightly different messages, but they are caused by the same failing kernel FB code.  I already did the leg work with rsalveti last cycle.
<mahmoh> rsalveti: GrueMaster: and root=USB-SATA (root=/dev/sdb2) booting from MMC/SD
<persia> GrueMaster, Ah, that makes sense.
<GrueMaster> It was supposed to be fixed with the edid update code that apparently never made it in.
<persia> cmagina, That's probably just an artifact of the CPU spinning on something else.  Unless a thread is asserting realtime, it shouldn't care if it doesn't get execution slices very often (although it's nice to warn the user in case it's all batch processing and the user needs to get more cycles or reduce the load)
<persia> Ah, that's extra annoying.
<persia> (and cooloney isn't idling yet :( )
<cmagina> persia: agreed, i'm still looking over the logs i did collect, hopefully there will be something of interest
<GrueMaster> I thought paulo was the arm kernel guru now.
<GrueMaster> (ppisati I think is his nick).
<persia> Dunno.  cooloney is still assigned both those bugs.  If they ought be reassigned, I leave that between them.
<GrueMaster> mahmoh: So in your USB testing above, was that with the kernel & initrd on USB or are they still on SD?
<mahmoh> both
<mahmoh> I loaded from MMC then booted to USB first, then tried loading from USB then booting to USB (sticks)
<persia> Does that mean that we've reached a point that if we put the right u-boot in flash/MMC then we can boot from USB cleanly?
<GrueMaster> Sweet.  So in theory, we can just have x-loader (MLO) and u-boot.bin on SD, or even no SD and u-boot.bin pushed via usbboot.
<mahmoh> yes
<mahmoh> right
 * persia celebrates reaching parity with other architectures
<persia> mahmoh, Does it still need to be FAT?  Can we load off e.g. ext4?
<GrueMaster> I wonder if elmo can utilize this in the buildd cluster?
<mahmoh> ooh, good question, I think it should be able to load off of ext2, I'll try it after my tests complete
<persia> For extra points, load directly out of /boot on USB-SATA :)
<mahmoh> persia: that won't work :( drivers on;y support sticks
<mahmoh> only
<mahmoh> or so I'm led to believe
<persia> mahmoh, Considering there's no way in the USB spec to distinguish sticks from other things that provide USB class-compliant storage facilities, I suspect you've been misinformed.
<persia> (or perhaps I have)
<mahmoh> persia: tell that to the driver considering it only detects one USB storage device out of two (usb-stick & usb-sata) - guess which one ;)
<persia> That said, the drivers might not be class-compliant, or be horridly buggy for certain sorts of storage characteristics.
<mahmoh> you always see USB-FDD/USB-HDD etc. in bios so there has to be some diff., maybe it's based on size?
<persia> USB-FDD is something else.
<persia> Rather than representing a mass-storage device, it represents a removable storage device.
<mahmoh> well that's supported though in u-boot, haven't tried though
<persia> Do you have one?  I have some dusty ones somewhere if it especially needs testing.
<persia> Not sure if I have any floppies for it, mind you.
<GrueMaster> u-boot "should" support usb-sata, but may not be enabled for panda.
<persia> There's no "enable"ing to do for that.
<mahmoh> I do have one but do we really want to test it, except for curiosity's sake?
<persia> USB MSC is USB MSC, and *doesn't* indicate whether it's one or another implementation.
<GrueMaster> config flags?
<persia> mahmoh, Up to you.  It's a time/interest thing.
<mahmoh> when I'm super bored ... == never
<persia> GrueMaster, Really?  Please don't tell me that someone created configuration flags to turn on/off buggy behaviour.
<mahmoh> persia: no, that's never been done before, ever.
<GrueMaster> well, considering usb support existis in u-boot since jaunty, but only recently for omap...
 * persia reviews version 1.3 of the spec, just to be sure
 * mahmoh has some land in FL to sell to persia
<persia> GrueMaster, Oh, perhaps.  But there really shouldn't be any way to turn on or off USB<->SATA gateways.
 * persia offers discount shares on a new alligator belt factory
<mahmoh> it's probably just an addressing space issue, can't support more than X gig so USB-SATA isn't an option?
 * GrueMaster offers to trade Oregon Coast property w/ ocean views for property in florida).
<persia> Or rather, if the device is more than some size, it fails to load, and is skipped.
<persia> That's buggy, but not configurable (and would work fine with a 2G USB PATA device)
<GrueMaster> mahmoh: What filesystems does u-boot support?  Could be as simple as no ext4 support.
<persia> mahmoh, Could you verify the Subclass code for your two USB devices (working, not working)?
<persia> (lsusb -v)
<mahmoh> I'm running ext3, so maybe
<mahmoh> GrueMaster: actually no, there's a fat fs and it doesn't detect the device
<GrueMaster> ext3 is ext2+journal.  Fully backwards compatible.
<mahmoh>   bDeviceSubClass         0    for both
<persia> Right.  So if both are MSC, and both are bDeviceSubclass 0, then they are the same.
<GrueMaster> Could be a simple "find 0-1 devices and return) thing.
<persia> Is there anything other than vendor/device identifiers (name, number, etc.) that differs in the descriptors?
<mahmoh> iConfiguration          4 USB Mass Storage  vs. iConfiguration          0
<persia> Which is which?
<mahmoh> bmAttributes         0xc0  vs  bmAttributes         0x80
<mahmoh> flash/works vs sata/not-recognized
<persia> Where is that?
<mahmoh> iInterface              6 MSC Bulk-Only Transfer   vs   iInterface              0
<mahmoh> in lsusb -v
<persia> So, which is which?  Are these all in the same order?
<mahmoh> why don't I just pastebin it all for you?
<persia> May as well.
<persia> One of those devices looks misimplemented, but I may be mistaken.
<mahmoh> http://pastebin.ubuntu.com/642971/
<mahmoh> it's possible but they both work in linux
<mahmoh> the usb-sata was the cheapest I could find ;)
<persia> Not surprising.
<persia> It only implements a subset of MSC, specifically BBB.
<persia> Side effect is that it would have poor performance with multiple parallel IO streams.  Depending on the backing store, and caching, etc. this may not matter.
<persia> Your USB stick supports CBI, which is a richer instruction set.
<persia> I'm perfectly willing to believe that u-boot only supports CBI devices, but I'll assert that this is unrelated to the backing store.
<persia> Your USB stick *should* have iConfiguration of 4 (USB Mass Storage), but in practice it doesn't matter, as it's defined at the interface level.
<persia> Oh, heh, I am out of date.  1.3 says "Usage of CBI for any new design is discouraged.".
<persia> This is probably worth a bug, as without BBB support, even USB "sticks" of the future may not work.
<mahmoh> persia: who's going to write it up?  I'm sure everyone would love that support in u-boot, I know I would!  Then you could have a real boot partition that really boots and updates easily!
<persia> mahmoh, As you have hardware known to be recognised *AND* not-recognised, I suspect you're a natural candidate.
<rsalveti> mahmoh: cool, the u-boot binary from the package should work the same way as my binary
<persia> Pass me the bug number and I'm happy to comment based on what I know of USB specs
<rsalveti> the patch is integrated and package uploaded
<mahmoh> rsalveti: how difficult would it be to get usb-sata support in u-boot?
<rsalveti> mahmoh: didn't work for you?
<rsalveti> I believe it should behave the same way as when using with a pen drive
<rsalveti> at least the usb protocol should be the same
<mahmoh> rsalveti: usb-flash-drive is recognized but usb-sata-drive is not
<mahmoh> I thought I read that it wasn't supported, only sticks
<rsalveti> oh, ok
<mahmoh> rsalveti:   31 Currently supported are USB Hubs, USB Keyboards, USB Floppys, USB
<mahmoh>   32 flash sticks and USB network adaptors.     http://git.linaro.org/gitweb?p=boot/u-boot-linaro-stable.git;a=blob;f=doc/README.usb;h=a8a4058de122d6c068d9cb91b218bdc89919c0b8;hb=HEAD
<rsalveti> mahmoh: I believe my sata disk did work
<rsalveti> using with usb
<rsalveti> let me check
<persia> What!  There's a static list in udev detailing which devices to support?
<mahmoh> rsalveti: if it does work then pls tell me which controller/oem so I can get a couple ;)
<persia> mahmoh, Try inserting the vendor/device pair for your device into the u-boot code.  That might be enough to make it work.
<mahmoh> that means I'll have to build it ;)
<rsalveti> mahmoh: run lsusb at ubuntu and paste me the output of your usb disk
<persia> rsalveti, http://pastebin.ubuntu.com/642971/
<persia> mahmoh, Really, compilation isn't scary :)
<persia> There are nice scripts that do everything for you.  You only have to type `debuild -b`
#ubuntu-arm 2011-07-13
<rsalveti> persia: mahmoh: http://paste.ubuntu.com/642981/
<rsalveti> using a usb-sata disk with a powered usb hub
<mahmoh> persia: I know, I'm not scared, just don't want to get distracted
<mahmoh> ah, 'cause hubs are supported!  that's cheating
<GrueMaster> Ok, I just got to a point where I could reboot with usb-sata attached, and u-boot detects it.
<persia> u-boot can't tell if the hubs are in the SoC, on the board, or external.
<rsalveti> you shouldn't connect a usb-sata disk directly, board doesn't have all the power to power it
<mahmoh> GrueMaster: you're using a hub?
<persia> GrueMaster, Excellent.  thanks for confirming this is a problem with mahmoh's device.
<GrueMaster> no
<mahmoh> it's working on my board
<mahmoh> GrueMaster: what's the model/make?
<rsalveti> but don't know if u-boot is have the support to give more power to the device
<rsalveti>    - Interfaces: 1 Self Powered 100mA
<mahmoh> ouch
<rsalveti> directly it'd consume 500mA
<rsalveti> let me try without a hub
<mahmoh> ok, powered hub it is
<GrueMaster> Hornettek Rhino.
<GrueMaster> Using external power supply (panda doesn't have enough power to support otherwise).
<mahmoh> gazoontite
<rsalveti> mahmoh: yeah, that's the problem
<mahmoh> ok
<GrueMaster> http://www.hornettek.com/pcaccessory/index.php/25q-hdd-enclosure/usb-20/rhino
<persia> I don't see anything in the u-boot USB code that would indicate it does power level negotiation, but I'm not that familiar with the codebase.
<mahmoh> rsalveti: but wait, it works under linux though?
<rsalveti> probably need to improve the usb protocol to do allow devices to request more power than the usual
<GrueMaster> I bought 4 at Fry's.
<rsalveti> mahmoh: yeah, but because on linux the kernel allows it to take 500mA
<mahmoh> ok
<mahmoh> looks bulletproof
<rsalveti> so, it works, but you need to power it with a powered usb
<GrueMaster> That would be the Defender model.  http://www.youtube.com/watch?v=uOCVEVNU-PA
<GrueMaster> It has a 5vdc plug.
<rsalveti> persia: I don't think it does
<persia> rsalveti, http://www.usb.org/developers/devclass_docs/batt_charging_1_1.zip has the info on the new shiny for granting up to 1.8A
<GrueMaster> persia: USB2.0 or 3.0?  Makes a difference.
<persia> GrueMaster, Battery Charging was introduced as part of 2.0, and I believe it was grandfathered into 3.0, although I'll admit that I haven't been paying as much attention to USB as I did 5 years ago.
<GrueMaster> Reason I say that is that the 2.0 plug can only handle x amps electrically, and that may be pushing the envelope.
<persia> There's been something like 5 revisions of the plugs.
<persia> But if the host isn't implemented with a plug that can handle that amperage, it isn't likely to be able to negotiate the higher amperage.
<persia> Mind you, some idiot might have wired up a port to appear to handle charging without sufficient support, but the legion of iPod owners complaining about burned devices would likely be a sufficient source of complaint that we oughtn't care.
<GrueMaster> Section 3.5 says the standard A connector is capable of 1500mA.
<persia> (not to pick on the iPod specifically, but most of the USB power hardware I see in shops that supports higher amperages is labeled "supports iPod", rather than "supports Battery Charging Detection")
<GrueMaster> A charger can push more if it has a port that can handle the load.
<persia> Right.
<persia> But that ought be limited at a level u-boot can't fiddle.
<GrueMaster> My nook color pulls 1500 if it has the custom microusb cable.
<persia> u-boot would fiddle the device registers to increase the level, but isn't likely to be able to reach higher than the device supports.
<GrueMaster> At any rate, I don't know what current the panda can push out the usb ports.
<persia> Supposedly 2A of the input power is expected to be used by the USB ports.  Mind you, that's hearsay: I've seen no documentation about this.
<GrueMaster> But it doesn't appear to be enough to handle these drives even with a USB Y cable.  The drives are 160GB rated at 0.56A
<persia> I suspect that the ports are likely rated at 1.5A each.
<persia> Remember, if the negotiation doesn't happen properly, even a Y cable will only provide 200mA
<GrueMaster> Ah.  So definitely a u-boot issue.
<GrueMaster> (kernel as well).
<persia> Looks that way.  Looks like u-boot doesn't support current negotiation, so if the device needs more than 100mA, then it just won't work.
<GrueMaster> Explains my earlier headache.
<persia> linux does have some current negotiation, at least up to the 500mA level.  That said, it may be that the specific USB driver used here isn't implementing it correctly, or something.
<NekoXP> check what is behind the ports
<persia> I have no idea if linux can support battery charging: anecdotally folks don't seem to get fast-charge of their media players / phones / etc. from plugging them into Ubuntu, so I suspect it doesn't.
<NekoXP> usually you have something like an ISL6185XXC there which will be rated for a particular current and for a particular overcurrent protection
<persia> NekoXP, Is that something software detectable?
<NekoXP> absolutely not
<NekoXP> but the pandaboard schematics are available right?
<persia> That's what I thought.
<GrueMaster> persia: I have not seen an issue charging my cell from my desktop, so I think the kernel has *some* logic in it.
<persia> GrueMaster, Does it charge as fast as if you attach it to a 1.5A 5V supply?
<GrueMaster> Not sure.  never really measured it, but it appears to be fairly decent.  And I don't think my phone can pull that much.  Need to look at the spec on micro usb.
<persia> NekoXP, So, while board designers might do all sorts of things, do you think there's any risk in attempting to comply with the current negotiation specs all the way up to 1.8A in u-boot/linux?  Would it be safe to rely on the hardware to simply not do what was asked if it hit it's limites?
<GrueMaster> Something to test with my nook though.
<persia> I've pushed 2.0A over microUSB, but that required special HW on both ends.
<NekoXP> absolutely do not :D
<NekoXP> 1.8A is way, way over the spec
<persia> Which spec?
<persia> According to Battery Charging Specification, it looks like a device can expect 5.25V at 1.8A assuming all negotiation is successful.
<NekoXP> ONLY if the USB controller and the stuff behind it complies with the battery charging specification
<NekoXP> which is a very complicated and kinda ass backwards spec
<persia> Wouldn't a non-compliant implementation not respond to bit-banging to tell it to provide more than 1.5A (or, in practice, really 500mA)?
<persia> (and yes, the spec is incredibly complicated)
<NekoXP> I would assume that the panda pmic is supplying port power
<NekoXP> so check if the pmic supports the BCS
<NekoXP> and check that it supports it from a *we are the host* POV, instead of the "we are the device and you are charging your pandaboard's battery via the OTG port" which I am absolutely sure it would support
<persia> Oh, panda almost certainly doesn't support BCS.
<persia> But in terms of adding support for current negotiation to upstream u-boot, I'm unsure how much we care about a specific implementation.
<NekoXP> it is entirely device specific
<NekoXP> but consider this
<NekoXP> if your system loaded and did not get past bootloader, why would you be plugging your iPhone into it
<persia> Sure, but if the system loaded, and started the bootloader, I might want to load my OS off my USB optical drive..  Those usually require ~700mA to spin up.
<NekoXP> but the maximum in the USB spec is 500mA
<persia> Unless one implements BCS.
<NekoXP> your CDROM drive will not comply with the BCS
<GrueMaster> It will with a usb Y cable.
<GrueMaster> 500ma per port.
<persia> Hrm.  I've seen a number of one-plug optical drives floating around, which only work when attached to newer platforms.  I had presumed they were doing something like that.
<persia> GrueMaster, But that doesn't require BCS compliance: just regular current negotiation (which u-boot also doesn't have)
<NekoXP> a USB Y cable is not the battery charging specification
<GrueMaster> Charging spec or not, the question remains of why I can't power a usb-sata drive with a usb Y cable.  Charging my cell is very low on the list, but having working usb-sata is very high.
<GrueMaster> (and I lost track of this thread when it diverged from that).
<NekoXP> GrueMaster, quite possibly because at the end of the day the port power provided will never reach the levels you want
<persia> GrueMaster, There's a bug in u-boot.  It doesn't do *any* current negotiation.  As a result, your Y-cable is only providing 200mA to your HD.
<GrueMaster> 506mA?
<persia> I'm curious if we want to implement BCS in u-boot.
<NekoXP> for instance if you're using Freescale's MC13892 PMIC on a device, using ther VUSB regulator to provide port power, it will supply 100mA and that's it
<persia> I think NekoXP is suggesting that this probably isn't a good idea.
<GrueMaster> Is it a u-boot or platform issue?  If u-boot, it is fixable.  If the platform can't handle the load due to design, that's a different issue.
<persia> NekoXP, Even if the software supports current negotiation?  The port can never do 500mA?
<GrueMaster> So, simple answer - hardware limitation.
<persia> GrueMaster, Both, but in the specific instance of the panda, there is support for 500mA.
<NekoXP> in the specific case of the board you're trying to make it work on you shouldn't need to NEGOTIATE for current
<GrueMaster> persia: if the hw will support 500ma but u-boot doesn't support autoneg, that's a software issue.  If the panda power regulator can't handle it, then it is hardware.
<persia> What?
<NekoXP> you simply have to configure the host controller, configure the port, turn VBUS on and initialize the device
<persia> NekoXP, But USB 2.0 specifies that the device is supposed to *ASK* if it wants more than 100mA.
<NekoXP> before you actually kick the device it cannot draw more than 100mA per spec anyway
<persia> GrueMaster, For those definitions of "software" and "hardware", it's a software problem.
<NekoXP> the descriptors will say whether it wants more
 * GrueMaster will check back for an answer later.
<NekoXP> and if so the host can grant that by turning on the regulator
<NekoXP> there's not really any protocol for it
<persia> NekoXP, Right, but what we've discovered is that u-boot isn't lifting the power even when the descriptors request more.
<GrueMaster> On a more immediate note, I just discovered panda (u-boot, kernel, whatever) doesn't like the SD to be removed, even when rootfs is on usb.
<GrueMaster> Very odd.
<NekoXP> GrueMaster, probably kernel
<persia> GrueMaster, Did you boot kernel from SD, or from somewhere else?
<NekoXP> there is an option to make the device a little persistent
<NekoXP> i.e. assume it's there and if not, puke
<GrueMaster> persia: Should be irrelevant as it isn't a mounted filesystem.
<NekoXP> persia, USB "current negotiation" is down to physics, mostly
<persia> GrueMaster, I think linux still uses the boot source as a backing store, if it can.  I might be mistaken.
<GrueMaster> Works fine on babbage3.
<persia> NekoXP, Except the bit where the OS reads the descriptors and tweaks the regulator to push to 500mA, unless I misunderstood something (in which case, please tell me what I should have read)
<persia> GrueMaster, Very odd.
<NekoXP> a device will not draw more current than you can provide it, and it will not draw current unless you turn it on.. you plug in a USB stick, the USB host controller is providing capability of 500mA (or whatever) to the device 99.9% of the time. if this is controlled by some kind of regulator this voltage can be changed based on power management policy. The USB spec states that an unconfigured device may only draw 20mA suspended (which goes away the moment you
<NekoXP>  talk to it) 100mA otherwise. If you read a descriptor that says 500mA then you may turn your regulator up to 500mA, but in actual fact, most systems just leave it at 500mA and you have no choice really
<NekoXP> if a device wants 1.8A then it will draw it if you supply it
<NekoXP> the real problem with magnetic media, cdrom drives and so on is that they have a ridiculous need for spinup current, which spikes and is probably way way over the maximum most USB regulators provide.
<NekoXP> as the device gets older, it actually needs more to spin up
<NekoXP> from experience, most board designers don't bother to actually have a configurable regulator
<NekoXP> it's on or it's off
<persia> Aha.  I think I understand then.  So the panda apparently defaulting to 100mA unless told to act differently by software is a specific quirk of the implementation, and in general the practice is to pump 500mA while expecting 100mA draw unless something odd happens?
<NekoXP> it supports 500mA or not.
<NekoXP> yeah
<NekoXP> and the reason it doesn't work is your disk is about 6 months old, it has some wear and tear, and the switcher behind the usb port can't handle a load spike as fast as the disk needs it
<persia> I see.  So, if my understanding of the issue is correct, we'd need panda-specific code in u-boot that checked stuff and turned up the regulators if appropriate.
<NekoXP> possibly
<persia> Mind you, u-boot needs to completely turn off USB before booting the OS, so just randomly cranking them probably isn't ideal.
<persia> Do you happen to know that this sort of thing is not required for common i.MX51 and i.MX53 boards?
<NekoXP> on the efika, vbus controls whether power is on or off
<NekoXP> it's configured through the phy which some people consider weird
<NekoXP> we just turn the damn thing on
<NekoXP> and this always goes through a hub, which is always powered
<persia> OK, so u-boot just scans USB, does it's thing, turns "off" the devices (but the hub is powered), and loads the OS?
<NekoXP> if you don't twiddle vbus, the hub gets 20mA and it fucking likes it. that's actually not enough to bring the hub up.
<persia> Right.  I think I understand.  Thanks.
<NekoXP> oh, yeah
<NekoXP> the other problem with disks is they actually need 12V supplies
<NekoXP> and USB is 5V
<persia> Depends on the disk.  Lots of 2.5" and 1.8" disks work fine with 5V.
<NekoXP> so there's some stuff on the board to get a12V supply from a 5V one and they kind of take time to work, and it reduces the current, and of course as THOSE components age.. they suck :D
<NekoXP> depends on the disk, really
<persia> Oh, indeed.
<GrueMaster> I have yet to see a laptop sata drive that needs 12v.
 * jburkholder got his pandaboard
<armelTest> hey anyone have probs with getting the build-essential packages?
<armelTest> anyone here?
<persia> armelTest, Lots of folk.
<persia> For hich release are you having issues getting build-essential packages?
<armelTest> 9.10 karmic
<armelTest> any thoughts?
<persia> Are you pointing at ubuntu-ports.ubuntu.com in your sources.list?
<armelTest> idk brb
<infinity> persia: By which you mean posts.ubuntu.com?
<infinity> s/posts/ports/
<armelTest> yeah im waiting on this device to restart
<persia> Well, considering your hostname and my hostname work equally well for karmic, I'm not sure it matters.
<infinity> persia: Eh?  ubuntu-ports.ubuntu.com doesn't exist. :P
<infinity> ports.ubuntu.com/ubuntu-ports sure does, though.
<persia> But it's after 29th April.
 * persia gets confused
<armelTest> ummm can i just echo "deb http://ports.ubuntu.com/ubuntu-ports/" > /etc/apt/sources.list
<persia> You could.
<persia> But that this works is an accident.
<infinity> Except that's wrong.
<armelTest> huh?
<armelTest> y?
<persia> You want "deb http://old-releases.ubuntu.com/ubuntu/ karmic main restricted universe multiverse"
<armelTest> ahhh
<infinity> echo "deb http://ports.ubuntu.com/ubuntu-ports karmic main" > /etc/apt/sources.list
<infinity> Oh, or old-releases, if karmic's been moved.  Right.
<persia> Except karmic will disappear from ports.ubuntu.com any day now
<infinity> I just meant "wrong" in that it was missing the dist and component(s). :)
<persia> It hasn't, but it's EOL, so there's no reason for it not to have moved.
<persia> Hence my earlier confusion.
<persia> armelTest, What is your hardware platform?
<armelTest> arm7
<infinity> Be a little more specific. ;)
<persia> Supports the ARMv7-A ISA?
<armelTest> htc incredible
<armelTest> android phone
<armelTest> brb
<armelTest> idk is there a way i could find out
<persia> Well, EOL for the incredible and EOL for karmic match, but given that platform, I'd want to run natty.
<armelTest> call me a dumb ass but what is natty?
<infinity> Ubuntu 11.04
<persia> armelTest, Find out what?  That you have a QSD8650?  I used wikipedia.
<infinity> I used htc.com, similar result. :P
<armelTest> yes that is it :-)
<infinity> And then I saw the word "Snapdragon" and died a little inside. ;)
<armelTest> lol
<persia> armelTest, So, karmic is EOL, and there's no support for it at all, plus it's slow and buggy.
<armelTest> bad exp with a snappy
<infinity> Nope, bad experiences with Qualcomm.  I'll recover some day.
<persia> From the command line, if you run `do-release-upgrade` you should get upgraded to something newer, shinier, and supported.
<infinity> persia: (Which would just be lucid, going from karmic)
<infinity> Though lucid runs fine on all my armel hardware here, with the possible exception of kernels.
<infinity> And I assume he's running an Android kernel.
<persia> infinity, Would it?  The do-release-upgrade manpage is kinda unspecific about precisely where you end up from older systems.
<infinity> Perhaps a bad assumption, but...
<armelTest> yeah cyanogen 2.6.37.6
<infinity> persia: Only LTSes provide the option to jump to another LTS, everything else will upgrade to the next release.
<infinity> persia: (In this case, his next release IS an LTS, but whatever)
<persia> That's a bug in the manpage then, because it says "upgrade to the latest release", rather than the "next newer release".
<armelTest> http://archive.ubuntu.com/ubuntu/dists/lucid/universe/binary-armel/Packages.gz404 Not Found [IP: 91.189.88.46 80], W:Failed to fetch
<infinity> Well, if you run it over and over again, you'll get to the latest! ;)
<infinity> But yeah, file a bug.
<armelTest> ahhhhh!!!!
<infinity> armelTest: No armel on archive.
<infinity> Oh.
<infinity> do-release-upgrade is confused.
<persia> Hrm?  I thought I fixed that all the way back to hardy!
<infinity> I bet it would be unconfused if your sources.list said ports.
<infinity> persia: Did you fix it for the old-releases case?
<infinity> (Since there's special-case code for s/old-releases/archive/)
<persia> infinity, I summarily rewrote deb lines in sources.list with what I thought was correct based on other conditions, excepting a whitelist (which didn't include old-releases)
<infinity> Whacky.
<persia> Aha, which special case might happen after my summary execution of random mirrors :(
<infinity> armelTest: echo "deb http://ports.ubuntu.com/ubuntu-ports karmic main restricted universe multiverse" > /etc/apt/sources.list && do-release-upgrade
<infinity> armelTest: 20 to 1 odds that doesn't trip the broken codepath. :)
<armelTest> ok brb
<armelTest> it may be working!!!
<infinity> Such excitement over a "maybe".  I like it. :)
<armelTest> nope
<armelTest> brb imma try something
<persia> infinity, Any idea where that special-case lives?  I don't see it in the update-manager or python-apt code, although I see lots of tests in update-manager to make sure it works.
<infinity> persia: I didn't write it, so not entirely sure, I just know it's there somewhere.
<infinity> persia: And might sometimes work.
<persia> I'm certain it's there, or the tests would very clearly fail.
<armelTest> root@localhost:/# do-release-upgradedo-release-upgradeChecking for a new ubuntu releaseDone Upgrade tool signatureDone Upgrade toolDone downloadingextracting 'lucid.tar.gz'authenticate 'lucid.tar.gz' against 'lucid.tar.gz.gpg'tar: Removing leading `/' from member namespcilib: Cannot open /proc/bus/pcilspci: Cannot find any working access method.Reading cacheChecking package managerPreparing the upgrade failedPreparing the system for 
<armelTest> blah
<persia> Heh.  Seems nobody ever tested do-release-upgrade from karmic.
<persia> And, yep, it's marked in LP so that we can't update it.
<persia> OK.  Next method.
<persia> Try "deb http://ports.ubuntu.com/ubuntu-ports/ lucid main restricted universe multiverse" as your sources.list
<persia> Then try `apt-get update && apt-get dist-upgrade`
<persia> This is more likely to break than do-release-upgrade, but also less prone to failures from the various bits trying to blunt the sharp edges.
<armelTest> i can do the apt-get dist-upgrade on a seperate line
<armelTest> i may run outta room
<persia> That works too :)
<armelTest> lol i only have an 8g sdcard and ummm its 82% full
<persia> Hrm.  That *might* work, but it might not.
<persia> The packages will be upgraded in place, so they shouldn't take up that much room.
<persia> That said, they all need to be downloaded first, so /var/cache/apt gets kinda full.
<persia> Running `apt-get clean` will remove any cached package files you have, which may improve things.
<armelTest> kewl i am learning so much!
<armelTest> this is awesome. the only reason i wanna do this is so i can develop android apps while driving down the road...
<infinity> I usually cheat and put /var/cache/apt on a NFS or SMB share when I'm upgrading devices with low space.
<armelTest> that is really smart
<persia> Android still doesn't have a self-hosted development environment?  Oh my.
<armelTest> it is upgrading!
<infinity> persia: It's not meant to.
<armelTest> well they have the ndk but i like using eclipse tho
<infinity> persia: Though, I imagine at some point it will anyway.
 * persia grumbles about silly people using embedded paradigms on perfectly reasonable general purpose computers
<armelTest> along with the jdk
<infinity> (Maybe that point is now, noting the mention of an ndk)
<armelTest> lol
<infinity> persia: And preaching to the choir on that one.  You have no idea how long I cursed Maemo failing at being perfectly self-hosting and for NO GOOD REASON, except that scratchbox broke it in subtle ways.
<armelTest> what sux is you have to use vncviewer to load x
<infinity> (Most things still built fine on Maemo itself, but sometimes things went pear-shaped due to SB breakage)
<persia> infinity, even the Maemo that shipped with the n810 was self-hosting, if you recompiled everything in a sane environment once: it just needed a bootstrap.
<infinity> persia: I think my N900 still has a Debian chroot with a full scratchbox environment IN THAT... Stop and think about that insanity for a second.
<infinity> persia: "Self-hosting, if you re-bootstrap" doesn't quite qualify. ;)
<persia> infinity, Consider a reinstall: http://wiki.ubuntu.com/ARM/N900
<armelTest> that is how linux runs on android chroot
<persia> Beats failing to self-host because of design decisions in my book.
<infinity> persia: That would be a better sell, if the URL worked.
<armelTest> through busybox
<infinity> Anyhow, off to dinner.
<persia> https://wiki.ubuntu.com/ARM/n900
<infinity> armelTest: Good luck with your fiddling.
<persia> armelTest, Oh, you don't run Ubuntu native?
<armelTest> no its chroot
<armelTest> i cant run native and still have my phone functionality
<armelTest> which sux
<persia> Lack or drivers?
<armelTest> idk never really looked in to it really brb
<persia> No worries.  There's only drivers for a few baseband chipsets, and not so many dialers.
<armelTest> https://wiki.ubuntu.com/Specs/AndroidExecutionEnvironment check this out
<persia> Yeah, that got squashed.  The mechanism by which it was supposed to work ended up being unmaintained by the Android folk.
<armelTest> see what you can make outta it. im just a simple programmer just spreading my wings into other platforms
<persia> NCommander and I should clean that up, and make it clear why it will/won't happen, but we keep putting it off because there is some good idea about how to do it which we don't get around to implementing.
<persia> As it turns out, lots of other people are trying to do similar things, which may mean that we can eventually implement it just by adding a couple upstream packages and filing some minor bugs.
<armelTest> xda has some good stuff on it but its greek to me right now
<armelTest> can i just manually delete the stuff from /var/cache/apt?
<persia> Better to use `apt-get clean`
<persia> Otherwise apt can get confused and complain.
<armelTest> oic
<persia> apt-get clean will delete everything safe to delete in there.
<armelTest> well ummm apt-get clean wont work because the dir is locked because its full
<persia> Right.
<persia> So, let's step back.  Since this is only a chroot, we aren't quite as afraid of bricking the device.
<persia> How did you construct the chroot?
<armelTest> nope aint afraid of bricking
<armelTest> hold on ill send you the script
<persia> !paste
<ubot2> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<armelTest> kewl
<armelTest> sorry son was trippin bout something
<armelTest> lol
<armelTest> http://paste.ubuntu.com/643036/
<persia> OK.  From where did you get /sdcard/ubuntu/ubuntu.img ?
<persia> I'm thinking it's probably easier to just replace that then try to upgrade, given the space.
<armelTest> from xda-developers.com
<armelTest> i could mount any image and chroot as long as i have the dirs right and the arc is arm
<persia> OK.
<armelTest> is that correct?
<persia> So, I won't recommend any image that isn't hosted by Ubuntu, because I can't trust that it's really Ubuntu
 * persia fails to say anything about http://forum.xda-developers.com/showthread.php?t=987740
<persia> So, there's a few ways you can get a mountable image file using Ubuntu.
<persia> 1) You can download one of the images, and then make it do what you want.
<persia> 2) You can run rootstock to generate a local image (for development only)
<persia> 3) You can run debootstrap yourself, and construct an image
<persia> I'd be happy to explain any of those if you like :)
<armelTest> intresting... i have heard of rootstock. i dont have another arm dev to make an image myself tho
<persia> Most folk run rootstock on an i386 or amd64 machine, but you will want to have Ubuntu installed there.
<armelTest> i do have an external 1tb
<armelTest> u suppose i could install it on that the live/persistant boot and make an image
<persia> Base images are usually less than 1GB.
<armelTest> i am about to free up some space on my sd card... got vids of my son i can move over
<persia> But they often need 2-3GB uncompressed space, so as long as you have more than 4G on that drive, you should be fine.
<persia> Heh, that might let the upgrade work :)
<armelTest> lol yeah if i didnt mess up this image by rm *.* in var/cache/apt
<persia> (and running `apt-get clean` post-upgrade will regain most of the space the upgrade needs)
<armelTest> only 1 way to find out... yeah the apt-clean didnt work
<armelTest> apt-get clean
<persia> Supposedly nothing in /var/cache is important.  That said, while I expect apt to be fairly robust, I've not tried that.
<persia> Does `apt-get update` work?
<armelTest> brb gonna restart my phone
<persia> You may need to repopulate apt's local cache of the available software sources before you can clean up.
<armelTest> shit this is gonna take a min
<armelTest> well my wife wants me to come be a husband... thanx for your help!!!
<rsalveti> janimo`: can you trigger a rebuild of wacomtablet? this will fix the ftbfs for it
<StevenK> rsalveti: Given back.
<rsalveti> StevenK: thanks
<rsalveti> StevenK: libtuxcap also need a rebuild
<rsalveti> crtmpserver too
<janimo`> rsalveti, given back, now that LP is writable again
<lilstevie> is there a way of configuring the lid open sensor information? I am inverted
<lilstevie> if I open the lid, it blanks the screen as per my powere management settings
<LPhas> i'm quite unable to read information in launcpad.net, but is this package https://launchpad.net/ubuntu-omap4-extras-multimedia supposed to be available to natty ?
<siji> Hi All
<siji> Anyone tried XBMC on ubuntu arm ?
<siji> hello
<siji> My rootstock build is returning errors like
<siji> I: Switching to Virtual Machine for second stage processing
<siji> Segmentation fault
<siji> W: Bad Bad Qemu, trying second stage one more time (LP #604872)
<ubot2> Launchpad bug 604872 in qemu-linaro "qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm" [Medium,Fix released] https://launchpad.net/bugs/604872
<siji> How to fix this
<siji> ogra_, any idea ?
<siji> friends ,my issue solved
<siji> added  qemu-arm-static
<mahmoh> my io tests are still runnning on both boards, now init's behaving but the threaded io is really impacting performance (terminal interaction is slow at best)
<mahmoh> cpu load is minimal, 4-30%, I guess that makes sense - I should check the scheduler though
<ogra_> note that we default to no-op on all our images
<janimo`> Preparation material for tomorrow's Ubuntu developer week, ARM FTBFS session. Feedback welcome :)  https://wiki.ubuntu.com/ARM/FTBFS
<mahmoh> well mine are set to cfg, oops, I need to check to see which kernel is getting loaded again
<mahmoh> but the server kernel should be deadline scheduler ogra_
<mahmoh> ^ right Daviey?
<ogra_> mahmoh, thats something the image build scripts should do, if they dont on your images, files a bug
<mahmoh> ack
<ogra_> for preinstalled we can be sure we are running on SD
<ogra_> for that no-op is the fastest
<ogra_> thats why we set it to no-op there by default, for server netinstall where you might install to rotary disks, the installer should select the scheduler based on the root device
<mahmoh> agreed but netinstall should install the correct kernel after tasksel and the server kernel should be deadline, which I need to verify
<mahmoh> so if I'm able to check - during - netinstall it'll
<mahmoh> change the scheduler?
<ogra_> i doubt there is code for that yet
<ogra_> talk to NCommander
<ogra_> iirc on the netinst images the flash-kernel-installer udeb creates the kernel cmdline, it should get code to detect the root device and add the proper elevator option to the cmdline
<mahmoh> makes sense, if it doesn't do that I'll file a bug
<mahmoh> thx
<amalgok> hello, I would like to know if I can find a Ubuntu for OMAP35x EVM
<amalgok> more exactly for AM3517
 * ogra_ isnt sure we have a kernel supporting that, but userspace will definitely be fine 
<amalgok> oh ogra, I've seen that you have built a Ubuntu for OMAP35x EVM
<amalgok> but the link is dead
<ogra_> that was loooong ago
<amalgok> haha okay
<ogra_> you should be able to just use the omap3 images but replace the uImage with yours
<ogra_> (and MLO/U-boot.bin)
<amalgok> yeah I have my uImage
<ogra_> see wiki.ubuntu.com/ARM/OMAP
<amalgok> also mlo and u-boot and x-loader
<amalgok> but do you know how to create the SD card for an update of the system?
<ogra_> ??
<amalgok> I've followed this
<amalgok> http://processors.wiki.ti.com/index.php/MMC_Boot_Format
<ogra_> ah, no, just create the SD like described on the ubuntu wikiw
<amalgok> but I don't understant how to place my kernel and filesystem into the nand flash then (update)
<amalgok> ah okay
<ogra_> then replace MLO, u-boot.bin and uImage on the first partition of the SD
<amalgok> oh okay
<ogra_> the EVM only has 128M, right ?
<ogra_> you will most likely want the headless image with that
<amalgok> 256
<ogra_> yeah, still to low for an ubuntu desktop
<amalgok> yeah I was thinking about :)
<amalgok> hum
<ogra_> unity.-2d with idling desktop eats 148M here
<amalgok> okay
<ogra_> gnome and xubuntu will be similar
<ogra_> KDE will use even more
<ogra_> lubuntu could work
<amalgok> maybe Matchbox
<amalgok> but don't know if Ubuntu support that
<ogra_> its in the archive
<ogra_> in universe
<amalgok> I can't find a version of ubuntu without X11
<ogra_> the headless image is what yxou want, just follow the wiki
<amalgok> okay I'm trying
<rsalveti> janimo`: thanks
<rsalveti> LPhas: not yet, TI didn't release all multimedia components still
<rsalveti> I know robclark is working on trying to get it all working, so soon we should have something :-)
<rsalveti> once we get it integrated with gst and such, then normal applications will be able to decode using hw acceleration
<robclark> rsalveti, display is in bad shape on 2.6.38..  I'm actually starting to work on 3.0..
<rsalveti> robclark: and how it's going with 3.0?
<rsalveti> so we'll end up skipping natty, but luckly it'll work for oneiric :-)
<rsalveti> and if we get sound working out-of-box it'd be a huge step forward ;-)
<robclark> I had some issues w/ i2c initially, making DVI not work.. but I seem to have that working now
<robclark> HDMI is a bit flakey... at least when you have kernel w/ PM enabled..
<rsalveti> robclark: hm, interesting
<rsalveti> robclark: are you also porting the drm driver?
<robclark> yes, of course ;-)
<rsalveti> awesome :-)
<rsalveti> robclark: and where are you publishing your work this time?
<rsalveti> robclark: would be nice to integrate at the linaro tree once you think it's good enough
<robclark> rsalveti, well, I'm trying to get display team to push the DSS patches.. and then once those are upstream I can push the drm driver
<robclark> well.. soon it will have a TILER dependency too (for GEM), but I'll try and keep that separate..
<rsalveti> robclark: cool, even better :-)
<brendand> is oneiric working with the pandaboard yet anyone?
<ogra_> sure
<GrueMaster> brendand: Alpha 2 server images work well, desktop is hit or miss (due to SD card variants).  Current netinstall works as well.
<GrueMaster> rsalveti: It looks like u-boot is generating two different mac addresses currently.  00:02:03:04:05:06 for bootp and then it looks for panda/pxelinux.cfg/C0A80045 for the pxe config.  pxe should be looking for the file with the mac address.
<GrueMaster> It may be doing a reciprical of the mac.  Haven't checked.
<rsalveti> GrueMaster: how it's getting to C0A80045?
<rsalveti> probably
<rsalveti> that's why this will be probably fixed once jcrigby fixes the mac address at u-boot level
<GrueMaster> ok
<GrueMaster> Grrr.  Local mirror isn't syncing with ports.u.c properly.  Can't do netinstall with local mirror.
<rcn-ee_at_work> GrueMaster, i've had good luck with apt-cacher-ng ....
 * ogra_ is approx fan
<GrueMaster> I'm using a combo of apt-mirror & ubumirror since karmic.  Worked quite well until Tuesday.
<ogra_> ah, its the tuesday bug
<GrueMaster> Fill me in.
<ogra_> a bug that shows up on tuesdays :)
<GrueMaster> This is not Windows!
 * ogra_ was just kidding ... no bug to point to 
<ogra_> heh
<ogra_> we had one where printing didnt work on tuesdays
<ogra_> its not impossible :)
<GrueMaster> I heard that there was an issue with debootstrap earlier this week.
<ogra_> well, with udev and the new /run directory i think
<ogra_> but yeah, it breaks debootstrap
<GrueMaster> I'm having to reinstall one system.  Somehow the partitions did a role reversal.  1G rootfs, 156G swap.  oops.
<GrueMaster> Doing a netinstall from ports.u.c works.  So I need to figure out what isn't getting mirrored.
<GrueMaster> apt-mirror only copies debs & source, ubumirror is setup with a large list of excludes to skip old releases & arches I don't care about.  Somewhere in there something is getting lost in translation.
<ogra_> https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28
<ubot2> Ubuntu bug 255161 in cupsys "I am unable to print from open office, I tried reinstalling open office but it did not work. I use a brother mfc240c printer and I am running Hardy. Printing from other apps has not been an issue. (dup-of: 248619)" [Undecided,Invalid]
<ogra_> btw :)
<ubot2> Ubuntu bug 248619 in file "file incorrectly labeled as Erlang JAM file" [High,Fix released]
<robclark> rsalveti, pvr Xorg driver is up and running on 3.0..  i2c still hitting "timeout waiting for bus ready" a lot, which is a bit inconvenient..
<rsalveti> robclark: cool, great progress
<jeremiah> pmcgowan: ping
<persia> jeremiah, He doesn't seem to be around just now.  Is there a general question with which we can help?
<ogra_> persia, linux-ac100 is in NEW fyi
<sgnb> it looks like all ocaml stuff started segfaulting recently on Ubuntu's armel... (whereas everything works fine in Debian)
<persia> sgnb, Do you have a trace (or a bug with a trace)?
<sgnb> persia: no, but have a look at https://launchpadlibrarian.net/75113357/buildlog_ubuntu-oneiric-armel.lwt_2.3.0-3_FAILEDTOBUILD.txt.gz
<sgnb> (I don't have an Ubuntu armel box at hand)
<persia> sgnb, Hrm.  Indeed, that looks unpleasant.
<sgnb> (same for postgresql-ocaml, ocaml-sqlite3, oasis...)
<persia> Yeah, with that level, of segfaulting, I'd expect it for everything.
<persia> Even works for Debian armhf, so unlikely to be an ISA issue.
<persia> ( http://buildd.debian-ports.org/status/fetch.php?pkg=postgresql-ocaml&arch=armhf&ver=1.16.0-1&stamp=1309697444 by example)
<ogra_> bah, sigh, how many more languages are there
 * ogra_ waits for apachelogger's spam on -changes to stop :P
<persia> I seem to recall that the answer was somewhere above 370 last time I tried to answer that question.  That was a few years ago, so the number can only have increased.
<sgnb> persia: but armhf is not native in Debian
<persia> sgnb, Hrm?  Does that affect how the buildd works?
<sgnb> persia: I mean, ocaml doesn't generate native code for armhf (whereas it does for armel)
<persia> ogra_, also, thanks for the wiki edit: I now have a happy glow.
<sgnb> so the generic bytecode compiler/interpreter is used there
<persia> sgnb, What sort of code does ocaml generate for armhf?  Why isn't it native?
<ogra_> persia, heh, welcome, lets just hope an archive admin is bored enough to review the kernel now
<sgnb> it generates a portable bytecode, with run with an interpreter written in C
<persia> Without the ability to debootstrap, I'm unsure how much I care about the timing there.
<apachelogger> lol
 * ogra_ will land the flash-kernel bits and -meta tomorrow 
<apachelogger> ogra_: couple more two come
<persia> sgnb, Do you happen to know why it isn't native for armhf?
<apachelogger> <50 ^^
 * ogra_ hugs apachelogger :)
<sgnb> persia: because it hasn't been activated
 * apachelogger hugs ogra_ right back
<sgnb> (so never tried)
<persia> sgnb, Hrm.  Then it *could* be an ISA issue :(
<sgnb> native code generated by ocaml compiler on arm always uses soft floats... would that be a problem?
<persia> No, Ubuntu armel uses a softfloat ABI, but it's ARMv7 vs. ARMv4t for Debian armel, which means that some assembly isn't compatible.
<ogra_> but that would have been a prob since lucid
<persia> Ubuntu armel is also compiled to thumb2 by default, rather than ARM, which has other knock-on effects in terms of allowable ISA and ABI interactions.
<persia> ogra_, Depends what instructions are being excited.  A new upstream version might have some improved optimisation, or changes to call semantics that could trigger something.  Needs investigation.
 * ogra_ blames toolchain or libc 
<ogra_> note that the old ocaml segfaults here
<ogra_> while building new ocaml stuff
<sgnb> "old"? "here"?
<ogra_> in the build log you linked
<persia> That's for lwt.
<ogra_> it calls /usr/bin/ocamlfoo
<ogra_> which segfaults durign execution
<persia> Sure, but I'm not sure why that is necessarily "old".
<ogra_> its not a new upstream, it is what is in the archive right now
<persia> Do you happen to know that no new upstream for ocaml-nox has entered the archive in oneiric?
<ogra_> no, i dont, do you happen to know it did ?
<ogra_> ;)
<persia> I do.  oneiric has 3.12.0, whereas natty only had 3.11.2
<sgnb> but stuff has been already compiled successfully with 3.12.0 in oneiric in the past
<persia> That's extra annoying.
<persia> Because it means that some library changed ABI without updating SONAME underneath ocaml.
<persia> sgnb, Do you happen to know the *first* package that FTBFS due to ocaml segfaulting wildly?
<sgnb> I think it is oasis
<sgnb> (according to http://people.canonical.com/~ubuntu-archive/transitions/ocaml.html )
<persia> ogra_, Do you know of any way to find stuff that built on 29th June?
<ogra_> not really, apart from checking -changes
<persia> That's sources, not binaries.
<persia> And 29th June was pre-DIF, so all the autosync stuff is invisible to -changes
<persia> sgnb, I really don't expect you to have an answer, but do you happen to know the last package that worked?
<sgnb> persia: my guess would be nurpawiki
<sgnb> or ocaml-data-notation, maybe
<sgnb> (based on what happend in Debian)
 * persia goes to investigate that, with hope, wondering how one could possible find this
<persia> Ah, yeah, given the essentially random timing of autosync, I have no idea how reliable that might be (autosync is a manual process, which happens whenever an archive admin has ~10 minutes to kick it off, but not less than twice a week)
<persia> nurpawiki build 2011-05-20
<persia> ocaml-data-notation failed 2011-06-28 with mp segfaults (unlreated failure).
<persia> 2011-06-28 to 2011-06-29 is close enough I'll dig through the versions of build-depends, hoping to find a useful discrepancy
<persia> libmpfr4 3.0.1-3 -> 3.0.1-4
<persia> libudev 171-0ubuntu3 -> 171-0ubuntu4
<persia> apt 0.8.14.1ubuntu7 -> 0.8.15ubuntu1
<persia> udev matching libudev
<persia> apt-transport-https matching apt
<persia> mprf4 looks like a no-op failed attempt to clean up how patches are applied in a format: 3.0 (quilt) package.
<ogra_> and the others dont look like they could make binaries segfault
<ogra_> (that worked before)
<persia> udev is a cleanup on stopping udevd processes, which shouldn't even be used in a buildd chroot.
<persia> No, but if I don't investigate, I'm not going to be confident :)
<ogra_> i think its some transient issue from something completely ocaml unrelated
<ogra_> i would have said libc but that doesnt match the timing
<persia> I'm not convinced it's transient, as it has persisted for two weeks.
<persia> Still, checking build-essential happens first, then specific build-depends (in part because I have to clean up my script to generate readable diffs for build-deps)
<ogra_> binutils was upgraded on the 18th ... doesnt fit either
<sgnb> the first segfaulting command is "/usr/bin/ocamlfind query -format %v findlib"... maybe it's easier to test it in past snapshots? (Ã  la git-bisect)
<persia> apt change is large, but I can't see anything that should affect other binaries at runtime.
<sgnb> oh! but ocamlfind itself changed meanwhile
<sgnb> (1.2.6 -> 1.2.7)
<persia> Indeed.  1.2.7+debian-1 failed, but 1.2.6+debian-1build1 succeeded.
<ogra_> aha, i though it didnt
<sgnb> I cannot imagine how this could have an influence, though
<persia> Maybe there was a misbuild.
<sgnb> "misbuild"?
<persia> Could "Make Camlp4 depend on Dynlink on every arch" affect the autodependency generators?
<ogra_>     - add armel to native architectures; note that the Dynlink module is
<ogra_>       not available in native code there: software using it should take care
<ogra_>       of this new possibility
<persia> Aha!  That would be the issue then.
<ogra_> from the ocaml changelog
<sgnb> this was way before
<ogra_> not sure thats the issue but it could
<persia> Debian bug #630490
<ubot2> Debian bug 630490 in libfindlib-ocaml "camlp4 depends on Dynlink on all architectures" [Important,Fixed] http://bugs.debian.org/630490
<ogra_> debian bug #347270
<ubot2> Debian bug 347270 in ocaml "ocamlopt produces buggy arm programs" [Important,Fixed] http://bugs.debian.org/347270
<ogra_> oh, another intresting entry
<ogra_> add binutils-dev to Buid-Depends
<persia> That's *OLD*
<sgnb> yes, way before nurpawiki
<persia> Oh, but not Fixed old :)
<persia> But yeah, ocaml isn't the issue.
<persia> Both the working and failed builds use ocaml 3.12.0-7
<ogra_> thats what came into ubuntu on may 5th
<ogra_> afterwards the ocaml transition started
<persia> Don't care.  It's not different between oasis and ocaml-data-notation builds, so it is unlikely to be the cause of one failing and the other succeeding.
<sgnb> the ocaml transition finished before stuff started segfaulting
<ogra_> yes
<sgnb> (it finished with nurpawiki)
<persia> Well, ocaml-data-notation was built in Ubuntu over a month after nurpawiki, but kinda :)
<sgnb> it was not part of the "ocaml 3.12.0 transition"
<persia> Ah.
<sgnb> by "ocaml 3.12.0 transition", I mean "recompile everything because ABI changed"
<persia> Right.
<sgnb> after that, we continued updating things in Debian as usual
<persia> Still, I'm suspecting findlib for now.
<persia> But I don't see anything in the patch that is especially exciting.
<persia> https://launchpadlibrarian.net/74281241/findlib_1.2.6+debian-1build1_1.2.7+debian-1.diff.gz
<sgnb> the changes also look innocuous to me
<sgnb> it might be that the generated assembly for the new version is somehow bugguy
<persia> There's a number of "failed to remove" and "cannot stat" messages in the build log.
<sgnb> OCaml code shouldn't segfault by itself
<persia> Shouldn't or can't?  It is native-compiled, right?
<sgnb> I don't see the difference
<sgnb> it is impossible in pure OCaml to do a segfault, it's a property of the language
<sgnb> and ocamlfind looks like pure OCaml
<sgnb> (I mean, except basic I/O)
<sgnb> segfaults in ocaml programs usually comes from C code called from OCaml code
<persia> That'd be can't :)
<persia> Lesser languages aren't defined in a way that prevents such behaviours.
<persia> But some *shouldn't*, because of how they work, for example python or java.
<persia> Whereas something like C has neither sort of protection, and segfaults reliably.
<persia> Aha!  So, the new findlib build is whining about not being able to parse ${ocaml:Depends}.
<sgnb> persia: you mean dpkg-gencontrol?
<persia> Yes
<sgnb> it doesn't matter
<sgnb> it is a common warning
<sgnb> and only related to build tools
<sgnb> (I mean dpkg-dev)
<persia> I thought that warning happened whenever one didn't handle the substr stuff properly.
<sgnb> it happens when the variable is not defined
<persia> But the package relationships are very similar between 1.2.6+debian-1build1 and 1.2.7+debian-1 : the latter adds a recommendation on libfindlib-ocaml-dev
<sgnb> it does that even for shlib:Depends
<persia> I'm of the opinion that one should only use variables in control that one defines, but I'm known for being kinda particular about things :)
<sgnb> maybe, but that's not the point here
<sgnb> if I had access to a faulty box, I would start running gdb on "ocamlfind query -format %v findlib" to see where exactly the segfault occurs
<persia> Unfortunately, it seems findlib doesn't have a test suite that runs at build-time, so we can't know that the build worked (or didn't).
 * persia tries to run debootstrap again, in vain hope, given the continued discussion in #ubuntu-devel
<persia> ogra_, In unrelated news, did you see my 0.0.0.0.0.0.0.0.1 package?  Any suggestions to improve the README or change the package split?
<ogra_> well, i would at least add another 0 to the version
<ogra_> i saw your ping in the other channel, but havent looked yet
<persia> Please don't.  I tried to add enough that when upstream (you) decides to actually release code, there would be no change of conflict.
<persia> s/change/chance/
<ogra_> wsell, i would just take yours :)
<ogra_> the code surely needs cleanup, i didnt write it with a generic installer in mind
<persia> Considering that the README isn't complete and talks about killing kittens, that -tools is missing one of the scripts, and all the other issues, I'd hope not directly.
<ogra_> and i cant imagine many ways to package it
<ogra_> you split it ?
<ogra_> what did you split into tools ?
<persia> Surely.
<ogra_> it should eb a single package with three initrd files
<persia> There's the stuff that belongs in the image, and the stuff that belongs on the machine used to create the image.
<persia> Go look.
<ogra_> one in conf.d one in hooks and one ins scripts
<persia> I think I have four scripts.
<persia> Maybe five.
<ogra_> the one additional script isnt for the public ... it will be worked into debian-cd
<persia> debian-cd is public :)
<ogra_> (the one that adds the md5sum file)
<ogra_> well, i meant as extra code
<persia> But yeah, if you're sticking the control code into debian-cd, then -tools isn't useful.
<ogra_> sure it should be public
<persia> Oh well.  libc6 still doesn't install in the chroot :(
<ogra_> build natty and upgrade ;)
<persia> Hrm.  I wonder if my wrapper scripts can handle that.
<persia> Maybe I'll just do a one-off upgrade of natty to test this one thing.
 * persia grumbles at dpkg: error: failed to open '/var/lib/dpkg/status' for writing status database: Invalid argument on a natty->natty upgrade
<persia> sgnb, I get an immediate segfault return from `ocamlfind query -format %v findlib` on current oneiric/armel
<persia> Any hints on what to check, or do you recommend digging through core?
<sgnb> persia: run through gdb, and pinpoint where the segfault comes from
<sgnb> (is it C code? is it assembler? is it a library?)
#ubuntu-arm 2011-07-14
<persia> Wow!  This is the most useless stacktrace I've seen in a while.
<persia> No pointers to where the segfault is happening.
<persia> And cyclical from frame #1, with gdb reporting a corrupt stack.
<sgnb> hum...
<sgnb> so probably in ocaml land
<persia> I'm happy to be a robot, but I don't have any idea how to begin to debug this without instructions.
<sgnb> well... you do have access to the surrounding assembly code, don't you? I would try to find the closest symbol or so
<persia> I'll need guidance for that.  I'm good at reading stacktraces, but don't really use GDB as such, beyond as a stacktrace generator.
<sgnb> I usually use the disassemble command
<sgnb> I should probably do that myself... is there a quick guide to set up an Ubuntu armel box in qemu?
<persia> Do you need full system emulation, or just userspace emulation?
<sgnb> I don't know... sothing enough to reproduce the problem
<persia> If the latter, `mk-sbuild --arch=armel --distro=ubuntu oneiric` should do it, from a Debian system
<persia> If the former, you'll need more setup, and I'd have to hunt up a guide.
<sgnb> W: Failure trying to run:  dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-9ubuntu2_armel.deb
<persia> Oh, right.  debootstrap is broken (/run)
<persia> `sudo rm -rf /var/lib/schroot/chroots/oneiric-armel`
<persia> Then `mk-sbuild --arch=armel --distro=ubuntu natty`
<persia> Then `sudo schroot -c natty-armel -uroot`
<persia> Then edit sources.list, and dist-upgrade.
<sgnb> avoiding libc6?
<persia> It doesn't actually avoid libc6
<persia> It just avoids the situation that makes libc6 fail to install with debootstrap for oneiric
<persia> Alternately, if you want persistence, edit /var/lib/schroot/chroots/natty-amd64/etc/apt/sources.list, and then enter the natty-armel-source chroot.
<sgnb> ok, I can reproduce the segfault
<sgnb> actually, a mere "ocamlfind" segfaults
<sgnb> but I get in gbd: qemu: Unsupported syscall: 26
<persia> That's fine.
<persia> We haven't been grilling qemu-user agressively recently, but I believe that support was added for all the syscalls need to build all the packages in the archive.
<persia> Which would include anything necessary to run ocamlfind properly.
<sgnb> 26 is ptrace
<persia> Mind you, that isn't how we build stuff, but the work was done to enable just the sort of debugging you're doing now.
<persia> Ah, hrm.  Maybe running gdb in that environment isn't so reliable :(
<persia> Well, I suppose you could try https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap
<persia> I've been reminded that there's a buildd chroot available from https://launchpad.net/api/devel/ubuntu/oneiric/armel/chroot_url if you like.
<persia> (or rather, from the URI given at that URL)
<sgnb> persia: actually, an empty program segfaults
<persia> Empty ocaml program?
<persia> Then I'm confused.
<sgnb> yes
<persia> Because ocaml didn't change between when it was working and when it wasn't working.
<sgnb> create an empty file "toto.ml"
<sgnb> run "ocamlopt toto.ml", then ./a.out
<sgnb> it segfaults
<persia> File "toto.ml", line 1, characters 0-1:\nError: I/O error: /tmp/camlasm637f94.s: Invalid argument
<sgnb> persia: with empty toto.ml?
<sgnb> for me, it compiles
<persia> That's the output from `touch toto.ml; ocamlopt toto.ml`
<sgnb> so it means that you cannot even compile anything
<persia> apparently.
<persia> I got here by dist-upgrading my natty buildd chroot, and installing ocamlfind.
<persia> Maybe I need to install something else?
<sgnb> that's what I did
<sgnb> something must have changed somewhere else
<persia> Between when I did what I did and when you did what you did?  There was only a short window.
<persia> And not much has been added to the archive, as folk are trying to fix the /run issue (publishing and buildds are expected to stop being manual any time now)
<sgnb> no, I meant between 2011-05-20 and 2011-06-28
<sgnb> (when ocaml stuff started segfaulting)
<sgnb> it must be something very fundamental in the toolchain
<persia> Well, we had a successful run on 2011-06-28 ( ocaml-data-notation ), and the failure on 2011-06-29 (oasis)
<persia> There is no difference in the versions of everything in a buildd chroot there.
<persia> Some differences in the build-depends, but nothing that I'd call "fundamental toolchain".
<persia> (as that would be Priority: required or build-essential, or in the complete dependency/recommendation tree of those)
<persia> It was just mpfr4, udev, and apt that differed in the base set.
<sgnb> it's getting late here
 * sgnb goes to bed
<persia> Sleep well.
 * persia updates the buildlog parsing scripts, and looks for differences in build-dependencies
<persia> Hrm.  ocaml-findlib is the only package with a different version.
<persia> Mind you, there are other packages that are present/absent in one or the other build based on differing build-dependencies, but those shouldn't matter for parallel runs of ocamlfind
<sgnb> well, one should find an oneiric snapshot of 2011-06-28, and try to compile and run a program there
<persia> Dunno if such a thing exists.
<persia> Does anyone happen to have an un-updated chroot including ocaml stuff from June?
<sgnb> persia: binutils is faulty
<sgnb> with the version from natty, the empty program works
<Martyn> hmm?
<sgnb> persia: was binutils the same between the two builds above?
<sgnb> Martyn: an empty .ml file compiled with ocamlopt segfaults on armel
<sgnb> (since ~end of June)
<persia> sgnb, Yes
<persia> http://paste.ubuntu.com/643682/
<sgnb> well, the upgrade from 2.21.0.20110327-2ubuntu2 to 2.21.52.20110707-1ubuntu1 did trigger the bug here
<persia> Ah, maybe we have more than one bug.
<persia> Both of those builds were running binutils 2.21.52.20110606-1ubuntu1
<sgnb> maybe one of them doesn't run native program at all
<sgnb> indeed, it seems that ocaml-data-notation doesn't run ocamlfind
<sgnb> ah no, it does
<sgnb> strange
<persia> I think that pair of builds is likely the closest in time we'll find between working and not working.
<persia> Everything from oasis on seems to have the same issue.
<sgnb> well: take a natty chroot, install ocaml-nox, upgrade everything but binutils and gcc, it works, upgrade binutils, and it doesn't
<persia> And this makes me suspect that findlib misbuilt
<persia> Very odd.
<sgnb> I don't think findlib is involved
<persia> BTW, oneiric can debootstrap again
<persia> What happens if you install https://launchpad.net/ubuntu/oneiric/+source/binutils/2.21.52.20110606-1ubuntu1 ?
 * sgnb really goes to bed now
<persia> heh
<armelTest> anyone know of a tool to edit the size of a disk image without messing up the data inside?
<persia> Doesn't exist, but there are tools that achieve most of the things that people want to do when they want to do that.
<persia> So, what do you want to do?
<armelTest> well i have the same img i was working with yesterday... the img size is only 2G i wanna make it 3
<persia> OK.  If I remember correctly, that was a raw filesystem on an image, with no internal partitions or anything.
<armelTest> right
 * persia grumbles at dd not behaving quite as expected.
<persia> Aha!
<persia> OK, try `dd if=/dev/zero of=my.img bs=1G count=3 && mkfs.ext4 -f my.img && mount -o loop my.img /mnt/new`
<armelTest> ok kewl imma try one more thing b4 i do that
<armelTest> thanx again
<persia> Heh, OK :)  Note that this creates a 3G image.
<persia> Then you have to copy stuff.
<persia> tar is probably easiest for that.
<lintux> 04 or 11.10 work with the arm archictecture here's the link for the dreamplug: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx
<lintux> oops
<lintux> i just purchased  dreamplug while it has ubuntu downloads my question is will 11.04 or 11.10 work with the arm archictecture here's the link for the dreamplug: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx
<lintux> my fault marvell kirkwood cpu
<lintux> anybody here?
<persia> lintux, Hey.  Ubuntu won't run on that device (although Marvell ships it with their own remix of Ubuntu)
<persia> http://dreamplug.googlecode.com/files/Dreamplug%20-%20Change%20OS%20from%20%20Debian%20to%20Ubuntu-20110615.1.pdf has instructions
<persia> Hrm.  Timing :(
<lilstevie> persia: bad timing there
<persia> Indeed.
<siji> Hi
<siji> Whether any netinstall option is avilable for ubuntu-arm
<siji> I mean atleast for building RootFs
<siji> janimo`, you there
<janimo`> siji, yes
<siji> hi
<siji> I gone through your doc
<siji> regd.devlopers meet
<siji> janimo`, here am working with Beagleboard and ubuntu-arm
<siji> And looking for a small ubuntu footprint version
<siji> (with minimal things)
<siji> So I think netinstall for arm will be good option
<janimo`> siji, I have never used netinstall so cannot comment on this :)
<siji> ok,now netinstall is not there for ARM
<siji> So why cant you add it in the developers agenda ?
<janimo`> siji, the session is about package build failures and aimed for those who want to help fix them. It is not about installing Ubuntu on ARM hw
<siji> janimo`, ok
<persia> siji, If you're looking for stable, small-footprint, check out the "headless" images.
<siji> persia, ok
<persia> http://cdimage.ubuntu.com/releases/natty/release/
<persia> For the beagleboard, you want the "OMAP3" image.
<siji> persia, i have tried those
<persia> The headless one?  It wasn't small enough for you?
<persia> Netinstall is only available for oneiric (in-development), at http://ports.ubuntu.com/dists/oneiric/main/installer-armel/current/images/omap/netboot/
<persia> But it may or may not work, depending on the current state of the archive.
<siji> persia, ok
<siji> let me try that
<persia> Thanks for helping test :)
<siji> persia, actually am in the process of deciding OS for one of our Device
<persia> siji, What sort of device?
<siji> An ubuntu based tablet
<siji> *without android :)
<persia> Oh, cool!  That sounds kind of exciting.
<siji> and i strongly prefer ubuntu
<persia> Cool!
<sgnb> persia: same pb, but it works with the one just before (2.21.51.20110421-6ubuntu1)
<sgnb> persia: reported it at https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/810402
<ubot2> Ubuntu bug 810402 in binutils "all native ocaml programs segfault on armel" [Undecided,New]
<siji> persia, my protorype is running with 11.04 now
<siji> Now try to enable touch screen
<siji> 8trying
<siji> *trying
<LPhas> hello, installing ubuntu-omap4-extras from trunk on ubuntu10.10 i get this error Error! Bad return status for module build on kernel: 2.6.35-903-omap4 (armel)
<LPhas> Consult the make.log in the build directory
<LPhas> /var/lib/dkms/pvr-omap4-kernel/1.7~git0f0b25f/build/ for more information.
<LPhas> Traceback (most recent call last):
<LPhas>   File "/usr/share/apport/package-hooks/dkms.py", line 57, in <module>
<LPhas>     report.write(open(apport.fileutils.make_report_path(report), 'w'))
<rsalveti> mahmoh: GrueMaster: next u-boot upload should have the unique mac address fixed on panda
<rsalveti> thanks to jcrigby
<rsalveti> still building
<GrueMaster> Yes, I saw the email.  Thanks.
<mahmoh> awesome!
 * mahmoh now has to convince jcrigby to make pxe a default (and /me needs to also investigate a boot failure by the likes of "test" with that setup)
<damian0815> hey folks.. i just got wlan working on my pandaboard, got a quick q about wpa_supplicant binary vs functions.sh versions...
<damian0815> basically /etc/wpa_supplicant/functions.sh includes a "-s" parameter when starting the wpa_supplicant daemon
<damian0815> but this isn't supported by the wpa_supplicant that comes with ubuntu natty
<damian0815> is this a bug? something wrong on my end?
<ogra_> NCommander, oh, in case you didnt notice, persia provided a patch for netboot that now also publishes the MLO and u-boot.bin files ... so we have publically available unpacked binaries for both
<ogra_> lool, so i'm just looking into adding the postinst/trigger bits to flash-kernel, whats the reason you focus on the ABI only in your original patch, shouldnt just the latest existing initrd suffice to get the version without splitting out the ABI
<GrueMaster> Still need to post non-uImage versions of the kernel & initrd (or create an abootimg netboot.img) for usbboot.
<ogra_> GrueMaster, meh, you should have said that when persia wrote the patch ... its just two more lines to the two he added :)
<GrueMaster> I noted it back at the rally.
<ogra_> bug ?
<GrueMaster> NCommander was working on the d-i at the time.
<ogra_> ah
<GrueMaster> No one told me persia was working on it.
<ogra_> he fixed the other issue a few days ago
<ogra_> spontaneous as response to a user request
<ogra_> but it was discussed largely in here, probably at a time where you were asleep though
<ogra_> bug #808810
<ubot2> Launchpad bug 808810 in debian-installer "Please publish MLO and u-boot.bin on download page for OMAP netinst" [Wishlist,Fix released] https://launchpad.net/bugs/808810
<GrueMaster> I'm guessing that the u-boot that is there is already out of date, given the fix for die-id based mac in pxe.
<ogra_> well, there was an upload today iirc
<ogra_>     - Generated unique usbethaddr (LP: #809015)
<ogra_> i guess thats the one
<GrueMaster> yep
<ogra_> so next d-i rebuild then
<LPhas> GrueMaster, any hint about this? http://dpaste.com/568564/
 * GrueMaster looks
<GrueMaster> I haven't seen that before, but I haven't looked at maverick in quite a while.
<LPhas> http://dpaste.com/568555/ this is the make.log
<GrueMaster> It looks almost like the maverick ppa got clobbered by the natty ppa release.
<LPhas> robclarck (from ti) sent me here saying
<LPhas> <robclark> hmm.. you might want to ask on #ubuntu-arm ...  I think there was some PM related API that changed in the kernel..  so when it upgrades the kernel, it tried to rebuild the old pvr kernel module, which failed..
<LPhas> <robclark> I don't remember how to get around that.. I think perhaps remove the sgx packages, then update, then re-install them
<LPhas> but makes no sense to me
<GrueMaster> I'll see if I can reproduce.  May take a while though.
<LPhas> understandable
<robclark> <LPhas> Linux panda 2.6.35-903-omap4 #22-Ubuntu SMP PREEMPT Mon Mar 28 17:25:09 UTC 2011 armv7l GNU/Linux
<robclark> that is not the trunk update..  which should be 2.6.35-980
<ogra_> but the trunk driver ?
<LPhas> mmmh
<LPhas> so
<LPhas> you are saying that i'm not using the up-to-date kernel
<ogra_> you are using the release kernel
<LPhas> that's strange
<robclark> yeah.. so I guess you end up w/ release kernel, but trunk userspace syslink libs and trunk firmware
<ogra_> but not the release PPA for pvr
<LPhas> ok, in which package i have te kernel?
<robclark> I seem to remember you need to uninstall pvr/sgx stuff to update.. otherwise the upgrade gets blocked by dkms compile error
<ogra_> linx-omap4 should be the metapackage pulling in everything
<ogra_> oh, that might be, could be that dkms is blocking
<LPhas> uhm uhm
<LPhas> dpkg drives me mad
<robclark> it is a bit ugly, but if you uninstall sgx/pvr stuff first, then upgrade, then re-install
<GrueMaster> It may not have updated the boot partition.  We have a bug filed about that.
<LPhas> i've already tryied to uninstall sgx/pvr
<robclark> It isn't really dpkg's fault..
<LPhas> and upgrade
<GrueMaster> Run "sudo flash-kernel" and it should update properly.
<LPhas> as you said
<ogra_> GrueMaster, indeed !
<robclark> problem is kernel API that changed, so old pvr kernel module won't compile w/ new kernel headers and visa versa :-(
<ogra_> why didnt i have that idea !
<LPhas> but no newer package were pulled
<LPhas> also, i tryied to run flash-kernel
 * ogra_ is hacking on exactly that code atm  :)
<LPhas> phas@panda:~$ aptitude show linux-omap4
<LPhas> Package: linux-omap4
<LPhas> ...
<LPhas> Version: 2.6.35.903.6
<ogra_> ugh, aptotude
<LPhas> what's wrong with aptitude?
<ogra_> thats just the meta
<ogra_> check for the linux-image package
<LPhas> Version: 2.6.35.903.6
<LPhas> (aptitude show linux-image-omap4 ...0
<GrueMaster> LPhas: Make sure you have maverick-updates in /etc/apt/sources.list
<GrueMaster> iirc, that was also an issue with maverick.
<LPhas> GrueMaster, yep, they seems to be there
<ogra_> dpkg -l|grep linux-image
<ogra_> try that
<LPhas> phas@panda:~$ dpkg -l | grep linux-image
<LPhas> ii  linux-image-2.6.35-903-omap4                  2.6.35-903.22                                     Linux kernel image for version 2.6.35 on TI OMAP4-based systems
<LPhas> ii  linux-image-omap4                             2.6.35.903.6                                      Linux kernel image for the OMAP4 architecture.
<ogra_> k, only 903
<LPhas> http://dpaste.com/568569/ sources.list
<ogra_> hmm, how did you add the PPA
<ogra_> that looks like manually hacked in, usually ppas end up in sources.list.d
<LPhas> yep, i put them in manually
<ogra_> (if you use the right tools)
<ogra_> well, better follow the instructions next time :)
<ogra_> wont do harm though
<ogra_> its intresting that you dont get the new kernel from the trunkl ppa
<ogra_> robclark, did you not provide a linux-meta package too in there ?
<LPhas> couldn't i simply download the deb file and dpkg -i into it?
<ogra_> well, there is a bug we'd like to identify :)
<LPhas> i get your point
<ogra_> so there is no -meta package
<ogra_> thats the issue
<ogra_> sudo apt-get install linux-image-2.6.35-980-omap4  linux-headers-2.6.35-980
<ogra_> try that one
<LPhas> installing
<robclark> ogra_, no idea..  I wasn't really too involved in the deb packaging stuff
<ogra_> well, thats definitely the blocker
<LPhas> so i won "i found a bug" t-shirt?
<ogra_> though its possible that one of the ubuntu-omap4-*-* packages would pull it in
<jayabharath> followup from #pandaboard....
<jayabharath> LPhas: plz file a bug against the TI natty PPA
<jayabharath> will ping the folks who maintain it to see if they can address it
<LPhas> uhm
<LPhas> this is maverick not natty
<LPhas> and i'm not 100% aware of what happened, not sure at least.
<LPhas> basically the meta package of linux-omap4 was not updated to include newest linux kernel?
<ogra_> no
<jayabharath> oops yeah maverick
<ogra_> there was no metapackage created at all
<LPhas> sob, now i've x not starting
<ogra_> the existing one in the archive cant depend on a linux-image outside of the archive
<ogra_> so someone would have had to create it inside the PPA with a higher version than the archive has
<ogra_> which didnt happen
<LPhas> FATAL: Module omap_gpu not found.
<LPhas> that's strange
<LPhas> oh, well, i probably got why
<LPhas> mmh i keep getting omap_gpu not found on startx
<LPhas> i removed and reinstalled ubuntu_omap4_extra thinking that previous installation compiled modules for the old kernel
<LPhas> but nothing, it keeps not working
<rsalveti> LPhas: which ppa are you trying to use at maverick?
<rsalveti> release or trunk?
<LPhas> trunk
<LPhas> i have to use it
<rsalveti> so you should be using the linux-kernel from trunk
<LPhas> realease worked fine
<LPhas> i'am
<LPhas> if you look at the history
<LPhas> we found a bug
<LPhas> that prevent me to automatically get the latest version of the kernel from trunk
<rsalveti> LetoThe2nd: 2.6.35-980.1release9?
<rsalveti> LetoThe2nd: sorry
<rsalveti> LPhas: 2.6.35-980.1release9?
<rsalveti> oh, ok
<LPhas> yep
<rsalveti> sorry, huge backlog
<LPhas> i noticed that linux-headers-2.7.35-980-omap4 was not installed
<GrueMaster> Interesting.  Fresh install of maverick, I am getting dependency failures trying to install ubuntu-omap4-extras.
<rsalveti> GrueMaster: ogra_: LPhas: http://www.omappedia.org/wiki/Ubuntu_OMAP_trunk
<LPhas> GrueMaster, interesting
<rsalveti> that's why meta wasn't included I believe
<rsalveti> need to update x-loader/u-boot to make it work
<LPhas> rsalveti, the "update the bootloader" part seems quite overcomplex
<LPhas> shouldn't just sudo flash-kernel do the trick
<LPhas> oh, it is intended
<rsalveti> LPhas: not for maverick
<LPhas> oh my
<GrueMaster> Ah, forgot that multiverse & universe were not added by default.  yet another bug (and I now remember filing it back in the day).
<LPhas> well, that is written on a lot of documents online
 * GrueMaster signs his life away to the TI liscense agreements in Maverick for the sake of testing.
<pmcgowan> jeremiah, ping
<ogra_> GrueMaster, you read them before clicking, right ?? especially the part talking about your first born i hope :)
<GrueMaster> Bah.  They can have him
 * GrueMaster is more concerned with the anti-cloning on Titan 6 clause.
<ogra_> i dont think it says they want him :)
<ogra_> i might misremember, but i think there was something abotu life long vacancy *g*
<persia> So, about exposing netboot stuff: I tossed in those lines as a whim.  The linked branch should make the process fairly obvious if anyone wants to include more files.
<persia> I don't know what needs doing with abootimg to generate the right files for USB: if someone *really* wants to send me code to stick in the file, rather than writing a patch, that works.
<persia> I'm also happy to review someone's patch adding abootimg code for syntax, integration, etc. if someone wants.
<persia> (although I can't commit, so it would be a "looks sane" class of review)
<persia> sgnb, Thanks for filing a bug about it.  Looks like useful progress is happening there.
<persia> ogra_, regarding the image list: it's not *my* list (if anyone's it's skaet's), and it has mx5 images for Server starting today and for Xubuntu Desktop starting on Tuesday, so not everything is supposed to wait until 0801
 * micahg notices a mention of xubuntu ARM images...
<persia> micahg, Yeah.  When 0705 passed with no images in site, I bumped the date to 0719, because I figured two weeks was a nice round number, and someone else had set server/mx5 to 0715
<persia> From my memory of our last conversation about it, you didn't really care about the specific date, as long as there was something to test sufficiently before alpha-3 that you had a chance to fix obvious problems.
<micahg> persia: sounds good, now I just have to take care of my other stuff so I can actually play with this image :)
<persia> sgnb, Apologies: I am having a bit of trouble following the discussion in bug #810402 : Does the 4.5 -> 4.6 change mean we need *another* ocaml transition for ABI shift?  Is there something else happening?
<ubot2> Launchpad bug 810402 in ocaml "all native ocaml programs segfault on armel" [High,Confirmed] https://launchpad.net/bugs/810402
<ogra_> note that there was an ocaml rebuild upload today
<ogra_> which apparently ftbfs on all arches (i havent looked at the logs)
<persia> Yeah, doko uploaded ocaml to build with a different GCC.
<persia> It didn't work.
 * persia grumbles at the institutionalilsation of *yet another* resolution: "qHD", with a vertical component less than 600 pixels (and also less than the 576 pixels we chased last time someone had this sort of brilliant idea)
<ogra_> well, but you should at least get back horizontally what you lose vertically :)
<persia> But the discussion in 810402 seems to be missing some bits, or at least it doesn't make sense to me as a conversation.
<ogra_> why else would they add a q in front :P
<persia> 'q' is for "Quarter".
<ogra_> must be something special :)
<ogra_> lol
<persia> 19020x1080, except only 1/4 of it, so 540 vertical.
<ogra_> so not for quality ?
<persia> 960 horizontal is fine.
<ogra_> sure
<Neko> 960x540? better than iPhone4 resolution! :)
<ogra_> well, thats close to PAL
<persia> Still means that we either have to squash software or declare the resolution unsupported as a primary display
<ogra_> i would go for the latter
<ogra_> how many devices that fit a formfactor we target are there ?
<ogra_> (with such resolution)
<micahg> janimo: I know where to find you when I do have porting questions, thanks :)
<janimo> micahg, ok ;)
 * janimo crosses fingers it is not chromium :)
<persia> ogra_, An increasing number, since the resolution has a special name, and glass is available, rather than being considered weird.
<mahmoh> I'm trying to run pts/java-scimark2 and all the tests fail, exit non-zero, so it's not working for sure.  Should I try the same tests with JemVM? (if that's correct?)
<GrueMaster> mahmoh: It would be interesting to look at the failure log to see why it fails.  I have openjdk-jre-headless running jenkins slave on panda.
<mahmoh> oh, and a crash in netboot too: http://paste.ubuntu.com/644324/ ( cmagina )
<mahmoh> GrueMaster: good point, let me try that
<mahmoh> GrueMaster: it wasn't installed correctly b/c unzip wasn't installed!  Is that a package bug I would guess?
<GrueMaster> dependency issue.  Should have resolved on it's own, but phoronix-test-suite relies on aptitude to install (which isn't part of the standard image).
<mahmoh> it's not?  It's installed on my image (netboot w/ basic server), unzip was not
<GrueMaster> I have seen a lot of dependency issues with phoronix.
<GrueMaster> My netboot install with basic server & openssh-server didn't have aptitude.  Not sure what else was missing.  Had to install build-essential for the io tests as well.
<GrueMaster> Possibly due to the debootstrap issues.
<mahmoh> GrueMaster: hm, build-essential was installed for me by pts, aptitude's on there, wonder why our installs are different, itneresting
<mahmoh> interesting
<GrueMaster> I installed fresh Tuesday, right in the middle of the bootstrap issues.
<mahmoh> ok, I'm installing now on another board so I'll check
<mahmoh> actually, the install crashed (noted above)
<mahmoh> bbib
<mahmoh> and if anyone is nice enough to take a look at this and tell me why it's failing I'd appreciate it:  http://paste.ubuntu.com/644336/
<GrueMaster> mahmoh: Install libaio-dev
<mahmoh> GrueMaster: awesome, thx
<mahmoh> oh, it's installed already
<Johu> Hy. I did this : http://seabright.co.nz/2011/03/29/building-the-ubuntu-pandaboard-kernel/ but it didn't seem to do anything. Where should the uImage be?
<phh> arch/arm/boot
<Johu> it only compilse some object files but makes no linking... is this right?
<Johu> It might  be I'm getting just to sleepy.  I'll continue tomorrow.
<phh> no that's not right
<phh> thsi page assumes you've got an arm crosscompiler
<Johu> I was doing it on arm not on crosscompiler
<Johu> Okey... thanks.
<phh> ok so you don't have CROSS_COMPILE= line ?
<Johu> in makefile?
<phh> ...
<phh> in the page you gave, it says to do export CROSS_COMPILE=blabla
<Johu> no
<Johu> i didn't need to..
<Johu> i didn't crosscompile.
<Johu> I was running it on panda.
<phh> so you didn't do what this page states like you first said ...
<Johu> eee... yes (angel).... i did allmost like it told
<phh> anyway, what did the make say ?
<Johu> It just made lot of .o and finaly one ld. It didn't link.
<phh> ld isn't a link tool ?
<phh> interesting
<Johu> Only on ld.
<Johu> I did something wrong. I'll go to sleep... won't anoy you any more.
<Johu> Thnx.
<phh> if you did something wrong there are errors in make log ...
<Johu> I'll come back with log tomorrow... there was no errors.
<Johu> Tnhx. Bb.
<persia> Could anyone point me to nice documentation on boot.scr?  I can't seem to find anything :(
<rcn-ee> persia, just something generic or?  (btw, if this is for the beagle, upstream has moved to uEnv.txt's instead, clear text..)
<persia> Not for the beagle, and for a vendor uboot, so not even something where I can happily leverage upstream, sadly.
<persia> But generic works.  I basically want to understand conditionals, how program flow works, and how variables are used.
<rcn-ee> ah, variables get fun.. they end up being 'true' if they are not defined..
<persia> In the end, I probably just want to setenv ramdisk/kernel/bootargs and bootm, but when digging through the pile of examples I have, it helps to have docs alongside to make sure I understand.
<persia> Oh my :)
<rcn-ee> kinda decent example here: https://github.com/RobertCNelson/flash-omap/blob/master/reset.cmd
<rcn-ee> if i boot that on  a pandaboard, where "beaglerev" is not defiend it'll drop into every if..
<persia> Wait, not only is the variable true if undefined, but the tests are automatically true if the variables are undefined?
<rcn-ee> yeah, that's what i ran into, it was annoying..
<rcn-ee> so you have to be pretty careful with the end target..
<persia> In one of the examples I'm looking at, there's a construction that might work around that: "if test "_${foo}" = "_"; then:"
<persia> (explicitly tests for null state, but presumably the same sort of thing could be extended to specifically testing a known state)
<rcn-ee> actually, yeah that should work, didn't think of that..
<persia> Heh, and that's why sharing is good :)
<persia> Mind you, having documentation that mentioned the flaw in the implementation of test and the workaround would be even better :)
#ubuntu-arm 2011-07-15
<persia> rcn-ee, Looking at your example, is that an entire menuing system for the flash on the beagles?
<rcn-ee> the idea behind that was to stop people from accidently flashing nand the xM's..
<rcn-ee> there's no nand of course, but i got a couple bug reports with interesting errors... ;)
<persia> Heh.
<persia> I was wondering: would it be worth replacing the skeleton system we ship in Ubuntu with something like that (slightly more robust)?
<rcn-ee> i've actually been working on something even crazier... autogenerate it at boot: https://github.com/RobertCNelson/netinstall/blob/master/mk_mmc.sh#L127 then with sed: https://github.com/RobertCNelson/netinstall/blob/master/mk_mmc.sh#L184 (so far the same script boots on imx53,beagle,panda,igevp2.. so not as many as you guys yet..)
<rcn-ee> /boot/image flash time..
<persia> Wow!  So this would be some generic framework that on first boot would (ideally) generate the perfect boot.scr for the target platform, and place that in the right place for the next boot?
<persia> So, there's two points of wonder I have remaining:
<persia> 1) If we put several kernels in some directory available to u-boot, would this be able to select the right one?
<persia> 2) Would this allow us to construct a u-boot that was capable of booting on all those devices, or would there still need to be a separate compilation of u-boot for each image?
<rcn-ee> i was actually hacking up rootstock to do the same thing.. install both the omap and imx image's then select the right one by which board was selected..
<rcn-ee> then one image for many boards.. (till device tree is ready)
<persia> Could I convince you to do that hacking with debian-cd directly?
<persia> That makes it trivial for us to use it to generate such generic images (as opposed to rootstock, where we'd have to port the code and we have to recommend nobody uses for production purposes)
<rcn-ee> is that the same one ogra,lool..  keeps reminding me to use? ;) do you have the tree? i just finished adding debian armhf support to rootstock this last weekend.. ;)
<persia> lp:~ubuntu-cdimage/debian-cd/ubuntu
<persia> It is most likely precisely the same codebase everyone else keeps suggesting :)
<persia> It's the one we use to build the images we ship.
<lool> gosh
<persia> ... ?
<lool> My eyes are wide open at the shell pieces that rcn linked to, and also by the recommendation to hack it in debian-cd directly  :-)
<lool> in fact I'd recomment the opposite  ;-)
<persia> How do you mean?
<lool> Have a simple interface to generate useful images in a script which consumes e.g. the name of the vmlinuz file to install and any other useful inputs and then use that from debian-cd
<persia> I thought that the linked code was boot.scr code, rather than shell code.
<lool> and other places
<persia> And that one would just drop it in verbatim in debian-cd
<persia> Ah, right.  I should look at the top of the files.
<persia> Yeah, having a utility that did the right thing, and having debian-cd call that utility is lots cleaner, if it's image-build-time, rather than first-boot-time that we calculate the boot script.
<lool> I considered proposing linaro-image-tools to do this
<persia> That said, I'd *much* rather see a first-boot-time solution.
<lool> it has the advantage of being python and with decent test coverage, supporting a bunch of boards
<lool> but I'm not entirely sure it's the right approach
<lool> I think I should stop here, it's not reasonnable to start such a discussion in my local time
<persia> Heh.  Sleep well.
<persia> I agree it would be nice to have a tool that did the right thing that we could use on the image builders *and* end user environments.
<persia> I also feel fairly strongly that we should strive for a sufficiently generic model that we *don't* need to have N different images, all with the same rootfs.
<persia> (or nearly the same: ignore things like /lib/modules for now)
<lool> Yes, so there's actually a forum where we discuss exactly this
<rcn-ee> exactly, one generic image is all we need, at some point the user will have to flash something, at that point is where the customization should be done.
<lool> but to support current SoCs, we will need some middle layer adapting the boot of each SoC to some standard image format for a while, so the question remians
<persia> rcn-ee, Users make mistakes.  I want it to just work, without customisation.
<lool> rcn-ee: Right now, there are different expectations between SoCs which don't allow this, but we could progressively transition in such a world
<persia> lool, Indeed.  It's messy now, until we have more mature bootloaders, and potentially a new generation of SoCs with ROM that integrates nicely with the richer bootloaders.
<lool> however, we could have some generic image format right now, and provide mini-images for SoCs we care about which allow loading this image format
<rcn-ee> lool, i was actually working on something silly. (till device tree's done..) have both and imx/omap image installed in the rootfs, then having the bootloader pick the correct one, based on what board the user selected... so you'd have one base iamge for imx and omap.. per say..
<lool> rcn-ee: so with Linaro "images" we split the soc specific bits out, and you combine them when writing the SD image
<persia> This is the function of linaro-image-tools
<lool> e.g. you download an Ubuntu rootfs, then imx specific bits then omap specific bits and you run linaro-image-tools to create omap or imx SD card images
<rcn-ee> yeah, pretty much...
<lool> while imx + OMAP might be combined in a single image, it's becoming exponentially complex when you factor more SoCs or things like aligning partitions, different partition types, and other constraints
<persia> I like better the idea of merged images, letting the user select the right thing, but last I heard, one needed a different build of u-boot for each board (and sometimes each revision of a board), which makes this considerably harder to accomplish.
<lool> like Samsung expects its bootloader near the imx one, so you wouldn't be able to do imx + samsung support
<rcn-ee> yeah, i haven't expanded enough outside imx/omap yet to see the bigger picture yet.... ;)
<lool> we didn't discuss detecting which SoC you're on; John Rigby had some idea that this could be done; it's also a fun research project, but it's pretty tricky
<lool> and that's not needed in the case of interim middle layer images
<persia> And it's very bootloader-specific.  I'm not sure devicetree helps at all, because we still have to find a way to get to linux.
<lool> just detecting variations of OMAP3 boards to infer their type of DDR is already quite hard to do reliably
<NekoXP> yeah the real issue here is you guys are *recompiling and reflashing u-boot* which is totally bad mojo and brick city awaits
<lool> it's not really a problem of which bootloader
<lool> the hardware doesn't provide the information to start with
<lool> NekoXP: I don't think this relates at all
<lool> but I can certainly say that we can't work on any such project if we aren't rebuilding u-boot ourselves
<persia> NekoXP, We only do that for dev boards.  We don't reflash u-boot for retail devices (or reflash u-boot past first install anyway)
<lool> at least not on this target SoC, someone else will have to do it
 * lool 'night! &
<persia> lool, Sleep well
<rsalveti> at least for omap it should be ok to have just one u-boot at least
<rsalveti> but still, we need something to provide the device id
<rsalveti> and that would be SPL or x-loader
<rsalveti> problem is that there's no pattern at all
<chedder> I have a question about network (Wired & Wireless), today I loaded this image on my board "http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/release/ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img.gz". when it installed, I was at a desktop and cound not enable the wireless or wired network - does anyone know what I am missing? I am a newbe btw
<persia> chedder, What does network manager tell you about available networks?
<siji> hi all
<siji> i have build ubuntu natty by using rootstock
<siji> On beagleboard
<siji> but my ethernet is not working
<siji> any solution ?
<persia> What sort of ethernet do you have?
<persia> If it's like the one on my Zippy, I think the issue is a lack of kernel drivers for it.
<persia> Or improper hotplug support.
<siji> persia, it's the defualt ethernet cming with beagleboard
<siji> as u said i doubt it's kernel driver issue
<siji> I have build natty from rootstock
<persia> I think you have a different beagleboard than I: mine only has ethernet on a breakout board (zippy), and that ethernet has never worked for me.
<siji> oh ok
<persia> I've always suspected a driver issue, because USB ethernet works fine.
<siji> oh ok
<siji> this was working fine with angstrom
<persia> By the way, you know that rootstock is good for experimentation, but not entirely suitable for the creation of production images, right?
<siji> I feel the same
<siji> One more clarification I needed
<persia> Heh.  I suspect angstrom has some patches to the kernel, or patches to udev to handle that (I'm not sure which is needed).
<siji> ok
<siji> Actullay in the boot directory of the natty vmlinux and initrd.img etc.. is 2.6.39
<siji> But my uImage is for 2,6,38
<siji> whether this will be the problem ?
<persia> Maybe, but only maybe.  More important than the contents of /boot are whether you have anything in /lib/modules/ that matches the currently running kernel
<siji> let me check
<siji> oh right
<siji> all the modules are only for 2.6.39
<siji> So either have to put 2.6.38 module there or ,hve to build new uImage for 2.6.39
<siji> Right ?
<persia> If you want to be able to load drivers, yeah :)
<siji> ok
<siji> let me give a try
<siji> persia, i guess it's detected now
<siji> lights are cming from etehrnet card
<siji> Trying to configure it ..
<persia> Cool!
<siji> persia, yes it's start working
<siji> Even my Wifi Module also detected
<siji> ;)
 * persia suspects mmcqd isn't supposed to consume more cycles than any other process
<infinity>  1131 ?        D     51:39 [mmcqd]
<infinity> That's 10 days uptime on a system that's a full archive mirror.
<infinity> It's not the top offender, but it's close.
<persia> You're clearly abusing your SD cards almost as much as I then
<infinity> (If the mirror wasn't on external storage, it probably would be top)
<infinity> Well, my root's on SD, cause I'm lazy.
<persia> This is on a system with root on /dev/sda
<infinity> Oh.  Well, stop doing mean things to your CD cards.
<infinity> (writing test images over and over?)
<persia> Worse: pieces of test images.
<infinity> Ick.
 * persia hopes to get to actual test images later.
<infinity> I was supposed to be asleep, wasn't I?
<infinity> I got distracted by Vi Hart talking about pie.
<infinity> Or pi.
<infinity> Or both.
<persia> My views on timezones and sleeping habits being what they are, I'm not sure I'm qualified to answer that question.
<infinity> I lost trach.
<persia> Tau!
<infinity> track, too.
<rsalveti> ppisati: ogra_: who is integrating the TI LT kernel at ubuntu?
<persia> rsalveti: Last I knew it was ppsati
<persia> But it was never clear to me if that was a LT kernel or a BSP kernel
<rsalveti> that's also what I want to know :-)
<rsalveti> what tree ubuntu is planning to use for omap 4, who is doing the work and how related it is with the TI LT tree
<ppisati> rsalveti: bsp kernel, based on agreen's kernel-tilt/master
<ppisati> and here is if you want to try it out
<ppisati> http://people.canonical.com/~ppisati/ti-omap4-next/linux-image-3.0.0-1-omap4_3.0.0-1.0~9765dd1_armel.deb
<ppisati> git://kernel.ubuntu.com/ppisati/ubuntu-oneiric.git ti-omap4-next
<ppisati> if you want to tweak it
<rsalveti> ppisati: so, it's TI LT + ubuntu sauce?
<ppisati> yep
<ppisati> oneiric/master + kernel-tilt/master + $omap4_only_stuff
<rsalveti> hm, ok, we also want the same thing for linaro, so I'm thinking how should we avoid duplicate work
<ppisati> where omap4_only_stuff so far is only some config
<rsalveti> ok, that's fine
<ppisati> pick it entirely
<rsalveti> and in theory there's no reason to keep patches !config in $omap4_only_stuff
<rsalveti> as agreen is taking most of the patches
<ppisati> agree
<rsalveti> jcrigby: so even less work for us atm
<rsalveti> ppisati: and when are you planning to push this to omap4 branch?
<ppisati> rsalveti: well, there's one issue with audio still, but i think we can skip it ATM
<ppisati> if it gets some testing, i can push it next week
<ppisati> btw, IIRC exactly next week the SRU team open the window for new kernel cycle
<ppisati> so it's a perfect timing
<rsalveti> ppisati: cool, good to know
<ppisati> whos is using omap4/panda?
<ppisati> me, you, grue, ogra and janimo?
<janimo> ppisati, I do
<janimo> stock oneiric
<janimo> upgraded from natty
<ppisati> janimo: cool, so can you give it a try?
<ppisati> janimo: http://people.canonical.com/~ppisati/ti-omap4-next/linux-image-3.0.0-1-omap4_3.0.0-1.0~9765dd1_armel.deb
<janimo> ppisati, sure
<ppisati> in the meantime...
 * ppisati -> lunch
 * janimo grumbles about canonicaladmin javascript bugs
<siji> persia, can u pls tell me abt where can I get pvr drivers for the kernel 2.6.38
<siji> is it bundled with omap ti Sdk ?
<persia> siji, You want https://wiki.ubuntu.com/ARM/OMAP/Graphics
<persia> I don't know whether it is in the TI SDK, or how TI licenses it to their customers: for playing around, feel free to use our code.
<siji> persia, ok
<persia> For production shipment, it's worth double-checking the terms of your supplier arrangement with TI
<siji> sure will do
<siji> persia, i have tried this link
<siji> it generated the driver only for 2.6.35
<siji> not for 2.6.38
<persia> You installed libegl1-sgx-omap3 libgles1-sgx-omap3 and libgles2-sgx-omap3, and it didn't autocompile for your installed kernel?
<siji> no
<persia> Well, what did you do then?
<siji> it has created one more module folder at /lib/modules/2.6.35 and pvr folder created there
<siji> 2.6.35-n90  I guess
<siji> which is i think not compatible  with .38
<siji> anyway let me give a try again
<siji> persia, Setting up linux-image-2.6.35-1-n900 (2.6.35-1.3.1) ...
<siji> Running depmod.
<siji> update-initramfs: Generating /boot/initrd.img-2.6.35-1-n900
<persia> siji: Hrm?  Aren't you working on a Beagle derivative?  Why use the n900 kernel?
<siji> am not using actually
<siji> it by default installed
<persia> Which image did you start from?
<siji> 2.6.38
<persia> As long as you start from one of the omap images, the n900 kernel shouldn't be installed.
<persia> That's only default for the n900 images.
<chedder> looking for help finding the modules to enable networking
<chedder> i am a newb - very cluness
<siji> persia, not getting you
<chedder> i am running a pandaboard
<chedder> I am using the 10.10 image, any thoughts
<persia> chedder: does your uname -a match the contents of /lib/modules?
<persia> siji: So, there's lots of kernels in the Ubuntu archive.  You want one ending with -omap.  The -n900 kernel might work on your hardware, but it might not.
<siji> persia, ko
<siji> *ok
<persia> siji: So, if you started with one of the armel+omap images, you won't have linux-n900 installed by default, and you won't be building stuff for .35 kernels.
<siji> persia, got your point
<siji> let me recheck my rootstock parameters
<persia> If you're just saying "gimme a kernel that works on this hardware", you might end up with n900, as that is also an omap SoC: you might have to specify the kernel you want.
<chedder> ummm no idea :)
<siji> ok
<siji> chedder, which kernel u are using ?
<siji> uname -a  will tell you that
<chedder> I used this "http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/release/ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img.gz"
<persia> chedder: OK.  So, at the prompt, run `uname -a`.  Also run `ls /lib/modules`.  Check to make sure that you have modules (in /lib/modules) for the kernel you're running (the version is shown in uname)
<ogra_> lool, around ?
<persia> If you just booted that image, and waited for the resize, and went through the OEM wizard, networking should just work.
<chedder> both wired and wireless?
<persia> For wireless, you might need to enable the TI PPA.  I forget (I only use wired on mine).
<chedder> a working wired connection would be just fine
<persia> OK.  So there's two ways to make wired work.
<persia> 1) When you're done booting, use the network manager applet to select a wired network.
<persia> 2) read interfaces(5), and edit /etc/interfaces
<persia> Of these, 1) is *lots* easier.
<siji> persia, can pls have a look into my rootstock parameters @http://paste.debian.net/122989/
<persia> I'm not familiar with rootstock.  I used it once, a *long* time ago, and never liked it.
<siji> oh ok
<persia> I'll look, but I don't promise much.
<siji> no issues
<lool> ogra_: half
<ogra_> lool, i'm playinf with your flash-kernel patch for triggers and noticed that you run from /etc/initramfs/post-update.d/ ...
<persia> siji: I'll recommend you use an Ubuntu kernel: try adding "linux-omap" to the seed list, and dropping the kernel0image line.
<siji> ok
<persia> Mind you, this may not actually work: I'm not sure what "kernel-image" does.
<ogra_> lool, the content of that dir is only executed by update-initramfs -u ... not -c, so it doesnt solve the problem of running at kernel upgrades
<siji> persia, will give a try
<ogra_> lool, or do i misunderstand the code completely ?
<siji> (building the image with "linux-omap" )
<lool> ogra_: I don't remember that part anymore, it's possible that I didn't handle all cases
<persia> rsalveti, I just noticed the last line at https://wiki.ubuntu.com/ARM/OMAP/Graphics : did you ever pursue that backport?
<ogra_> well, it does implement triggers just fine, it just doesnt change anything in the faulty behavior
<lool> ogra_: I think I had described this part of the problem in a separate message
<ogra_> hm, k
<lool> ogra_:  /etc/initramfs/post-update.d and /etc/kernel/postinst.d calls keep a
<lool>  note of which kernel initrd are being touched, and update
<lool>  /var/lib/flash-kernel/known-kernels with the data.  flash-kernel would
<lool> ogra_: maybe I failed sending the etc/kernel snippet though
<ogra_> yeah
<ogra_> i dont see it
<ogra_> well, i think for now i'll go with a simple implementation in our flash-kernel
<rsalveti> persia: afaik, yes
<persia> Odd.  I don't see it in the archive.
<persia> Is it blocked on testers?
<siji> persia, till now everything is happening smoothly
<siji> I have made the image from rootstock , with 2.6.38
<siji> Just installing sgx packages
<siji> now it's only installing 2.6.38 header
<persia> siji, Heh, excellent.
<persia> Random stuff on the net might work (and rcn-ee's stuff tends to be fairly good), but it's often safest to stick to the packages in the repositories until you have something *nearly* working, and then get patches in (best if you can get patches that can be applied to Ubuntu).
<siji> ok
<siji> persia, yes it's starts working
<siji> :)
<ogra_> GrueMaster, some testing of my recent flash-kernel change for bug 701698 would be nice next week :)
<ubot2> Launchpad bug 701698 in boot "update-initramfs -c does not update the bootloader" [High,Triaged] https://launchpad.net/bugs/701698
<GrueMaster> Oh, you actually fixed it?
<ogra_> well
<ogra_> i worked around it, lool has a real fix but thats very complex
<ogra_> with my fix it can happen that flash-kernel is run multiple times
<ogra_> during one apt-get (dist-)upgrade  run if you have more than one kernel package you get
<GrueMaster> Ok, I'll make it a point to test next week.  Is this an SRU or oneiric only fix?
<ogra_> oneiric only until after my vacation :)
<GrueMaster> ok
<ogra_> its adding one file so SRU should be easy
<rsalveti> mahmoh: GrueMaster: u-boot is correctly setting the mac address now
<rsalveti> and it's the same one detected by the kernel
<rsalveti> just booted here with pxe and it all went fine
<rsalveti> :-)
<infinity> rsalveti: \o/
<mahmoh> rsalveti: 2/2, thx!
<GrueMaster> rsalveti: i'll test it once the IO tests finish, probably tomorrow.
#ubuntu-arm 2011-07-16
<chedder> can someone point me to ubuntu\arm benchmarks
<zandubalm123> Anyone could comment abt virtualbox vs vmware in terms of performance? I need to install one on my ubuntu box and I am looking for speed....
<zandubalm123> Anyone could comment abt virtualbox vs vmware in terms of performance? I need to install one on my ubuntu box and I am looking for speed....
<mahmoh> hmm, running IO tests, unsure what caused this: http://paste.ubuntu.com/645160/
<GrueMaster> mahmoh: Looks like either your external drive was shut down or possibly put into sleep mode and didn't wake up.
<GrueMaster> chedder: Sorry, we do not publish benchmark results as a rule.  We sometimes use benchmark tools to ensure no speed regressions or as a test suite for app functionality.  Try a web site like Phoronix.
<chedder> GrueMaster - thanks. Can you tell me what benchmark tools are used commonly?
<chedder> I will look at Phoronix as well
<GrueMaster> Off hand, no, not on arm.  Most of the testing prior to this cycle has been hands-on.
<GrueMaster> But I would imagine phoronix-test-suite, as it is fairly complete.
<chedder> thanks, I am at the website now
<GrueMaster> Just remember that on arm, benchmarks don't mean as much, as each SOC is designed for specific tasks.  For example, the TI OMAP series is designed for cell phone & tablet use, whereas Marvell designs for NAS boxes.
<GrueMaster> It can almost be like comparint an Intel Atom to an Intel iCore7 Xeon.
<slava__> Hello, everyone! I have a problem. Arch - armv4l (str8132). I have sources, but can't rewrite kernel into flash, because as I found out, that kernel is not compatible at all. Well, I need to hook one syscall. I have found sys_call_table address, but that table is ro only. How can I change attributes of this kernel section from module? Kernel version is Linux NAS 2.6.16-star #812 Mon Nov 17 15:27:34 CST 2008 armv4l GNU/Linux
<persia> slava__, armv4l!  How does Ubuntu even run on that?
<persia> ogra_, How could bug #701698 possibly be related to r-cran-boot?
<ubot2> Launchpad bug 701698 in boot "update-initramfs -c does not update the bootloader" [High,Triaged] https://launchpad.net/bugs/701698
<slava__> persia, yes. I can install some graphical packages here through compiling.
<persia> Oh my!  Well, good luck with your kernel issue.
#ubuntu-arm 2011-07-17
<ogra_> persia, ? r-cran-boot ?
<persia> ogra_, According to the bug activity log, you changed the package to "boot", which source package only produces one binary: "r-cran-boot".  I suspect you wanted to add a tag or something, but I wasn't sure.
<alastor9> Hello. Does video acceleration work in Natty on Panda ?
<alastor9> Natty video acceleration on Panda = ? :D
<prpplague> alastor9: if someone is available and knows the answer, they well respond, no need to repeat the question
<alastor9> Ok
#ubuntu-arm 2012-07-09
<ppisati> guys, how do i enable autologin?
<ppisati> ogra_: omap3 netinst didn't change since Friday, do you know why?
<ppisati> ogra_: http://ports.ubuntu.com/ubuntu-ports/dists/quantal/main/installer-armhf/current/images/omap/netboot/
<brainwave> d> ubuntu waits for a keypress after booting, before displaying the login prompt
<brainwave> <resurrected> I cannot find a way to make it go to the login prompt without that keypress
<brainwave> http://imagebin.org/220061 The login prompt is displayed after that step, only after i press enter. is that normal behavious
<janimo> infinity, hello good sir. I again have armadaxp kernels in incoming, longing for -proposed.
<ogra_> does it have its passport and visa ?
<infinity> janimo: Does that kernel include the changelog from the previous one?
<infinity> janimo: (If not, I'm not sure it's worth rebuilding...)
<infinity> janimo: Also, when it's ready to be copied to proposed, the "promote-to-proposed" task on the tracking bug should be set to confirmed.  Gives me a hint that I have work to do.
<infinity> janimo: (Accepted now, will fix overrides in the next hour)
<janimo> infinity, thanks, forgot about the promote to proposed tag, or rather I thought it is to be handled by The SRU Kernel Bot
<janimo> infinity, it should have the previous changelog entry too, the one that got overwritten
<infinity> janimo: I meant in the .changes (which is why you'd want to build with -v$old_old_version)
<infinity> janimo: Oh well.  It just means you get to close all the bugs between 1602.5 and 1605.8 by hand. :P
<janimo> infinity, 1603 is in updates afaik, only one release got skipped by being caught up with in proposed by a newer one
<janimo> so one bug to be closed by hand
<infinity> janimo: Oh, err, yeah it is.
<infinity> janimo: Went cross-eyed and looked at quantal.
<infinity> janimo: (Which is still on the same kernel as precise-release... Do you plan to do something about that?)
<janimo> infinity, about quantal. we'll probably sync the latest sru to it soon. Had some blockage about it having to have a different ABI than precise. ikepanhc is handling that
<janimo> long term quantal is moving to 3.5 but that hangs on starting /bin/init at this point so not ready
<infinity> janimo: It doesn't need a different ABI than precise if it's literally the same SRU, I can just copy it over.
<infinity> janimo: But long-term, we want it to be 3.5, yes.
<infinity> janimo: Don't put any effort into repackaging 3.2 for quantal, that's a waste of everyone's time.
<janimo> infinity, Ike said something it needing to be 1800 not 1600 based but I do not know why
<infinity> janimo: Just remind me when I promote to updates/security to also copy to quantal.
<janimo> oh not repackaging, for sure
<janimo> not sure why he said there'd be conflicts
<janimo> even with the exact same binary
<janimo> awesome
<infinity> janimo: It's only needs a different ABI series if it's going to diverge or be rebuilt.  If we just copy it around, it's all good.
<cduclos> has anyone experienced any file permission issues (with sudo commands, etc.) when booting fs from a usb hd as opposed to booting from a sd card
<cduclos> I am trying to boot on a pandaboard
<cduclos> worked fine with sd card, but things were slow. so I switched to a usb hd
<robclark> fwiw, I checked the obvious things w/ cduclos.. suid bit is set on /usr/bin/sudo, etc..
<robclark> but he is using ext3 (I am using ext4.. I'm not sure if that is a requirement with precise)
<infinity> ext3 or ext4 should both work fine.
<infinity> Was this installed from a d-i netboot image, or just copied over from a preinstalled SD with a bit of hope and prayer?
<cduclos> preinstalled sd img.. I am using GLP1.6.3 if that makes a difference.
<robclark> (that is 12.04, fwiw)
<infinity> If you plan to run from a hard drive, I highly recomment just using the netboot images to install directly to said hard drive, bypassing the error-prone copying to and from an SD.
<infinity> recommend, too.
<robclark> infinity, permissions on stuff in /dev and /usr/bin/sudo look fine.. so I guess however it was copied, it looks like file permissions where preserved..
<infinity> That said, copying from SD *should* work (I've done it before), so no, I can't think of what the actual problem is that you might be having.
<robclark> (ie. same procedure has worked for me before)
<infinity> But anything that looks even vaguely like filesystem confusion, I tend to just blame on SD cards until I have proof that I shouldn't.
<infinity> And I'm generally right. :/
<cduclos> infinity, where would I be able to get a netboot image to install on the hd
<infinity> http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/
<infinity> zcat either boot.img-fb.gz or boot.img-serial.gz to an SD and go to town.
<infinity> (fb versus serial should be a fairly obvious distinction)
<infinity> That'll get you a base (serverish) install, if you want a full desktop from there, "apt-get install ubuntu-desktop^" should fix you up.
<janimo> infinity, which tool exactly is passed the -v$PackgeVersionInUpdates to include extra changelogs in the .changes file?
<janimo> debuild/dpkg-buildpackage?
<janimo> ah. dpkg-genchanges via the above
<janimo> I am again amazed at what a rush of adrenaline after asking a question can do. Read the manpage paragraph again and found the answer in 5 seconds, where 5 min ago I did not see anything relevant after staring for considerably more
<janimo> aka the Enlightenment after pressing Send effect
<infinity> janimo: Yeah, genchanges, via buildpackage and, if you use it, via debuild. :P
<janimo> I use debuild, more high level, less typing too :)
<scientes> do you guys support the tegra 3 (Nexus 7 tablet)?
<scientes> oooooo http://www.androidauthority.com/lg-f180-specs-quad-core-snapdragon-s4-100167/
#ubuntu-arm 2012-07-10
<In0perable> .////
<In0perable> hi everyone
<In0perable> looking for a kernel/module package thats decent
<In0perable> for 12.04
<In0perable> for eee pad transformer
<In0perable> hmm
<brainwave> I am getting warning Cache not enabled during boot
<ppisati> ogra_: with today's daily omap3 netinst i was able to complete an installation, but the system won't boot since it didn't create the first vfat partition with uImage&c
<Just-in> Does anyone know if there is a size limit on microSD on the Beagleboard XM? I know it comes with a 4gb but i have a few 16gb and a 64gb laying around.
<LetoThe2nd> Just-in: 16gb should certainly work. and i'd suspect 64gb to also do, but i've never tried.
<Just-in> Sweet i've never loaded a preinstall before so this should be fun once my board gets in.
<ogra_> there are 64MB microSDs ?
<ogra_> i thought 32M was the upper end
<ogra_> ppisati, awesome
<ogra_> ppisati, flash-kernel was fixed though, it theoretically should set up everything fine, i'll do a test install myself to check whats wrong
<Just-in> yeah they make 64gb micros now
<ppisati> ogra_: the problem is that when you choose "use the entire disk" the vfat partition is not created
<ogra_> ah, yeah, you need to choose "guided"
<ogra_> then it is created
<ppisati> ah
<ppisati> crap
 * ppisati restart another installation
<ogra_> just doing a chicken install should get you a working system
<ppisati> chicken?
<ogra_> (chicken= set up a chicken in front of the kbd and make it pick the enter key all the time)
<ppisati> ahhhh...
<ppisati> (weird Germans...)
<ogra_> (you could also try a girlfriend but these are less patient usually)
<ogra_> :)
<ppisati> so
<ppisati> it fails the "chicken test"
<ppisati> i'll retry with guided
<ppisati> let's see
<ogra_> guided *should* be the default
<ogra_> isnt it ?
<suihkulokki> ...I'm sure someone has made a "usb pecking chicken" device
<ogra_> hahaha
<Just-in> i may have to make a usb powered chicken now....
<suihkulokki> Just-in: share us pictures once done :)
<Just-in> i think i still have a foam feathered chicken in the storage room.
<Just-in> and girlfriends are less patient always
<ogra_> xranby, hey ... do you happen to know if there were any specific java plans for 12.10 (and if so, where they were written down) ... i seem to miss doko constantly on IRC
<xranby> ogra_: the main plan is to focus on openjdk-7 and drop openjdk-6
<ogra_> right, but there is no written doc or anything ?
<ogra_> (or a UDS spec)
<xranby> ogra_: there is, let me dig it up for you
<xranby> ogra: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-java7
<ppisati> ogra_: the default is "Guided - use entire disk"
<ppisati> ogra_: and it doesn't create the vfat/dos boot partition with uImage&c
 * ogra_ hugs xranby 
<ogra_> ppisati, weird, it did on my omap4 desktop install
<ogra_> might be because you are running off the SD without having partitions
<ogra_> (which you typically do on netinst images, the desktop image comes with a separate already created vfat)
<ppisati> yep
<ppisati> shall i fill a bug about it?
<ppisati> i mean
<ppisati> do we support netinsta at all?
 * ppisati grabs a coffee
 * Just-in wishs he had coffee
<ogra_> ppisati, well, we test netinst, we dont "release" or "not-release" it since it simply drops out of a normal debian-installer build
<LetoThe2nd> ogra_: btw, can you hand me a link to the netinstallers?
<ppisati> LetoThe2nd: http://cdimage.ubuntu.com/netboot/quantal/
<LetoThe2nd> ppisati: thx
<LetoThe2nd> *notice* the "installation guide" links are either nonfunctional or misdirecting to other, relatively unrealted pages.
<brainwave> have ubuntu -server installed on pandabaord, installed xfce4 and want to forward desktop over vnc
<cospan> hello, is this the correct forum for running Ubuntu on the Beaglebone?
<cospan> sorry, its been a long night, is this the correct forum for asking questions about running Ubuntu on the Beaglebone?
<ogra_> for userspace yes ... we dont really have beaglebone support or images
<cospan> hmm, I have questions about building a custom kernel and installing it, if this isn't the correct forum would you point me in the right direction
<cospan> I would really appreciate it
<ogra_> try #beagle then
<cospan> thank you very much
<ogra_> they cover the non distro specific stuff
#ubuntu-arm 2012-07-11
<jeremiah> .c
<janimo> ogra_, marvin24 did the 3.1 kernel issue have something in common with https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/936667 ?
<ubot2> Ubuntu bug 936667 in upstart "Upstart early job logging causes boot failure for systems with no initramfs (error is "No available ptys")" [High,Fix released]
<ogra_> janimo, well, we always have an initrd
<janimo> any news on that particular nvidia kernel issue?
<janimo> ogra_, is that still holding up quantal ac100 images?
<ogra_> and  that bug is fixed since mid-precise
<ogra_> no, what was holding up was my time to fix ac100-tarball-installer and additionally research the oops i get on boot
<ogra_> the installer is fixed now
<ogra_> tomorrow if i have new images i'll move on with the kernel issue
<janimo> ogra_, kernel oops on install or first boot?
<janimo> ok
<ogra_> sadly ui cant quickly roll images manually atm
<ogra_> we only have one builder thats constantly occupied
<janimo> is that a regression?
<ogra_> janimo, first boot, some initrd issue i think
<ogra_> we dropped all non panda HW from the datacenter
<janimo> I thought the builder situations was only going to get better
<janimo> ah, a good move otherwise
<janimo> and not enough new pandas?
<ogra_> and until tere is a new mandabox server we only have one machine for livefs builds
<ogra_> i think we have a lot of new pandas, but someone needs to set them up
<hrw> ogra_: build iamge at home?
<ogra_> no, thanks, i have better stuff to do than to set up the ubuntu build infrastructure at home
 * GrueMaster has the infrastructure, but no loinger has the time or desire.
<janimo> the fact our build insfrastructure is so involved as opposed to dead-simple live-build means noone can really take over properly without too much effort
<marvin24> janimo, ogra_: I hope the console can be fixed soon
<marvin24> otherwise we need to boot with console=tty1 as a workaround
<marvin24> janimo: did you tried to compile a 3.5 kernel for tegra already?
<janimo> marvin24, no, since Iheard from you it has no graphics :)
<marvin24> it has, but a bit buggy
<marvin24> maybe still makes no sense to try it
<janimo> I may give arm-soc a try - it has more tegra stuff than 3.5
<janimo> I just saw too many kernel tree lately that don't even build, so I am not too attracted to yet another one
<janimo> :)
<marvin24> janimo: yes, me too :-)
<janimo> lilstevie, do you know anything about the status of the 3.1 jhinta kernel for tf101? It sort of boots here, but hangs on starting network manager
<janimo> the xda forums are horrendous
<marvin24> I wonder if tf101 also has the console problem
<janimo> marvin24, I had to boot with --no-log
<janimo> marvin24, , otherwise not sure how the console problem manifests itself, I did not boot ac100 with 3.1 yet
<janimo> it just prints out the kernel logs, then starting init and a few scripts, pausing on NM
<marvin24> yes, it oopes shortly after entering userspace boot
<marvin24> but looks random
<janimo> no oops on screen and no ramconsole built in this kernel
<marvin24> is plymouth installed?
<janimo> marvin24, yes. Should  I make it -x ?
<janimo> meanwhile I'll rebuild the kernel with ramconsole on
<marvin24> no, it hangs here only with plymouth installed
<marvin24> but uninstall is also only a workaround
<janimo> marvin24, iirc ogra said making lib/plymouthd or some unexecutable is a workaround
<marvin24> yes, or add console=tty1
<marvin24> and leave it executable
<janimo> marvin24, do you know if tegra2 kernels can support multiple hw from the same build? Ie. ventana, harmony, ac100, tf101 all built in?
<janimo> marvin24, thanks, I'll try that too
<janimo> will that redirect console output to somewhere invisible?
<marvin24> the kernel does, but the bootloader doesn't
<marvin24> janimo: yes
<marvin24> in mainline, everything will depend on device tree
<marvin24> so you can boot the same kernel on all tegras
<marvin24> but we ee
<marvin24> ... need uboot for this
<marvin24> uboot passes device tree to the kernel (same kernel for all)
<marvin24> I don't know how other archs are doing it now
<janimo> marvin24, in 3.1 there's no device tree yet afaik
<marvin24> yep, only in mainline
 * janimo wonders if a single zImage could be used on both ac100 and tf101
<marvin24> sure, add tf101 to mainline
<marvin24> or add a device-tree
<marvin24> as I said, *all* tegras (tegra2 and tegra3) should be bootable from a single kernel
<janimo> so with current 2.6.x/3.0 non-DT, what is uboot specific in the kernel? I see nothing in what I build for in the confis
<janimo> configs
<janimo> marvin24, yes in mainline, I was wondering pre-DT where we are and will likely still be in 12.10
<marvin24> the current bootloader (fastboot) does not support device trees
<marvin24> while u-boot does
<marvin24> so, mainline + u-boot or fastboot + 3.1
<marvin24> (uboot can also boot 3.1 kernels)
<marvin24> but hw support is not finished
<marvin24> we have to wait - again :-(
<marvin24> but regarding DT support, tegra is pretty complete
<janimo> marvin24, chmod -x /sbin/plymouthd made it boot into X. will try console= too thanks!
<marvin24> janimo: good
<janimo> marvin24, do you think it is a nvidia kernel bug?
<marvin24> yes, I talked to an engineer from nvidia
<marvin24> and he was able to reproduce it on ventana (tegra2 dev board)
<marvin24> could also be ubuntu related ...
<janimo> do they plan to address it in 3.1?
<marvin24> but the kernel shouldn't oops
<marvin24> janimo: yes
<janimo> possibly, ubuntu userspace is a bit different
<marvin24> we tried to track it down (and still try)
<marvin24> janimo: I will request a new kernel build when it's fixed ;-)
<janimo> marvin24, sure ;)
<janimo> marvin24, back to the previous issue - the idea of single image for multiple kernels is _dependent_ on device tree? Since in menuconfig you can check any number of arches to support
<marvin24> with "arches", do you mean omap, tegra, ...
<marvin24> or boards?
<marvin24> you can select different boards, but our bootloader is buggy and does not accept multi-board kernels
<marvin24> janimo: no idea what tf101 bootloader does
<janimo> marvin24, afacit just takes an android bootimg and starts it :)
<janimo> like the ac100 one, not sure about details
<janimo> marvin24, ah so the ac100 bootloader would choke on a kernel image that has any other board than paz00 enabled too?
<janimo> I meant just tegra2 based ones (paz00 and tf101 in particular)
<marvin24> in fact, no one knows what it does
<marvin24> s*y
<marvin24> I had the impression, that the bootloader reads the machine-id from the kernel and feeds it back to the kernel
<LetoThe2nd> prpplague: howdy pardner
<prpplague> greetings
<LetoThe2nd> prpplague: found time to look at the video i told you?
<prpplague> LetoThe2nd: sorry no, yesterday was crazy i had some car troubles from the previous afternoon
<prpplague> LetoThe2nd: can you give me the link again? i have it at home
<LetoThe2nd> prpplague: ah kay... hope you got things roted out?
<prpplague> LetoThe2nd: yea
<LetoThe2nd> sorted out, even :/
<prpplague> LetoThe2nd: i had the car worked on friday, turns out they put one of the nuts back on without the cotter pin
<LetoThe2nd> aw :(
<prpplague> LetoThe2nd: damn near got killed by a large truck on monday afternoon after the front passenger tie rod came off while i was cross an highway intersection
<LetoThe2nd> prpplague: http://www.youtube.com/watch?v=ufBCoHP-8Yk&list=UUXHs7mzjNipr-xp1Bps2zew&index=2&feature=plcp
 * prpplague looks
<prpplague> LetoThe2nd: you said about 50 seconds in?
<LetoThe2nd> prpplague: interesting part is from 0:55 onwards or so.
<LetoThe2nd> prpplague: glad nothing bad happened then
<prpplague> LetoThe2nd: this video is work safe correct?
<LetoThe2nd> prpplague: totally yes.
<LetoThe2nd> prpplague: its from an educational fair near me.
<prpplague> LetoThe2nd: ahh dandy!
<LetoThe2nd> prpplague: and inside that rc car is a panda :)
<prpplague> LetoThe2nd: yea i think those guys were in cambridge a while back at ELC
<prpplague> LetoThe2nd: with an early prototype of the design
<LetoThe2nd> prpplague: will meet those guys sometime in the next two weeks probably, was really surprised there are other panda users in this small town.
<prpplague> LetoThe2nd: hehe
<LetoThe2nd> prpplague: btw got one or two minutes for private?
<LetoThe2nd> (just noticed we're not even in #pandaboard)
 * prpplague checks the time
<prpplague> LetoThe2nd: yea, got about 5-10 mintues
<smplman> does anyone know where i can find the status of the SGX drivers on a BB XM running 12.04?
<smplman> and audio also
<xranby_ac100> smplman: check the linaro website
<xranby_ac100> smplman: all the latest linaro releases are based on 12.04 with improved kernels and drivers where available
<xranby_ac100> smplman: sorry i think i gave you bad advice.. they only support the pandaboard nowdays
#ubuntu-arm 2012-07-12
<prpplague> just fyi for anyone interested, the call for participation for ELC-E end august 1 - https://events.linuxfoundation.org/events/embedded-linux-conference-europe/cfp
<lilstevie> janimo: well, personally I do not trust his stuff as far as I can throw him, he has been a massive pain with things like not being even able to identify the root device, and he doesn't really know what he is doing
<janimo> lilstevie, I don't know whom you are referning to anymore, I saw about 3 3.1 based kernel trees on xda :(
<lilstevie> <janimo> lilstevie, do you know anything about the status of the 3.1 jhinta kernel for tf101? It sort of boots here, but hangs on starting network manager
<lilstevie> ^^ that one
<janimo> lilstevie, ah ok. INdeed that's the last one I tried. It boots but touchpad at least does not work
<lilstevie> janimo: I have had serious problems with him in the past
<janimo> lilstevie, it baffles me that in such a large community there's no 'blessed' git tree where everyone tries to build from an improve on. Instead there are from scratch ports and people posting binaries and zips around on megaupload for others to test
<lilstevie> janimo: welcome to the world of donation hustling
<sveinse> I'm running qemu-debootstrap to fetch natty armel. However, often than not, it fails with could not download package, or failed to get release file. The server it's using is a local mirror on our lan (and its working fine). Have anyone else had any experience with this issue?
<tinti> sveinse: which error?
<Just-in> so running into a issue when trying to unpack the 12.04 image for Beagleboard XM. Im running the comand md5sum ubuntu-12.04-r3-minimal-armhf.tar.xz and it gives me errors.
<Just-in> tar: xz: Cannot exec: No such file or directory I checked and the file is in home. Did the md5sum check and it picked the file right up.
<ogra_> unpacking ?
<ogra_> where did you get that image from ? thats definitely not an official one
<ogra_> (there is nothing to unpack with the official ubuntu images)
<Just-in> got it from here http://elinux.org/BeagleBoardUbuntu#Demo_Image
<ogra_> right, not an ubuntu image,  ask the creator
<ogra_> (which is likely robert c. nelson (rcn-ee), judging by the url)
<Just-in> is there a better image for the beagle board xm you may know of?
<ogra_> https://wiki.ubuntu.com/ARM/OMAP that links to the official images
<Just-in> sweet got it.
<smplman> xranby_ac100: yea i looked at linaro stuff
<Just-in> WOO sd card is written and set up. Thanks for the help!
<ogra_> note that the desktop install requires a monitor for the initial setup
<ogra_> if you want to use serial you need to use the server image
<Just-in> Im useing the desktop one so ill grab a monitor with dvi.
 * ogra_ sighs, still no sign of life with the ac100 images
<Just-in> thats not good
<ogra_> janimo, did you ever look into why we cant use more than 2M for the ac100 initrds ?
<ogra_> seems the quantal one is 2.6M ... and quantal images hang at the toshiba splash
<janimo> ogra_, never looked at that, only knew - from you - that there is a limit
<janimo> ogra_, is this a know limitation of the bootloader, known by the whole ac100 community?
<ogra_> janimo, well, i dont know if its known by anyone, i just see it exploding if i pass a certain size
<janimo> ogra_, O
<janimo> I mean I'll have a look too :)
<janimo> ogra_, what did quantal add that increased the initramfs size? I recall you saying that's the reason we should not add Ubuntu SAUCE as cryptsetup would increase the size too much
<ogra_> well, i tink binaries just got bigger
<ogra_> though ...
<ogra_> it seems dropping the cmdline makes it boot ?!?
<ogra_> (which is indeed bad since i cant get a working tty without console=tty1)
<janimo> ogra_, so droppping the cmdline entirely lets it boot but any cmdline options causes hangs? that is indeed weird
<janimo> ogra_, is console=tty1 needed as a workaround for plymouth + 3.1 kernel issues?
<ogra_> no, its needed for the broken kernel
<ogra_> afaik marvin24 still waits for a fix from nvidia for that one
<janimo> ogra_, but the same thing that chmod -x plymouthd works around?
<ogra_> you dont get any tty output without it
<ogra_> so i got it booting but have a black screen
<janimo> ogra_, even X does not show?
<ogra_> no X in the installer :)
 * ogra_ tries with only console=tty1 added
<ogra_> janimo, hmm, ok, seems i got it up to a point where i get output and dont hang in the bootloader, but now it panics
<janimo> ogra_, ah the tarball installer. But good, progress :)
<ogra_> "stack-protector: Kernel stack is corrupted in: c06a594c"
<ogra_> no idea what to do with that ... especially since i cant scroll back now
<janimo> your own zImage or quantal deb?
<ogra_> quantal deb
<janimo> a cusotm kernel built is likely needed to debug it
<janimo> I can try debugging it
<ogra_> sigh, i feared that
<ogra_> well, i have a shiny new fast desktop workstation here ... just finished building it ... i guess i should start trying a cross build one day ;)
<janimo> ogra_, it's an excellent time to start cross compiling :)
<ogra_> haha
<janimo> if it is shiny new and fast you may get 2-3 minute kenrel builds
<ogra_> not really, once we have the calxeda HW cross building will so be last century
<janimo> my oldish core duo takes 20 min for a deb, and mucxh less for a barebones zImage
<ogra_> you will just build with -j2048 and get 30sec kernel builds :)
<janimo> you mean in 2015 :) ?
<janimo> or do you know somethig I don't
<ogra_> well, once we have the calxeda HW accessible for devs in the DC
<janimo> by that time 32 core Core i9 will kick any ARM server's butt anyway :)
<ogra_> lol
<ogra_> well, we worked with Martyn for two years to make sure we dont need to do any bringup work, so we had a guarantee that we can immediately put the HW into the london DC ...
<janimo> I used quad armadaxp for some builds and it is fast, but not quite as my laptop. is calxeda supposed to be much faster?
 * ogra_ still doesnt get why that stuff went to lex ... but hey ... no more arm team, ...
<ogra_> calxeda is supÃ¼posed to be much *more* ... not much *faster* :)
<ogra_> you will simply drown in spare cores ;)
<janimo> leave it to libreoffice builds to shame any hardware
<ogra_> pfft
<ogra_> if you build a kernel you can have a job for every .c file ... that should be really speedy ...
<ogra_> for LibO its indeed bound to the slowest step of the build
<janimo> memory will be a bottleneck for large c++ builds
<janimo> I am not sure how much RAM calxeda hw has
<ogra_> they have DIMM sockets afaik
<janimo> it may not make sense to have more than -j8 if that fills up 2-3Gigs
<ogra_> like the armadaxp you should be able to just pulg in ram ... though i think it can only address up to two G
<janimo> well 32bit still, so limited indeed
<ogra_> right
<ogra_> the big advantage of claxeda is that you simply can throw cores at  a task if you need them ...
<ogra_> s/cores/machines/
<ogra_> would be good if the kernel could just merge the ram of these into one big chunk ;)
<robher_> 4G RAM on calxeda
<Just-in> Does the 12/04 arm image come with SGX video acceleration on it?
<marvin24> janimo, ogra_: if you give me something to test, I can try it here
<ogra_> well, i doubt you would see much more than i on your screen :)
<marvin24> btw, we could try with a 2 MB zero file in the initrd to check if it is a loader or and expander problem
<marvin24> ogra_: but I have a serial interface
<janimo> Just-in, try the linaro panda images, those have sgx by default
<janimo> make sure you pick the right flavour, only some have x11+sgx enabled
<Just-in> will that work on a Beagle board xm?
<ogra_> 12.04 has full SGX support
<ogra_> oh, not on omap3
<ogra_> and linaro wont have that either
<Just-in> thats what i was afraid of.
<ogra_> TI doesnt release the omap3 SGX drivers built for hardfloat
<Just-in> should i back down to 11.10 then
<ogra_> robher_, oh, how do you address the last GiG then ? PAE ?
<Just-in> not sure how smooth it will run with out SGX
<ogra_> what do you want to run ?
<Just-in> so far all it will be is a pc for people to use during breaks till i get a tower in.
<ogra_> the framebuffer driver is fine for all 2D stuff, its pretty usable even without SGX for normal desktop bits
<Just-in> im sure they will want to watch youtube and all that.
<ogra_> LOL
<ogra_> you surely picked the wrong arch
<Just-in> im starting to agree
<ogra_> (no flash for arm linux ...)
<Just-in> then they have no youtube
<Just-in> they can live
<ogra_> right
<robher_> ogra_:  1G kernel, 3G user
<janimo> Just-in, listen to ogra, I am not uptodate with panda/sgx
<ogra_> janimo, not panda, beagle :)
<Just-in> i wonder if Zsnes will run ok.
<ogra_> i dont think that needs 3D support in any way
<Just-in> shouldnt
 * ogra_ has to run out and pick up his GF from a 50km away dentist appointment ... 
<Just-in> ouch
<ogra_> i wonder if other peoples GFs pick their dentist in the town they live in :P
<Just-in> mine didnt
<ogra_> heh, so i'm not alone
<Just-in> i think it so we have to go and get them
<Just-in> and listen to the drugged up convos on the drive home.
<ogra_> haha
<Just-in> aww man i just remebered i have some old usb game pads for the old cable set top boxes i could use for zsnes...
<Just-in> today is a great day
<marvin24> ogra_: I've put a 10MB file (full of zeros) into the initrd and it still boots
<marvin24> a 3MB file full of "randoms" gives an oops on boot ;-)
<janimo> marvin24, does a 10Mb initrd fit in the boot partition?
<marvin24> sure, if it's full of zeros it will be compress very well :-)
<marvin24> oops -> http://paste.ubuntu.com/1088351/
<janimo> marvin24, ah uncompressed 10M
<Just-in> what hardwar eyou running that on?
<marvin24> Just-in: ac100
<marvin24> the oops looks like it cannot find the root fs
<Just-in> well isnt that a neat looking netbook
<Just-in> dear god that came with 2.1 on it
<marvin24> sure my dear
<marvin24> yes, that was an epic fail
<marvin24> but a nice hw ;-)
<Just-in> man
<Just-in> would have liked to see 1gb ram matched with the tegra
<marvin24> given that most other have 1GB ...
<marvin24> chromeos would have been better on it
<marvin24> but linux desktop also works nice with zram enabled
<janimo> indeed, a new toshiba with tegra3 and 2Gb of RAM would be an awesome netbook. Too bad there's no market for it
<Just-in> yeah
<Just-in> i like my little netbook
<Just-in> best 700 i ever spent
 * marvin24 only spend 120 ...
<marvin24> for his 2nd one
 * Just-in has a I7 and nvidia 335m
<Just-in> nothign better then gaming on a plane ride
<marvin24> and you call this a netbook?
<marvin24> time has passes sooo fast ...
<Just-in> it has a 11 inch screen and no cd drive so..
<Just-in> a uber netbook?
<marvin24> or a heater
<Just-in> lol
<Just-in> Shockley doesnt get to hot
<marvin24> ah, "Initramfs unpacking failed: uncompression error"
<marvin24> so likely a kernel thing
<janimo> ogra_, git clone -b packaging-3.1  git://kernel.ubuntu.com/jani/ubuntu-ac100.git
<janimo> CROSS_COMPILE=arm-linux-gnueabihf-  ARCH=arm make paz00_defconfig
<janimo> CROSS_COMPILE=arm-linux-gnueabihf-  ARCH=arm make  -j 16 zImage
<janimo> or whatever, depending how many cores you have :)
<janimo> you probably get a zImage in 1 minute
<stgraber> ogra_: are today's omap4 images working for you?
<ogra_> stgraber, i havent tested omap4 since the alpha release
<ogra_> but they should
<stgraber> ogra_: it's failing with "oem-config/enable doesn't exist" here... I haven't been able to install for a reason or another for over a week now :) (testing with edubuntu though, but shouldn't make a difference)
<stgraber> starting an install with -d now, hopefully I can figure out what's going on
<marvin24> ogra_: I think the compressed initrd is either not loaded completely, or the end is overwritten after load
<marvin24> I tried to increase initrd_phys, but no change
<infinity> marvin24: With which bootloader?
<infinity> marvin24: If this is under uBoot, try setting "setenv initrd_high 0xffffffff"
<infinity> marvin24: If fastboot, no idea.
<marvin24> fastboot ...
<marvin24> I ask a u-boot user to try on #ac100
<infinity> If it's just too big, it could be getting truncated in the boot partition?
<marvin24> no, nvflash would fail
<marvin24> infinity: but if the kernel uncompresseds the initrd over the compressed initrd, we have a problem
<marvin24> AFAIK, the mem layout is kernel, compressed initrd, uncompressed initrd
<marvin24> there is also something tiny before the kernel
<ogra_> stgraber, erm ... are you sure you are testing a live image ? we dont roll preinstalleds anymore apart from ac100
<ogra_> (i dont think live does anything with oem-config by default)
<stgraber> ogra_: it's definitely a live image ;)
<ogra_> weird
<stgraber> ogra_: it's crashing right after hw-detect so I'm testing the new ubiquity as Colin added some debugging in that area of the code
<ogra_> i wonder where that comes from then ... we used to use oem-config indeed on the preinstalleds
<stgraber> based on some other bug reports on LP, the error might be completely unrelated to the problem ;)
<ogra_> heh, hopefully
<stgraber> well, maybe for you, but I'm not looking forward to debug something where the only error message has nothing to do with the problem :)
<stgraber> though it's pretty rare to get an "obvious" ubiquity bug these days, they're all weird race conditions triggering a crash 5 minutes after the actual problem happened
<Inoperable> hi
<Inoperable> anybody alive in here?
<ogra_> stgraber, i'll test omap4 tomorrow, in case you didnt get to the issue yet, i'll take a look as well
<ogra_> omap4 was simply out of my focus for a few days ... fighting with debian-cd and the ac100 issues
<Inoperable> ogra_, ac100 is a tegra2 thing, right?
<Inoperable> im trying to get debian on eee pad transformer
<Inoperable> is working pretty well as far as you use the console ;)
<ogra_> Inoperable, lilstevie does the same with ubuntu :)
<Inoperable> ogra_, yeah i know - just got his OLife opened on the console ;)
<Inoperable> and flashing it like 234 time
<Inoperable> i guess i'm gonna fry that flash ram sooner or later
<Inoperable> lilstevie, what is this tegra 2 flash thing? i wanted to beta test ;)
<marvin24> btw, will ubuntu pack http://nv-tegra.nvidia.com/gitweb/?p=tools/tegrarcm.git;a=summary ?
<marvin24> it is an open-source nvflash replacement
<infinity> Oo.
<infinity> Works on all the same devices?
<infinity> And does the same thing?
<marvin24> works on all tegra devices
<marvin24> only for flashing via usb
<ogra_> marvin24, i'm on it but it moved down on my TODO
<ogra_> srwarren pointed me to is two weeks ago
<ogra_> s/is/it/
<marvin24> ogra_: cool, thanks!
<infinity> ogra_: Do you maintain anything in Debian?
<ogra_> infinity, its the free nvflash that exists way longer than nvflash already (internally at nvidia)
<infinity> ogra_: I'd either (a) sponsor that for you, or (b) do the Debian maintenance.
<ogra_> infinity, well, i was wondering about DD :)
<infinity> Right, well, you maintaining and me sponsoring it for you is a good step on the road to DDship.
<ogra_> but essentially i'm doing that since i started at canonical ...
<ogra_> though being flash-kernel uploader in debian would massively help, stuff starts piling up again already ...
<Inoperable> marvin24, any docs for tegra-rcm?
<Inoperable> i just compiled it and it runs - but i dont know how to use it hehe
<Inoperable> the readme does not says a lot ;)
<Inoperable> well nevermind
<Inoperable> does anybody got a working 3.1 kernel on tegra2?
#ubuntu-arm 2012-07-13
<ndec> ogra_: hi. are you aware of any problem to play mp3 with 12.04? we get segfault with gst/libmad, and if we rebuild libmad with  âdisable-aso  there is no problem. i am surprised that I don't see a bug for that...
<ogra_> hmm, havent heard of that
<ndec> if you don't hear MP3, it's because of that ;-)
<ndec> do you have an ARM h/w running ubuntu close by?
<ndec> if you could try a gst-launch playbin2 uri=file://<xxx.mp3> that would be nice.
<ogra_> nothing with a desktop install atm (doing low level work here) but i will test that
<ndec> ok. thx
<Laney> does the daily live image (quantal-desktop-armhf+omap4) install onto the same sd card it's booted from?
<Laney> I was expecting to be able to install it onto a USB disk but it just went ahead and installed without giving me a choice of destination
<LetoThe2nd> um, have the images ever been different?
<ogra_> Laney, no, you need an USB disk
<Laney> I don't know what happened then
<ogra_> and you should get the normal ubiquity partitioning dialogs as on x86 ... if not, thats a bug
<ogra_> "use whole disk" should default to your USB disk
<Laney> I chose timezone, keyboard layout, username
 * ogra_ guesses he needs to do a test install to take a look, stgraber also reported some weird stuff yesterday
<Laney> and indeed cfdisk confirms the USB disk hasn't been touched
<ogra_> well, smells a bit like the installer is in oem-config mode ... stephane had an oem-config related error messsage too
<ogra_> though i have no idea why that would be
<Laney> I can believe that, yeah
<ogra_> if you look at the SD, do you actually have a squashfs on there ?
<ogra_> (second partition)
<ogra_> (in the casper/ dir)
<Laney> ogra_: I see no casper/ there
<ogra_> oh
<ogra_> which image did you download then ?
<Laney> http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-armhf+omap4.img
<Laney> argh
<Laney> hang on ...
<ogra_> looks ok to me
<Laney> spot the difference
<Laney> zcat quantal-preinstalled-desktop-armhf+omap4.img.gz | sudo dd bs=4M of=/dev/sdb; sudo sync
<ogra_> lol
<ogra_> K
<ogra_> i should probably add a quantal section to the wiki :P
<Laney> "check your tab completion"
<ogra_> the img file can just be dd'ed
<ogra_> no need for the zcat
<Laney> compressed?
<Laney> I think I got that from some wiki page
<ogra_> it isnt compressed
<ogra_> right, as i said, i need to update it for quantal
<Laney> oh, the desktop one, yeah
<ogra_> sudo dd if=quantal-desktop-armhf+omap4.img of=/dev/sdb bs=4M
<Laney> already doing it
<ogra_> good
<ogra_> theoretically that one should work ....
<ogra_> *theoretically*
<ogra_> *whistle* ...
 * Laney coughs
<Laney> this looks a lot more like ubiquity
<ogra_> phew
<ogra_> i hope the bootloader install works now or hw-detect ... it failed in one of these steps
 * ogra_ isnt sure which of the two
<Laney> ogra_: ah, bah, it failed
<ogra_> how ?
<Laney> not sure yet
<Laney> hopefully apport collects useful info, otherwise i'll look
<Laney> ogra_: bug 1024356
<ubot2> Launchpad bug 1024356 in ubiquity "quantal armhf+omap4 daily live 2012-07-12 crashed" [Undecided,New] https://launchpad.net/bugs/1024356
<Laney> need any more?
<ogra_> looks fine, thx
<Laney> cool
<ogra_> debconf.DebconfError: (10, "oem-config/enable doesn't exist")
<ogra_> aha
<Laney> seen before?
<ogra_> thats the same bug stgraber saw yesterday
<Laney> nice, feel free to dup it
<ogra_> i dont think he filed it actually :)
<ogra_> but he pinged me about it
<Laney> tsk
 * Laney retreats back to precise-server :P
<ogra_> ppisati, https://launchpadlibrarian.net/110025692/UbiquitySyslog.txt ... lots of "swapper/0: page allocation failure" ... and "smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped" in there
<ppisati> ogra_: was reading it
<ogra_> ah, k
<ppisati> is there a way to "open" the image and replace it with my own kernel? is it the live install?
<ppisati> ogra_: ^
<ppisati> the page allocation failures are a dup of this
<ppisati> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/746137
<ubot2> Ubuntu bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released]
<ppisati> and the workaround listed there didn't solve the problem
<ppisati> do we still use it?
<ogra_> ppisati, you should be able to replace uImage on the first partition as long as the module symbols match
<ppisati> ogra_: i'll try
<ogra_> the initrd is a capser initrd, thats a bit more tricky to rebuild
<ogra_> *casper
<ppisati> uhm
<ppisati> ogra_: btw with live installer
<ppisati> "Failed to unmoun partitions"
<ppisati>  /cdrom
<ogra_> that shouldnt cause a fatal error
<ogra_> (x86 USB installations dont have /cdrom either)
<ppisati> it's stuck there
<ppisati> and i can't go further nor back
<ogra_> todays image ?
<ppisati> yep
<ppisati> just downloaded
<ogra_> there was a ubiquity upload ....
<ppisati> let me retry
<ogra_> but that wont be on the image i guess
<ogra_> (uploaded 11:35 , images were published at 12:00 ... unlikely that it made it on todays build)
<ppisati> ogra_: so, /dev/mmcblk0p2 is mounted on /cdrom
<ppisati> ogra_: and the installer "needs to do changes to the partition table" but can't since a partition is stil mounted (/cdrom indeed)
<ogra_> err
<ogra_> are you trying to install to the SD ?
<ppisati> ogra_: seems it's impossible to installe don the sd card
<ogra_> thats why the partitioner shows that big fat warning if you select it :)
<ppisati> it means we can't install anymore on the sd card then
<ogra_> you can do it but need to create the rootfs partition beforehand and tell the partitioner to not recreate the partition table
<ppisati> what a mess
<ppisati> ok
<ppisati> i'll try on the usd hdd
<ogra_> (iirc the message the partitioner has says exactly that)
<ogra_> its an old and known restriction ...
<ppisati> does it say we can't install on the same card?
<ppisati> whatever
<ppisati> let me try with the usb hdd
<ogra_> you could take over the toolchain maintenance from infinity, i know he has ideas since a while how to fix it, but he never finds the time for it )
<ogra_> ;)
<ppisati> no way, infinity is doing a great work! :)
<ppisati> btw
<ppisati> "toolchain maintenance"? don't we get it from linaro?
<ppisati> i mean the toolchain
<ogra_> sure, but thats far from prefect ... there are still enough bugs to weed out ... and also bootstrapping a new arch like armhf (or aarm64 next) takes some manpower ...
<ppisati> i guess so
<ogra_> which is usually adams :)
<ppisati> but i though we got it from linaro and we didn't touch it
<ogra_> we ofte enough do
<ogra_> *often
<ogra_> look at who uploads eglibc ;)
<ogra_> he usually works very close with linaro
<ogra_> anyway, i know he has ideas for a fix, but that might require huge amounts of ram i fear (moving the installer to a tmpfs or so)
<ogra_> the partitioner shouldnt show the device to you though ... i think we should have a bug for this ...
<ogra_> i.e. if there is a pre-made partition on the device to install to, it should show it ... if the partition isnt there it should be hidden
<ogra_> that would make far more sense than the current warning nobody reads
<ppisati> to me the biggest drawback is that user now needs another medium besides the sd card to do the installation
<ogra_> right
<ogra_> thats on purposee
<ppisati> really?
<ogra_> demoing a system from the slowest media you can use on it isnt really a helpful demo
<ppisati> true
<ogra_> and thats largely what these images are, demos
<ogra_> beyond that, we really want to get rid of any arch specific deltas when not needed
 * ogra_ runs an ubiquity debug session to get more info 
<ppisati> ok
<ppisati> installation finisehed here
<ppisati> reboot
<ppisati> (i can;t type today)
<ogra_> its friday the 13th ... nobody expects you to be able to type :P
<ppisati> or to survive...
<ogra_> heh
<ppisati> cool
<ppisati> it took a bit
<ppisati> but it booted
<ogra_> nice
<ppisati> but now i need an sd install only (sprinting next week and i don';t want to bring my hdd around)
 * ppisati -> reinstall preinstalled
<ppisati> don't we produce omap4 preinsatalled anymore?
<ogra_> nope
<ppisati> there's only the server
<ppisati> i'll use that
<ogra_> as i said above. you can install to a pre-created partition on the SD
<ppisati> server is faster
<ppisati> i'll leave the desktop version @ home
<ppisati> and
<ppisati> btw, the splash screen didn't work during the boot
<ogra_> yep, known
<ogra_> bug 1018907
<ubot2> Launchpad bug 1018907 in plymouth "plymouth in quantal on arm does only boot with black screen" [High,Confirmed] https://launchpad.net/bugs/1018907
<stgraber> ogra_: trying with the latest ubiquity it actually worked here... but according to cjwatson and the ubiquity diff, there wasn't any fix in there...
<stgraber> so it's some kind of race and I got lucky, I guess
<ppisati> stgraber: omap4 live daily?
<ogra_> stgraber, my test install is in the last stages, lets see
<stgraber> ppisati: yep
<ogra_> ok, crashed here too ... apport running
<ogra_> (i ran with ubiquity -d, lets see if that shows the issue)
<stgraber> ogra_: check /var/log/syslog for a stacktrace containing "oem-config/enable doesn't exist"
<stgraber> ogra_: Colin added some debugging in ubiquity with the latest release to try and catch that bug (or another bug in the same area), so hopefully you'll have something in the log that'll help debugging
<ppisati> doh...
<ppisati> it did work here...
<ogra_> sigh
<ogra_> i have a totally different error
<ogra_> thats absolutely not helpful :(
<ogra_> (massive amounts of ext2 errors in syslog)
<stgraber> fun
<ogra_> yeah
<ogra_> i still dont get why the images default to use an ext2 partition for /boot ... we dont make any use of it
<ogra_> rsalveti, hey
<rsalveti> ogra_: hey!
<ogra_> rsalveti, do you have any ETA for new dkms drivers for omap4 that work with TILT ?
<rsalveti> ogra_: ti pushed a new version at the ppa, I'll be reviewing it later today to see if I can update the driver available at quantal
<rsalveti> but it should work with tilt
<ogra_> awesome, thanks ... since we have full jockey support all users get offered the installation immediately after first boot
<rsalveti> yeah, makes sense
<ogra_> so having a fixed package in the archive would help a lot :)
<rsalveti> the newer driver will probably require a few patches on some other packages, but I'll review those as well
<rsalveti> ogra_: ppisati: regarding the smsc95xx messages, the workaround was part of jasper
<rsalveti> and if we want to install the rootfs at a usb driver, we need it around from first boot
<rsalveti> otherwise you'll get tons of messages and it'll make the system slow
<ogra_> oh, i remember, that was a sysctl workaround
<ppisati> rsalveti: do you carry it in linaro? the workaround i mean
<rsalveti> ppisati: yup
<janimo> marvin24, ogra_ the free nvflash replacement does only work with unlocked devices of course. Useful since it is easier to install than nvflash if it's packaged but does not do anything which already can't be done
<janimo> such as flash locked down hardware :)
<janimo> marvin24, if X fails to start with 'TEGRA: Failed to initialize display controller library' where would you look for a fix?
<janimo> 2.6.39 kernel
<janimo> 2.6.36 works with the same userland/X
<marvin24> janimo: urg
<marvin24> update your kernel ...
<janimo> to 3.1 ?
<marvin24> or 3.0
<janimo> transformer not ac100
<janimo> works with 26.36
<marvin24> ah, you need the right display drivers for your kernel
<marvin24> every kernel has a different one
<janimo> just thought you know since it is tegra2 stuff
<marvin24> we just skipped this version ;-)
<janimo> heh, nvidia dev site is closed due to attacks at the moment
<janimo> but I'll try getting another L4T if that should solve it
<janimo> IIRc L4T had one for 2.6.38
<marvin24> yes, someone stole 450000 yahoo acounts and tries every site now with the same passports
<marvin24> I don't know if NV every released L4T for a .39 kernel
<janimo> and this is a reason for closing down a site? I am glad google did not follow nvidia devzone's lead :)
<marvin24> not yet ...
<marvin24> they are very nervous
<janimo> they have kernels for each L4T tagged appropriately but the reverse is not true
<janimo> ogra_, did you do some more detective work on the ac100 crash with large initrd?
<marvin24> janimo: fastboot can only handle 2 MB initrds
<marvin24> hard coded
<marvin24> which was more than enough, android uses 150 k !
<janimo> marvin24, is ubuntu already using best compression method? It's lzma right?
<marvin24> no, I always used xz (which is not so good)
<marvin24> we could try with lzma though
<janimo> I think they are comparable
<janimo> we need to get the ubuntu initrd size down for ac100 then I guess
<marvin24> yeah, nearly equal
<marvin24> but my testdata is a bit bad for this
#ubuntu-arm 2012-07-14
<lilstevie> ogra_: you about?
<mobile> helo world
<mobile> i have probleme to boot after change display in boot.scr
<mobile> version ubuntu 12.04 on beagleboard xm
#ubuntu-arm 2012-07-15
<robclark> hmm, Depends: linux-ti-omap4 but it is not installable
<robclark> any idea what makes apt-get think something can't be installed?
<robclark> (this is filesystem started via debootstrap, and yes I've added ti ppa and apt-get update'd)
<lilstevie> apt will think something is not installable if a condition in the depends cannot be met
<robclark> right, but any way I can get more output to hint at what that condition might be?
<robclark> I'm guessing something is missing because I started w/ debootstrap
<lilstevie> pastie the error message?
<robclark> not too much informative that I can see, but hang on
<robclark> lilstevie, http://hastebin.com/gaqedakido.vhdl
<robclark> oh, g-damn-it
<robclark> I think debootstrap gave me an armel filesystem
<lilstevie> apt-get install linux-ti-omap4
<lilstevie> see why linux-ti-omap4 is uninstallable
<robclark> I think all stuff in ti ppa is armhf
<lilstevie> but that will generally do it
<robclark> yeah, debootstrap gave me armel..  ok.. time for take-2
<lilstevie> heh
<lilstevie> well yeah, debootstrap is not used these days
<robclark> well, issue was I was doing debootstrap from my oneric filesys..  I did really trust dist-update for the armel->armhf upgrade
<robclark> but I didn't give --arch so I guess it just assumed armel
 * robclark didn't even realize there was an armel precise
<robclark> (s/did/didn't/)
<os_> hi
<os_> can i install ubuntu on a nokia phone which use symbian
<os_> ?
<os_> any answers?
<scientes> os_, must be armv7
<os_> yeh it is
<scientes> oh, symbian is a totally differn't OS
<os_> i know
<scientes> so it would be a PITA
<os_> can i replace it with ubuntu?
<scientes> well you would have to be able to modify the bootloader
<scientes> and you would have to have hardware support in linux for all your devices
<scientes> and chipset
<scientes> and arm hardware support really isn't that good
<os_> :(
<scientes> i mean there is good support for some hardware, but it isn't like x86, where one kernel you can just boot and see
<scientes> there are like a bazillion differn't incompatible kernel configs, so you have to compile for your specific chipset
<os_> :(
<os_> ok
<scientes> and anyways, ubuntu isn't really targeted at super-small devices and those type of input methods, although work is very appreciated
<os_> ok
<os_> thanks
<scientes> if you want to work on arm, i recommend one of theses well-supported boards: http://www.linaro.org/engineering/getting-started/low-cost-development-boards/
<scientes> here is a netbook: https://wiki.ubuntu.com/ARM/TEGRA/AC100/
<os_> ok
<os_> thanks
<scientes> linux/ubuntu can be installed in a chroot on android
<scientes> canonical is even selling it http://www.ubuntu.com/devices/android
<scientes> so, hardware support is actually pretty good, sans graphics drivers, but its pretty complex--and the way arm works, chips arn't neccicarily compatible, its not like you have a standardized base like x86
<LetoThe2nd> probably saying "there is no one-click-installer" would have sufficed. or a plain "no"
<LetoThe2nd> ;P
<scientes> LetoThe2nd, indeed
#ubuntu-arm 2013-07-08
<mijk> hey, anyone here using a Chromebook?
<hrw> mijk: yes
<mijk> did you install ubuntu using chrouton?
<hrw> no
<hrw> I used chrubuntu script
<hrw> once will sort out few things I will remove chromeos totally
<mijk> haha, that'd be good
<mijk> I assume you're using the Samsung?
<mijk> ARM-based
<hrw> yes
<mijk> okay, did you need to flash the firmware?
<hrw> otherwise you would not ask on #ubuntu-arm right?
<hrw> mijk: do what?
<mijk> lol, just making sure, just making sure
<mijk> flash the BIOS in order to go into developer mode
<mijk> I read an article that mentions this
<hrw> it is on other models
<mijk> but it's talking in general about all Chromebooks
<hrw> each chromebook has other way of going into developer mode
<mijk> the ARM just needs the keypress to get to it?
<hrw> arm one has it simple
<hrw> kind of
<hrw> press Esc+F4(aka Refresh)+Power
<hrw> keep Esc until get white screen with some text
<hrw> press Ctrl-D, then Enter
<hrw> sth like that - I always check on web
<mijk> that's all you need?
<mijk> that's awesome then
<mijk> I thought I was going to have to use git and compile a new firmware or something
<hrw> no
<mijk> no, I mean to get into developer mode
<hrw> http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-arm-chromebook#TOC-Entering-Developer-Mode
<mijk> so I still need to get a read/write u-boot then?
<hrw> no
<hrw> mijk: http://marcin.juszkiewicz.com.pl/tag/chromebook/ maybe will give you some more info
<mijk> I'll just use crouton for now to be safe :P
<hrw> never used and do not plan to
<mijk> chrubuntu is probably the best way to go but I don't feel like bricking my chromebook trying to get Ubuntu to boot natively ;)
<hrw> you can't brick this device
<hrw> in worst case you will restore it to out-of-box system
<benbloom> I'm confused. According to my understanding TS running Precise armhf should support udf. i've installed udftools through apt-get but it doesn't seem to work. Linux 2.6+ kernel should support udf. Am I missing something?
<benbloom> EDIT I'm confused. According to my understanding TrimSlice running Precise armhf should support udf. i've installed udftools through apt-get but it doesn't seem to work. Linux 2.6+ kernel should support udf. Am I missing something?
#ubuntu-arm 2013-07-09
<maxinux> benbloom:  cat /proc/filesystems
<maxinux> the kernel may not have been cmopiled  with it
<benbloom> yes maxinux: http://paste.ubuntu.com/5857005/ not there! is there a way to add support after the fact?
<maxinux> recompile the kernel w/ udf support
<maxinux> add it as a module, and make modules modules_install
<maxinux> then modprobe it and pray
<maxinux> otherwise you may have to re-run make
<benbloom> hmmm. sounds like a big job. I've been thinking about starting with ubuntu-server from scratch instead of the preconfigured install provided by compulabs. maxinux, is there a good tutorial on how to cross-compile armhf on my i86 pc for use on the other device?
<maxinux> there is a cross compile dev kit you download for that
<maxinux> its pretty easy once its setup
<benbloom> is that gcc-arm-linux-gnueabihf ?
<benbloom> I've only used ubuntu installers for this. but I've been wanting to shake my dependence (pun intended) on canonical and apt. i'm very comfortable on the CL and in bash... just a noob when it comes to the low level stuff
<maxinux> benbloom:  believev that be it
<maxinux> and you set your CCPREFIX to arm-linux-gnueabihf-
<benbloom> thanks
<benbloom> so maxinux, Sorry to be a pest, but I've been following http://www.cnx-software.com/2012/03/27/cross-compiling-the-arm-linux-kernel-in-ubuntu-12-04-lts/ and I was wondering is there a config file where I decide which modules I want in and which I don't for this build?
<maxinux> in the github repo its in is a .config file
<maxinux> so you can simply make oldconfig;make
<maxinux> or make menuconfig
<maxinux> to update options
<benbloom> thx.
<maxinux> np
<maxinux> most people dont cross compile on a daily basis ;)
<benbloom> yeah. It's getting more common though with all the micro-PCs coming to market.
<maxinux> yah
<maxinux> though a beaglebone is fast enough to compile its own kernel
<benbloom> Trimslice only has HDMI for video output. I use it headless via ssh
<maxinux> need to add serial support?
<maxinux> id hope that was compiled it but not in the config.txt
<benbloom> it has a mini-RS232 port. I'd like to be able to use my old laptop as an interface if I could. the preconfigured ubuntu install that compulabs has released is really not designed with the uses I am looking for in mind.
<benbloom> is there descriptions of what each configs are fore in arch/arm/configs?
<benbloom> i see that there's a 'tegra' one, I guess i should try that?
<maxinux> no
<maxinux> ti omap3/4
<srwarren> Are there mirrors of ports.ubuntu.com?
<ogra_> srwarren, sadly no (there might be some inofficial ones, not sure)
<srwarren> ogra_, pity; that makes running debian-cd a little harder. Well, generating a local mirror before running it, that is.
#ubuntu-arm 2013-07-10
<mevon> hello anyone ever build an SD boot for an A10S device?
<drasko> Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/main/o/openssl/openssl_1.0.1-4ubuntu5.9_armhf.deb  404  Not Found
<drasko> any ideas?
<ogra_> apt-get update
<drasko> ogra_, error still persists
<ogra_> what release are you using ?
<drasko> Precise LTS
<ogra_> do you have precise-security enabled ?
<drasko> nope
<drasko> should I?
<ogra_> yeah
<drasko> OKm let me retry
<ogra_> seems 1.0.1-4ubuntu5.9 was superseded by 5.10
<ogra_> ah, but it landed in precise-updates, not security, so make sure to have that enabled
<drasko> yes, theser are bot enabled infact
<drasko> but I did not have multiverse and universe
<drasko> just restricted
<ogra_> well, you are downloading something from main there
<ogra_> so that wont matter
<ogra_> you definitelly need precise-updates though
<drasko> wll enabled, still having the same error
<drasko> Err http://ports.ubuntu.com/ubuntu-ports/ precise-updates/main openssl armhf 1.0.1-4ubuntu5.9
<drasko> 404  Not Found
<drasko> I did apt-get update, off course
<ogra_> precise-updates doesnt have 2.9
<ogra_> err
<ogra_> 5.9
<ogra_> why would it try to download that
<drasko> No idea
<ogra_> grep updates /etc/apt/sources.list
<ogra_> how do your sources.list lines look like for it ?
<drasko> http://pastebin.com/vjMn97D0
<infinity> There's no way that would persist after an 'apt-get update' unless you're behind a reverse proxy that's messing with you.
<drasko> infinity, no, but I am in chrooted ARM system with wemu
<drasko> *qemu
<infinity> That shouldn't matter.
<drasko> should not matter, though
<ogra_> hmm, looks all fine
<infinity> Show me the output of apt-get update?
<ogra_> i clearly see https://launchpad.net/ubuntu/precise/+source/openssl/1.0.1-4ubuntu5.10
<ogra_> and http://ports.ubuntu.com/ubuntu-ports/pool/main/o/openssl/ has it too
<infinity>    openssl | 1.0.1-4ubuntu5.10 | precise-security | source, amd64, armel, armhf, i386, powerpc
<infinity>    openssl | 1.0.1-4ubuntu5.10 | precise-updates | source, amd64, armel, armhf, i386, powerpc
<ogra_> yeah
<infinity> Yeah, 5.10 is clearly current in both updates and security.
<infinity> drasko: Output of "apt-get update" and "apt-cache policy openssl"
<drasko> http://pastebin.com/wGtmCbBe
<drasko> http://pastebin.com/eQ8uitpv
<ogra_> hmm, any proxy in your LAN ?
<drasko> nope
<drasko> All used to work just fine
<infinity> Well, that's absolutely not what's in the Packages files on ports...
<infinity> Furthemore, 5.10 was released to updates 6 days ago, so if it's a proxy messing with you, it's a really, really broken proxy.
<infinity> drasko: rm /var/lib/apt/lists/* and update harder?  If you still get stale packages files, it's definitely a proxy between you and us.
<drasko> infinity, after I removed the problematic file the problem is corrected
<drasko> thanks
<srwarren> So, I want to build an install CD (really an install SD card) for Ubuntu for my ARM system...
<srwarren> I've built the saucy kernel and validated it boots OK on my system
<srwarren> I've built a debian-installer image, both netinstall and cdrom (for armhf generic) and see that the installer runs when I boot with the initrd
<srwarren> Next up I need to create the CD image with all the packages etc. At the moment, I don't really care if it's server, alternate, ... just something (I only have a serial port on many of my systems anyway, so text mode and non-live is best for now)
<srwarren> Should I be looking at ubuntu-cdimage to do that? It seems to have all kinds of hard-coded SSH host names and paths like /srv/cdimage.ubuntu.com, which makes running it locally for dev/test problematic...
<cooloney> hey ogra_ and rsalveti
<cooloney> do you guys have any idea about the questions from srwarren?
<rsalveti> yeah, need to check how that's done in ubuntu-cdimage/livecd-rootfs
<rsalveti> ogra_ should know most of what is needed there
<rsalveti> guess you could create a similar image as done for omap4
<cooloney> rsalveti: thanks, how's going? long time no talk.
<srwarren> rsalveti, yeah I'm trying to look at ubuntu-cdimage now. The issue is it seems a little tied to Canonical infra-structure, so I'm not sure how to get it running locally
<rsalveti> cooloney: hey, good, indeed :-)
<rsalveti> cooloney: busy with ubuntu-touch, and you?
<cooloney> rsalveti: yeah, i know, i'm playing with v4l2 camera stuff for Tegra
<rsalveti> cool
<rsalveti> upstreaming or just enabling it atm?
<cooloney> rsalveti: so you have a real ubuntu phone to play. hehe.
<rsalveti> yeah :-)
<cooloney> rsalveti: oh, firstly make that works internally and upstreaming it later.
<rsalveti> got it :-)
<rsalveti> where are the tegra 4 devices? :-)
<cooloney> rsalveti: hah!!, try project shield!
<rsalveti> yeah, that's a nice one
<cooloney> rsalveti: good device for hacking
<rsalveti> should be quite fast
<cooloney> yeah, definitely. will you guys come to CA for some conference this year?
<rsalveti> not sure yet, but we'll see
<rsalveti> would be nice to have at least a sprint there
<cooloney> i met some forks 2 months ago in Oakland. but didn't see you there
#ubuntu-arm 2013-07-11
<vipzrx> hello
<vipzrx> how can I find the path which gcc used to do with #include <XXX>
<vipzrx> when I am reading the source code , the cecet tells me that it can not find some header files location . Now I must tell the cedet where are these header files /
<vipzrx> it the file /home/jb/Documents/soft/soft_src/panda-linaro/system/core/init/init.c , there are a lot of #include <XXX.h> . I want to know   the location of XXX.h
<Offshore> greetings, guys
<Offshore> im building headless custom arm device (AllWinner A11); got kernel compiled, it runs with debian rootfs perfectly
<Offshore> but when i try ubuntu 13.04 armhf core, i cant boot due to plymouth
<Offshore> how can i tune it to avoid any graphics or better avoid any non-failsafe techniques?
<Offshore> uart log:
<Offshore> ...
<Offshore> <4>init: plymouth main process (50) killed by ABRT signal
<Offshore> <4>init: plymouth-splash main process (243) terminated with status 2
<Offshore> <4>init: failsafe main process (291) killed by TERM signal
<Offshore> <4>init: plymouth-stop pre-start process (414) terminated with status 1
<Offshore> ....and hang up (kernel panic?)
<Offshore> (have no idea what happens)
<Offshore> phuken hate that :(
<Offshore> got to use debuan i think
<Offshore> *debian
<ogra_> just remove the plymouth upstart jobs ... its trivial
<Offshore> ogra_, after a little bit of googling i realize that plymouth is kinda hardcoded thing
<ogra_> you dont need to start it
<ogra_> just remove the jobs and it will work
<ogra_> (or fix your kernel to have proper fbcon support)
<Offshore> so, just rm -rf /etc/init/plymouth* ?
<ogra_> yeah
<Offshore> ogra_, fbcon? the only way to connect to device is uart (/dev/ttyS0)
<ogra_> well, then proper VT support at least
<Offshore> well. what .config flags related to this thing?
<Offshore> *are
<Offshore> i just want to keep rootfs as untouched as it possible (rm -rf /etc/init/plymouth* is the last resort)
<Offshore> hehe.
<Offshore> ogra_, no luck with rm -rf /etc/init/plymouth*
<Offshore> <4>init: failsafe main process (204) killed by TERM signal
<Offshore> and hang up
<ogra_> how did you create your rootfs ?
<Offshore> first tried ubuntu-core-13.04-core-armhf.tar.gz
<ogra_> well, thats for building something on top
<ogra_> not really something to boot
<Offshore> ive also tried debootstrap --verbose --arch armhf --variant=minbase --foreign raring /target
<ogra_> no
<Offshore> (then cp quemu -- mount proc&pts -- chroot into target and second stage, of cause)
<ogra_> use qemu-debootstrap from qemu-user-static
<ogra_> that will just create a cross chroot for you
<ogra_> then you indeed need to make sure to have a serial getty configured, else you will never get a login on the serial port
<Offshore> whats the diff between qemu-debootstrap and debootstrap --arch armhf ....... then cp /usr/bin/qemu-arm-static target/usr/bin and chroot into there?
<ogra_> qemu-debootstrap uses binfmt to actually provide you the ability to just chroot into the root you created
<ogra_> it just saves you from a ton of extra work
<Offshore> ok ill try, but its not a problem right now
<ogra_> did you set up a proper serial config yet ?
<Offshore> echo 'T0:2345:respawn:/sbin/getty -L ttyS0 115200 linux' >> /etc/inittab
<ogra_> no
<ogra_> follow the serial howto from the ubuntu wiki
<ogra_>  /etc/inittab isnt used since ages
<ogra_> like 4 years or so
<Offshore> ogra_, thanx a lot
<Offshore> finally got kernel initialized
<ogra_> :)
<Offshore> by the way
<Offshore> why the f language-pack-en depends on firefox localization package?
<Offshore> even when firefox is not installed
<ogra_> you want the -base package
<ogra_> the above is a toplevel meta package for languages
<infinity> It doesn't depend on it...
<Offshore> and until raring it (firefox localization package) even was not available on armhf, so dep was broken
<Offshore> infinity, sorry, does not depend of cause, but recommends it
<infinity> (base)adconrad@cthulhu:~$ apt-cache show language-pack-en | grep ^Depends
<infinity> Depends: language-pack-en-base (>= 1:13.04+20130418)
<infinity> (base)adconrad@cthulhu:~$ apt-cache show language-pack-en-base | grep ^Depends
<infinity> Depends: locales (>= 2.3.6), language-pack-en (>= 1:13.04+20130418)
<infinity> (base)adconrad@cthulhu:~$ apt-cache show locales | grep ^Depends
<infinity> Depends: libc6 (>= 2.9-0ubuntu10) | libc6.1 (>= 2.9-0ubuntu10)
<Offshore> one moment please.
<infinity> In precise, it did Recommend it, yes.  But recommends don't prevent you from installing without.
<infinity> And, of course firefox-locale-en is available on armhf.
<infinity> (And always has been)
<Offshore> # apt-get install language-pack-en
<Offshore> ........
<Offshore> The following extra packages will be installed:
<Offshore>   firefox-locale-en language-pack-en-base
<infinity> apt-get --no-install-recommends install language-pack-en
<Offshore> indeed :)
<infinity> Not that having firefox-locale-en installed hurts anything.
<Offshore> well i just wanted to say that its better not to be recommended
<infinity> And it's not in saucy, so you win. :P
<Offshore> infinity, my apologies, i cant reproduce now the situation i met some time ago about firefox-locale-en package cannot be found in armhf reps. maybe it was before precise
<Offshore> infinity, hah, finally :)) but stable saucy'll be available only in autumn
<Offshore> so, concluding plymouth stuff. I WAS AN IDIOT :) and have not properly configured serial console :)))
<Offshore> and it wasnt necessary to remove it from upstart
<Offshore> debian worked correctly because i conf'ed serial console in /inittab
<ogra_> ah, lucky you, plymouth breaks the boot with kernels that have issues with VT and fbcon
<ogra_> means your kernel is fine then :)
<Offshore> :)
<Offshore> thank you guys, again
<Offshore> udevd[171]: error changing net interface name wlan0 to wlan2: Device or resource busy
<Offshore> cant understand why does it do that (renaming)
<infinity> Offshore: A rule in /etc/udev/rules.d/70-persistent-net.rules perhaps?
<ogra_> because it created a persistent rule for your laptop when you built the chroot
<ogra_> would be my guess
<Offshore> ogra_, hmm.
<Offshore> infinity, ill take a look, thanx
<Offshore> ogra_, "sudo: unable to resolve host ubuntu-gnome" lol. You definetely right about qumy-debootstrap :))
<ogra_> :)
<Offshore> infinity, is there any common way to totally flush /etc/udev/rules.d/70-persistent-net.rules ?
<Offshore> it seems that is it
<Offshore> (i mean not editing)
<Offshore> *directly
<infinity> Offshore: hand-editing is the way to go.  Just delete the offending line(s).
<Offshore> well manual edit is always an option
<Offshore> awwww another question :)
<Offshore> sometimes system hangs on reboot
<Offshore> just before reboot
<Offshore> i cant fig out conditions for it
<Offshore> [sw-ehci1]: close clock
<Offshore> <6>[sw-ehci1]: shutdown end
<Offshore> [sw_hcd0]: sw_hcd shutdown start
<Offshore> [sw_hcd_host0]: Set USB Power OFF
<Offshore> [sw_hcd0]: sw_hcd shutdown end
<Offshore> <0>Restarting system.
<Offshore> [  203.290000] Restarting system.
<Offshore> ...and over
<infinity> That would be a kernel bug.
<infinity> Userspace is long gone by then.
<infinity> So, if your kernel (sometimes) fails to reboot your hardware, that's between you and your kernel.
<Offshore> but its... sometimes! not always :/
<infinity> The sometimes could be a clue.  If it only happens when a certain device is plugged in, on Tuesdays when the moon is full, dunno.
<infinity> But it could just as easily be sketchy hardware/firmware.
<Offshore> for me its absolutely random
<Offshore> kernel hacking is not my best practice
<Offshore> maybe i just can arm the watchdog? :))
<infinity> Anyhow, definitely a kernel (or hardware) problem.
<Offshore> hm, "arm the watchdog"
<Offshore> oh my goddess
<Offshore> at last.
<Offshore> earlier i hav yp to 80% rw packets dropped on wlan interface
<Offshore> *have up
<Offshore> magic.
<Offshore> ubuntu.
<Offshore> :))
<Offshore> http://raw.aopdg.ru/temp/dscn1937_skjhbveo587bgy.jpg
<infinity> I want to meet the person at Allwinner responsible for their naming scheme, so I can smack them.
<infinity> And the same with Apple.
<infinity> "The A5 is an A9, and the A10 is an A8" is the most confusing sentence ever.
<Offshore> yup. allwinner's a10 is more powerful than a13
<maxinux> they are allwinners @ allwinner
<Offshore> and a20 is more powerful than a10
<Offshore> magic, again
<Offshore> however their cpus are convinient, cheap and powerful
<Offshore> and solderable by hands :)
<Offshore> # sudo halt -p
<Offshore> ...
<Offshore> [sw_hcd_host0]: Set USB Power OFF
<Offshore> [sw_hcd0]: sw_hcd shutdown end
<Offshore> <0>Power down.
<Offshore> [ 1447.390000] Power down.
<Offshore> [axp] send power-off command!
<Offshore> [axp] set flag!
<Offshore> [axp] reboot!
<Offshore> so tired.
<Offshore> reboot => sometimes halt
<Offshore> halt => everytime reboot
<Offshore> damn
<Offshore> ogra_, https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap, its really useful, thanx
<ogra_> wow, thats massively outdated
<Offshore> so "mk-sbuild --arch armhf raring" wont work? :(
<Offshore> ogra_, if i compile kernel with CONFIG_IP_PNP (IP: kernel level autoconfiguration), do i still need dhcp3-client?
<Offshore> infinity
<infinity> That's really meant for very simple PXE-type setups.  It won't do any fancy userspace stuff that dhcp-client does (like, say, setting your DNS servers from dhcp)
<infinity> So, if you're happy with only contacting hosts by IP, and completely disabling any userspace networking fanciness, sure. :P
<Offshore> uh :(
#ubuntu-arm 2013-07-12
<Kevin`> where can I get the kernel configuration or binary package for a newish kernel version for pandaboard?
#ubuntu-arm 2013-07-14
<terramir> quick question what kind of arm horse power would you need for visual pattern recognition like as in face recognition just different
<PRISMAdmin> clear
<PRISMAdmin> Guys, how well does the ARM build of Ubuntu run on the nexus 10? I know that it runs fairly well on the Nexus 7 but what about the nexus 10? I cannot find any resource about it, prolly drowned by the whole Ubuntu Touch deal
<twb> lilstevie: ping.  What's the status of current transformers?  My old TF101 just completely hung twice in a row for no obvious reason, so maybe it's time to upgrade.
<twb> I noticed one in a store was running Windows, which makes me suspect it can't run linux at all
#ubuntu-arm 2014-07-09
<Martyn> Hey all
<Martyn> Jon's on a train, I'm on a plane ... all us ARM-sever people are scattered around the planet
<mahmoh> biabiyatch!
#ubuntu-arm 2014-07-12
<virtouni> Hey, folks. Do I get access to software repositories with ARM images, the same way I get apt-get on x86?
<infinity> virtouni: Yes.
<virtouni> infinity: All three architectures listed on the Ubuntu Wiki ARM page?
<infinity> virtouni: I'm not sure which wiki page or arches you're referring to, to be honest.
<virtouni> infinity: https://wiki.ubuntu.com/ARM
<infinity> virtouni: We support two architectures (armhf, which is ARMv7 hard float, and arm64, which is the 64-bit ARMv8)
<virtouni> No forget that, tell me where I can read more about it.
<infinity> You mean subarches, or platforms, I guess, if you're referring to that page, though it's 2 years out of date.
<virtouni> Apparently so. Where can I get newer info?
<infinity> To be fair, I'm not sure if anyone's been updating the wiki docs, so the answer might be "nowhere".
<virtouni> Eh, well, let me describe the situation, if it can be of help to help me.
<infinity> The d-i netboot images are sort of self-documenting in the "which boards can you boot without putting a bunch of time into it" way.
<infinity> http://ports.ubuntu.com/ubuntu-ports/dists/trusty/main/installer-armhf/current/images/generic/netboot/
<virtouni> My friend wants a tablet for general purpose computing. Of course Android or Windows RT is out of the question. So we'd like to know what devices we can get so that we may flash it and have our way with.
<infinity> Oh.
<infinity> I think you'll find that pretty much no tablet works "out of the box" with any general purpose Linux.
<infinity> There's going to be a lot of hacking on your end.
<virtouni> That's a given.
<virtouni> But we need a starting point.
<infinity> Well, by which I mean there won't be disrto provided kernels, which extends to not having distro images or installers either.
<virtouni> The main issue, as I see it, are GPU driver and the ability to flash, going beyond arch compatibility.
<infinity> You'll get to hack up a kernel on your own, then build a distro root on there (using a rootfs tarball like Ubuntu Core can help a bit)
<virtouni> Ugh...
<virtouni> I thought at least some Ubuntu release would be able to be used.
<virtouni> What of the Nexus devices?
<infinity> Granted, if it's an Android device, it already has a Linux kernel. :P
<virtouni> Can I flash a Nexus device with standard Ubuntu instead of Touch?
<infinity> We ship unsupported kernels for some Nexus devices.  Still no installers or "images", though, you get to put the bits together yourself.
<infinity> Unless, as you note, you install Ubuntu Touch instead.
<infinity> But, spoiler alert, those are all still Android kernels and Android drivers, just with a regular Linux userspace stuffed on top. :)
<virtouni> Can't I strip Touch packages from the image and introduce desktop packages?
<infinity> Sure, if you put the image in read-write mode, it's just a normal Ubuntuish thing you can apt-get install and remove with.
<infinity> Except for the weird container setup required to make the android/linux hybrid work.
<virtouni> Well, that's quite straight-forward isn't it?
<virtouni> Can I get repo though?
<infinity> Yeah.  It all uses the same repositories.
<virtouni> YEAH!
<infinity> And most everything is built on all 6 architectures.
<virtouni> Which six?
<infinity> i386, amd64, armhf, arm64, powerpc, ppc64el
<infinity> My point being that there's no "Ubuntu ARM" product, per se, it's all just Ubuntu, once you manage to get a userspace going on some device, it's all the same thing.
<virtouni> So, we need to mount the image, and the chroot? And what's the weird container? (I need to know so that I don't mess with it accidentally)
<infinity> Just that kernel, bootloader, and installer support on ARM devices sucks, because ARM device OEMs suck. :P
<infinity> I actually know shockingly little about how Touch devices are laid out.
<infinity> You might be better off asking ogra_ for more details if/when he's around.
<virtouni> I'm just concerned that ARM packages available though they might be, they won't work on some devices due to the clusterfuck of of implementations
<infinity> But, in theory, it should be simple to install touch on a Nexus device, flip to read-write, and remove all the bits you don't like.
<infinity> And add the bits you want.
<virtouni> Yes, now I only need to know how to get to the point of apt-geting them. chroot, as I suggested?
<infinity> A chroot tarball on a working Android system is a simple way to go.  But that's not the same as "installing a touch image", which should be covered here: http://developer.ubuntu.com/start/ubuntu-for-devices/installing-ubuntu-for-devices/
 * infinity wanders off to start his weekend.
<virtouni> By chroot, I meant chrooting into the mounted Ubuntu Touch. Mounted on a desktop PC or something. Before flashing the device with it.
<virtouni> I don't see where the image comes in in the instructions. :(
<virtouni> Well, I'll be back later, thanks a lot infinity.
#ubuntu-arm 2015-07-06
<bpye> Running 14.04, gdb spits out "Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error", I've built the binary locally so I am under the impression it should be debuggable...
<RoDuS> hello
<RoDuS> newb with a question
#ubuntu-arm 2015-07-08
<Aleksa> I want to bring ubuntu to my tablet Prestigio. I have read some official Ubuntu pages and I am still not sure if I get it right.
<Aleksa> Is ALL I need Root file system (Rootfs) with custom kernel image?
<Aleksa> I understand that kernel is needed.
#ubuntu-arm 2015-07-09
<ar4imale> Hi guys ! We have couple wyse t50 thinks cliens with very old ubuntu 10.4 on board. We want to upgrade it, but we uname to found property image to do it. Can you advise us how we can update ubuntu 10.04 as minimut up to 120.4 via internet ? do-release-upgrade and update-manager unable to see new version and wyse support is not very frendly
<ar4imale> may be possible to change repo manually ?
<ar4imale> and run aptitude update after ?
<infinity> ar4imale: You could just s/lucid/precise/ in sources.list and 'apt-get update && apt-get --purge dist-upgrade', but you'd want to pay very close attention to what apt tells you it plans to do and see if it looks scary. :P
<ar4imale> infinity: thank you very much
<ar4imale> I`ll try
#ubuntu-arm 2015-07-10
<k82wong> Hi, I'm running a fork of ubuntu-arm and my apt-get isn't working. I can connect to the internet, download certain packages, but I can't install things like htop or i3
<k82wong> Can someone help me? I don't know if the source.list is phony or whatnot\
<k82wong> My /etc/apt/source.list is paste.ubuntu.com/11857261
#ubuntu-arm 2015-07-12
<mijk> hi
<mijk> any good ARM laptops that run Ubuntu 100%?
#ubuntu-arm 2016-07-11
<theptr> hi someone who knows stuff about the pine64 ?
<theptr> !logs
<superman_> Hello Friends - I am a newbie Pi user, purchased my Pi 3 device a few days ago. I have been having difficulty setting up the wifi. When I enter my wep password into the field. Nothing happens. Also Please note, when I hover the mouse over the wifi icon - it says "wlan0: not associated". Any help would be greatly appreciated.
#ubuntu-arm 2016-07-12
<GinoManWorks_> Hey, I have an apt question. So I have a bunch of rPis which I administer but they're not connected to the internet. but I want to perform the updates on them so they're caught up with an updated image burned into future rPi units. The form of the update I want to be a set of .debs and an install script that installs them in order which is then tarred and gzed and then attached to the end of a shell script that performs the update. Is that
<GinoManWorks_> possible? has anyone ever done something like this before?
<genii> !offline
<genii> Ah, right, no ubottu here
<GinoManWorks_> sorry that didn't go according to plan
<GinoManWorks_> maybe I'm crazy for thinking I can do this but...
<GinoManWorks_> I figured it was worth the question
<genii> GinoManWorks_: "If you need to download Ubuntu packages using another machine or OS, check the desired packages in Synaptic and select File > Generate package download script. See also !APTonCD"
<GinoManWorks_> yes
<genii> ...is what the bot would have come back with
<GinoManWorks_> ok. What if you don't have synaptic because you have no gui installed
<ogra> genii, there used to be one ... not sure why it isnthere
<ogra> bug #1
<GinoManWorks_> I see a "ubot9"
<ogra> (i see it in the user list too)
<ogra> yeah
<k1l> some time ago some bots were not joining all channels. logbot was missing some channels, too
<GinoManWorks_> Yeah, right now synaptic requires X and I don't have any X installed
<GinoManWorks_> APTonCD seems promising to a degree but it requires you to basically copy every package on the system now into the external device which would make my script go from being 500 lines to several gigabytes
#ubuntu-arm 2016-07-13
<msvb-lab> A little lost (sorry) but I'm looking for some official collaboration from Canonical for a few forthcoming educational events, workshops. Anyone know who the contact would be for embedded/IoT Ubuntu education?
<rbasak> msvb-lab: http://www.ubuntu.com/internet-of-things/contact-us perhaps?
<rbasak> msvb-lab: or http://partners.ubuntu.com/programmes/iot has a link.
<msvb-lab> rbasak: Thank you, I'll give the two links a glance.
#ubuntu-arm 2016-07-14
<curious482> i everyone!  I'd like to know how exactly I can get these prebuilt files (http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/) working from Qemu on Windows, to emulate an Arm architecture running Ubuntu Core?
<curious482> s there some kind of special kernel image I would need?
<curious482> Is
<curious482> I tried to start with a prebuilt Raspberry Pi Image but after copying the above files into a new raw img (after mounting them from windows, which might bork permissions) I'm not sure how to rewrite the raspberry pi's run batch file for qemu, which said:
<curious482> qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2012-07-15-wheezy-raspbian.img -kernel kernel-qemu -m 192 -append "root=/dev/sda2"
<curious482> ow can I change that to instead use the "ubuntucoreraw.img" file I created in Windows?  What kind of Kernel should I be using or where do I get it?
<curious482> thanks so much for any help.
#ubuntu-arm 2016-07-16
<Nishikino-Maki> i use the apt-get install the kernel (linux-headers-generic \ linux-image-generic) but i reboot my arm device it's still boot to old kernel(3.6) not new kernel(4.2)
<Nishikino-Maki> btw my arm device is OrangePi PC
<jost> is ports.ubuntu.com down?
<jost> Seems to be back online.
#ubuntu-arm 2017-07-14
<leafwindd> Hi, besides the server arm64 iso, is there a desktop iso for ubuntu ARM that would work on an armv8 laptop?
#ubuntu-arm 2017-07-15
<Fahr> Hello all, I am trying to cross-compile some software for arm64 on an amd64 - one of the dependencies is libboost-all-dev. I know there is an arm64 version of this package (https://launchpad.net/ubuntu/xenial/arm64/libboost-all-dev/), but cannot seem to get it installed. I did a dpkg --add-architecture arm64, followed by an apt-get update, but the only libboost-all-dev package I see is the
<Fahr> amd64 one - can anyone tell me what step(s) I am missing here?
#ubuntu-arm 2018-07-09
<chris_99> Hey, i'm just wondering, i'm compiling for ARM (Pi) which is working fine with the armhf libs i installed via apt-get, but i also want to compile a program using an am64 version of a library (msgpack) for both amd64 and armhf, is there not a way to install libmsgpack-dev:am64 and  libmsgpack-dev:armhf?
