#ubuntu-arm 2009-10-01 <ogra> lool, do we know which packages would have to be recompiled ? <ogra> "Then <ogra> we would like to look at rebuilding affected binaries. <ogra> " <ogra> not a very detailed list :) <ogra> lool, imho we shouldnt tinker with something like that this late in the cycle <ogra> we have a workaround for oo.o and i dont think we saw other fallout yet <NCommander> ogra, I dunno, I've seen quite a bit of instability in karmic verus jaunty. gnome and firefox especially <ogra> i dont <lool> ogra: As I note, I'm working on building the list <ogra> yes <NCommander> ogra, its possible its dove related <ogra> i wasnt following #mobile since you asked to have all conversation here :P <ogra> amitk_, poke <ogra> amitk_, in drivers/video/mxc/mxc_ipuv3_fb.c there is a line "static unsigned long default_bpp = 16;", can you change that to 24 with the next upload ? * amitk_ pokes ogra with a spear <ogra> ouch * ogra tapes the hole in his belly <amitk_> ogra: colors not looking good? <lool> Yup <ogra> amitk_, well, depends ... http://launchpadlibrarian.net/32366612/dsc_3982.jpg <lool> ogra: Do we have a bug for this? <lool> ogra: The xsplash bug would be fine <ogra> not for the driver <lool> Add a task with linux-fsl-imx51 <ogra> no it wouldnt <ogra> i'll add a new one <lool> Ok your call, please file a new bug then <ogra> the xsplash bug affects other arches apparently <ogra> ah, and you said 32, i see the driver actually has a 32bpp stting <ogra> no idea why it isnt picked up from cmdline ... i guess it needs a special format once again <amitk_> ogra: that is default_bpp. Can't the Xserver request another bpp? * ogra sighs about that driver <ogra> amitk_, the xserver is fbdev :) <ogra> we dont have a real xserver yet <ogra> and the fbdev only uses the settings it has on kernel startup <amitk_> right, can't you request it on cmdline? <ogra> so we either re-add the video option to alkl default cmdlines which we dont want or just make the driver do the right thing <amitk_> ogra: just curious why you don't want it in the cmdline? Since it has the same effect - of imposing 24bpp policy on the users <amitk_> and that (policy) is better handled outside the kernel <Martyn> ogra : OOoo... looks pretty <Martyn> not anything like it's supposed to .. but very pretty :) <ogra> amitk_, because that means to use a hack <Martyn> ogra : Is there not a 16 bit version of the xsplash? <ogra> amitk_, if the driver doesnt dtrt i'm not really hot on hacking around that in ten different places <amitk_> yeah, I kinda like the 16bpp look ;) <ogra> ah, thats why you dont want to change it <amitk_> ogra: ok, fire a bug at me and thou shall have it. (And you get to pick up the broken pieces if it explodes after the change) :) <ogra> i'll do a testbuild over night :P <amitk_> I still think it should be on the cmdline so that we can fix it easily incase other stuff blows up <ogra> then a lot of scripts need to be changed <Martyn> speaking of broken testbuilds ... I'm going to need some guidance on the right way to make the PBX-A9 PPA <ogra> if anything blows up because your monitor doesnt do 32bpp, you can change your cmdline as easily <lool> NCommander: I get a shitload of output when booting an installed dove y1; could you open a bug to get the kernel printks and other bits quieten down to info messages instead of warnings or something? <lool> NCommander: there's a bug for this on imx51 already #ubuntu-arm 2009-10-04 <kblin> hm, durn. it would've been too easy to expect that blog post on building kernels to just work <hamannp> Build a rootfs from scratch <hamannp> ?? <Martyn> yep <Martyn> you need help? <hamannp> Yeah. I get a bunch of nasty errors. I can't get networking. <Martyn> Ick <Martyn> there are some better ways to get a rootfs now <Martyn> you can strip one out of the dove or i.mx51 image <hamannp> Ok. Leta dmit something: I don't know what I'm doing. Can I explain what I want to do? <hamannp> hello? <armin76> lol <armin76> explain, explain :) <hamannp> Ok. <hamannp> I have a sheeva plug kit. I put it on my network, and put a full app stack on it. I have the same app arch scaled horizontally on Ubuntu amd64 VMs. I thought to myself, it would be cool to emulate some arm vms, and reproduce the horizontal architecture on Arm. Follow me? <armin76> hrm... <armin76> emulate arm on arm? <hamannp> Nope. I'll keep explaining. So I have a home Lan network. It has a bunch of old Pcs, this Sheeva kit, and a bunch of VMs. It's behind a router from my Cable provider. The VMs connect to this lan through a static bridge network on a Host. br0. I want to emulate 6 or 7 arms on qemu so that I can try out a deployment arch that I already have on amd64 vms. Make sense? <armin76> so you want to emulate arm :D <hamannp> Yes! And use my existing static br0 with multiple emulated arms with static ips. <hamannp> I'm stuck getting even one built cleanly. I also can't get it on my bridge NW, even when I copy over configs from my exisitng amd64 vms. <armin76> can't help on that, sorry <hamannp> How bout a tut on getting even one built? I tried the main wiki, and I get nasty errors. I can pro'lly figure out the networking. I think the problem is that I can't build it without errors. <hamannp> BTW, the wiki links to an old kernel. The bug report says that some of the errors I got have been fixed. IS there a magic vault of up to date ARM kernels and img's somewhere? <armin76> no clue, you should ask ogra or lool <hamannp> ok thanks! <Martyn> armin76: To whom should I address the request to have a smooth-stone PPA for karmic? <Martyn> I have a working dist now for our in-house work <Martyn> it runs on the pbx-a9 <armin76> woot <armin76> Martyn: why you ask me? :P i don't have anything to do with ubuntu :) <armin76> but same answer as hamannp :D <Martyn> LOL <Martyn> because you hang here, and just might have picked up the info <Martyn> <-- not canonical either, right :) <Martyn> armin76 : You're an amazing font of information sometimes <armin76> :D <NCommander> Martyn, I had talked with lool earlier today on how we could do "universal" armel images for SoCs that used u-boot as a bootloader <NCommander> (basically, an extension of the boot.scr functionality I created) <NCommander> Martyn, but I need a per-soc identifier to make it work, and the MACH_ID is probably the best way to it (with a way for us to override it if necessary ;-)) <Martyn> I think so too <NCommander> Martyn, hence why I'm talking to wdenk on this <Martyn> yep yep <Martyn> I don't know why there is this huge push against non devtree solutions <NCommander> Martyn, I'll be first to admit our universal image idea is a hack, but its better than the alternative <Martyn> yes <Martyn> I really, REALLY want a universal UEFI loader <NCommander> Martyn, because most people look at i386, and see how braindead it is <NCommander> Martyn, +1. <Martyn> for more reasons that one, but I'll -take- a u-boot loaders that works <NCommander> Martyn, but even if it exists, there will be a ton of inheta before its standard, and we still have legacy stuff to deal with <Martyn> NCommander : New topic for a second <Martyn> I have a fullly working image for 9.10 beta on PBX-a9 now <NCommander> Martyn, I dunno if I should be happy or scared <Martyn> what and to whom do I need to propose something to in order to get an install img for the platform? <Martyn> like the dove, and the i.mx51 have now <NCommander> Martyn, what bootloader? <Martyn> u-boot <Martyn> + ARM monitor <Martyn> well, other way around <Martyn> ARM monitor + u-boot <lool> NCommander: To be fair the boot.scr concept comes from beagleboard <lool> That's where I got the idea and told you about it <NCommander> lool, true, although boot.scr is quite a bit more advanced than the beagle boot system <lool> It uses loops but it's the same concept <lool> anyway <kblin> crap <kblin> I think my sheevaplug just died <kblin> so much for that piece of hardware <hamannp> Ok. I've been trying for days to get a working ARM image with networking based on the tutorial. My last idea is to burn it to cd and boot from that. Anyone know where I can get an .iso version? <ali1234> hamannp: what tutorial? what hardware are you using? <hamannp> I've got an amd64 desktop with 4GB of RAM. I want to emulate a couple of ARM machines on my desktop. Here's the basic tut https://wiki.ubuntu.com/ARM/RootfsFromScratch <ali1234> so qemu then... <hamannp> Yes, sorry. <ali1234> ok, so at what point does it deviate from what you expect? <hamannp> When I boot up, I get at least 4 errors. I about "file system Fusectl not supported" and another about /lib/modules not existing. I get another about this bug : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/346378 <ubot4> Launchpad bug 346378 in linux "net.ipv4.tcp_syncookies is a unknown key (CONFIG_SYN_COOKIES=y missing in ARMEL build config)" [Low,Fix released] <ali1234> ok, well those shouldn't be fatal <hamannp> That's good to know. I'm trying to add them to my existing bridge network. br0. When I copy the settings from my amd64 VMs that use that network, I still don't get networking. I thought may be I should fix the boot erros first. <ali1234> well you can fix those by recompiling the kernel with support for those things it is complaining about <hamannp> I have been able to log in. May be the machines are working, and the networking problem is something else. <ali1234> i had some problems with networking btw <ali1234> something to do with dns - it just wouldn't work. but specifying ips did <hamannp> I'm using ips <hamannp> Would any of those problems effect networking? <ali1234> i don't think so <ali1234> they didn't for me, but i'm using real hardware <hamannp> Ok. Then I wonder to what to check next. Like I said, I copied over settings from other VMs that use the network fine. <ali1234> qemu VMs? <hamannp> I built them using the python.vmbuilder <hamannp> FWIW, I have on Sheeva dev kit on my network with the same settings as my other VMs <ali1234> i don't really know what you mean by that <hamannp> Sorry kvm. <ali1234> i think you have to configure the bridge on the host machine too <ali1234> the vmbuilder probably does that for you <ali1234> but i don't know because i don't use qemu/kvm <hamannp> I've had the host bridge working for 6 months. I have it setup for kvm to automatically add a static ip and configuration for the host bridge network. The hoist side is good. <ali1234> kvm isn't the same thing as qemu-arm <ali1234> so do you see the interfaces on the brctl? <hamannp> Yes. Shouldn't it use the same unix networking? Is there something different? <hamannp> I don't fully follow you. I setup br0 for static ips in my /etc/network/interfaces file and bring it up automatically. If I do an ifconfig on the host, it shows up. <ali1234> brctl show <ali1234> that will list the interfaces that are part of the bridge <hamannp> yes, it shows eth0, which is right. <hamannp> it also shows vnet0, not sure what that is. May be default network for kvm???? <ali1234> probably <hamannp> Huh. I'm stumped. <ali1234> each virtual machine has it's virtual nic, which has endpoints on both the guest and the host <hamannp> Yes. <ali1234> on the host you have to bridge them all together, and with the real eth0 <ali1234> you say you have kvm doing this for you <ali1234> but qemu-arm does not use kvm <hamannp> I edited each guest /etc/network/interfaces. Although I've now got it setup so that when I run the build script, it edits them automagically. <ali1234> sure. you you have to configure it in the host too <hamannp> I edited the qemu /etc/network/interfaces file manually to have the same settings as the kvm VMs that use the bridge. <ali1234> great <ali1234> that's correct <ali1234> so, which vms are currently running right now on your host? <hamannp> I've got a couple of kvm vms running using br0 just fine. I've got a qemu ARM with the same settings, which isn't able to reach the network <ali1234> and all are up and running? <ali1234> what interfaces do you see on ifconfig -a <hamannp> Hold on. I'll check. <ali1234> look for tun0 or tap0 or similar <hamannp> I don't see tun0 tap0. <hamannp> I just see see eth0, vnet0, and br0 on the host <ali1234> how did you launch qemu? <hamannp> Hold on. I'll paste the command line. <hamannp> qemu-system-arm -M versatilepb -kernel ./vmlinuz-2.6.28-11-versatile -hda qemu-armel-200910011752.img -m 256 -append "root=/dev/sda mem=256M ro" -net nic,macaddr=00:16:3e:00:00:01 -net tap <hamannp> May be I see the problem <hamannp> Should I have ended it with -net br0? <ali1234> hmm i don't think so <hamannp> Ok. stumped again ;) <ali1234> hmm try modprobe tun <ali1234> and then relaunch qemu <hamannp> ok <ali1234> this time you should get a tap0 or tun0 to add to br0, and then it should work i think <hamannp> ok. It's booting the machine. <hamannp> I get a tap0 <ali1234> the if should be up already <hamannp> sorry? <ali1234> the interface should get created as soon as qemu starts, i mean <ali1234> the tap0 that is <hamannp> ok <hamannp> It's there <ali1234> so, now brctl addif br0 tap0 <hamannp> ok <ali1234> now it should work :) <hamannp> Ok. I'll test here in just a second. <hamannp> Btw, qemu boots sloooooooooow <ali1234> well yeah, it's basically an emulator <ali1234> unlike kvm which uses virtualization <hamannp> Gotcha. <hamannp> I might need to head to my local electronics store (Fry's) and pick up a dozen dev kits. <ali1234> meh. cross compilers and what not... <ali1234> qemu can still be faster than the real hardware sometimes <hamannp> I've got the one Sheeva plug dev kit. A little flakey, but fun to play with. <ali1234> no such luck here, i'm hacking on my mobile phone :) <hamannp> Have you seen the dual-core Marvell 1.2ghz? <ali1234> i've heard about that stuff but never seen it <hamannp> They can take 1GB ram/core <hamannp> It works! You're the man! How do I get it to work next time? <ali1234> um..... hang on <ali1234> edit /etc/modules <hamannp> host machine? <ali1234> add a line with just tun on it, as per the instructions in the comments <ali1234> yeah, on the host. assuming you use ubuntu <hamannp> Of course I use Ubuntu!!!!!!!!!!!!!! All the time ;) <ali1234> and you need to make a script to add the interface to the bridge like it shows on the tutorial <hamannp> I think I can do that. <hamannp> I should have it from this chat log. <hamannp> Thank you!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! <ali1234> the /etc/qemu-ifup thing <ali1234> not sure how that works though <hamannp> I can do it manually until I figure it our. <hamannp> Thanks alot! I'm gonna grab a beer and jump in the hot tub. Literally. You've made my day! #ubuntu-arm 2009-10-05 <ali1234> those instructions have been cribbed from here i guess: http://www.aurel32.net/info/debian_arm_qemu.php <ali1234> debian probably loads the tun module by default <hamannp> I'll check it out. I'm kinda self taught, so my networking knowhow is spotty. <hamannp> Worse, still, I'm long on academics. It let's me dream up sophisticated ways to get in over my head. <hamannp> Ciao! I'm sure I'll see you around this channel. <lool> ogra: We have a really serious issue <lool> ogra: our redboot binary doesn't work on b2.5 anymore <lool> or perhaps it's related to some settings <lool> ogra: I couldn't boot my b2.5 since a week or so <lool> ogra: I manually replaced redboot on the SD card with the one from the archive, and it didn't work <lool> ogra: I manually replaced redboot on the SD with the latest one from FSL and it worked <lool> ogra: So it seems related to fconfig data <lool> ogra: I rewrote a live image and it worked <lool> ogra: I suspect we need to update the fconfig data on redboot upgrades <lool> I cant reproduce it anymore now since I wiped the SD card with the issue <ogra> lool, weird, works fine here on fresh installs as well as updates <ogra> lool, i usually try both before i upload the new redboot <lool> ogra: I dont know what happened; I'm pretty sure it's fconfig data since I rewrote redboot on the SD <lool> I guess I should have kept a backup, too bad <lool> ogra: I fear it's something overflowing a var, or a var missing <lool> ogra: For intsnace UUID= overflowing bootcmd <ogra> yeah, i usually replace the redboot binary on the running SD i use first <ogra> and then redo that SD with a completelky fresh setup using the new redboot <ogra> if both work i upload <ogra> i cant imagine UUID overflowing bootcmd <ogra> i had setups where i had to test FSL setup with ten liners more in the bootcmd script <ogra> *lines <ogra> do you know which version the old redboot was you replaced ? <lool> ogra: Hmm good questions <lool> It was for B2.5 but how old, no idea <ogra> i know we had a broken one druing early karmic <lool> ogra: I dont even know how it broke exactly; I had taken the SD out to do various boot testing <ogra> weird <lool> ogra: But the way it broke was spectacular <lool> random leds would turn on <ogra> wow <lool> boards would shut off by itself <ogra> did you have anything plugged into the NIC ;) <ogra> the grounding issue can affect the whole system ... <lool> ogra: No, I unplugged everything when that started t ohappen <ogra> hmm <lool> ogra: Well the grounding issue wouldn't explain why one redboot worked and not the other <lool> ogra: Still I'm a bit scared that FSL's uboot worked and not ours <ogra> no, indeed <lool> I used the latest one from their SDK 1.6 pre-release <ogra> ours works <ogra> it is just featureless <ogra> and oem wont use it <lool> Well ours didn't in my test, then worked when I wrote the whole SD image <ogra> i had it working here <lool> ogra: Well as I said, I cant reproduce the issue anymore <lool> Even with our redboot <ogra> well, up to the u-boot prompt <ogra> well, i havent heard about such an issue yet and havent seen it myself ... all we can do is keep an eye on it i guess <ogra> i'll try to make some time free to test the different karmic versions, i still have them around <lool> thanks <lool> kubuntu fails to build due to gtk+ -- ironic and suspicious <ogra> heh <ogra> i think it uses some qt-gtk translator thingie <ogra> not sure how it's called nowadays <ogra> are you sure its gtk itself ? <lool> ogra: libgtk2.0-bin: Depends: libgtk2.0-0 (>= 2.18.1-1ubuntu1) but 2.18.1-1 is to be <lool> installed <lool> I'm sure yes <ogra> evil <lool> I thought gtk wasn't in kubuntu <ogra> it shouldnt be, did you notify Riddell or ScottK ? <ogra> i know they have that gtk theme layer handling tool, but that doesnt require gtk <lool> ogra: I did not <flaco> hey all.. I'm planning to buy a beagleboard.... and put ubuntu on them... my question is if gstreamer and python works on this plattform <lool> flaco: Yes <lool> We dont provide the kernel part though <ojn> is anyone (community?) looking at wrapping up the various components already? <ojn> (openmax/gstreamer integration, that is) <lool> For beagle? I dont spend much time on beagle support in ubuntu myself nor do I know of people here who do, but there are some community provided kernels out of ubuntu <lool> Concerning gst or openmax integration, I didnt see the beagle bits myself yet <lool> Are these fully open? <ojn> lool: for omap, not board specific really. <ojn> lool: everything but the code running on the DSP is. The trick is to pick the right TI project, there seems to be a few stale ones. :) <ojn> (and the code running on the dsp is, for all intents and purposes, equivalent to firmware anyway) <flaco> lol, thanks for the answer... so I need to build those packages for use on arm? <flaco> lool, thanks for the answer... so I need to build those packages for use on arm? <lool> flaco: You can use the ubuntu user space <lool> flaco: http://elinux.org/BeagleBoardUbuntu <Martyn> lool : I just saw a beagle clone that was well made .. it has ethernet (SMSC1918), USB 2.0 host, usb OTG, DVI + hdmi output (and LCD cable via membrane cable), etc... <Martyn> it's the first one I've seen that is a good "desktop board" contender <Martyn> frankly the only thing "missing" is 802.11(b/g/n) <Martyn> and that's that USB is good at <Martyn> mmmm .. aptitude install rootstock <ojn> martyn: url/product name? <Martyn> ojn : it's being made by students at the University of Texas/Austin <Martyn> I don't think they have come up with a cute name yet. I heard it called 'PoodleBoard' <lool> Martyn: ethernet is nice <ojn> Ah, so not productized (yet). Seems like there are a few already though. IGEPv2 looks promising <ojn> gumstix overo with tobi comes close too. <Martyn> the overo is very nice <Martyn> (and very out of stock, damnit) <Martyn> I wanted one <ojn> Martyn: I think they manufacture them in batches, so placing an order makes it more likely to show up soonish. :) #ubuntu-arm 2009-10-06 <superdug> why am I so impressed with linux on a processor that can run linux? <ogra> lool, so about imx-libs and xserver-xorg-video-imx and theior linking .... xserver-xorg-video-imx needs to link against mxcfb.h/ipu.h as well (looking for it on include/linux), do you know if the policy allows it that i would copy both headers during package build into imx-libs so it would ship these two in /usr/include/linux and the xserver wouldnt have to be hacked up for isung linux-headers ? <ogra> s/isung/using/ <lool> ogra: I think this would create another libdrm and I dont think we want that; it sounds like these headers should be in the kernel tree instead? <lool> ogra: In which case we'd have to build-dep on linux-headers-imx51 instead of linux-libc-dev because of the mx51 stuff not being upstream <ogra> lool, yes, it is in the kernel tree atm <ogra> and imx-libs dep on linux-headers-imx51 and build fine with it <ogra> the xserver has no configure option to add additional includes though <ogra> and hasnt /usr/src/linux* in its default include path <ogra> given that apps that build against imx-libs always need to have the headers from linux-headers it would be more easy to have imx-libs ship them in the default include path instead of having to hack up each app that uses them <lool> Oh right <lool> ogra: I disagree that we want imx-libs to ship them <lool> These headers are in the kernel source and should remain there <lool> ogra: But we might have to move them to the expected place <ogra> ok, then i'll need to hack up the xserver autofoo <lool> Or add -I flags when using imx-libs <lool> ogra: Well you could also copy them in linux-fsl-imx51 <lool> But you'd have to be really careful in only adding new headers <ogra> hmm, would linking not work ? <lool> Perhaps it's best to add an -I flag for now; until the headers make it to linux-libc-dev <lool> To avoid any clash <lool> ogra: Well linking or copying, yeah, but the issue is that if the upstream kernel or another vendor or another kernel tree (e.g. lange) wants to provide the same filenames, we're in trouble <lool> While adding the -I is safe <ogra> i could make a link from /usr/include/linux/mxcfb.h to /usr/src/linux-headers/*.../mxcfb.h in the libimx-dev package <ogra> i think currently its highly inlikely that we get the same files anywhere <ogra> ipu.h and mxcfb.h are pretty exclusively only on the imx51 arch <lool> I'm not too hot on it <ogra> well, ok, i'll hack up the xserver for now to look in the linux-headers dir too <ogra> but that makes two packages that have to stay in sync <lool> ogra: Actually one thing which strikes me is that the headers are under an ABI path <ogra> right <ogra> which is pointless unless the patches get actually updated <ogra> even if we have an ABI bump they usually stay untouched <lool> ogra: The core of the issue is that we currently rely on linux-libc-dev/armel to build everything on armel <lool> While we truly have multiple kernel ABIs <lool> One per subarch <ogra> yeah <ogra> plus vendor patches <lool> We cant have multiple linux-libc-dev <lool> I think using the upstream kernel ABI/API is best for us by defalut <lool> But we could use a more specific ABI/API for packages which need it, like here <ogra> right, but that wont work for such device specific headers <lool> Still, this should be offered by the linux-fsl-imx51 packages <ogra> well, i fear any changes in the packaging of linux-fsl-imx51 <lool> So perhaps we should have a linux-libc-dev-fsl-imx51 which would install in /usr/include/fsl-imx51/* (/linux etc.) <ogra> especially this late in the cycle and with the experience i made this round <lool> (I'm speaking long term) <lool> I dont think that's doable for karmic <ogra> yes, i understand <ogra> right <lool> (But I want to get the logic right as to solve this properly next cycle) <ogra> yup <lool> ogra: So either imx51 gets merged upstream in the kernel and we use linux-libc-dev (unlikely before long), or we come up with such a hack <ogra> well, atm there are in max 5 devices <lool> ogra: I'd rather use a new binary package for this since the linux-headers packages already have use cases <ogra> so that package would be fairly empty <ogra> we only use three of the 5 atm <lool> ogra: I think it would be a full replacement for libc-dev <lool> ogra: In theory, the ABI could be difference in some places than the upstream one <ogra> though sahara was enabled in the config, i will probably switch it back on in imx-libs <lool> ogra: e.g. they could add some fb ABI calls <lool> (ioctls) <ogra> ah <ogra> yep, i understand <lool> ogra: Is this approach fine with you for karmic+1? * ogra thought of it as addon package <ogra> yup <lool> ogra: Ok; now looking at what we can do in karmic <ogra> bloats the archive with duplkicates though ... but surely the best path to take <lool> ogra: So I dont think we want to change kernel at this point <ogra> well, both packages arent even in the archive <ogra> and unlikely to enter <ogra> so let me add hacks to the packages for now <lool> ogra: What we could do is have imx-libs build-dep on linux-headers-fsl-imx51 and copy the latest headers from there into imx-libs <lool> or use them directly there <ogra> thats what i asked initially for :) <ogra> it alreayd build-deps on the headers <lool> Well I prefer planning the clean fix first, then looking at immediate workarounds <lool> ogra: Do you that in imx-libs or xorg-imx51 or both? <ogra> and libimx-dev can easily copy them into /usr <ogra> i would do it in libimx-dev and make it ship them in /usr/include/linux <ogra> then have the xserver just b-d on libimx-dev <lool> Well dont you think we can implement the /usr/include/fsl-imx51 part directly? <ogra> that would mean to hack up the xserver package to look in there <lool> Which will be needed for the long term plan anyway <ogra> ok <ogra> so i'll do both <ogra> copy the headers and hack up xserver <lool> Cool <ogra> thanks :) <lool> ogra: Do you want to file the bug for the lucid stuff? <ogra> can do <lool> Ok <lool> ogra: I just had this bug again that I did a reboot on babbage 2.0 and it shutdown instead; do you know if we have a bug for that or shall I file one? <ogra> we dont <ogra> and i didnt see such behavior yet <lool> ogra: So reboot works for you? <ogra> yep <ogra> but thats 2.5 <JamieBennett> lool: I had the exact same thing yesterday <lool> Right <ogra> you have other weird issues on your 2.0 <lool> JamieBennett: On 2.0 and/or 2.5? <JamieBennett> 2.0 * ogra remembers the xterm issue <lool> JamieBennett: did you try on 2.5? <JamieBennett> I don't have the lead yet (going to a specialist shop this morning to get it. <JamieBennett> ) <lool> b444386 <lool> #444386 <ogra> we should try to make that bug appear on 2.5 too, then it would at least shut off at all :P <lool> Eh <lool> I thought the same, that it was really ironic that one shuts off too easily while the other cant <ogra> yeah :) <JamieBennett> lool: have you seen video issues with 2.0 on the desktop? I have about 20 pixels missing from the top left hand corner running horizontal. <ogra> could that be caused by the toolchain issue ? <lool> ogra: make sure you include karmic+1 or something in the headers bug <ogra> will do <lool> ogra: No <lool> The toolchain issues are only problematic when doing stack unwinding in C++ stuff, so not in the kernel <ogra> ok <lool> JamieBennett: I did file a couple of video bugs on b2.0 * JamieBennett goes to look <lool> JamieBennett: 2.5 is more stable so nobody bothers with the 2.0 specific bugs <JamieBennett> ok <ogra> JamieBennett, does it go away if you definate a video= option on the cmdline <lool> JamieBennett: https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51 and ~ubuntu-armel bugs are good places to check for them * ogra thinks he has seen that before <lool> https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/430969 <ubot4> Launchpad bug 430969 in linux-fsl-imx51 "Display unstable when running xterm" [Low,New] <ogra> JamieBennett, make sure to have the laters redboot-tools (0.7) you can easily edit the cmdline with redboot-cmdline from the running system <JamieBennett> ogra: haven't tried, just strange that its 1px x 20px top left and nothing else <lool> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/358956 <ubot4> Launchpad bug 358956 in linux-fsl-imx51 "armel Babbage iMX51 line truncation and addition on VGA output" [Undecided,Incomplete] <ogra> i think it goes away if the driver gets a video= option <JamieBennett> ok <lool> JamieBennett: Can you reopen that last bug if it matches? <JamieBennett> lool: Will do. <ogra> JamieBennett, try with video=mxcfb:1024x768-32@60 <JamieBennett> ogra: OK * ogra hopes he has that right from the top of his head <lool> JamieBennett: also, the first bug (xterm makes display unstable) wasn't confirmed by anyone else; it's low prio but your confirmation would be nice <JamieBennett> lool: I'll look into it now <ogra> lool, the truncation bug is different though ... its just a small square above thats rendered black directly over the applications menu <ogra> s/above/at the top/ <lool> JamieBennett: Or perhaps file a new bug, use your judgement <lool> It was painful to setup this local debmirror, but it feels so snappy when I use it that I really don't regret it! <lool> I think I'll enjoy deboostrap as well <JamieBennett> Just caught your Bug #430969 on camera lool :) <ubot4> Launchpad bug 430969 in linux-fsl-imx51 "Display unstable when running xterm" [Low,New] https://launchpad.net/bugs/430969 <lool> k <ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ grep -r "pin config changed" * <ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ * ogra scratches his head <ogra> i wonder where "iomux_config_mux: Warning: iomux pin config changed" might come from on boot <ogra> its the very first bootmessage the babbage spits out <ogra> lool, the regulator errors on bug 438680 look suspiciously like a porting error <ubot4> Launchpad bug 438680 in linux-fsl-imx51 "please quieten down bootmessages" [Low,Triaged] https://launchpad.net/bugs/438680 <ogra> i wonder if i should open a new bug for it <ogra> ogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ grep -r "with no identifier" drivers/* <ogra> drivers/regulator/core.c: printk(KERN_ERR "regulator: get() with no identifier\n"); <ogra> lool, i think bug 439282 should be high instead of medium <ubot4> Launchpad bug 439282 in linux-fsl-imx51 "does not power down the system properly" [Medium,Confirmed] https://launchpad.net/bugs/439282 <ogra> what do you think ? <lool> ogra: I dont really care beween the two as long as it's fixed ;-) <lool> ogra: I dont think it's a big deal for a developer board <lool> I find it a pain that sound doesn't work because I can imagine people using that for development <lool> And ethernet not working with NM is also a pain for a desktop use case, since ethernet is in the soc it hits all boards <lool> But wiring of the PMU is likely to differ per board (as it does on lange for instance) so I'm not too concerned that we use power when off; even if it's a bug we should try to fix for release <lool> ogra: Not sure what you want me to do about the regulator stuff? <ogra> nothing, i want to know if you would consider it better being a separate bug <ogra> i have no idea what it implies if the code isnt properly integrated with the core kernel regulator code <ogra> the messages seem to come from that <lool> Oh I dont know either <lool> probably best to check with kernle folks <ogra> yeah <ogra> waiting for brad or some other ARM person to get up though <NCommander> ogra, I talked w/ cjwatson. The easiest way to get partman-uboot tested is in an alternative CD environment. Probably best if I spend a few cycles working on this with your assistance (as we want alternates anyway ...) <NCommander> er <NCommander> lool, <ogra> NCommander, but d-i should come up, shouldnt it ? <NCommander> ogra, it doesn't get as far as partman <ogra> whats the stopper ? <lool> NCommander: Well they are mostly working already <NCommander> lool, they are? <lool> NCommander: For me alternates worked <lool> I think I tested netboot <lool> I got the console fonts bug and then the symlink issue IIRC <ogra> lool, right, cd detection fails on the normal alternates <NCommander> Oh, netboot works, but there isn't a way to easily preseed on netboot <ogra> netinst should work if you have a working NIC * NCommander notes that he should probably write a boot.scr for netboot soonish <lool> NCommander: Oh and I had to do the cdrom-detect/try-usb=y thing <lool> NCommander: There isnt?? I thought there was a preseed file on the CD and it's just a kernel cmdline parameter <lool> Oh you mean in the image itself; I'm sure we can add that <NCommander> lool, ah :-) <lool> NCommander: files are in initrd, so it's probably trivial to add one and add a cmdline arg <NCommander> lool, yeah, I was going to make that change once I sit down and hit d-cd with a shovel <lool> it's debian-installer rather #ubuntu-arm 2009-10-07 <pwnguin> http://dooble.sourceforge.net/maemo_dooblescratchbox2.PNG <pwnguin> lol <pwnguin> windows vmware ubuntu xephyr maemo <siji> hi mike^, <siji> I successfully compiled clutter 1.0 with EGL support <siji> Now am getting excellent performance specially with animations etc <lool> siji: Cool <Vink___> Hi, how do I create a ubuntu filesystem for ARM, anything simliar to OpenEmbedded? <Vink___> anyone? <ojn> Vink___: https://wiki.ubuntu.com/ARM/RootfsFromScratch <Vink___> Can I compile the rootfs with customized packages? I want to add/ remove a lot of stuff <Vink___> ojn: Can I compile the rootfs with customized packages? I want to add/ remove a lot of stuff <ojn> Vink___: It comes with alot of packages already, and the rest you can install with apt-get just like under regular ubuntu/debian <ojn> If you feel a need to waste computrons on rebuilding your own software every time, then ubuntu isn't the obvious choice. gentoo or OE might be a better base. #ubuntu-arm 2009-10-08 <dpb> is the current karmic booting on the beagleboard? I'm getting "init: procps main process (670) terminated with status 255" on boot and it stops there <beyossi> i am looking for a glib-2.20.0 and gstreamer-0.10 packages to be installed by apt-get into my beagleboard. The list of packages with the package name inside is long and I can't find out which is the package I need. can someone help with that? <beyossi> well, I took the most wider package, so I am sure it depends on the basic library I need :-) -life are easier when you memory <lool> beyossi: What do you need? <lool> beyossi: shared library? development headers? <lool> beyossi: apt-cache search libglib should give you a list with short descriptions <lool> dpb: I run karmic on beagleboard <lool> dpb: Do you use an initrd? <lool> dpb: Try with an initrd; would also be nice to see your full boot log on serial console <beyossi> lool: thanks, i found. <beyossi> my application compilation looks for asm/hwcap.h <beyossi> any idea what library to install?, is it libasm-dev? <beyossi> found. you need linux-libc-dev #ubuntu-arm 2009-10-09 <dpb> lool: I don't use a initrd. Is there some howto how to do an initrd for an arm rootfs? I used rootstock to build the rootfs. <dpb> lool: here's the boot log if you're interested: http://koti.kapsi.fi/dpb/beagle.txt <dpb> lool: what kernel do you use? what is recommended? <lool> dpb: For beagle, there are debian packages on the web <lool> dpb: http://www.rcn-ee.com/deb/kernel/beagle/karmic/ <lool> dpb: I run a self built kernel <lool> dpb: Your kernel cmdline looks good, not sure why you dont get further output <lool> dpb: I didnt reboot in a while since the new mountall arrived <lool> dpb: It might be that it's borken without an initrd (that should be supported though); to create one, use update-initramfs -c in the chroot <lool> perhaps using qemu if you dont have working ARM hardware <lool> dpb: I'm abroad right now, but could probably help more next week <dpb> lool: ok, thanks <dpb> lool: hrmm, I wonder why rcn-ee.com and rcn-ee.net has different kernels... .net has much more newer kernels too, with the same exact path otherwise... ;o <lool> Eh <lool> No idea <lool> not running that site <lool> I'm using my own kernels <lool> dpb: Otherwise, the linuxomap tree mostly works <lool> (tmlind'd) <lool> (tmlind's) <ogra> grmbl, cdrdao seems to use $(uname -m) at buildtime <lool> ogra: fix it! <lool> ogra: I think Jamie was looking at it already <lool> ogra: Did you see the conversation on the debian patch already? <ogra> no, i didnt know there is a debian patch <lool> ogra: You fail basic grep then :) <ogra> i just looked at the FTBFS list and started a testbuild with the armv5tel files copied <lool> 22:38 < JamieBennett> caused by a missing RULES/ file for armv7l <lool> 22:38 < JamieBennett> has arm4l <lool> 22:46 < lool> JamieBennett: debian/patches/10-rules-armel.patch <ogra> funnily fakeroot debian/rules clean does run ./configure for about 40 times <lool> 22:48 < lool> JamieBennett: Our armel architecture is v6 and Debian's is v4, the build shouldn't have to know about v4 or v7; it would be nice to foce the build to use the target arch instead of the detected buildd arch <ogra> there is armv5tel <lool> Did you read debian/patches/10-rules-armel.patch ? <ogra> nope <ogra> ogra@dove:~/devel/cdrdao-1.2.2$ less debian/patches/10-rules-armel.patch <ogra> debian/patches/10-rules-armel.patch: No such file or directory <ogra> pfft <lool> 22:50 < lool> JamieBennett: minimum change: add v7l because that's what our buildds are, good change: make the build use the target arch instead of buildd arch, perfect world change: fix the build to detect what it needs to know about instead of trying to support all arches in the world <ogra> dpatch ... heh <lool> I don't know what you're looking at, I see the pathc just fine <lool> dpkg-source: info: extracting cdrdao in cdrdao-1.2.2 <lool> dpkg-source: info: unpacking cdrdao_1.2.2.orig.tar.gz <lool> dpkg-source: info: applying cdrdao_1.2.2-18ubuntu2.diff.gz <lool> vi debian/patches/10-rules-armel.patch <ogra> its .dpatch :) <lool> It's not <lool> cdrdao (1:1.2.2-18ubuntu2) karmic; urgency=low <lool> ogra: We are not Debian :-) <ogra> well, thats what the archive gave me <ogra> cdrdao (1:1.2.2-17) unstable; urgency=low <ogra> seems my apt cache isnt up to date <lool> ogra: My version being newer, I suspect you suck ;-P <ogra> pfft <lool> ogra: You're so yesterday-ish <ogra> heh <lool> Was pushed Oct 3 <ogra> yeah, i'm working remotely <ogra> my laptop has my approx instance for my LAN <ogra> so the dove board doesnt find the up to date source <lool> haha <lool> As I was saying you suck :) <lool> I'm running a script to disable/enable my mirror when I'm traveling <lool> But mirror is on the LAN <lool> ogra: I should mock you again for your slowness <ogra> :P <ogra> he cdrdao code should really be fixed to not use uname though <ogra> *the <lool> I agree <lool> Actually I said it earlier :) <ogra> .oO(hungry .... it smells so good and i didnt have dinner) <lool> That said it's probably easier to fix it like Debian for karmic <ogra> indeed <lool> ogra: You had 3 beers <ogra> liquid bread doesnt count <lool> ogra: And at least 2 cigarettes <ogra> more <ogra> i go a smoker room :) <lool> OMG <ogra> *got <suihkulokki> there is a bunch of other packages that use the same build system and will need same fixes <suihkulokki> basicly all packages from the same upstream author... <ogra> who evet invented that should be shot <ogra> *ever <ogra> ah, k <ogra> that explains something <lool> suihkulokki: (I omitted the part of the logs where I name the upstream and complain about him ;) <suihkulokki> he-who-name-whe-shall-not-mention <ogra> do you fear he shows up at your door ? <ogra> thats just because of the umlauts, no ? #ubuntu-arm 2009-10-10 <ogra_n900_> well, at least webchat works <ogra_n900_> hey JamieBennett <JamieBennett> ogra_n900: Guess you got it working then ;) <ogra_n900_> nope, webchat.freenode.net FTW <JamieBennett> :) <ogra_n900> yay <playya_> ogra_n900, you already have a n900? <ogra_n900> playya, yup, nokia gave them away at the maemo summit <lool> playya_: You dont? <lool> davidm has one, ogra has one, I have one <lool> Everybody has one these days <lool> I bet jamiebennett has one too * armin76 doesn't <ogra_n900> hehehe <playya_> lool, no. I#m a poor student <playya_> i hope ogra will be available in gÃ¶ttingen. i need a photo of the device in my hands ;) <Meizirkki> omg rootstock finally works! <Meizirkki> w00f :P <Meizirkki> roope@ruoska-ng:~/Tyokansio/TBuntu/images$ sudo qemu-system-arm -M versatilepb -kernel ./vmlinuz-2.6.28-versatile -hda TBuntu9.10.img -m 512 -append "root=/dev/sda mem=256M ro" <Meizirkki> Segmentation fault (core dumped) <Meizirkki> >_< <Martyn> stragce it <Martyn> strace it rather <Martyn> I've been making karmic rootstocks all day <Martyn> most work <Martyn> although I'm not using the stock versatile kernel (I have my own extensions) <Meizirkki> after cahnging -m 512 to -m 256 it booted, but now shows kernel panic <armin76> feature :D <Meizirkki> yes #ubuntu-arm 2009-10-11 <armin76> eFfeM: afaik yup, but lool may tell you officially :) <armin76> eFfeM: yup as in armv5 is dead wrt ubuntu <eFfeM> armin76: understood, ty <lool> eFfeM: We wont provide official armv5 binaries, but I wish we'd have non-official tools + repos to create such binaries <eFfeM> lool: thanks for the info, guess this means for now I have to move on if I want something more recent #ubuntu-arm 2009-10-12 <daver> hi there, any SmartQ users on here? <Stskeeps> we're a good bunch of them in #mer <daver> oh really? <Martyn> Is there any special kernel cmdline I need in order to get karmic to boot? <Martyn> Right now, I'm using: <Martyn> console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 #ubuntu-arm 2009-10-13 <amitk> ogra: your rootstock script looks for qemu, I believe you need qemu-arm-static? <amitk> or rather qemu-kvm-extras <amitk> ogra: await my trivial patch while a struggle through bzr <Martyn> Okay, more fun with Karmic this morning --- <Martyn> mountall:/proc/filesystems: No such file or directory <Martyn> init: mountall main process (638) killed by SEGV signal <Martyn> This is what I get at the end of the boot sequence... <Martyn> [ 22.769409] Waiting for root device /dev/mmcblk0p2... <Martyn> [ 22.794891] mmc0: new SDHC card at address 8fe4 <Martyn> [ 22.800201] mmcblk0: mmc0:8fe4 SD04G 3.69 GiB <Martyn> [ 22.805053] mmcblk0: p1 p2 <Martyn> I'm assuming this is caused by the new init replacement? <amitk> Martyn: I recall lool talking about this and that it was fixed in the latest upload <Martyn> I just built a rootstock 12 hours ago <Martyn> is that upload newer than that rootstock? <Martyn> (do you know if lool made a launchpad bug I could look it up against?) <amitk> Martyn: dunno, but I think it was fixed today <amitk> ogra: does rootstock work with apt-cacher-ng? -m <url> isn't working. <Martyn> urk .. today eh? <Martyn> Well, I'll try building another rootstock then <Martyn> I hate how long it takes <amitk> Martyn: hence the question about apt-cacher-ng above :) <amitk> I think rootstock should either be modified to cache the .debs in a local dir <amitk> or use apt-cacher-ng <amitk> It probably does, I am just too dense to figure out how <Martyn> afik I haven't seen anything that lets it cache the .debs <Martyn> which would, frankly, be awesome <amitk> though the biggest bottleneck isn't downloading the .debs, but installing them inside qemu (which isn't multi-core friendly) <Martyn> Mine is downloading the .debs <Martyn> Because right now it's at #268 <Martyn> and still going <lool> amitk: You need qemu-arm-static for rootstock <lool> amitk: It uses binfmt misc to run the executables and cant work with a qemu needing shared libs <lool> Martyn: mountall as fixed < 12 hours ago <lool> +was <lool> Martyn: You need .2 <Martyn> Yeah, so I'm building a new rootstock <Martyn> .2? <Martyn> what's the fix? <Martyn> /bin/sh /usr/bin/rootstock --fqdn beagleboard.i.smooth-stone.com --login default --password default --imagesize 2G --seed xfce4,gdm --dist karmic --serial ttyS2 --kernel-image http://rcn-ee.net/deb/kernel/beagle/karmic/v2.6.31-rc8-3777b1e-ang1.1/linux-image-2.6.31-rc8-ang1.1_1.0karmic_armel.deb <Martyn> <Martyn> That's my current build <lool> Martyn: There are a bunch of changes <armin76> Martyn: any news wrt my ssh access? :) <Martyn> lool : they should all appear in the rootstock I'm doing, right? <Martyn> armin76 : Didn't I send you the ip/log/pass? <Martyn> look for an email from lauren32@example.com <armin76> hrm.. <armin76> Martyn: probably got marked as spam :/ can you resend it please? <armin76> when did you send it? <Martyn> A long while ago <armin76> i got junk mails up-to 25th sept <Martyn> pretty much after you first asked <Martyn> Okay, later when I get a chance to hit the lab <armin76> :( <Martyn> right now I'm still working on getting the new rootstock working <armin76> ok, thank you :) <Martyn> init: procps main process (650) terminated with status 255 -- new error <Martyn> It doesn't seem to affect much on the board when I boot ( it proceeds to doing keymap, etc ) <Martyn> but still, it's odd that procps is dying <ogra> amitk, i use it with approx here, it doesnt work if you use localhost in the url <ogra> beyond that it should just work <amitk> ogra: do you have a pre-synced archive or does it cache on the fly? <ogra> on the fly <ogra> but given that i usually build one or two images a day it is usually up to date <Martyn> huh .. so I should be able to use apt-cacher-ng, as long as I use the fqdn? <Martyn> (and not localhost.localdomain?) <ogra> right <armin76> Martyn: hrm...i don't think i ever gave you my mail :P <Martyn> I'll remember that for my next build <armin76> lauren32@example.com :) <amitk> ogra: what does the --kernel-image option do in rootstock? Since it can't really flash the kernel into the SD. <ogra> amitk, used by beagle, not my code <ogra> it didnt break the rest so i simply accepted the patch <ogra> ignore it for anything but beagle <ogra> (i think the manpage says that) <Martyn> yep <Martyn> and I'm using it on a beagle :) <Martyn> looks remarkably good, actually.. latest rootstock only has the procps bug on boot <Martyn> amitk: and you can flash the kernel onto the SD for some architectures :) <Martyn> the PBX-A9 now has a u-boot loader that will look on the mmc card first, rather than nand <ojn> gumstix will even load u-boot from mmc before it loads it from nand <ojn> (_very_ convenient :) <Martyn> X-Loader does rock that way :) <Martyn> beagle can do, with the correct X-Loader <NCommander> lool, at the risk of being dense, what specifically is the problem with mountall on dove (aside from the fact it breaks images)? <lool> NCommander: I dont know <NCommander> lool, meh, I guess its going to require bisection with the latest uploads to figure out what broke it :-/ <lool> Why? <NCommander> lool, well, mountall preventing the system from coming up even on installed systems. Its a regression based off one of the most recent updates, so I want to isolate what version it popped up in <ojn> Hmm. What's the supposed procedure to get an uimage to boot from using ubuntu kernels? linux-image-<foo> only gives me a vmlinuz?! <lool> NCommander: it's not the latest version <lool> NCommander: .2 should be fixed <lool> ojn: Depends of the board <lool> ojn: mkimage
{'channel': 'ubuntu-arm', 'month': 10}