/srv/irclogs.ubuntu.com/2010/03/22/#ubuntu-arm.txt

loolapw: Heya10:02
loolapw: On https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524893 the config change can actually be reverted; it didn't help and wasn't actually needed once the fix was found10:03
ubot4`Launchpad bug 524893 in qemu-kvm (Ubuntu Lucid) (and 3 other projects) "versatile: Can't boot initramfses (affects: 1)" [Low,Fix released]10:03
loolI also had in mind to kill the default cmdline from the config, it overrides the ATAG mem information and qemu-ssytem-arm uselessly defaults to 32MB of RAM10:04
lool(that is, passing -m foo to qemu-system-arm isn't enough, one has to pass mem=foo too)10:04
persia32MB!!!!!10:04
loolYup10:04
looltriggers d-i "Low mem mode"10:05
loolpersia: It's from the defconfig10:05
loolit's an old board10:05
persiaright.10:09
loolapw: sent to the list10:17
loolpersia: BTW did you get a chance to go over the /Ports page?10:18
loolpersia: I'd like to hook it up from the /Development page now10:18
persiaUnfortunately not.  It was top-of-my-list for Saturday, until something else intervened.  I'll look at it as soon as I've eaten.10:21
loolOk thanks10:21
=== ogra_ is now known as ogra
nosse1Are there any good reasons for me to up my host to Lucid to develop/build Luicid ARM targets (w/rootstock)?11:57
rcn-eenosse1, depends if you also want to test x86 lucid. ;) otherwise karmic works fine, just use the bzr trunk of rootstock11:58
nosse1of course I want to test Lucid x86 as well... ;)11:59
nosse1rcn-ee: rootstock is one, script right? Not spread across several files?12:00
rcn-eeyeah, it's just a script that access qemu..12:00
nosse1excellent. I think I got it then.12:01
nosse1Now I'm this close to attempt to run Lucid on TI AM3517 Zoom eval kit12:01
rcn-eeit should work as i run it on a varity of omap35x targets... just make sure you config meets these requirements http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head%3A/readme.txt12:04
nosse1rcn-ee: Have you deployed Ubuntu on any omap35x targets for production environments, or just still development?12:06
rcn-eenah, i haven't pushed my customers off karmic yet, as lucid just hit beta-1 last week..12:09
rcn-eei have two internal development beagles running it 24/7 thou, testing different things..12:09
nosse1Ush... ARM Lucid didn't work out-of the box... Well, I didn't really expect that either...13:07
ograworks here :)13:08
nosse1It boots the kernel, and head into NFS, but then it just sits there after "init: ureadahead main process (552) terminated with status 5"13:09
ograah, NFS13:09
ograthere might be mountall bugs with NFS, check launchpad13:10
nosse1Are there any good tools for debugging nfs-links? i.e. smart cmd options for tcpdump13:10
nosse1I'd like to see what specific files are being accessed13:10
ograwell, try to reach your server from the busybox shell in your initramfs etc13:10
ograthats why ubuntu uses initramfs all over the place ... makes debugging so easy :)13:11
nosse1hehe: That might just be it then. I tried without initramfs :o13:11
ograwell, depending on your kernel it should work even without initramfs13:12
ograits years ago i used rootfs on NFS so i wont be a big help13:12
nosse1Because you dont really need the initramfs if everything is build statically in the kernel, right. Theres nothing special the distro requires?13:13
ograthere is13:13
ogralost of packages place stuff inside the initramfs in ubuntu13:13
ogra*lots13:13
nosse1How do you build one then?13:14
ograupdate-initramfs -c -k <your kernel version>13:14
ograon a running system13:14
nosse1Thats assuming a running system, yes13:14
ogra(prefix that with sudo)13:15
ograif you dont have a running system, take your sd make sure to have qemu-arm-static installed and run the command in a chroot on the SD13:15
ogra(on your x86 system)13:15
* nosse1 noob, SD=?13:16
ograSd card13:17
ograoh, you probably dont use one if you use NFS :)13:17
ograjust chroot into your exported rootfs then13:17
nosse1Ah. So thats how you run instead of NFS?13:17
ograusing an SD card, yes13:20
nosse1I recon, since you compile packages natively, moving files back and forth to x86 isn't made as often as you would on a purely crossed target13:21
nosse1..so a SD card is fine13:21
ograright, i usually only use x86 for bringup and building a booting image13:22
nosse1i have to admit my other colleagues are sceptical to build the apps natively on a 500MHz ARM target13:23
ograwell, if you use ubuntu as ubuntu developer you can just develop under x86 :)13:24
ograthe packages are built automatically on all arches anyway13:24
nosse1yes, I see both advantages and disadvantages of doing it like this13:25
ograit really depends *what* kind of app you buiuld natively though13:25
nosse1I'm a little worried that vanilla ubuntu becomes too heavy for a small ARM target, yet it is nice to not have to worry about the system13:26
ograif its just a desktop app it surely is a lot easier to build it natively and have all dependencies already available13:26
ograwell, define *small*13:26
nosse1The other alternative is some kind of LFS in a cross build environment13:26
nosse1Our product will have a sys-flash of 1G13:26
ograLFS cross building might gain you incompatible binaries13:27
ogra1G flash isnt enough for any of the ubuntu desktops13:27
ogranot sure about LXDE but even if that would fit it wouldnt leave you much space for user data13:28
nosse1Yes. Package and product upgrade feats of distro like Ubuntu is very tempting13:29
ograindeed13:29
nosse1No desktop (sort of). The product will be a end-user product where the user shall not know that Ubuntu is running behind the curtain13:29
nosse1But it will be a Qt app running either on X11 or directly to fbdev13:30
nosse1Size isn't that critical (shoult fit into 1G), but startup-time into final application is far more critical.13:30
ograwell, if you only compile your app, i would go with natively ...13:30
ograwhats the desired time you have ?13:31
ograand with which bootloader ? :)13:31
nosse1Q is then how much tweeking to Ubuntu is needed to make the app start fast enough13:31
nosse1TI uses U-boot13:31
ograwhich is a fairly slow thing in itself13:32
nosse1Lets say 10-30 secs is fine13:32
ograthats half of it for uboot13:32
nosse1Uboot will be optimized in order to speed things up13:32
nosse1thats the easy part13:33
ograif you only fire up your app 15sec should beeasily doable13:33
ogramy laptop takes 8 from grub to gnome desktop atm ...13:33
nosse1Ah, but it's a laptop.. What are we talking about on your ARM targets?13:34
ograand that starts a lot more stuff, even though its x86 and 4G RAM and a fast SSD, 15sec for u-boot-end to app-on-screen will be achievable13:34
ograARM targets are depending on the disk you run your system off13:35
ogramainly13:35
ograubuntu-netbook on a babbage board takes from 35 to 45sec13:35
ogra(thats imx51 from USB key or USB attached SATA disk)13:35
ograthough imx51 loses nearly no time to the bootloader ... (6-10sec)13:36
ograredboot is a lot faster than u-boot ... but a lot less flexible13:36
nosse1BTW: Those ARM targets used in the Launchpad build farm, what kind of machine/specs are we talking about? Some of these compiles must take a while?13:37
ogra(and very painful)13:37
ograthe ARM buildds are all imx51 800MHz 512M machines13:37
nosse1Yeah, I know. I've been working with imx35 previously and thus redboot13:37
ograwith USB disks13:37
persia`lool: Regarding Development/Ports : there's a lot of TODOs left: are you sure you want to strong-link it already?15:01
persia`Also, there are N ways to set up schroots: I'm unsure I want to document all of the manual methods (and they're all painful).15:01
loolpersia`: We could hide them as comments15:01
persia`Yeah, hiding them works.15:01
loolpersia`: Well, I'd like to document how you use sbuild for arm development15:01
persia`I can document use easily.15:02
persia`For creation, I can't recommend mk-sbuild enough.15:02
loolpersia`: hidden now15:02
loolpersia`: Oh ok, I thought you tested mk-sbuild successfully?15:02
persia`Sorry: translation error.  I mean to say that not using mk-sbuild is so painful that there is no limit to the degree to which I will recommend it to any schroot/sbuild users15:03
loolpersia`: Do you consider the sbuild section good enough?15:04
persia`Basically, one has to create the (directory, tarball, LV snapshot, etc.) manually, and then stick it somewhere, and then write the configuration manually.15:04
persia`I'll add in some notes on usage with schroot and sbuild.15:04
loolpersia`: I'm not a regular sbuild user; I have it installed and now how it can overall work, albeit not the latest features thereof15:05
loolpersia`: Ok good15:05
loolpersia`: When you're done, just remove the commented-out TODO15:05
nosse1Where does rootstock stage its files?15:24
nosse1OK, sorry for my elementary questions: If I have a rootstock/qemu image either as .img or as tar.gz, how can I invoke qemu to boot from that image/root?16:02
nosse1I.e. I need a kernel and I need to make the kernel load the root from the image, I presume16:02
ogranosse1, see the rootfs from scratch wikipage (from the channel topic)16:03
nosse1ogra: embarrasing. Of course, thanks!16:05
persia`lool: Sorry that took so long.  Use of schroot/sbuild documented : please take a look to make sure it makes sense to you.16:09
loolpersia`: Looks good16:15
persia`lool: What I wonder is if we need to go to any more effort to make clear that these procedures (should) work for armel/powerpc/sparc16:15
persia`(getting a little off-topic for this channel)16:16
persia`I don't want to create the impression that one must use pbuilder for armel and sbuild for powerpc, nor the impression that this is armel only.16:16
loolpersia`: Let's hope that the people reading it are technical enough to understand that, and fix it if we discover it's a problem16:16
persia`That sounds reasonable :)16:16
loolI don't think it's off topic for this chan since we're trying to improve ports documentation as driven by the lack thereof for arm  ;-)16:17
persia`heh16:17
persia`Do you happen to know if qemu-system-ppc needs as many special arguments as qemu-system-arm ?16:17
loolpersia`: I happen not to know16:18
* persia` either16:18
persia`Oh well, there's enough fast ppc HW out there that most folks use native anyway.16:18
loolISTR seeing people run qemu-system-ppc without any -M arg, but I don't know what kernel's we're building for16:18
loolWow powerpc has a vmlinux and armel a vmlinuz, how odd16:19
nosse1ogra: Now this is interesting. Earlier this day I failed getting lucid to run on target. Kernel booted, but failed in userspace. When I now start qemu, I get the same failure16:22
ogranosse1, whats the failure ?16:32
nosse1Hold on. I hoped I could get the console output with -nographic, but it only dumps the pre-linux bootloader16:35
persia`nosse1: I often find "-monitor stdio" to be  useful argument when I'm having issues, as this lets me manipulate the session in the terminal whilst it executes in the SDL environment.16:39
nosse1ogra: From the start of init, I see the following messages 1) modprobe: Could not load ...modules.dep  2) init: ureadahead main process (381) term. with status 5   3) mountall: Could not connect to Plymouth     4) Same as 1 again16:42
ograthats all fine16:42
ogranothing to worry about16:42
nosse1Then nothing. After a while I get sda sense key errors in qemu16:43
ograthats something to worry about :)16:43
nosse1This time I'm running from ext3 file-image16:44
ograhow did you build your image ? just using rootstock --notarball ?16:44
nosse1Yup16:44
ograand then the commandline from the wiki ?16:45
ograwith the kernel from there ?16:45
nosse1Hold on, I'm getting lots of errors on e2fsck of the image16:45
nosse1yes16:45
ograi dont see that here16:46
ograwhat was the exact commandline you used with rootstock ?16:46
nosse1Hoi.. Here I got a tracedump of something in the console16:46
nosse1I used "sudo ./rootstock --imagesize 1G --seed ubuntu-minimal --dist lucid --notarball"16:46
ograah16:47
ograwell, that will fire up oem-config16:47
nosse1rootstock is the patched one to be able to use my karmic against lucid16:47
ograwhich can take a few minutes to start16:47
loolpersia`: Apparently, one needs to pass -M prep to qemu-system-ppc, and one needs a BIOS which we lack in Ubuntu; see https://bugs.launchpad.net/ubuntu/+source/openbios-sparc/+bug/18349516:47
ubot4`Launchpad bug 183495 in openbios-sparc (Ubuntu) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy (affects: 3) (dups: 1)" [Medium,Confirmed]16:47
ogranosse1, if you want to prevent oem-config just use th e-l and -p options for rootstock16:48
ogra*the -l16:48
loolpersia`: surprisingly, the two files mentionned by https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/60478 are around on my system16:48
ubot4`Launchpad bug 60478 in qemu (Debian) (and 1 other project) "Missing files for qemu-system-ppc (dup-of: 183495)" [Unknown,Fix released]16:48
ubot4`Launchpad bug 183495 in openbios-sparc (Ubuntu) "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy (affects: 3) (dups: 1)" [Medium,Confirmed]16:48
nosse1ogra, thanks I'll try. My end objective is to get a working image for me to be able to use on target.16:49
persia`lool: I have them both as well.16:49
ogranosse1, well, if you boot it on the target system, just wait a little longer, it will bring up oem-config after a while16:50
persia`lool: I know far too much about the openhackware and openbiod-sparc issues.  They aren't fixable with current Soyuz.16:50
ograto configure user, language, keymap etc16:50
ograW: u-boot-omap3 source: quilt-build-dep-but-no-series-file16:51
persia`lool: OK, so qemu-system-foo really only works for armel right now.  That makes it easy.  Thanks for checking.16:51
ograhmm, is that new ?16:51
persia`ogra: No.16:51
ograi never needed debian/patches/series before16:51
nosse1ogra, I have to admit I perhaps didn't wait long enough to determine whether the target was busy or dead.16:51
ograpersia`, well, the complaint is16:51
persia`quilt creates it automatically.16:51
persia`No, it's been around since jaunty, at least.16:51
nosse1ogra, but the output was the same on targes as on qemu16:52
ograweird, i never saw that before when building a package and picking quilt16:52
ogranosse1, on qemu it will take even longer until oem-config comes up16:52
persia`You probably never didn't have a series file before.  Like I said, quilt does it automatically.16:52
persia`ogra: I've found quilt incredibly easier to use since adding http://paste.ubuntu.com/399386/ as my ~/.quiltrc16:53
ograah, thats nearly the same cjwatson gave me16:54
persia`His was from /usr/share/doc/quit/README.source16:55
persia`Which works exactly the same, only faster for 90% of cases.16:56
nosse1The kernels you build for target, do you cross compile them or do you also do that natively?16:56
ogranosse1, see /topic :)16:57
persia`nosse1: Everything is natively compiled.16:57
ograbah, sigh ... series needs to contain a comment16:57
persia`No it doesn't.16:58
nosse1What happens if I install gcc from my qemu. Will it be capable of generating code for real target?16:58
persia`nosse1: As long as your target is compatible with the instruction set gcc is targeting, yes.16:59
ograpersia`, diff.gz wont represent empty files16:59
ograso lintian still complains16:59
ograunless i add a comment or something16:59
persia`ogra: series shouldn't be empty unless you have no patches, and if you have no patches, you shouldn't have a build-dep on quilt.16:59
ograpersia`, i want the new packages i build to reflect a selection for the patchsystem17:00
ograso people touching the package know what to use17:00
ograogra@babbage2:~/u-boot-omap3-2010.3git20100315$ lintian -i ../u-boot-omap3_2010.3git20100315-0ubuntu1_source.changes17:00
ograogra@babbage2:~/u-boot-omap3-2010.3git20100315$17:00
ograthere we go :)17:00
persia`Just use Format: 3.0 (quilt) then.  No build depenency required.  No debian/rules magic.  Expresses the preference for quilt.17:00
* ogra builds a binary17:00
ograpersia`, i wont revert what i did now :)17:01
* ogra has to get the thing done today 17:01
persia`anyway, you're supposed to express that preference in debian/README.source17:01
persia`Just ask first next time :p17:01
ograexpressing that preference in README.source doesnt quiet down lintian17:02
ograi want the package to be ready so people can just drop in diffs17:02
ograas i do with i.e. dpatch17:03
ograand given that asac perfers quilt and i get heat from people that i use dpatch everywhere i thought i should start switching to quilt17:03
ograeven though i dont like it17:03
ograin any case i want my packages to be ready for patching right away, without having to fiddle with build-deps17:04
persia`Fair enough.  Next time you do a package, make me walk you through using format 3.0(quilt) so you have it easy.17:04
ograok17:04
persia`(which never requires build-dep on quilt and still uses quilt)17:04
ograogra@babbage2:~/u-boot-omap3-2010.3git20100315$ lintian -i ../u-boot-omap3_2010.3git20100315-0ubuntu1_armel.deb17:10
ograW: u-boot-omap3: wrong-bug-number-in-closes l3:#XXXXXX17:10
ograPFFT !17:10
persia`ogra: You want (LP: #...) anyway.  This is the pain of dh_make17:13
persia`Don't forget to make it not Priority: extra too.17:14
ograi know, i just havent filed a bug yet17:14
ograerr, what prio should it have ?17:14
* ogra always leaves it extra17:14
nosse1Can I shutdown qemu/debian from the monitor gracefully? I notice the ext2 img is easily corrupted17:16
ograpersia`, what but debootstrap uses the priority field anyway ?17:16
nosse1errr  ubuntu NOT debian. Sorry.  (Don't throw any stones.)17:16
ogranosse1, we wouldnt exist without debian, why would we throw anything ? :)17:17
nosse1:D17:17
persia`ogra: Every package manager displays it17:17
ogranosse1, the karmic version used ext2 and i'm not sure you can do anything beyond "sudo halt" ... afaik the kernel wont power off the VM, you need to close it then17:18
ograpersia`, so suggest a prio :)17:18
ograits a bootloader that only exists on arm and shouldnt be used anyway unless you build images17:18
persia`ogra: "optional" is correct for nearly all new packages17:18
ograok17:18
persia`Wait.17:19
persia`"shouldn't be used anyway unless you build images"?  Is it not useful for installed devices?17:19
nosse1ogra, the login/pwd of my image doesnt work so I cannot login. And the image runs when using -snapshop. The kernel crashes without it17:19
ograpersia`, well you can use it if you roll your own beagle images17:20
ogratheoretically17:20
ograbut for ubuntu installs we'll use flash-kernel anyway to write u-boot to NAND17:21
* nosse1 trying rootstock again17:21
ograso there is no real point in actually using it for anyone (while you *can* if you want to)17:21
ograpersia`, main point of the package is to make d-i and live images using the u-boot-beagle.bin file from this package (along with the MLO file from the x-loader package thats already in the archive)17:22
persia`ogra: OK. YOu have a special package where "extra" happens to be correct.  This is very rare :)17:22
ograah17:22
ograpersia`, you have to teach me one day how to make proper dh7 packages that can do multiple runs for different configs on the same source17:23
ograeventually i want the u-boot-omap3 package to support all omap targets but that needs several builds17:24
ogra(with one binary for each target)17:25
persia`ogra: That's going to take time, and is best done with physical presence I think.  That is the sort of thing where looking over a shoulder is useful.17:25
ograi know how to do it the old way but dh7 is rather blurry to me17:26
persia`Yeah.  dh(1) is just as flexible as dh_*, but most folk get confused because of the CDBS-like features.17:27
ograyeah17:27
ograits not important now though ... rather a L+1 thing17:27
ograbeagle only is sufficient atm17:28
ograbut given the source can also build for zoom1/2 and EVM boards i'D like to sopport them one day17:29
nosse1Must qemu be run as root?17:44
nosse1According to e2fsck, the images produced by rootstock have fs-errors17:48
persia`qemu definitely doesn't need to be run as root.17:48
rcn-eenosse1, that's pretty normal, just let it clean it up...17:49
rcn-eee2fsck is usually not happy with the time variances so it checks just in case..17:50
ograor use lucids rootstock (since you build minimal images anyway)17:50
nosse1Yes, but it seems to be coinciding with crashes of apps inside qemu. I'm not sure, it just seems that way17:50
ograin lucid rootstock defaults to ext317:50
nosse1I'm getting inode count errors and such17:50
rcn-eenosse1, does it clear up on the next reboot?17:54
nosse1Sometimes I get kernel crashes, sometimes stack dumps in the console and other times I get "I/O error, dev sda"17:54
nosse1Using -snapshot seems to remedy all of these errors17:54
rcn-eesounds fun, which kernel you using?17:55
nosse1vmlinuz-2.6.31-rc3versatile1-cortex-a817:55
ogranosse1, thats definately not the one from the wiki17:56
ogra(i asked you before if you use the one from the wiki)17:57
nosse1Yes, you're right. I have no clue where this vmlinuz-2.6.31 came from. It was just lying in my dir.17:58
nosse1But using the one from the wiki, I still have the sda I/O error issue17:58
ograheh17:59
rcn-eehey ogra, just catching up on the backlog, you guys really planning to put the kernel in nand?18:00
rcn-ee(omap's)18:00
ograrcn-ee, likely, yes18:00
ograas long as kernel and initramfs actually fit18:00
rcn-eeokay.. yeah they should... but as side note, the xm might come with no nand.. (to get 1Gb ram..)18:01
ograi need to do some measuring ... my last days were busy with packaging x-loader and u-boot and starting to design the live images18:01
ografrom tomorrow on i'll start working on the flash-kernel changes we need and on the actual image builds18:02
ograwe will definately flash x-loader and u-boot with the versions from the image during install18:03
ograi'm not 100% sure about kernel and initramfs yet18:03
ogra(for now my focus is to have *something* ready by end of the week ... we'll be able to make changes to that before beta2)18:04
asacogra: use deb318:04
ograasac, ??18:04
asacerr source format 3.0 ... that comes with great quilt integration18:05
ograasac, for my next packages i will ... to late now :)18:05
asacyou dont need to know how to use it in order to work with it18:05
ograthats evil !18:05
asacogra: if you used quilt we can just convert it easily18:05
rcn-eetrue.. ;)  btw, i got my iegp2 working over the weekend.. with 500.2  it'll need about 4-5 backports from 2.6.34-rc2 for dss2/ethernet.. ;)18:05
ograright18:05
asaccool18:05
ograasac, i'm trying to use quilt by default now even though i hate it18:06
ograrcn-ee, do you know if iegp2 uses the same x-loader and u-boot ?18:06
nosse1ogra, I still get I/O error on sda using qemu and this time the kernel from the wiki ( ;) )18:06
rcn-eeit's different... ;)18:07
ogranosse1, sorry i have no idea whats going on there, does your user own the disk image ?18:07
ogra(i.e. does he have write access to it)18:07
ograrcn-ee, sad18:07
nosse1ogra, yes18:07
* ogra would love to have one generic omap image that works everywhere18:07
rcn-eeIt's using 1.4.2 x-loader, but i'm not sure if it's the same as beagle.. (it does use OneNAND Flash, so that's different..) the U-boot is 2009.08 and uses boot.ini scripts at boot. (instead of beagles boot.scr) same format thou..18:08
nosse1I'll search around18:08
ogranosse1, worst case you could grab rootstock from lucid18:09
rcn-eebut 720mhz & 512Mb ram, so it's going into my gcc farm after i get lucid booting.. ;)18:09
ograor just change ext2 to ext3 inside the rootstock script manually18:09
ograrcn-ee, hey, thats nearly as good as the babbage board :)18:09
ograyou just need SATA ;)18:10
ograok, my revC4 boots with x-loader and u-boot from the archive ...18:10
rcn-eeyeap it is.. ;)  yeap no sata, but onboard wifi and bluetooth.. ;)18:10
ogratime to call it a day ... i was up early18:10
ograwifi ++18:11
rcn-eesound cool, you have c4 usb patches right?18:11
ograi havent booted to a rootfs18:11
ograamitk would know if we have all patches18:12
rcn-eeu-boot set's up the regulator for the ehci port on the c4, that's why i asked.. i don't think they are in u-boot mainline yet...18:12
ograrcn-ee, do you know if the board initalizes the framebuffer if you dont give any omapfb options on cmdline ?18:12
ograoh, i packaged u-boot-omap3 ;)18:13
rcn-eeokay, that should work then..18:13
ogradidnt touch mainline18:13
ograsarkomans tree18:13
rcn-eei was thinking that over the weekend..  it didn't in the past... and we've always defined it on the command line...18:14
nosse1ogra, I'm using a rootstock patch which i got from asac. I needed it to be able to run qemu for a lucid target on a karmic (64-bit) machine18:14
rcn-eeso i would say no...18:14
ogracrap18:14
rcn-eethere is a read edid script in angstrom.......18:15
ograthats really messy behavior ... it should jut read EDID18:15
ograyeah, that was dropped years ago from ubuntu18:15
ogradoesnt help me if i need the value on cmdline18:15
ograthe driver should just check the monitors capabilities and set the highest resolution by default18:16
rcn-eethe other issue, the omapfb comand also allocates kernel memory too for the frame buffer...18:16
ograi wonder why that seems to be so hard18:16
rcn-eeWell, there is a big limitation on the screen size... (hardware pixel clock)18:16
ograthat should also have a default value18:16
asaci think starting with fbfev isnt good to add EDID - but have not looked closely18:17
ograwell, but you know your pixel clock capability18:17
rcn-eethat's one reason i always recommend the 720p value, it's the most compaitable and biggest..18:17
ograso you can fall back to something hardcoded18:17
ograits just evil to have to define *defaults* on the cmdline18:17
ograat least these should be there automatically18:17
ograi find it ok to *override* on cmdline18:17
ograbut making it a requirement is just bad habit18:18
rcn-eepixel clock limitation is here; http://elinux.org/BeagleBoardFAQ#Display_resolutions_.23218:18
asacogra: do we have graphics drivers for beagle already?18:18
ograasac, from debian, yes18:18
asacogra: is that in archive and just works?18:19
rcn-eeit's a sudo neon optimzed framebuffer driver...18:19
ograasac, havent tried yet18:19
rcn-eethe guys at allwaysinnovating also did their own varient of that too..18:19
ograbut yes, there is omapfb and omapfb with NEON18:19
ograwe have two to pick from, not sure how good they are18:20
ograi'll test that once we have a working image18:20
rcn-eeuse the neon one...18:20
ograone step at a time :)18:20
asacogra: i guess we have neon in cpuinfo?18:20
ograif thats stable i will :)18:20
asacshouldnt we just install both and it will pick the right one?18:20
ograasac, at least with the pre-built kernel amitk gave me18:20
rcn-eeit's been the default in angstrom for a good year and half.. ;)18:20
asacsounds promissing. nice18:20
ograrcn-ee, angstrom uses different toolchain18:21
ograso i wont say hooray until i tested it ;)18:21
rcn-eeyeap, 4.3.3 vs 4.4.x..18:21
ograbut yes, promising for sure18:21
* ogra wonders if 500.2 finally made it to the archive18:22
asacogra: does JamieBennett has a usable environment alöready? maybe he can check that?18:22
ograasac, he should have everything he needs18:22
asacogra: whats the status on imx kernel in -proposed ?18:22
asac:-P18:22
ograno idea, was it uploaded already ?18:22
* ogra didnt get any pings yet /me thinks18:22
rcn-eewhich reminds me.. did amit put the vfp patches you used for imx in omap's branch?  it needs it to..18:23
JamieBennettasac, ogra, ping me in the morning if you want me to check something, about to leave the house in 10 minutes18:23
ograno idea, that kernel is fully his work, i only saw two binaries yet18:23
ograJamieBennett, just bring up your board tomorrow so you can test stuff18:24
asacJamieBennett: ok. would like to have the omap x drivers checked ...18:24
asacJamieBennett: 1. do both (neon + non neon) work18:24
rcn-eeokay, well it's no in mainline yet either, so it would be easy to spot in the log..18:24
JamieBennettogra: will do, first thing I'll do in the morning18:24
asac2. is the right driver automatically selected if we install both18:24
ograasac, given the kernel is stable enough to even try :)18:24
asacogra: thought we are already there?18:24
rcn-eeno, it won't... i had a user with that problem on karmic..18:25
ografor me 500.2 has multiple issues18:25
asachmm18:25
ograasac, its there but buggy18:25
ograusb didnt work18:25
ograwhich is somewhat essential on a beagle :)18:25
asacdid we backport their patches or just took the right upstream branch for .32?18:25
ograext4 wipes the FS18:25
ograi think its plain mainline .3318:25
rcn-eeasac, just a config issue on the usb..18:25
ograi see the modules loaded18:26
ograit oopsed when i unloaded18:26
asacrcn-ee: cool. can you give ogra or kernel team pointers?18:26
ograthough i didnt put much time into it yet, booting and image rolling is my current main concern18:26
ograonce thats ready we can fiddle with the rest18:27
asacogra: right focus on that. jamie and rcn-ee can probably help if you spit out first iamges ;)18:27
ograespecially *everyone* can as soon as we have daily builds :)18:27
rcn-eeyeap, that's my goal.. ;) my staging area is here: https://code.launchpad.net/~beagleboard-kernel/+junk/lucid-ti-omap  and i got a good number of random omap boards.. ;)18:27
ograi want to extend our user base first :)18:27
asacrcn-ee: can you reproduce the issues ogra mentioned?18:28
ograanyway, i'm really done now ...18:28
asacogra: see you tomorrow18:28
* ogra calls it beer o clock for real now18:28
rcn-eebut we don't have enough boards yet for new users.. ;)18:28
rcn-eetake it easy ogra.. ;)18:28
ograrcn-ee, revC18:28
ograthere are lots and lots of users :)18:28
rcn-eeasac, i forgot, what issue? ;)18:28
asacrcn-ee: he said his beagleboard is unstable with current kernel in lucid18:29
ograUSB and ext4 are the things i spotted yet18:29
rcn-eeThat's strange.. although i have ran 500.2 more then 5 minutes.. (boot [x], things work [x])18:29
ograunloading the twl driver makes it oops18:29
rcn-eebut mailine 2.6.33 is stable for me..18:29
asacrcn-ee: are you using lucid packages etc.?18:30
ograthey are here if you look for them http://people.canonical.com/~amitk/ti/18:30
rcn-eeyeap...  one beagle it's all chroots, another beagle it's different partitions with each dist18:30
rcn-eethanks ogra, will test those...18:30
ograi think at least ...18:31
ograi hust noticed they still say 500.118:31
asacthats 500.118:31
asacack18:31
asacwhere is 500.218:31
asac?18:31
asacin archive?18:31
ograi think that *is* 500.2 just wrongly versioned18:31
ogra500.2 was FTBFS this morning18:31
rcn-eei know amit was testing scripts...18:31
rcn-eeasac, i know usb can be solved with: https://lists.ubuntu.com/archives/kernel-team/2010-March/009484.html  but the question is why desn't the twl stuff like being moderlized...18:33
rcn-eeit could be timing with specially since CONFIG_TWL4030_USB sets the power regulator on the musb...18:34
nosse1Are there any real speed or size differences between ARMv7 and earlier?18:34
rcn-eenosse1, think 486/686/etc.. ;)18:35
nosse1heh18:35
nosse1good answer ;)18:35
rcn-eeit just gets more complicated since there are alot of x's.. x86...18:36
nosse1theres an opinion here claiming that the 'x' of the distro doesnt really matter. The important stuff is the end-user app18:37
nosse1so out of curiosity I was wondering if there had been any real (linux) benchmarking to it18:38
rcn-eenosse1, take a look at these, sheevaplug is armv5 and debian squeeze is built for armv4 http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-3173-25135-2276618:38
nosse1rcn-ee, thanks18:41
rcn-eeno problem, it was a fun comparsion test, i'm planning to redo it again, and add a iegp2 for comparsion, it has the same clock speed as the c4, but double the ram..18:42
comradekinguI sent a mail to phoronix asking for them to test various arm distros and settings18:47
comradekinguseeing they already have..18:48
rcn-eeoh they haven't yet... ;)18:48
rcn-eeI've talked with a couple of them at phoronix, they do have access to some arm boards..18:49
comradekinguI asked about the latest developer boards, so i guess my question is still valid18:50
rcn-eeyeap it is..  if you search for arm under their search_results, there is another anonymous user running tests other then me...18:51
comradekinguWith the barrage of ARM cellphones being released and the ever increasing software stack on there is think they should allot more time for it18:52
rcn-eeyeap..  but you get these funny comparisions.. http://global.phoronix-test-suite.com/?k=profile&u=linuxeasecom-14106-16996-652218:52
rcn-ee(the lame and ogg) results are invalid on that one.. i should bug phronix, they are missing a dependicy..18:54
nosse1Don't you think that there's a lot LFS out there for embedded targets such as ARM phones?18:58
comradekinguExactly18:59
nosse1I mean in our product, it is quite new to endorse a distro. I'm living in the LFS/busybox compile-all-in-a-large-image kind of thing18:59
nosse1I'm still not 100% convinced to deploy ubuntu into our product18:59
nosse1Hopefully my playing around with ubuntu can change that. I'm certainly happy with Ub. on hosts19:01
comradekinguEven nokia isnt alone in the mobile linuxworld anymore19:02
comradekinguOnly palm is i think19:03
nosse1Since ubuntu is built natively, this implies that you build your own toolchains as well (don't use the popular CodeSourcery, or do you)?19:05
nosse1All right, I think I finally got the qemu thing going. Tomorrow I will try it on real target.19:58
nosse1If it still doesnt work, what is my approach for figuring it out? I know it started init, but I didn't get a login prompt19:59
nosse1For all you guys helping me out: I hope I haven't annoyed too much. Thanks a lot for you help!20:04
jim_reesHow hard would it be to get ubuntu running on this? http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=17041480428920:20
=== bjf is now known as bjf-afk

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!