=== fta_ is now known as fta
=== fta_ is now known as fta
=== fta_ is now known as fta
=== fta_ is now known as fta
=== fta_ is now known as fta
=== fta_ is now known as fta
=== fta_ is now known as fta
=== bjf is now known as bjf[afk]
=== fta_ is now known as fta
ukleinekzumbi: the story is over, Linus pulled :-)07:45
=== fta_ is now known as fta
=== hrw|gone is now known as hrw
ogracooloney, urgh, please ship vmlinuz in the linux packages08:31
ograwe use flash-kernel on all arm platforms to do special stuff to the binaries (i.e. running mkimage to create uImage)08:32
ograi dont want to special case flash-kernel for certain platforms08:32
ogracooloney, we need to create uInitrd anyway on each update-initramfs trigger so it makes no sense to ship uImage in the package (and we had that discussion before several times)08:33
* cooloney nods to ogra 08:35
cooloneyogra: great, understand.08:35
=== amitk-afk is now known as amitk
lagmythripk: Hi09:13
fjrivashHello, I created a rootfs using this command sudo rootstock --fqdn qemu-test --login qemu --password qemu -d karmic --notarball, I compiled a kernel in the standard way (make, make modules, make zImage) and try this command sudo qemu-system-arm -M versatipb -cpu arm11mpcore -kernel ./zImage -hda qemu-armel-201007121813.img -m 256 -append "root=/dev/sda rootwait", but I got just a black screen.09:26
fjrivashthanks in advanced for any comment about this.09:26
fjrivashother thing is : is this the right way to cross compile my kernel ? make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-09:27
fjrivashthanks again in advanced09:27
ograif you got a binary thats likely the right way :)09:27
ograi would suspect you are missing some console settings09:27
lagfjrivash: Which board are you using?09:28
fjrivashogra, I got it after make zImage09:28
ogratry with -nographic09:28
ogra(on the qemu cmdline)09:28
ograthat should at least show some kernel messages09:28
fjrivashlag, a CNS3410 (it is an arm11mpcore which is compatible with armv6kz)09:29
fjrivashogra, thanks I will try it right now09:29
ogra(note that you cant ctrl-c qemu then, you need to close the terminal to stop it)09:30
ograor kill it from another term09:30
fjrivashjejejeje I see! it was so funny, I thought that was something else bad09:30
lagWell done ogra09:31
fjrivashogra, I got nothing :S. it think it must be the kernel09:31
lagI take it back ;)09:31
lagDoes qemu not have pre-boot messages09:32
lagSimilar to a bootloader?09:33
fjrivashactually yesterday I built a new image using karmic. lag AFAIK you must install a bootloader if you want to use it to load a kernel image09:33
lagDo you need one?09:33
lagOr will qemu be the bootloader too?09:34
fjrivashwell to be honest I trying to avoid that. but it seems that I need one, for example u-boot09:34
lagAsk ogra09:35
lagogra: Do you need a bootloader when you use qemu?09:35
fjrivashlag thank you very much. :D09:35
ogralag, nope09:35
lagI might install it and have a play09:35
sebjanogra: coming back to uImage creation - how to make update-initramfs generate the uImage? Is there a script to update in the kernel package or somewhere else?09:36
ogralag, i think you *can* use a bootloader ... i think lool does that in his qemu-maemo experiments, but specifying the kernel should be enough to get a booting system09:36
ograsebjan, flash-kernel does it09:36
ograsebjan, have a look at update-initramfs and the flash-kernel source09:36
ograsebjan, since my last update to flash-kernel that should happen automatically on ubuntu images09:37
ografor omap3 and 4 at least09:37
sebjanogra: it does not for our omap4 kernel packages at least, this is why I came up with this dirty hack :)09:38
fjrivashogra, lag thank you very much I will recompile the kernel because I think that is the problem, I will let you know09:38
ograsebjan, flash-kernel requires /etc/flash-kernel.conf on omap4 (thats created during first boot of the image)09:39
lagfjrivash: Where did you get qemu-system-arm from?09:40
fjrivashfrom repositories09:40
ograsebjan, and you need at least flash-kernel 2.28ubuntu2 for panda support09:40
fjrivashactually I did a qemu-system-arm --cpu ? and there is an arm11mpcore support-09:40
ograsebjan, and also a /boot/boot.script file as input for the used boot.scr09:41
lagIt's not in my repository09:41
ogralag, qemu-kvm-extras09:41
lagogra: Thanks09:42
ograrootstock pulls it in automatically09:42
ogratogether with qemu-arm-static09:42
ografor arm chroot handling09:42
fjrivashthat is right09:42
sebjanogra: ok, I was far from it :) thanks! Could you please send me an example flash-kernel.conf file?09:42
ograsebjan, UBOOT_PART=/dev/mmcblk0p109:43
ograsebjan, thats all :)09:43
ograsebjan, flash-kernel only needs to know where the bootloader partition is (and you need the /boot/boot.script as input)09:44
* ogra takes a break09:46
sebjanogra: thanks!09:46
fjrivashin which cases do I have to use a ramdisk?09:46
fjrivashI mean I have read that you can specify a initrd in qemu command but I am not pretty sure if I need it.09:47
fjrivash(figuring out)09:48
=== XorA|gone is now known as XorA
laglool: Ping10:04
lagfjrivash: Did you build the kernel yourself?10:06
lagfjrivash: Do this from the root of your kernel tree: "find . | grep vmlinuz"10:07
fjrivashthere is no vmlinuz, there is a zImage which is in a boot directory, I am compiling the kernel (again)10:08
fjrivashthe first time I got a zImage of 40mb10:08
lagYou must have debugging symbols turned on10:08
lagAnd all your drivers built into the kernel10:09
lagfjrivash: Use this: http://www.aurel32.net/info/debian_arm_qemu.php10:10
lagAnd slowly supplement its components for your own10:10
lagI've just tried one of my kernels, but it doesn't support omap out of the box10:10
fjrivashmm I see. let me check that url.10:11
lagmythripk: ping10:11
mythripkyes lag10:19
lagGood morning10:19
lagOr afternoon where you are10:19
lagHow are you/10:19
fjrivashI found this one http://wiki.debian.org/ArmEabiHowto which is based on that one lag but with new kernel images.10:20
mythripklag : ya good afternoon, fine  thank you , did you see the mail i sent on the code sequence for sysfs and bootargs10:20
lagfjrivash: Good. Use that and slowly supplement its components for your own10:21
lagmythripk: I did10:21
lagmythripk: I am seeing some odd behaviour10:21
mythripkie ?10:21
fjrivashlag thank you very much I am working on it right now, I will let you know.10:21
loollag: pong10:22
lagmythripk: When the monitor goes to sleep after a time - when it wakes up, the setting have gone back to fuzzy10:22
mythripklag: even with the sysfs u mean10:22
lagmythripk: So: Boot up -> Fuzzy | Use sysfs -> Good | Sleep-Wakeup -> Fuzzy10:23
lagThe board is still awake10:23
lagIt's just the monitor which is put to sleep10:23
mythripklag: with fuzzy you mean the out of range10:23
mythripklag: how do you get the display out of sleep , if you set fb black it would not go to sleep10:24
mythripklag: Ping ping echo "0" > /sys/class/graphics/fb0/blank this command would not suspend the TV .10:27
lagmythripk: I get the display out of sleep by pressing the keyboard10:30
lagmythripk: Yes, I mean 'out of range'10:30
lagWhy would I want to do that command?10:30
mythripklag: even with the out of range block  appearing at the centre , you can still see the commands ?10:31
mythripklag: That command will not blank the TV , ie the TV will not go to sleep10:31
mythripkhave you tried a different HDMI cable ?10:31
lagI didn't use that command10:31
lagThat cable works fine on my Beagle10:31
mythripkyou could use that command in case you dont want the TV to sleep10:32
lagWe have to put our displays to sleep10:32
lagWe are an Operating System10:32
lagWell a distribution10:33
mythripkthat is fine , you need not , that was just in case it was not expected.10:33
lagThat is not the problem10:33
lagThe problem is that it does it and it's not meant to10:34
lagSo needs fixing somehow10:34
lagThat is not the only odd behaviour10:34
lagWhen you told me to boot with less arguments, it worked perfectly on start-up (with the cmdline args)10:35
lagBut on a subsistent boot it was 'out of range' again10:35
lagWith the same settings10:35
mythripkone reason from your log i have seen is that there are too many bootargs and thus hdmimode is not effective , thus it is going to a wrong non desired setting10:36
lagBut I have reduced the number of bootargs10:37
lagAnd the behaviour is the same10:37
mythripkand now the timing is correctly set? can you pastebin the log since bootargs10:37
mythripkbecause i dont see this behaviour on viewsonic or samsung TV that i have10:38
lagThey are not correctly set10:43
lagIt was, once10:43
lagBut on subsequent reboots they reverted to incorrect10:44
mythripkok , I have an RFC for autoboot of HDMI , i will be posting on OMAPPEDIA , that would atleast remove your bootargs problem10:46
lagCan I follow that?10:47
mythripkyes , Please10:47
mythripklag:I will be putting it on http://omappedia.org/wiki/Display_Drivers_Domain_Wiki10:49
mythripkonce i'm done with sanity testing10:49
loollag: Hey you pinged me, I ponged, but then I didn't hear anything anymore?  :)10:50
=== amitk is now known as amitk-afk
mythripklag: But one confirmation , it is only in your LG make TV you are seeing this issue right , not in any other monitors10:55
laglool: Everything came alive at the same time - can you give me a minute please?10:59
lagmythripk: I don't have any other monitors to test10:59
lagmythripk: If you want to send me other monitors to test, I'd be more than happy to10:59
laglool: Do you use qemu to boot omap images?11:00
loollag: I do11:13
loollag: They need a bootloader on the images, and that apparently doesn't work with current Ubuntu images, but it should in theory work11:14
loollag: https://launchpad.net/~lool/+archive/ports-dev/+packages has maverick packages of qemu-maemo11:14
laglool: Okay, that explains a lot11:14
loollag: something like qemu-maemo-system-arm -M beagle -m 256 -sd ubuntu.img -serial stdio11:14
loolThat works more or less with Angstrom ATM, it boots well into the kernel, but then I get some divide by zero in the kernel which I didn't lookinto11:15
ogralool, hmm, we had that with the omap kernels too11:15
ogra(division by zero errors)11:15
lagYes we did11:15
ograsmells like a kernel prob, not like qemu11:15
lagI can't remember what the cause was though?11:15
* ogra neither11:16
ograbut i remember some oopses that had such an error in front of them11:16
lagI think I had them when I tried to boot the XM with Lucid11:16
loolI tried an older Angstrom kernel, I'd be surprized if it had divide by zero errors11:17
* ogra thinks he saw them together with the ureadahead OOMs too11:17
loolFirst thing with Ubuntu images would be understanding why it doesn't work in qemu-maemo11:17
lagOgra likes to blame everything on the kernel11:17
lagIt's an easy scapegoat11:17
ograindeed :)11:17
loologra: Let's just blame everything straight to lag then?11:17
ogralool, can only be the bootloader/x-loader11:18
loologra: it could be the partition layout11:18
* lag == scapegoat No111:18
ogralool, else you would at least see u-boot messages11:18
ogralool, we use the angstrom script to create our bootloader partition11:18
markos_lool: fwiw, I've officially sent a request to rejoining Debian, I intend to work on the armelhf -or whatever it's called- in a much more official -or semi-official- way now11:18
markos_no idea how long it takes, but it won't take as long as a full NM application11:18
loolmarkos_: did you follow linaro-dev discussions?11:19
markos_(this after reading most mails on linary and debian-arm lists)11:19
loolAbout NOT doing a new port   :-)11:19
ogralool, well, the OE script which angstrom uses as well :)11:19
loolmarkos_: I find the discussion very interesting, but I find it a hard sell for the bunch of people interested in working on the port11:19
markos_still reading, haven't finished yet :)11:19
loolmarkos_: I've personally written to zumbi to tell him I would like to semi-officially work on that port11:19
loolas in, with my Debian hat on and on a best effort basis11:20
loolbut I expect to help as much as I can11:20
ogralinaro goes debian ? :)11:20
loolSure, we're not tightened to Ubuntu11:21
loolwe're helping all distros out there if we can and know how to11:21
* ogra was joking, i know that11:21
loolBut we're also splitting our time wisely   ;-)11:21
markos_there is nothing to prevents us (Genesi) from working on an unofficial  hardfp port just as we are now, with no new port name, because on our cpu (a8), there is a lot to gain and it can give us a competitive advantage -and of course to others that choose to use our repository11:22
markos_at the very least we can provide testing and patches for packages that fail to build for hardfp11:23
markos_I'd really hope for a new port though11:23
markos_it would make things easier -and- provide a new optimized port for newer cpus11:23
markos_with no new port -regardless of the toolchain changes- it's guaranteed that performance will always be sub-optimal11:24
markos_other arches don't have such a big problem11:24
* zumbi confirms lool's wanting to help on Debian port11:25
markos_eg. on ppc, the abi is the same always, if someone wants more performance they can always install a -altivec version of the package -if available of course11:25
ogramarkos_, depends ... look at ubuntu, we still call what we have "armel" even though its totally not what you get in debian11:25
mythripklag: I shall send the link to the RFC to solve your bootargs problem , it would do an autodetect , but for your out of range problem i have contacted the hardware and power management folks i shall get back once i get a reply , as it doesnt appear to be a HDMI s/w issue.11:26
ograwe could as well just default to hardfp11:26
zumbiogra: debian is upstream, linaro, ubuntu, mint, .. all of them will fork11:26
ograsince we dont support any of the old CPUs anymore11:26
ograzumbi, indeed and its surely the better move to have what we have in ubuntu in our upstream already11:26
ograwill save us a lot of work11:27
ograi'm just pointing out that armel != armel if you look at it today11:27
lagmythripk: Thanks, I'll look forward to it11:27
ograand to be honest i'm not really lookinf forward to all the script changes we have to do based on a name change11:27
markos_ogra: yes, that's exactly what I did as well, if I waited for toolchain fixes, I still wouldn't be able to test a single package :)11:28
hrw12:19 < ogra> lool, well, the OE script which angstrom uses as well :)11:29
hrwogra: thats Ångström script which is stored in OE repository11:29
ograhrw, heh, well, whatever way you want it around, our boot partition is created the same way :)11:30
lagsebjan: ping11:30
ograso it cant be poartitioning imho11:30
zumbiogra: so do you suggest 3 different "armel" flavours: debian, ubuntu and genesi's11:30
markos_zumbi: if ubuntu decides to go hardfp themselves, there would be need for only 211:31
ograzumbi, no, the opposite11:31
zumbiogra, ok, i misunderstood :)11:31
ograzumbi, if hardfp shows up in debian (and also uses our current defaults v7 etc) it would be the logical choice for me to switch ubuntu over11:31
ograzumbi, i'm just fearing all the script changes for scripts that look at $arch+$subarch we currently use in ubuntu11:32
loolmarkos_: The point Mark is making is that they are other ways to rip (most?) of the benefit of hardfp, a new port adds permanent fragmentation though11:32
zumbiogra: but ubuntu will keep maintaining two different armel ports? or just one?11:32
ograzumbi, preferably just one optiomized for cortex-a8 and bigger11:33
loolmarkos_: Costs such as doing the validation twice, or costs such as for ISVs trying to provide binaries are quite high11:33
ograzumbi, thats what our current armel already is11:33
loolmarkos_: Consider that we don't have a flash plugin for 64-bits after all this time11:33
ograzumbi, for me it would just be a name change plus a different fpu11:33
markos_lool: I don't see that as necessarily a bad thing, why should a router developer care for neon optimizations or vfp stuff that a desktop distro developer would insist upon?11:33
loolmarkos_: flash might just land on arm soon, and now we will require two versions?11:33
markos_and vice versa11:33
loolmarkos_: Fragmentation11:34
loolmarkos_: You might release an android phone build on vfp or non-vfp hardware11:34
loolsuddenly, you have to use a different stack11:34
looland people have to provide different native builds11:34
markos_lool: by the time it arrives, lightspark might work on arm already and even surpass official flash11:34
markos_important as it is, flash is not the driving force behind a distro11:34
loolmarkos_: Eh it was just an example obviously11:35
markos_lool: I'm not aware of any important non-free software that would act as a show-stopper, apart from flash11:35
hrwlool: many android/winmo phones with armv6 cpu do not have vfp11:36
zumbilool: how much is codesourcery, ARM and linaro to make those compiler changes? -- are they worth it?11:36
ogralool, what ? you are not working on fixing a 64bit flash ?11:36
loolmarkos_: Even for Debian, it means new buildd network, new images to validate, packages to change, the work will eventually be distributed on a bunch of DDs, but the sum of it is HUGE11:36
loolhrw: precisely, thanks for mentionning it11:36
loolmarkos_: Consider the market place use case11:36
loolmarkos_: I ship an OS, and ISVs can offer apps for it11:36
hrwlool: qualcomm msm armv6 cpus to be exact11:36
XorAhrw: the msm72XX CPUs tend to lack VFP11:37
markos_also, android is totally irrelevant to ubuntu/debian, they already have totally separate binaries11:37
loolmarkos_: Suddenly, this OS might come in two incompatible flavors and ISVs have to provide builds for the two flavors and test the two11:37
markos_and totally incompatible11:37
ogramarkos_, its not ... there are hacks that make android work in ubuntu11:37
ogranot officially in the archive but you can use them11:37
markos_exactly that, hacks, it even has a different libc11:37
loolThese are just example11:38
loolI could have said MeeGo and made the same point11:38
markos_I understand your point11:38
markos_but in my experience, users will very rarely pick a package from another distro -eg. a meego user from an ubuntu netbook for example and try to make it work11:39
ograthere might be a meego ubuntu image at some point, who knows11:39
loolmarkos_: It's not about other distros, it's about ISVs11:39
markos_so compatibility is not really important here, Adobe for example, will most likely have a single instance of most important distros and build on each one separately -I  don't know if that's the case, but I imagine it's a logical scenario11:39
loolmarkos_: In Android, Maemo, MeeGo, Ubuntu, you get to add packages and software from ISVs11:40
ograand these users would surely want to be able to use all of the ubuntu archive on their systems11:40
loolmarkos_: heck, that's even true for Ubuntu, vmware provides binary .debs11:40
loolOr Adobe Acrobat Reader11:40
loolor many others11:40
ograor flash :)11:40
lool(that was covered already)11:40
markos_yes I totally understand your point11:40
* ogra was referring to adobes flash package :)11:40
loolmarkos_: Once you create the port, and you have a somewhat popular userbase11:40
loolDebian derivatives will appear (probably including Ubuntu I'd guess)11:41
looland products will ship based on it11:41
looland the ARM world will be fragmented a bit more11:41
loolSo I'm /very/ split on this point11:41
markos_my point is, if Adobe would provide the same package with just rebuilding it on the same hardware -and no other extra development- why should they not do that,11:41
loolmarkos_: they need to port it, validate it twice etc.11:41
markos_lool: ARM is way beyond unification :)11:41
=== fta_ is now known as fta
loolmarkos_: You think adobe flash would work without any tweaks on hradfloat calling conventions?  I bet not11:42
ograthe opposite is the case thanks to linaro11:42
markos_lool: it's the most fragmented architecture out there :11:42
loolI bet upcoming ones have NEON opts and stuff11:42
markos_lool: neon works just fine on hardfp11:42
loolmarkos_: And fragmentation is the main issue, and initiatives like Linaro fight fragmentation towards consolidation11:42
loolmarkos_: My point is, there is manual assembly in flash player, so they will have to adapt11:42
markos_if done using pure asm, maybe, if done using C intrinsics, they most definitely not11:43
loolmarkos_: I think it's a large body of code with assembly, and has good chances of hitting the issue11:44
loolmarkos_: In any case, I think the main problem is that the alternate plans being discussed are far away11:45
loolmarkos_: Both because they need long developments and because they need a certain class of people (experienced toolchain devs)11:45
loolmarkos_: So I currently suspect the port will happen by virtue of being atteinable now11:46
ograwe could switch M+1 to hardfp in ubuntu and act as a testbed for debian11:46
ogradebian would just have to take our armel defaults then11:46
ograand we would rename to armelfp in M+211:47
ograwithout having to do more changes than renaming11:48
markos_ogra: I could act as a testbed for Ubuntu myself, I could rebuild Maverick for example for hardfp and provide testing/patches11:48
markos_my goal ofc would be to have a hardfp maverick build11:49
loologra: "switch"11:49
ograwell, we wont do a hardfp build in maverick but test results would surely be appreciated11:49
loologra: you dont switch11:50
loolit's binary incompatible11:50
ogralool, its a full rebuild, i'm aware of that11:50
loolyou can introduce a new port, deprecate armel, and them move to the hard-float one11:50
loologra: No, it's incompatible11:50
loolit's a new bootstrap11:50
loologra: You can't "upgrade" to it11:50
ograoh, indeed11:50
loologra: I think you need to read the debian-arm@ discussion11:51
ogralool, i do11:51
ogranot extensively but i have read some of the thread11:51
ogralool, indeed we would have to make a cut, but we will become the best optimized v7 distro in the end so i dont think its a bad thing11:52
ogralool, what i wont do is maintain two arm arches11:53
loologra: See that's the main issue11:53
loologra: You dont want to maintain two arm arches11:53
loolNobody wants11:53
loolwell Debian is ready to start that11:53
ogradebian does already, no ?11:53
ograthey would get a third11:53
zumbidebian is discussing it! not ready for anything, just Genesi is ready11:54
loolbut in practice, ARM Cortex-A class CPUs with VFP are the high-end ones, and many devices will ship with A-class CPUs without VFP, including phones and netbooks11:54
ograir is the arm oabi port completely gone ?11:54
loologra: Debian only has an armel port right now11:54
ograah, i thought arm was still existing11:54
loolThat said, Ubuntu already excludes non-VFP hardware11:54
ografor us its not such a big step apart from upgradeability11:55
sebjanlag: pong11:55
=== amitk-afk is now known as amitk
markos_lool: anything new reg. soyuz release as standalone?12:09
loolmarkos_: I'm not tracking that personally, ping salgado on #linaro12:10
lool.br time12:10
lagsebjan: Good morning12:14
lagAfternoon even - doesn't time fly?12:14
sebjanlag: yes indeed :)12:14
lagsebjan: Do you have any documentation you can send me for OMAP3 and OMAP4?12:15
lagsebjan: A developer's manual or such12:15
lagsebjan: Containing memory maps, register addresses and definitions etc12:16
sebjanlag: the technical data manual for omap3 shall be available publicly...12:17
sebjanlag: it is not out yet for omap412:18
sebjanlag: regarding the beagle, there seem to be good links here: http://elinux.org/BeagleBoard#Manuals_and_resources12:21
lagBut nothing for the XM?12:22
lagOr Panda?12:22
lagThe two boards I own :D12:22
markos_lool: does gcc-linaro include hardfp patches from CS? I'm pulling the 4.4 branch now to test12:23
sebjanlag: I have never looked for the XM, if it exists, it shall be reference on the wiki? For panda, it will come when it is release ;) We shall have omap4 data manual soon I hope.12:24
lagsebjan: Perhaps I need to be a little more specific12:30
lagsebjan: Do you have the developers reference for the OMAP363012:30
sebjanlag: you shall ask this on the #linux-omap channel, they shall be able to provide you clear answers regarding public documentation and where to get it12:32
ograshould be on ompazoom.org12:33
lagThanks sebjan12:33
ogra(if it exists)12:33
loolmarkos_: Yes12:33
ograthough there is likely no XM docs yet since XM isnt sold yet12:33
loolmarkos_: We're rolling a test tarball if that makes testing easier for you12:33
=== fta_ is now known as fta
mythripklag: others:   http://omappedia.org/wiki/RFCs  please have a look at it and provide comments if you have any , it is for the Autodetect feature for HDMI13:17
ogramythripk, could it be a higher default than 640x480 or would that break on to many screens ?13:21
ogra(800x600 would be a bit better for X driven distros)13:21
lagmythripk: That system for RFC is weird13:23
ogramythripk, what also would be cool would be if custom_edid_timing could seed the available framebuffer modes (and xrandr)13:23
ogralag, you mean using powerpoint ... ? :)13:23
lagogra: My Maverick install falls into a initramfs shell13:26
ogradid you fiddle with boot.scr ?13:26
ogramanually i mean13:27
ograaha :P13:27
lagIt's the only way I can see the screen at all13:27
ogramust be the kernels fault then *g*13:27
ogradid you update the system recently ?13:27
ograflash-kernel changed a bit and expects a clear text /boot/boot.script file as input now13:28
ogra(which jasper now creates by default)13:28
lagIt's the current build from last week13:28
mythripkogra:  it would break many screens and the only compliant resolution is 640 48013:29
ograwell, if you didnt upgrade and your root=UUID line in boot.scr is still correct i dont see how you could end up in a busybox13:29
ogramythripk, ok, no choice then i guess13:29
mythripkbut it would read EDID , and set it to the timing supported by TV13:30
ogralag, show me your boot.scr :)13:30
ogramythripk, right, i only think about the fallback default13:30
mythripkso only reason why it would set 640 480 would be if EDID is not read correctly13:30
mythripkogra,lag  , so does the design look ok ?13:31
ograyes, looks ok to me, did you look how the kms drivers do it btw ?13:31
ograi guess there is a lot overlap13:31
ograkernel mode setting13:31
ograit is what all distros use nowadays13:31
ograi'm pretty sure there is code that reads EDID in all of them13:32
mythripkogra , i shall have a look13:32
ograeventually we would like to have KMS working on omap413:33
* ogra thinks robclark knows some background here 13:33
ograas i'm not a graphics guy and only scratch the surface of such technology13:34
robclarkgm mythripk, gm ogra13:34
ograheya, morning13:34
mythripkgm rob, the discussion is on the redesing of HDMI edid for auto detect13:34
* lag feels left out of robclark's gms13:34
ograrobclark, i was just wondering if there isnt possible overlap with KMS stuff that could be used13:34
robclarkgm lag13:34
robclarkprobably is13:35
lagmg robclark :)13:35
* lag is happy now13:35
sumitsemwalgm robclark, ogra :)13:35
ograheh, gm sumitsemwal13:35
sumitsemwalgm amitk13:36
robclarkI suspect the gfx team will need some API for 3rd party display driver for KMS..   but I've not looked at their xf86-video driver yet..   so not sure the details of how it will work..13:36
robclark(that is on my todo list for the week)13:36
ograrobclark, no hurry, but its probably easier to steal there than reinventing the wheel :)13:37
=== Termana_ is now known as Termana
* robclark needs coffee13:37
=== sumitsemwal is now known as sumits
=== dyfet is now known as dyfet_away
robclarkmythripk: fwiw, I think we need somehow some callback when monitor is detected...13:41
robclarkI'm not sure if that would be exposed to userspace thru omapfb, or thru gfx driver..13:41
robclarkbut somehow xserver needs to find out when you, for example, plugin 2nd monitor13:41
amitkhey sumits! :)13:42
amitkhow are you doing?13:42
sumitsamitk: doing good! and you?13:43
amitksumits: I'm good. Good to see you on here :)13:43
sumitsamitk: been here, mostly silently though.13:46
amitksumits: I hope you've 'met' lag, mpoirier and cooloney who're spearheading the omap enablement efforts on the Ubuntu-side13:47
=== fta_ is now known as fta
sumitsamitk: have met lag, [i think have met cooloney and mpoirier at UDS?]13:48
sumitsgm cooloney, mpoirier13:48
markos_lool: the subarch/capabilities concept might be the right solution14:37
loolmarkos_: Not here, no14:37
loolIt's an incompatible ABI, and that needs a new port14:37
markos_here = ubuntu?14:37
loolwell unless we go for Mark's proposal14:37
markos_or in this case?14:37
loolmarkos_: No, here == hard float port14:37
loolmarkos_: Happy to move to #linaro BTW14:37
markos_oh I see you're discussing it there?14:38
markos_or not.. anyway  I joined to actually follow what's going on14:38
loolmarkos_: we're discussing many things there   ;-)14:45
loolmarkos_: I just dont think the new armhf port is an Ubuntu problem right now14:45
markos_it isn't14:45
loolIt's a Debian and Linaro topic mostly, so seemed sensible to move it over14:45
ogralool, x-loader 1.4.4 is uploaded, next successfull image build should have it (for your qemu testing)14:49
=== dyfet_away is now known as dyfet
rsalvetiogra: when opening armel related bugs, should just including Ubuntu armel porters and the tag armel be enough?14:52
ogralag, ^^^ can you test one of the next omap3 images on your XM too ?14:52
ograeverything after 20100713 on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/14:52
lagogra: I can14:54
ograjust want to know if it regressed14:56
loologra: Thanks14:57
ograGrueMaster, seems the kernel team added some fixes to urwadahead, might be that the OOMs are fixed15:00
GrueMasterI'll test them when I get them.15:00
ograGrueMaster, https://bugs.edge.launchpad.net/ubuntu/+source/ureadahead/+bug/501715 smells like the father of ours :)15:02
ubot2ogra: Error: Bug #501715 is private.15:02
ograhuh ?15:03
ograit definately isnt15:03
ograrsalveti, so looking at your code i like most of it ...15:20
rsalvetiogra: so, what you didn't like? :-)15:21
ograrsalveti, what i dont like is that you use genex2fs even if root is used15:21
ograbetter create an image, mount it and cp the contents15:21
rsalvetiogra: I decided to try only genext2fs to have just a single solution, avoiding supporting two possible paths15:21
ograthat will be much faster, genext2fs first allocates the full image size in ram15:21
ograso it eats tons of ram for bigger images15:22
rsalvetiogra: yeah, I noticed that15:22
ograand gets very slow15:22
ograso in that case i think a second code path is a valid solution15:22
rsalvetiogra: that's what I realized when testing here, I thought about moving back root to the old solution also, but didn't integrate into the code15:22
rsalvetiogra: ok15:22
rsalvetiogra: I can move the root path to the old solution again, np15:23
rsalvetiit's actually faster15:23
rsalvetiif you get 2,3 G image, it's *much* faster15:23
rsalvetiogra: that's fine, I can change it here15:24
rsalvetiogra: any other comment?15:24
=== fta_ is now known as fta
ograrsalveti, the rest looks ok15:25
rsalvetiogra: nice, will move the root solution back to what we currently have for rootstock and send the link for you to review again15:26
=== bjf[afk] is now known as bjf
lag<ogra> lag, ^^^ can you test one of the next omap3 images on your XM too ?16:20
lagogra: Crashes and burns16:20
=== XorA is now known as XorA|gone
ogralag, <ogra> everything after 20100713 on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/16:28
ograasac, i'm planning to add a call to "/usr/lib/gdm/gdm-set-default-session une-efl" to jasper (only if the .desktop file for that session exists) so that it always defaults to the 2D session if thats installed16:49
ograasac, any objections ?16:50
prpplagueogra: is usbfs no longer available with ubuntu 10?16:58
ograprpplague, thats obsolete since two years or so ?!?16:58
ogralag, i dont care about todays image :)16:59
prpplagueogra: problem is openocd uses usbfs16:59
ogralag, only about future images, after 2010071316:59
* lag tuts16:59
ograprpplague, fix it to work with something more recent than 2.6.18 then :)17:00
ogra(me is exaggerating, i dont know the exact version when usbfs vanished, but its quite a while ago)17:00
prpplaguehehe, or just use fedora, hehe17:00
lagI've had OpenOCD work on later kernels than 2.6.1817:00
prpplaguelag: yes it works fine with later kernels, just needs to have usbfs turned on17:01
* prpplague can use openocd and usbfs with ubuntu 917:01
lagOn the debugging machine?17:01
=== hrw is now known as hrw|gone
lagprpplague: Do you have an openocd.cfg that works with OMAPx17:03
prpplaguelag: with omap3, yes, see the beagle openocd page on elinux17:04
lagI don't know where these places are17:04
ograprpplague, heh, that means you used a non ubuntu kernel17:04
lagGoogled it17:04
ograso dont say you used usbfs with ubuntu 9 :)17:05
prpplagueogra: i did a straight ubuntu install17:05
ograhow, we only started supporting omap in lucid17:05
prpplagueogra: hunh?17:06
* prpplague is refering to x86 ubuntu install17:06
ograi thought omap317:07
prpplagueogra: openocd is a jtag utility to debug ARM devices17:09
ograprpplague, if the ubuntu package doesnt work in ubuntu because of usbfs that definitely deserves a bug17:09
prpplaguehmm, don't know if there is an ubuntu package for it17:10
* prpplague looks17:10
ograthere is a debian one since ages, so i'd expect the ubuntu package to exist as long17:10
prpplagueogra: i'll have a look this evening, but from past experience the one that is usually included as package(for any distro) is usually way out of date17:14
ograVersion: 0.3.1-1 on lucid17:15
lagprpplague: My device's voltage is to high to work with OMAPx?17:16
prpplaguelag: what jtag device do you have?17:17
lagAmontec Tiny17:17
lag2.8v -> 5vv17:17
prpplaguelag: should have purchased a flyswatter, hehe17:17
prpplaguelag: *cough*17:17
lagIt wasn't about when I bought this17:18
lagAnd dev-boards weren't so weak ;)17:18
prpplaguelag: actually i released the flyswatter before the amontec tiny was release17:18
lagHow long has the Flyswatter been around?17:19
* prpplague checks the actual dates17:20
lagprpplague: Do you do work for?17:21
prpplaguelag: TinCanTools but i am currently contracted out to TI17:22
prpplaguelag: june 5, 2007 was the release date for the flyswatter17:22
lagAnd for Amontec?17:22
lagI think I've had it ~3-4 years17:22
* lag checks17:23
prpplaguethe earliest entry i see is august of 200717:26
prpplaguei know they had the amontec jtagkey but i didn't think they released the tiny until later17:26
prpplaguelag: ahh i stand corrected17:28
prpplaguelag: looks like the jtagkey-tiny was released in nov 200617:28
davidmlag, do you want a flyswatter?17:29
davidmprpplague, do you think I can get a flyswatter by Thursday if I order today?17:30
prpplaguedavidm: yea, should be able to17:30
davidmOK thanks17:31
prpplaguedavidm: it will ship today most likely17:31
prpplaguedavidm: and since you are in the dfw are it should arrive pretty quick17:31
davidmOK let me run this down, with my kernel folks and then I'll place an order if they want them17:31
prpplaguedavidm: dandy17:31
=== amitk is now known as amitk-afk
prpplaguedavidm: grab some trainer boards as well hehe17:32
davidmI just got in a Zippy2 so that should be good17:32
davidmlag, mpoirier do you need flyswatters?17:37
mpoirierflyswatters ?17:38
ograto splat bugs :)17:38
davidmJtag for beagle17:38
mpoirierhaven't looked at it - hold on.17:38
robclarkprpplague / davidm:  chris or myself could probably carry to prague if shipping is not fast enough to reach you before you leave (just fyi)17:38
prpplaguedavidm: make sure you order the BeagleBoard adapters as well17:39
davidmprpplague, yea, it's in my shopping cart now, I'll commit if I get a go ahead from mpoirier and/or lag17:40
prpplagueokie dokie17:40
ograasac, did you see my ping above wrt default gdm session ?17:42
lagI would love to have a Flyswatter17:47
lagMy Amontec Tiny is to manly for OMAP17:47
* ogra just uses bugspray17:47
=== fta_ is now known as fta
=== zyga is now known as zyga_
prpplaguedavidm: rusty at TCT is ready to ship your flyswatters when you are ready18:12
=== fta_ is now known as fta
=== fta_ is now known as fta
lagdavidm: Did you see my comment?18:42
davidmlag nope18:43
=== robclark_ is now known as robclark
=== fta_ is now known as fta
=== zyga is now known as zyga_
=== fta_ is now known as fta
prpplaguedavidm: you get your flyswatters ordered?20:34
davidmprpplague, the guys decided there was no rush so I'll place a standard order while I'm overseas and time delivery for my return.20:35
prpplaguedavidm: ahh np20:35
loluengohi everyone!20:52
=== zyga__ is now known as zyga
loluengoi have a noob question21:26
loluengodoes ubuntu on arm need somthing like a screen to work?21:27
loluengocan i use it as an OS over a UART terminal?21:28
loluengo(i mean a console-only system)21:28
GrueMasterYes, you can.  What hardware are you working with?21:30
loluengoi haven't defined my hardware yet21:33
loluengobut looking to get an evaluation kit for an ARM920T micro21:35
rsalvetiloluengo: just pay attention on what board you want to get if you want to test ubuntu on it21:37
GrueMasterJust be aware that Ubuntu lucid+ images only support Armv721:37
rsalvetikarmic supports armv5, if that's enough for you21:38
rsalvetiyou can use openembedded if ubuntu doesn't run on your board, but it's quite different21:38
GrueMasterActually, karmic is armv6+vfp.21:45
loluengoand how can i know which "V" is the board i'm looking?21:46
GrueMasterThe arm version.  If at all possible, I would recommend something with Cortex-A8 or A9 as they are the latest and will be the best supported.21:47
GrueMasterWhat is your goal for this project?21:47
rsalvetiGrueMaster: oh, right21:47
rsalvetiand depending on the price the beagleboard could be the best choice for you21:48
rsalvetiit's fast, supported and not that expensive21:48
GrueMasterThat was going to be my suggestion as well, although personally I would wait for the BeagleXM.  Double the memory, faster, built in ethernet, some other features.21:49
GrueMasterAnd not much more expensive.21:49
rsalvetiyeah, better option21:50
rsalvetiloluengo: you can get the correct arm version of your cpu at http://en.wikipedia.org/wiki/ARM_architecture21:50
rsalvetitake a look at the big table21:50
loluengohmm i hadn't heard of BeagleBoard21:52
GrueMasterIt has been around for a while, so most of the kinks have been worked out.21:53
loluengowhat do you think of this board?22:00
loluengois it a good one to get started with ubuntu on ARM?22:00
GrueMasterIt looks rather old.  200mhz?  32M sdram?22:04
GrueMasterCheckout http://beagleboard.org22:04
loluengooh... i see22:05
rsalvetiloluengo: checkout beagleXM22:06
rsalvetiis much much better than this one :-)22:06
GrueMasterShould be about the same cost (if I am translating the currency correctly).22:06
loluengothe xm is usd 180 on digikey22:12
loluengobut not available yet22:12
GrueMasterIt should be shipping sometime around EOM.22:12
loluengoi think i'll wait for then22:15
loluengoand then start trying ubuntu on ARM :D22:15
rsalvetinice :-)22:15
loluengodoes anyone know the minimum system requirements for running ubuntu on arm?22:58
rsalvetiloluengo: lucid+ requires you an armv723:00
rsalvetiand you should have at least 256 of ram, but 512 would be much better23:00
rsalvetiif you want the desktop experience (like netbook)23:01
loluengoi just need a console23:04
loluengo256 mb of ram shouls be enough?23:04
rsalvetiI'm running ubuntu on my beagle with 128, but without graphic, just as a server23:05
loluengoand how much of flash memory do you use for the system image?23:12
rsalvetifor minimal I guess it goes around 256, but 512 would be the recommended one for a usable system23:13
rsalvetibut I'm running my beagle with external sd cards23:13
loluengoaaa ok @rsalveti23:28
loluengoyou boot your system from the sd card?23:28
loluengoand the ram, is on chip? or on board?23:29
rsalvetiloluengo: yep, the boot loader loads the kernel from the sd and put it as the root fs23:47

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