#ubuntu-arm 2009-04-01 <ogra> lool, why is your padding code so complex ? * ogra would have used: dd if=/dev/zero bs=1 count=$pad 2>/dev/null >> $FILE <ogra> lool, YAY ... padded initramfs works with my latest image build ... <kennethreitz> !ls <ubot4> The linux terminal or command-line interface is very powerful. Open a terminal via Applications -> Accessories -> Terminal (Gnome) or K-menu -> System -> Konsole (KDE). Guide: https://help.ubuntu.com/community/UsingTheTerminal <lool> ogra: Uh my padding is exactly what you wrote: -dd if=/dev/zero bs=$pad count=1 2>/dev/null <lool> And BTW that is problematic for RAM issues, but well... <ogra> its way more complex piping dd <ogra> "dd if=/dev/zero bs=1 count=$pad 2>/dev/null >> $FILE" vs: "(cat $ifile dd if=/dev/zero bs=$pad count=1 2>/dev/null) | dd of="$ipadded" bs=4k 2>/dev/null " <ogra> so you have two dd processes in yours <lool> ogra: Yes; with differing bs? <lool> ogra: Oh I see your point; right, I could have changed that when I introduced the padded file <ogra> you can actually pad the file directly <ogra> without creating a tmpfile <lool> I need the tmpfile <lool> Because of fis <ScriptRipper> btw, did any of you read this: http://tuxradar.com/content/ubuntu-rewrite-linux-kernel-using-mono <ScriptRipper> full cover :D <Stskeeps> ScriptRipper: now, it isn't totally insane after seeing stuff like Singularity :P <ScriptRipper> it looks like the author in the middle fusioned also Canonical and Novell <ScriptRipper> and they hired Mark as the new chairman of this company also.... <ScriptRipper> its the best for today i saw <ogra> ScriptRipper, thats future planning, we'll actually port the mono kernel from the python version once thats finished <ScriptRipper> ah, the difference between the marketing people and the project planning :D <cooloney> lool, i uploaded a kernel deb package at http://people.ubuntu.com/~roc/linux-image-2.6.28-11-iop32x_2.6.28-11.38_armel.deb <cooloney> lool, could you please try it to see whether the bug is still there <cooloney> lool, https://bugs.launchpad.net/ubuntu/+bug/349104 <ubot4> Launchpad bug 349104 in linux "[arm] iop32x panics instead of starting d-i from initrd" [High,In progress] #ubuntu-arm 2009-04-02 <Martyn> prepare to be very, very afraid ... I got XenArm working on the babbage <amitk> what is XenARM? port of Xen to ARM? <Martyn> Yep! <Martyn> It was done for cellphones, but it works absolutely great on any arm9 or arm11 variant <Martyn> although I need to work on some of the hardware abstractions <Stskeeps> Martyn: terrifying but absolutely neat <amitk> *shudder* <Martyn> amitk : It's useful. Arm clock rates are going nowhere but up, arm CORES are going nowhere but up <Martyn> amitk : Hypervisors did exist without CPU support for a long time ... this may be something that gets ARM to add virtualization support into the ARM soft core <amitk> Martyn: I can see it being useful (e.g. to run the telephony stack in a vm on a phone), but xen is complex * NCommander notes we could jut run QEMU in on a xen-amd64 host :-) <lool> Martyn: Well that's highly interesting to us; we'd have use of that for virtual builds <lool> NCommander: That was the plan <NCommander> lool, it was? <NCommander> Cool! <Martyn> Well, I'm having a few problems right now with the abstraction of the bus that has the network controller on it <Martyn> so, for the moment I can -run- the arm Xen hypervisor, but only communicate through serial <Martyn> and don't even have the ghost of a whisper of a chance of getting graphics up #ubuntu-arm 2009-04-03 <cooloney> ogra, do you have any time to take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/353196 <ubot4> Launchpad bug 353196 in linux "ixp4xx hwclock command stopped to work since beta release" [Medium,Triaged] <ogra> cooloney, would on the weekend be ok ? <ogra> i'm so busy with the babbage atm <cooloney> ogra, no problem. i will back to Shanghai this weekend from Lexington, -:)) <ogra> ok <Martyn> re <Martyn> Getting u-boot working on the babbage is ... painful <Martyn> on the other hand, I think I may have licked the issues involved in at least getting the kernel into memory <amitk> Martyn: what do you think of openfirmware <Martyn> i don't have an opinion at this time <Martyn> Frankly all monitor and boot environments/shells need only do one thing to make me happy ... -boot- the damned systems :) <Martyn> (and take up as little NAND/nvram/etc as possible) <Martyn> firmworks had a working ARM based openboot firmware <Martyn> I don't know the status of that now <Martyn> it was for the pxa270 based thing <amitk> I met with the guy behind it - Mitch. He has something for the versatilepb kernel in version control <Martyn> CodeGen has a working implemenation for the EVM <Martyn> it would be nice to have on the babbage, but who's going to pay them to do it? <Martyn> amitk : what's the repository it's in? <Martyn> considering I've spent days banging my head against the wall trying to get u-boot to do my bidding... <Martyn> Mitch would be Mitch Bradley then.. I take it? #ubuntu-arm 2009-04-04 <kcowolf> Has anyone had any luck getting Ubuntu ARM working under QEMU in Windows? <kcowolf> think I got it <nab> have people run into this problem before: <nab> evolution-indicator gnome-pilot gnome-pilot-conduits <nab> mobile-broadband-provider-info libmbca0 <nab> E: There are problems and -y was used without --force-yes <nab> Kernel panic - not syncing: Attempted to kill init! <nab> I: Killed ... <nab> hello ogra #ubuntu-arm 2009-04-05 <garren> which build tools everyone using buildroot or OE or something else? <NCommander> anyone around who has a working babbage booting the beta or any other image? #ubuntu-arm 2009-04-07 <Martyn> ogra : I have an alpha-quality u-boot now <ogra> nice <Martyn> ogra : Should I commit a bug and patch? <ogra> sure, but that wont enter jaunty anymore <Martyn> frig <Martyn> we're locked on Redboot for now then, eh? <ogra> yes, and it works just fine, is configurable from the running system etc <Martyn> thanks to a -lot- of work by lool, you, etc... <ogra> http://people.ubuntu.com/~ogra/arm/babbage/ has todays image <Martyn> It's just a pity we have to do all those contortions :) <ogra> lool is nearly done integrating the build script into the autobuilders, so std images will show up this week on cdimage.u.c <Martyn> ogra : Are you experiencing any board lockups or instability surrounding using the USB bus? <Martyn> ogra : I keep getting hard lockups when using a network USB adapter <ogra> we were told to not use the normal USB ports but the mini <ogra> at least for devices with some payload <lool> Martyn: Same here, but we moved to the builtin ethernet again now <lool> Martyn: It's better with the latest 2.6.28 we ahve <ogra> i have kbd and mouse in normal USB ... HDD on mini with powered HUB <Martyn> lool : Someone found the slow performance issue for the built in ethernet? <ogra> we got patches <Martyn> ogra : using one of those weird usb A-B cables? <Martyn> mini a/ minib <ogra> they are in the current kernels but cause other probs <Martyn> *sigh* * ogra points to bug 356517 and bug 356975 <ubot4> Launchpad bug 356517 in network-manager "udev does not detect eth0 on armel" [High,In progress] https://launchpad.net/bugs/356517 <ubot4> Launchpad bug 356975 in linux "imx51 oops after watchdog call" [High,New] https://launchpad.net/bugs/356975 <Martyn> So many issues to solve, and Pegatron is already starting tooling up for ARM based netbooks with the i.mx515 in them <Martyn> Yeah, I just saw 356975 <ogra> it doesnt stop the NIC from working * Martyn lets the 3 hour download from ogra's image repo start <ogra> but i dont see any plug events anymore for the cable <Martyn> Is redboot entirely frozen for jaunty? <Martyn> Or is it possible that I might be able to get a usb-boot patch in? <ogra> i dont think we can add new features at this point <Martyn> Oh well. <ogra> we're close to RC <ogra> bugfixing is the main focus now * ogra would be very very thankful for any idea or help on bug 328167 btw <ubot4> Launchpad bug 328167 in gnome-keyring "[arm] gnome-keyring-daemon eating 100% CPU at login in Jaunty" [High,Triaged] https://launchpad.net/bugs/328167 <ogra> its our biggest blocker atm <Martyn> ogra : I'll take a look at it <ogra> that would be cool, we need as many eyes as possible on it <ogra> (i know NCommander planned to look as well and i'll donate the the rest of my week to it too) <NCommander> ogra, as far as I can tell its a Babbage specific issue <NCommander> ogra, I was unable to reproduce it on anything else :-/ <ogra> it is <NCommander> ogra, oh, I didn't see that in the bug report :-/ <ogra> but we still need to solve it <Martyn> To debug the issue, I'm going to have to do a debug build <Martyn> there's not trace information <Martyn> not/no <ogra> there is the upstream bug <Martyn> NCommander : it happens on the EVM as well as babbage <NCommander> ogra, the upstream bug doesn't have a full backtrace <ogra> but what i added there is apparently not enough * NCommander is going to have to trace it through the entire GNOME stack until it calls into libc <NCommander> ddebs are your friend for this <ogra> Martyn, you have an EVM that survives gnome ? <Martyn> yeah <Martyn> but I cheat :) <Martyn> usb->video adapter <ogra> soldered RAM on it youreself ? <ogra> -e <Martyn> no, I just live with an extremely swappy system <Martyn> it's slow as tar <ogra> heh <Martyn> no, slower <NCommander> Well, we do know its a regression, we didn't start seeing it until about February <ogra> yeah <NCommander> Martyn, sounds like my Babbage running with the pendisk <Martyn> slow as pure glass flowing down a window * NCommander is setting up the other one with the USB HDD <Martyn> hey, I have a BeagleBoard tucked away in the drawer <Martyn> this might be a good time to drag it out, and see if I can get the gnome-keyring issue to show up there <NCommander> Martyn, +1 <NCommander> I couldn't reproduce on something running a 2.6.25 kernel, but I can't upgrade to the latest kernel either <NCommander> (newest userland) <Martyn> My only issue there, is the crappy usbOTG on the board <NCommander> and my slugs don't have enough RAM <NCommander> Martyn, ow. Thats going to hurt <Martyn> but I think it's possible to solder two pins together on the mini USB port, and not have to deal with getting a special OTG cable <Martyn> I should have done the mod ages ago <ogra> on mine a plain mini->-std USB adapter works <Martyn> ogra : I need keyboard, mouse, ec.. <Martyn> so I need to connect it to a usb hub first :) <Martyn> brb <Martyn> okay, BeagleBoard pulled out of drawer <Martyn> ogra, any reason to think the kernel that was built for your image wouldn't boot it? <ogra> ?? <ogra> the imx51 kernel on the beagle ? <ogra> no, that surely wont boot <Martyn> ogra : Sorry, brain not working .. I meant "any reason your image wouldn't boot with a proper Beagle kernel..." <Martyn> error existed between user and keyboard <ogra> no, should work <Martyn> good, that gives me a consistent platform to test <Martyn> Of course, it helps if the clock is set <Martyn> There has -got- to be a way to kill that @#$@$ annoying bug <NCommander> Martyn, we know its a regression, it popped up around Feb 20th <Martyn> I mean, sure, we know it's not really 1970 ... <NCommander> Oh, THAT bug <Martyn> yep, the pam bug <NCommander> That one got fixed <NCommander> Its not pam, its shadow <NCommander> Martyn, is that using a daily vs. a beta image? <NCommander> (it was fixed after beta) <Martyn> daily, but I'm downloading Oscar's latest one now <Martyn> 24% complete .. it's a slow download today <NCommander> Martyn, Oscar? <NCommander> Martyn, if your still seeing the password bug on a fresh install thats a problem <NCommander> :-/ <Martyn> ogra <Martyn> Well, i've got another 30 minutes before the download is complete <Martyn> NCommander : Then we'll see if the password bug remains <Martyn> but if it's reported fixed, I shouldn't see it * ogra points to http://cdimage.ubuntu.com/ports/daily-live/20090407.2/ look, there is a babbage image ;) <lool> http://cdimage.ubuntu.com/ports/daily-live/current/ is the stable URL <ogra> right <NCommander> ogra, I don't see a babbge image at that URL ... <NCommander> Oh <NCommander> bah, you need to mark it armel+imx51 :-P <ogra> cjwatson didnt want to <ogra> given that its the only arm live image we build anyway <ogra> the html text will be updated though <ogra> anyway, out now ... bye <NCommander> Martyn, how goes your install? * NCommander is currently grabbing all the ddebs <NCommander> ogra, you around? <lool> Did someone try usplash on babbage? <lool> The initramfs is really slow, that surprizes me <NCommander> lool, it works on PowerPC AFAIK, so it *should* work. How well, I dunno * NCommander finally is getting some useful backtraces :-) <Martyn> re <Martyn> NCommander : I'm recompiling the kernel for the Babbage board <Martyn> NCommander : Turns out there wasn't one handily available for some reason <Martyn> er, Beagle, not babbage <NCommander> Martyn, there are plenty available, why are you recompiling for Babbage? <Martyn> Brainfrarting continues <NCommander> Oh, Ubuntu doesn't officially support Beagle <Martyn> Right <Martyn> so I'm compiling Beagle <Martyn> but >only< changing the parameters needed to get it working on Beagle, so as to hopefully see if I see the same issues <Martyn> because I'll be using the Babbage userland <NCommander> heh <Martyn> time to compilation completion -- 1hr 8min <Martyn> Ah, the joys of native compilation <pwnguin> how significant is uclib to the arm port? <Martyn> we use uclib? <pwnguin> looks like no <Martyn> I use uclibc to produce busybox images early on during a bring up of a new arm board... <Martyn> but AFIK (YMMV) the jaunty arm port is full blown glibc <pwnguin> yea, i was thinking it'd be part of busybox or something but i guess not <pwnguin> intersting. uclibc is in hardy <pwnguin> dropped from intrepid and later i guess. <pwnguin> only reason i ask is because i was revisiting a patch dump from Garmin, trying to figure out why a patch wasn't applied upstream. it seems tracked down to uclibc, but if debian / ubuntu aren't using uclibc there's probably no interest in the patch or upstreaming it. * NCommander headthunks <pwnguin> NCommander: ? <NCommander> pwnguin, working on g-keyring-daemon <pwnguin> fun #ubuntu-arm 2009-04-08 * NCommander is trying to bisect the problem <Martyn> can't sleep <Martyn> I've got the BeagleBoard working (the root password reset issue did _not_ show up, btw) <Martyn> I cannot replicate the issue on the Beagle. <Martyn> so it -must- be babbage specific <lool> ogra: Any idea why the initramfs takes so much time to mount the SD when booting the install SD? <lool> Hmm I wonder whether it tries to mount the SATA disk and times out <ogra> likely <ogra> casper iterates over all devices <ogra> the SATA->USB bridge always creates a device even if nothing is attached <lool> Yes :-/ <ogra> next HW version will have PATA <ogra> for now we have to live with that <lool> ogra: So we should drop that LIVEMEDIA thing, it doesn't help <ogra> i think it timed out without it <lool> Ah <ogra> let me finish the script parser, i'll check the livemedia thing afterwards * ogra curses shell for being bad with multiline strings <lool> We should also try splash <ogra> breaks <lool> What breaks? <ogra> usplash <ogra> try it <ogra> it totally wasnt on my list for jaunty so i didnt pay any extra attention but to disable it <ogra> i have it on the TODO for KK <lool> Is there a bug for it? <ogra> nope <Martyn> ogra : I couldn't reproduce the keyring daemon taking up 100% cpu on the Beagle board <Martyn> ogra : I can, however, reproduce it on the Babbage, and will continue looking at it as soon as I get a mini to standard USB cable <Martyn> afternoon #ubuntu-arm 2010-04-01 <rcn-ee> Hey DanaG, nope i haven't written the dkms script for the sgx stuff yet, in theory it'll use ubuntu's ti-omap headers... <DanaG> That'll be cool... even if we have to put the .run script in a specific place. <DanaG> At least then it won't try to "make clean" in a workdir that doesn't exist! =Ã¾ <rcn-ee> exactly.... <DanaG> Oh yeah, the ubuntu omap kernel seems to have some race condition with the musb_hdrc module... <DanaG> sometimes it oopses, sometimes it works. <rcn-ee> playing with 500.4, it's closer but still not ready.. ;) <DanaG> And when it "works", trying to load g_anything gives "no such device" <rcn-ee> that's with ubuntu's and not mine with the usb config change? <DanaG> Right. <rcn-ee> (which also makes it fun as the only way to tell, is "dmesg | grep gcc" ) <DanaG> Oh, and on Ubuntu, suspend works... but there's no way to resume. <rcn-ee> sweet, it's closer... <rcn-ee> does it respond to button press's for wakeup? <DanaG> nope. <DanaG> The only button I have is the "user" button. <DanaG> I'll try it with a usb numpad right now... <DanaG> But wake-on-lan from the asix didn't work. <rcn-ee> argh, they disabled the otg port.. (only ehci on my c2..) ... <DanaG> hmm, usb keyboard didn't wake it, either. <rcn-ee> i think in suspend, the usb bus is taken down, so their might not be much hope in waking it up... <DanaG> dang. <DanaG> hmm, I should try to usb-wake the asix on one of my x86-based systems. <rcn-ee> that would be an interesting comparsion... <rcn-ee> i know some bios have a 'usb wake' option, we really dont' have those type of options on arm.. <DanaG> And there's no ACPI here, either. <DanaG> And no /sys/firmware/anything <rcn-ee> exactly... there is also a spi/i2c bus on the expansion port, one of those might be able to help wake it up.. <DanaG> argh, stupid pm-utils... brought down the interface. <DanaG> er wait <DanaG> nope, the netbook just brought usb down. <DanaG> Interestingly enough, the USB hub stays powered with beagle in suspend. <rcn-ee> not sure... 50/50 that could just be the external power supply.. <DanaG> interesting... on the netbook, with usb-wake enabled, it always re-wakes a few moments after suspend. <rcn-ee> i think i found the otg problem, CONFIG_USB_GPIO_VBUS was moved to an external module... <rcn-ee> so the hardware works, just got to figure out what's missing in arm.. (hopefully it's not hte acpi routines) <DanaG> weird... usb wake applies even with nic not plugged in. Must be the webcam doing it. <rcn-ee> i think usb wake, starts the pc with any activity on the bus.. <rcn-ee> okay uploaded a working 500.4 to my testing location, amitk isn't going to like my one revert.. planning tomorrow to figure out why the dss2 config isn't working properly.. <DanaG> FATAL: Error inserting gpio_vbus (/lib/modules/2.6.33-500-omap/kernel/drivers/usb/otg/gpio_vbus.ko): No such device <DanaG> oh wait... forgot to actually dpkg -i <DanaG> nope, still same. <DanaG> weird... having beagle plugged into usb is hanging lsusb on the host. <DanaG> Also weird: asix isn't sending any packets to the network! <rcn-ee> strange... my asix works.. <DanaG> Mine only works if I unplug it and replug it. <DanaG> It's the 3-in-one usb+ethernet thingy. <DanaG> If I boot with it connected, it doesn't work -- it only works once I disconnect and reconnect the hub from the EHCI port. <DanaG> That IS weird... asix isn't seeing any incoming packets, either. <DanaG> https://bugs.launchpad.net/ubuntu/+source/linux-ports/+bug/462796 <ubot4> Launchpad bug 462796 in linux-ports (Ubuntu) "asix based Apple USB Ethernet device drops periodically (affects: 1) (heat: 6)" [Undecided,New] <DanaG> That really IS highly strange. <kblin> DanaG: is that a revC4 or a revC3? <DanaG> C4. <kblin> I see, nm then :) <hrw> morning <hrw> XorA: you here? <XorA> hrw: I am now <hrw> XorA: customer with ubuntu wish? <XorA> just being nosy <XorA> this is even quieter than #angstrom :-D <hrw> depends <hrw> looks like it is more US timezone <XorA> hrw: you doing ubuntu stuff these days? <hrw> got some query on that <amitk> beginnings of a 4 day easter holiday here in EU * XorA is in the EU and not on hols :-( <amitk> (holidays start tomorrow, mind you) <amitk> and the ubuntu archive is frozen for beta-2, so no new uploads, so people catching their breath <amitk> doing laundry and so forth <XorA> heh <Mikeinaus> Hi - are there any Cortex M3 programmers in here?? <Martyn> Hey all... <Martyn> what's the correct task to create the full server install? <Martyn> I just tried 'server' and it sort of falls over and dies #ubuntu-arm 2010-04-02 <NCommander> eggonlea: you around? <eggonlea> NCommander, yes. #ubuntu-arm 2010-04-04 <nosse1> This is the URL for the Lucid kernel with the arm branches, right: http://kernel.ubuntu.com/git/ubuntu/ubuntu-lucid.git <nosse1> Where can I get the .config file for the Lucid ti-omap kernel? <nosse1> I.e. when I check out the Ubuntu lucid kernel (on the ti-omap branch), is the config entirely found in debian.ti-omap/config/config.common.ubuntu? <nosse1> Because I have no idea of how to convert the debian/* config scheme into a .config which I can use... <DanaG> there should be a file /boot/config-2.6.33-500-omap file in the data file. <nosse1> DanaG, I don't have a running system, so I cannot get the boot file. Hmm. But I can pry it out of the binary release file <crimsun> eh? just look in the right branch <crimsun> a couple ways: 1) git checkout --track -b ti-omap remotes/origin/ti-omap; 2) http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=tree;f=debian.ti-omap/config;h=e8112097747fd67e71b88c4e738ce68704cb663e;hb=refs/heads/ti-omap <crimsun> ^^^ nosse1 <nosse1> crimsun, yes I have that branch checked out. How does ubuntu compile the config from the debian.ti-omap/config files? concat them? <nosse1> Or, I'm actually more interested in learning how to generate the .config file using debian/rules. <nosse1> Ubuntu has some config/build layer built build upon the kernel source which I haven't figured out how to use <crimsun> see the rules file. <Fatih`> Hi <Fatih`> I have a davicom usb to ethernet adapter, it causes problem, i'm not able to connect to the internet <Fatih`> is there any vay to download packages from my regular pc and install it on the beagleboard ? <Fatih`> i need to install octave from the repo #ubuntu-arm 2010-04-05 <videorechner> hi, I am looking for a arm cortex a9 board but there seems to be none, that doesnt cost a fortune or isnt available, but today, I found this one: http://www.kmckk.co.jp/eng/kzmca9/index.html does someone know more about that? <DanaG> hmm, is beagleboard an a9? <DanaG> oh, I see... <DanaG> that's multi-core. <videorechner> beagle is omap 3xxx <videorechner> cortex a8 <DanaG> ah. <prpplague> DanaG: omap4 is cortex-a9 dual core <DanaG> Is that what the beagle-XM will have? <prpplague> no <prpplague> DanaG: detail info on the new features of the xm - http://groups.google.com/group/beagleboard/browse_thread/thread/6604a0debf003c8a <DanaG> I do find it a bit of a bummer that they didn't expose the USB+LAN chip's 15 GPIOs. <prpplague> DanaG: why? <videorechner> I heard arm cpus are missing a smp unit, what does that mean in consequence? <DanaG> It would be nifty to be able to use an expansion board and still have a bunch of gpios. <prpplague> DanaG: but you have a bunch of gpios already <DanaG> Muxed with other stuff, though. <prpplague> videorechner: the cores act independently in many way <prpplague> DanaG: can you give me an example of a case condition? <DanaG> I was more just theorizing, actually. <DanaG> Right now I don't use GPIOs at all, anyway/ =Ã¾ <videorechner> prpplague but ubuntu can handle them like any other dual core? <DanaG> hmm, what boards actually do have the dual-core ARM? <prpplague> DanaG: it would be much much easier for you to use a i2c gpio expander than try to use the gpios on the lan9514 <DanaG> Looks like XM will still be single-core. <prpplague> videorechner: i do not know currenty <prpplague> DanaG: correct <DanaG> I'm interested in the Marvell 1.2GHz ARM stuff, also. <XorA|gone> http://www.electricpig.co.uk/2010/02/17/texas-instruments-omap4-blaze-twin-screens-android-and-a-projector/ <XorA|gone> thats dual core <XorA|gone> and a very sweet bit of kit <prpplague> XorA|gone: toooooooo bulky, hehe <DanaG> heh, I was pondering replacing the sucky samsung netbook with a better HP one (5102) or that Onkyo DX dual-1366x768 thingy... then I tried an SSD and realized that'd be more useful. <XorA|gone> prpplague: well your the board dude, shrink it to the size of my Touch HD2 :-D <prpplague> XorA|gone: hehe <comradekingu> Who had sufficient lack of decency enough to make a bezel for that abomination. <comradekingu> ??? <comradekingu> It goes without saying you can make cases for stuff. What idea are they pitching, "ready for market"? "Dual vertical span with separation in between on a phone is a good idea"? <prpplague> comradekingu: for which item are you refering? <comradekingu> http://www.electricpig.co.uk/2010/02/17/texas-instruments-omap4-blaze-twin-screens-android-and-a-projector/0 <comradekingu> http://www.electricpig.co.uk/2010/02/17/texas-instruments-omap4-blaze-twin-screens-android-and-a-projector/ <prpplague> comradekingu: ahh right, there were very specific reasons for the size and shape <comradekingu> prpplague: Im guessing the gold trim has its reasons too, but come on... <prpplague> comradekingu: i think that was just for show, all the ones i've seen are all black <comradekingu> prpplague: Actually it was the colour that made me want to keep my eyes closed. <prpplague> comradekingu: if you could get your ultimate OMAP4 board what would be? <comradekingu> Pandora? <comradekingu> no, thats OMAP3 <prpplague> comradekingu: i mean feature wise, is a case really that important ? <comradekingu> http://upload.wikimedia.org/wikipedia/commons/0/0f/Wonderswan_color-JD.jpg <comradekingu> Feature wise id like displayport, other than that just the usual stuff <prpplague> comradekingu: what type? <DanaG> My ultimate ARM device of any sort: take HP Mini 5102, stick a 1.2GHz ARM in it, and have open graphics (or at least closed graphics with build scripts that don't suck). <DanaG> "suck" being "tries to 'make clean' on a target workdir that doesn't exist". <prpplague> DanaG: hehe, trustme i know all too well <prpplague> common them here is having a case <comradekingu> prpplague: From what i remember the only useful feature of DP 1.2 was daisy-chaining displays <prpplague> comradekingu: hdmi? <DanaG> The PowerVR stuff makes NV installer look "wonderful", in comparison. <prpplague> comradekingu: dvi-i ? <comradekingu> prpplague: Rather save the cash for something cool <prpplague> comradekingu: ?? <comradekingu> Ultimate has to be unencumbered by lousy standards imo <prpplague> comradekingu: which standard is lousy? <comradekingu> hdmi <prpplague> comradekingu: interesting <comradekingu> Someone over at the hdmi consortium envisioned i would want to buy a 250$ soundcard to send undecoded audio to a reciever, a task which can only be done by one special release of a proprietary app on a proprietary system. <comradekingu> They can keep all their 8CH audio for all i care, i wont support it. <DanaG> I'd rather just have a good sound card in the PC. <DanaG> And a decent set of speakers (my Logitech Z-5300 are decent, once you turn the sub on its side so the port sits against carpet). <ogra__> plars, http://people.canonical.com/~ogra/linux-image-2.6.33-500-omap_2.6.33-500.4_armel.deb that has the USB patch from the bug, please test and comment on the bug #ubuntu-arm 2010-04-06 <plars> ogra: sorry, was away... will test tonight if you haven't already <crimsun> plars: I haven't had time to look at the straces for the PA bug; when you run using sudo, what's holding /dev/snd/* open? (sudo fuser -v /dev/snd/*) <peterkirn> apologies if this question was posted before; my cable just went out. anyone have any issues setting up sudo/su on rootstock? <rcn-ee> peterkirn, what's it not doing? <peterkirn> well, when I created the root file system, I set up flags for userid and pwd. those work to login, but the pwd fails on su - and sudo returns no root privs <peterkirn> that is, sudo rootstock with flags --login userid --password pwd to create the image <rcn-ee> that's strange... it worked for me with an image last week.. rootstock sets up the defined user with sudo privledges... <peterkirn> su returns an authentication error for that password; sudo returns "must be setuid root" <peterkirn> "/usr/bin/sudo" is root:root... that's right, yes? <rcn-ee> that's strange... i had a user with the same issue on the beagleboard forum today,... <rcn-ee> digs for the link.. <peterkirn> yeah, this is a hawkboard. ;) of course, could be our lack of experience (I'm not completely green, but...) <rcn-ee> it was thisone: http://groups.google.com/group/beagleboard/browse_thread/thread/a2eea0446fab84ce/3ff6c6f16fce7874?lnk=gst&q=sudo#3ff6c6f16fce7874 that's two in a row... <rcn-ee> he was using karmic, and your using jaunty.... different versions of sudo.. <rcn-ee> did you 'sudo tar xjfp' when you extracted the file system? <peterkirn> reading, thanks! well, I think the hawkboard is so far happy only with jaunty. I am building jaunty under karmic rootstock, though. <peterkirn> sudo tar xfp, yes <rcn-ee> yeah that should be fine.. running lucid... <rcn-ee> stumped.. same problem, no connection, he used my demo image and your using rootstock... <rcn-ee> if it keeps happening i'd file a bug with rootstock... <peterkirn> I got even more aggressive, tried chmod 777 for the whole stick <peterkirn> anything else to try, in the meantime? <rcn-ee> give one of my ancient builds a try, it works for a year on the beagle: http://rcn-ee.net/deb/rootfs/ubuntu-9.04-minimal-armel.tar.7z <rcn-ee> user: ubuntu pass: temppwd just add your own hawkboard kernel.. <peterkirn> I'll try chmod chown on sudo again, too, apparently sometimes repeat goes at it help <rcn-ee> you might have to set the permissions from your other pc.. <peterkirn> yep, will give that a try, too. what size is it? glad I had my droid handy during yet another internet outage on timewarner. ;) <peterkirn> thanks! <rcn-ee> it's 66Mb.. just a simple console demo image... <peterkirn> ok, great. will let you know what happens and see if it makes sense to open a ticket. <rcn-ee> i built that image with build-arm-rootfs so we might be seeing a regression.. <peterkirn> yeah; I will definitely compare results with each <peterkirn> ah, that's weird. <peterkirn> if I sudo chmod 4111 /usr/bin/sudo on my pc, I get must be setuid root <persia> I've encountered this before, when a filesystem was copied to VFAT, and then copied to something sane again. <persia> Dunno if that is the cause this time, but ... <peterkirn> hmm, interesting. well, for me, only ext3 <persia> Then definitely a different issue. <rcn-ee> i think it's just somethign with today, another user on the beagleboard group is having login problem with gdm in lucid... <peterkirn> ah, must be I actually have something screwy on this karmic laptop. on my fedora machine, no problem. <peterkirn> there was that big magnetic storm today. ;) okay, now seeing if it works booting on the hawkboard. <peterkirn> but, yes, that'd explain it... it simply inherited the permissions problem from this laptop. <peterkirn> hmmm, that didn't help with the issue, but I'll take some time and try with the other image. <plars> rcn-ee: hi, was looking at bug 541030, perhaps I'm looking at a different tree but I don't find a commit b586f759f4dda7622a90f68c9c05424e777b8b2b that you reference in there, which tree are you looking at, and what is that changeset doing that you revert? <ubot4> Launchpad bug 541030 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "omap kernel musb/ehci ports not enabled on beagleboard (affects: 1) (heat: 12)" [Critical,Triaged] https://launchpad.net/bugs/541030 <rcn-ee> Hi plars, i've narrowed that commit down some more, i'll push a couple more notes... that commit is: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=b586f759f4dda7622a90f68c9c05424e777b8b2b <rcn-ee> it's in the ti-omap branch... <plars> rcn-ee: ah, I see, thanks! <rcn-ee> no problem.. it's a fun CONFIG, since enable a couple options waterfalls more, so lots of tweaks.. <rcn-ee> plars, i'll dig into it more tomorrow... but i have that commit seperated into a safe commit and a broken commit.. However part of the broken commit can still be salvaged (OTG setting) Just got to re-figure out the correct config sequence that works.. <DanaG> hmm, now that the dl5 kernel doesn't have the g_* drivers as modules... now I can't load g_audio. <NCommander> eggonlea: you around? <eggonlea> NCommander: ack <nosse1> Hi guys. How do you kick off ubuntu (with initrd) from u-boot? <nosse1> The important part is how you load the initrd image <persia> nosse1: It really depends on which uboot and where the initrd is stored. <nosse1> persia: I'm running U-boot 2009.11 (for AM3517 by TI) and I have options for where to store the initrd <nosse1> Currently its on an NFS server, like the kernel image, but I can move it if neccessary <nosse1> Point is, do you load the initrd to memory using u-boot and then pass the address for it to the kernel? <persia> That certainly ought work (e.g. "initrd=0x11700000,8M"), but I'm not sure if it works without the initrd load. <amitk> nosse1: you'd provide two addresses to 'bootm' - kernel and initrd <nosse1> amitk, ok. Do you need to supply the initrd address in the kernel parameters? <amitk> nosse1: no AFAIK <nosse1> I'll try that. Thanks <DanaG1> http://elinux.org/Talk:BeagleBoardUbuntu <DanaG1> check that... even if you're on a different board. <amitk> right, elinux has some good instructions on generic board bringup <hrw> morning <amitk> morning <nosse1> How do you generate the initrd image for u-boot? The /boot/initrd.img file is a gzipped cpio archive, and when I load it U-boot complains about "wrong ramdisk image format" <XorA> nosse1: you need to run mkimage from uboot-utils <nosse1> Ah, so the initrd must be mkimagized as well.... <XorA> I beleive so <XorA> for some wierd reason <persia> Is that a uboot limitation, or something fixable? <amitk> persia: u-boot requires it for kernel, initrd, bootscript <amitk> it hads a 64 byted header to each <amitk> s/hads/adds <persia> Makes sense, although unfortunate. <amitk> a minor annoyance, admittedly. But I script it away. <persia> Is that the sort of thing that would make sense as a rootstock option? <amitk> is it the job of rootstock to give a dd'able sd image? If not (as I suspect), then no <persia> No, rootstock only generates rootfs tarballs. <nosse1> eh? I have generated ext2 images from rootstock that I've dd-ed to target. Works fine. <nosse1> (well.. fine is somewhat an overstatement: I'm still working on bringing up the system) <persia> nosse1: Indeed. rootstock is good at what it does. The point being that it *isn't* the tool to generate images, but only filesystems. <nosse1> rootstock can build an image/tarball using a custom kernel (from a deb file). How can I generate such a deb from my custom kernel source? <nosse1> I can copy the debian.* dirs from the ubuntu lucid kernel source (and use e.g. the ti-omap branch). However I dont know how to get from these source to a deb file :( <persia> debuild -b <persia> Or us pbuilder or sbuild for a clean build environment. <hrw> nosse1: make-kpkg is a tool <hrw> from kernel-package <amitk> make-kpkg is not supported by Ubuntu, infact we will discourage its use <hrw> what does replace it? <persia> debuild -b <hrw> but debuild require debian/ dir - right? <persia> Yes. <hrw> and make-kpkg creates such when not present <amitk> hrw: the ubuntu kernel uses its own buildsystem (based on debuild) and has its own way of managing configurations <hrw> ok <amitk> https://wiki.ubuntu.com/KernelTeam/KnowledgeBase <--- lots of info about maintaining ubuntu kernels <amitk> and other stuff.. <nosse1> My biggest challenge in this respect has been to ubuntuize a vanilla or 3rd party kernel in order to make it run ubuntu on target <nosse1> But I seem to make progress in this respect now <hrw> ok <nosse1> Will Lucid be release for ARM as well (for the 10.04 LTS release date)? <JamieBennett> nosse1: yes <JamieBennett> we have the same release date <nosse1> :D <nosse1> Do you have a defined list of supported targets/machines for this release? <nosse1> I.e. I have an AM3517-evm which the lucid kernel image (ti-omap) is not working currently. <JamieBennett> nosse1 Freescale iMX51 and Marvell Dove platform are the officially supported arches <nosse1> ok <JamieBennett> and omap (beagle board) <nosse1> Is this based on EVM availability? <JamieBennett> basically what ever image you see here - http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ <nosse1> Can EVM donation to key developers help addition of support for other HW? <amitk> nosse1: it's based on what is considered a priority for the first release of OMAP (and yes that includes HW availability) <JamieBennett> nosse1: outside of our official images, any hardware enablement would be on a developers own time <amitk> nosse1: donations are unlikely to help at this point (very close to release) but we'd appreciate QA help and bugs regarding what is _not_ working <nosse1> Ah, so it has been a policy decision to support iMX, Marvell and beagle board. <nosse1> Point is, we're building a product based on the AM3517, and of course we'd like to see official support for that target <amitk> nosse1: policy in terms of contracts, yes <nosse1> Again, porting is WIP, so I will have more info of what works and not works later <rcn-ee> nosse1, what's that board currently doing on bootup? I don't have any of the Logic based boards.. <nosse1> AM3517-EVM from TI, which is a Zoom AM3517 eval kit <persia> nosse1: If you can find a config that supports AM3517, and also supports the beagleboard for the Ubuntu kernel source, please submit a patch that does that. <amitk> nosse1: I've said in the past, I think - point me to patches that will make your board work better (I think the base kernel should just boot) and I'll consider it <amitk> nosse1: there shouldn't be any _porting_ involved IMO if this a basically an EVM board <nosse1> amitk, Yes I know, and thanks. I will supply more info/patches/etc. when we get there. <robclark> nosse1: isn't AM35xx pretty similar to OMAP35xx? <amitk> (assuming same peripherals, ofcourse) <robclark> I guess same filesystem would have high likelihood of working, if you had a suitable xload/uboot/uImage <hrw> JamieBennett: you work @canonical now? <nosse1> Yes, I think so. It's just tailored for industrial instead of commercial/mobile <robclark> ok, that is what I thought.. <nosse1> The question is if Ubuntu will accept patches and fixes to a HW which is not officially supported, that all <persia> It ought be possible to construct a kernel that works for either, but xload/uboot will surely differ. <JamieBennett> hrw: yes <robclark> well, if you ignore accelerators (not sure if AM35xx has DSP?)... userspace should be quite similar * XorA normally finds the same rootfs can boot on many many different boards if udev is working right <robclark> yup <persia> nosse1: As long as 1) it doesn't break anything, 2) if complies with freezes, and 3) it doesn't require more trees, probably. <amitk> nosse1: YES we will accept patches. But not necessarily all of them :) <nosse1> The vanilla debian lucid kernel for ti-omap does not work (it crashes). I have to use a 2.6.32 kernel supplied by TI. I have not investigated the extent of patches between the ti-omap ubuntu kernel and the one from TI <nosse1> My guess is that when we have overcome the kernel obstacle, hopefully Ubuntu will work OOB * hrw -> printer for some papers to read/sign <persia> You'll need to do that investigation. Especially this late in the cycle, patches that aren't known to work also for supported boards are very unlikely to be accepted. <nosse1> Thats why I asked if ARM is releasing together with 10.04... :D <persia> All the architectures have the same schedule. They are all based on the same sources, uploaded at the same time. <persia> We happen to like ARM in this channel, but it's not special in any way in an Ubuntu context. <amitk> nosse1: I haven't seen a bug report yet regarding this kernel crash (hint). If I do, I might be more able (and inclined) to help <nosse1> I think the job you guys devote to Ububtu ARM is awsome! It really simplifies the use of linux if we can use vanilla Ubuntu for a embedded target. <rcn-ee> hey amitk, any opinion on my mess of bug 541030 i was thinking about also insmod'ing the driver with a script in the initramfs if it was possible.. <ubot4> Launchpad bug 541030 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "omap kernel musb/ehci ports not enabled on beagleboard (affects: 1) (heat: 12)" [Critical,Triaged] https://launchpad.net/bugs/541030 <nosse1> amitk, thank you, I appreciate it. I will submit as we have something. BTW: The lucid ti-omap kernel crashes on startup on the AM3517. Are you interested in a bugreport on that? (being a unsupported HW and all) <amitk> rcn-ee: working on the USB issue ATM (top of my list) <amitk> nosse1: yes, I'm interested in seeing what the crash is. <persia> nosse1: Just to be clear, Ubuntu isn't an embedded OS. It's a general-purpose OS. If you have very powerful hardware, you don't have to play embedded, but don't think you can reliably make it work with 128MB flash and 32MB RAM (which is fine for some OSs). <amitk> rcn-ee: are you saying in that bug (still reading through it) that compiling the modules in gets rid of the bug? <nosse1> persia, no problem. Our product will have 512M and 1G flash, so ubuntu-minimal with our app on top will fit perfectly <rcn-ee> Right now, just compiling in that original config change.. only the ehci port is active on startup.. Whereas you have to insmod one of the drivers to get the otg port working... <XorA> rcn-ee: OTG needs at least one gadget driver <rcn-ee> once i reverted the b585 commit, that config patch gives you an active ehci and otg port on startup.. I've currently seperated the b586 commit into a safe (doesn't break musb) and a what breaks it.. <nosse1> What draws me to Ubuntu (over pure embedded linuxes, like OpenEmbedded) is the package maintenance and upgrade system. Having this, makes us focus solely on our app and we can consider the HW as a "general PC" <amitk> rcn-ee: you're testing this through a powered USB hub, I presume? <rcn-ee> correct... with a correct otg to usb connector... <rcn-ee> XorA, yeah i usually leave the ethernet gadget built in... <persia> nosse1: Then you're in the right place. Just don't confuse it with real embedded stuff: there's all sorts of stuff installed that "wastes" space from that viewpoint. <rcn-ee> I'm going to spend some more time on it today, CONFIG_USB_MUSB_OTG=y is in the bad diff, but I've been using it fine on my own builds.. It's just the right combination of config options to get it to work... <amitk> rcn-ee: right, we need to fix the Kconfig options upstream DTRT <rcn-ee> yeah... more then likely, but as a note CONFIG_USB_MUSB_OTG=y does work in my 2.6.33.x mainline branches on rcn-ee.net.. <nosse1> /etc/fstab needs to be configured with the correct / source right? Because this is used in the initrd image to remount root, right? <persia> Right. <nosse1> Do you have a standard workflow (like update-initramfs) for making U-boot images from the kernels in /boot ? <nosse1> amitk, OK Now I've loaded the ti-omap kernel with the kernel crash. You want me to submit the full output? <amitk> nosse1: dmesg, cat /proc/cpuinfo output is appreciated. Please attach it to a launchpad bug * persia recommends using `ubuntu-bug linux-tiomap` <nosse1> amitk, Can't give cpuinfo, as I cannot get so far to have a console. * amitk would recommend that too, but suspects nosse1 isn't running the full rootfs yet <amitk> nosse1: ok <nosse1> Which project/package? This one: https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect <amitk> nosse1: file it against linux-ti-omap <persia> https://launchpad.net/ubuntu/+source/linux-ti-omap/+filebug/?no-redirect <nosse1> sorry for being such a newbie here, but I understand you want me to put tags on it? <persia> "armel" is probably enough to start. <persia> But it's somewhat superfluous for that package, as it doesn't work on any other architecture :) <nosse1> Does this bug 556482 contain the information you need. I'm humble to comments... <ubot4> Launchpad bug 556482 in linux-ti-omap (Ubuntu) "kernel crash when booting on AM3517-EVM (affects: 1)" [Undecided,New] https://launchpad.net/bugs/556482 <persia> nosse1: Please also attach /proc/cpuinfo and dmesg <nosse1> persia, for a system that I can't boot? <hrw> nosse1: kernel outputs something during boot right? <persia> The output was attached. <hrw> nosse1: and /proc/cpuinfo from working kernel <hrw> ah, did not yet checed <persia> dmesg from working kernel may also be interesting (but make it clear that this is not the regular kernel), just as a reference. <nosse1> this is the initial bringup of this HW, unless you guys have used the AM3517 evm before <hrw> nosse1: remove audio from kernel and boot <nosse1> Yeah, I have done that in my own custom compiles. I still can't boot for some other reason. Point is, I assumed you were interested in feeback regarding the vanilla kernels <persia> Absolutely, but the more information you can provide, the better a chance that the issue can be fixed. <nosse1> Will do. Except the kernel will not be compiled natively (yet) since I don't have a running system. I have to crosscompile to speed things up until then <hrw> nosse1: according to kernel output problem is in am3517 audio drivers <nosse1> Yes, that is what I also figured <amitk> nosse1: as hrw stated, could you recompile the kernel with sound disabled, it looks like a sound driver crash <amitk> [ 675.150604] AIC23 Audio Codec 0.1 <amitk> [ 675.154052] Failed to add route LOUT->Line Out <amitk> [ 675.158538] Unable to handle kernel NULL pointer dereference at virtual address 00000004 <amitk> nosse1: but thanks for pointing out a problem in my own configs, I will now move sounds drivers to modules, they're not required for boot <nosse1> np. I'm looking forward to try the new kernel ;) <hrw> btw - can I download working kernel+rootfs for beagleboard somewhere? <amitk> hrw: http://cdimage.ubuntu.com/cdimage/ubuntu-netbook/ports/daily-live/current/ <amitk> hrw: dd to an sd card and go! <hrw> gracias <persia> hrw: If it doesn't work in any way, please file lots of bugs: it *should* work. <persia> hrw: Also, we're currently preparing for the beta2 release: if you're up for participating in the test review process, /join #ubuntu-testing and folks will get you sorted. <hrw> persia: I will take care of resulting bugs in May. April is already booked for other projects <persia> hrw: Please file the reports, even if you don't fix them. The idea is that if we don't know what is broken, we can't fix it :) <persia> (and the other idea is that we want to make sure the image called "Beta 2" is actually decent) <hrw> sure <amitk> ogra__: asac: any chance the beta2 images will enable serial port by default? <persia> amitk: I believe they don't currently, but that could be enabled if you think it's a beta-blocker. Does the current kernel have all the right support? <persia> amitk: And don't you need a new kernel for beta2 anyway, for USB? <lrg> persia: I have that build machine info for David M. Can you send me his email details, I didn't get his card in Nice <amitk> persia: there is nothing lacking on the kernel side for serial port support, it is missing in userspace (kernel cmdline + //etc/init). <hrw> lrg: you here too? * hrw see more and more OE developers aroung ubuntu/arm <lrg> hrw: I'm everywhere :) <amitk> persia: It severely hampers working with the board for sure <persia> amitk: So, if that gets turned on, doesn't it break something with plymouth? <amitk> persia: if it does, I haven't heard of it. <hrw> persia: developer board should always respond on serial port with getty <hrw> thats why my desktop has 7 serial ports <persia> hrw: Yes, but 1) that's different than console, and 2) the images Ubuntu produces are end-user images (which can be used for development). <amitk> persia: I've always disagreed with point 2 being a reason to disable serial console (even on FSL and MVL) <persia> amitk: Well, how about other architectures? <persia> I'm not opposed to serial consoles, but I don't see any reason for ARM to be special, vs. e.g. PPC or amd64. <amitk> persia: ARM is special in the sense that we're working mostly with dev boards and vendor kernels that are still WIP. So debugability (sp?) is a must. <nosse1> For you guys running u-boot, how do you update the images from the stock kernels? Do you mkimage manually, or is there some tool/script available which triggers on update-initramfs? <amitk> nosse1: http://people.canonical.com/~amitk/ti/linux-image-2.6.33-500-omap_2.6.33-500.4_armel.deb is a kernel w/o sound compiled-in. See if it works better for you. <nosse1> amitk, Thanks. I got this: <nosse1> dpkg: error processing linux-image-2.6.33-500-omap_2.6.33-500.4_armel.deb (--install): <nosse1> short read in buffer_copy (backend dpkg-deb during `./lib/modules/2.6.33-500-omap/kernel/net/econet/econet.ko') <hrw> nosse1: refetch as you have broken deb file <nosse1> I can be a bug in qemu which I use to deploy the deb * nosse1 refetching <hrw> nosse1: manually extract deb file <nosse1> The deb download no2 is different from first. Either amitk rebuilt the deb or my download was faulty the first time <nosse1> amitk, Crashed at the same spot. I'm double checking to see if I am running the new kernel or not * armin76 has better hardware than NCommander (still) <persia> armin76: Isn't that usually the case? I would expect it to be a requirement for your distro of choice :) <hrw> 'your penis is larger then mine' talks again? <persia> !ohmy | hrw <ubot4> hrw: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others. <persia> But yes. <hrw> but how many of you has armv4t board with EP93xx cpu? <XorA> persia: made it back to tokyo then? <hrw> totally broken VFP unit, hardware decelaratted graphics... <persia> hrw: heh. Don't think that can even run any Ubuntu. <persia>
{'channel': 'ubuntu-arm', 'month': 4}