[01:15] <lfitz> if i want to install ubuntu 9.04 on sd card for the sheevaplug do i need uInitrd?
[01:16] <lfitz> this is the last line of the error: Kernel panic - not syncing: No init found.  Try passing init=
[01:16] <lfitz> basically it starts the boot process...
[01:17] <lfitz> I have two partitions on the sd (boot partition is ext2 with uImage) and (root partition is ext3 with rootstock fs)
[05:13] <DanaG> say, I'm interested in that spec about "port glxgears to OpenGL ES".
[05:14] <DanaG> I want to try it on my Intel netbook with libgles1-mesa stuff and libkms and such.
[05:46] <GrueMaster> join #panda
[06:00] <Baybal> hello
[07:55] <sebjan> cooloney: Hi! Did you see my email regarding the segfault patch? Is it ok for you?
[08:03] <ukleinek> npitre: rmk refused to optimize the u-boot related targets, my patch just results in a refusal to build a non-working image
[08:35] <ogra> sebjan, is there a reason for not printing "Uncompressing Linux... done" with the panda kernel ? it works fine, but its very irritating that it doesnt behave like other kernels
[08:39] <amitk> ogra: there is a patch to remove that printk?
[08:39] <ogra> amitk, no idea, but it doesnt print that line :)
[08:39] <amitk> on serial console?
[08:39] <ogra> it boots fine nontheless
[08:39] <sebjan> ogra: you are right, I didn't notice that!
[08:39] <ogra> yeah
[08:39] <amitk> strange
[08:40] <ogra> http://paste.ubuntu.com/459728/
[08:40] <ogra> then it switches to HDMI and moves on with booting
[08:40] <sebjan> I don't know where it comes from (or does not come from :))
[08:42] <michaelh1> Pretty sure it's from the first stage decompressor.
[08:42] <ogra> my target is anyway that endusers shouldnt have to touch serial at all, all config is done via boot.scr on the vfat, so it will only confuse devs but would be nice to have it back :)
[08:42] <michaelh1> head.S?  Something like that?
[08:43] <ukleinek> "Uncompressing Linux... done" needs an implementation of putc in arch/arm/mach-xxx/include/mach/uncompress.h
[08:45] <ukleinek> ... and obviously it only appears if you boot a zImage.  Do you?
[08:47] <ogra> well, uImage but made out of vmlinuz
[08:48] <ogra> so it is compressed, yes
[08:48] <amitk> the omap code has the right stubs in arch/arm/mach-xxx/include/mach/uncompress.h
[08:48] <ogra> the boot process and setup we use is identical to the beagleboard where we get that message
[08:50] <amitk> ogra: You can check if there are OMAP4 related patches to arch/arm/plat-omap/include/plat/uncompress.h
[08:50] <amitk> I don't have a tree handy ATM
[08:51] <ogra> heh, me neither
[08:51] <ogra> thats why i asked the tree admin above ;)
[08:55] <sebjan> there is something related to machine registration into this file (debug uart registration depends on the machine type)
[08:56] <sebjan> I see that the regular omap4 board is registered, but not the panda... I'll see if I can add the panda here
[08:58] <ogra> cool, thanks :)
[09:10] <cooloney> ogra: i got it.
[09:10] <cooloney> ogra: d9f5007491e3b6693dd00487981676b6b3005d72 in our git kernel tree
[09:10] <ogra> ah
[09:11] <cooloney> t d9f5007491e3b6693dd00487981676b6b3005d72
[09:11] <cooloney> Author: vikram pandita <vikram.pandita@ti.com>
[09:11] <cooloney> Date:   Sun Nov 22 10:10:49 2009 -0800
[09:11] <cooloney>     omap: introduce OMAP_LL_DEBUG_NONE DEBUG_LL config
[09:11] <cooloney>     
[09:11] <cooloney>     Zoom2/Zoom3 kind of boards do not use omap uarts for console.
[09:11] <cooloney>     These use external debug board for console.
[09:11] <cooloney>     
[09:11] <cooloney>     So these boards should not have "Uncompressing Kernel...."
[09:11] <cooloney>     log put on omap uarts.
[09:11] <cooloney>     
[09:11] <cooloney>     By interoducing OMAP_LL_DEBUG_NONE option,
[09:12] <cooloney> sebjan: does our panda also affected by this patch?
[09:16] <sebjan> cooloney: this is the function where the uart to use for the uncompressing trace gets selected
[09:17] <sebjan> I just tested adding the panda registration here and I can now see the trace on my panda
[09:17] <sebjan> I will post the patch to my tree (it's a 1 line)
[09:20] <cooloney> sebjan: thanks, man
[09:22] <ogra> cooloney, sebjan, did one of you test the kernel with X ?
[09:22] <ogra> it freezes here no matter what i try
[09:23] <ogra> hmm, or not ... just seems extremely slow
[09:24] <ogra> i guess there is still some issue with the SD/MMC I/O
[09:26] <cooloney> ogra: i am waiting for my hw. so never try that X before
[09:26] <ogra> cooloney, oh, sorry i tend to forget that you dont have the HW
[09:26] <cooloney> sebjan: how about you?
[09:27] <ogra> seems the freezes happen if i dont specify mem=463M on the cmdline
[09:27] <ogra> now it works but is very slow
[09:32] <amitk> cooloney: do you have a beagle board?
[09:32] <cooloney> amitk: no
[09:32] <amitk> cooloney: you will in Prague :)
[09:32] <ogra> amitk, he'll get a panda soon
[09:32] <ogra> i think its on its way already
[09:32] <cooloney> amitk: yeah, i will. panda and prague, hehe
[09:32] <cooloney> ogra: yeah, i hope it will arrive this week
[09:32] <amitk> cooloney: I'm bringing you a beagle as well
[09:33] <cooloney> amitk: thanks a lot
[09:33] <ogra> we need more XMs in the team
[09:33] <ogra> XM support is still behind
[09:34] <amitk> lag has one now
[09:34] <ogra> yeah
[09:34] <ogra> i still havent found whats wrong with our u-boot yet
[09:34] <cooloney> cool man
[09:34] <ogra> currently the XM doesnt boot with the archive u-boot
[09:35] <lag> Mine does
[09:35] <lag> Just not initrd
[09:35] <ogra> lag, thats equivalent to "doesnt boot" :)
[09:35] <ogra> initrd is a requirment for ubuntu images
[09:35] <lag> :)
[09:36] <ogra> mine does boot with the binary from rcn, including initrd
[09:36] <ogra> but i cant find the difference in our sources, he seems to use the same i use
[09:36] <sebjan> ogra: I have been doing some testing with the UNE UI, is that what you mean?
[09:37] <ogra> sebjan, well, i just wanted to know if X seems usable for you, here it freezes every time it accesses the SD
[09:38] <ogra> i'm currently testing the panda images from http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/ the oem-config screens take ages to show up
[09:38] <ogra> (note that only 20100706.1 will have the mem=463M fix in them, they are currently building)
[09:39] <sebjan> I did not have such issues the last time I tested... It was not very fast, but I suspected it was because it seems that both UNE and the regular gnome desktop UI are started (bug 596004)
[09:39] <ubot2> Launchpad bug 596004 in netbook-meta (Ubuntu) "with 2D UI (une-efl) selected, the gnome desktop toolbar is also visible and seems to be running (affects: 1) (heat: 242)" [Undecided,New] https://launchpad.net/bugs/596004
[09:39] <ogra> would be helpful if the panda had some indicator LED for SD access, you never know if it reads or actually is dead
[09:40] <ogra> sebjan, yeah, that bug is on my list but shouldnt cause much slowdown
[09:40]  * ogra triages it properly
[09:41] <ogra> gah, now it seems to hang hard again
[09:42] <ogra> and i was already through oem-config and in the slideshow
[09:43] <ogra> sebjan, what kind of SD's do you use ?
[09:43]  * ogra currently has a class 4
[09:44] <sebjan> ogra: I also use class 4 cards (Kingston)
[09:44] <ogra> (micro SD with adapter)
[09:45] <ogra> hmm doesnt seem to come back to life
[09:46] <sebjan> (regular SD card for me)
[09:47]  * ogra wishes he could at least get far enough to have a user created 
[09:47] <ogra> so i could read any logs
[09:49] <ogra> cooloney, is the binary we have in the archive recent ? does it have all fixes and patches ?
[09:58] <cooloney> ogra: the M ti-omap4 kernel? i we got lots for fixes and patches from sebjan except the syslink module patch
[09:58] <cooloney> ogra: what's uname -a in your system
[10:00] <lag> sebjan: Is syslink discoverable?
[10:02] <sebjan> lag: you'll have to explain me what it means 'discoverable' :)...
[10:04] <cooloney> sebjan: i am guess, it means probable?
[10:04] <lag> At the moment (with the module patches applied) the kernel doesn't 'discover' the device and load the modules
[10:06] <cooloney> lag: did you add the platform device and resource in the panda board files in mach-omapX?
[10:07] <lag> Yes
[10:08] <lag> If I register the device alone I get KERNEL and UDEV uevents
[10:08] <lag> But I need a DRIVER uevent
[10:09] <lag> I've tried registering a platform driver, but because the device is unknown to the kernel the .probe function is never called
[10:15] <cooloney> lag: the .name field of the platform device in your board file should be the same of the driver platform name in syslink driver. IMHO
[10:16] <sebjan> lag: I suppose that we are missing something either in the device declaration or in the driver... this is what we need to get sorted out
[10:17] <lag> cooloney: It is
[10:17] <lag> I've moved the .probe function to the same place as the __init function
[10:17] <lag> The __init function is called and the driver is registered successfully
[10:17] <lag> But .probe is still not called
[10:18] <lag> .probe functions are not called if the kernel does not know about the device
[10:18] <lag> Hence the discoverable question
[10:18] <lag> sebjan: It's not even getting as far as the driver
[10:19] <lag> sebjan: I think we need more information in my (__init) function to tell the kernel about the existence of the hardward
[10:19] <lag> hardware*
[10:19] <ogra> cooloney, well, we only had one upload yet and i cant get to a point in the image to type in uname (i cant get past user creation before the board hangs hard)
[10:20] <lag> I am in the process of putting the driver & device register code in the same place - see what that does
[10:20] <ogra> cooloney, so i cant really say what uname would give, but i'm pretty sure its 2.6.34-900.1 since that was the only upload we had yet
[10:21] <cooloney> ogra: oh, please wait, i can provide a new testing kernel for you,
[10:21] <ogra> lag, arent there any other devices you could just steal from ?
[10:21] <ogra> cooloney, doesnt help, i'm testing images, they build from the archive
[10:21] <ogra> cooloney, we should rather kick leann to do a new upload if the tree has so many patches
[10:21] <cooloney> ogra: ah, right
[10:22] <cooloney> ogra: ok, i think rtg will upload that
[10:22] <ogra> lag, i could imagine rfkill to be a platform device doing something similar to what we need
[10:22] <ogra> cooloney, ah, right, he did the last upload too, i missed that
[10:24] <sebjan> lag: send me patches of your current changes, and I'll tell you if I have an idea and try to play with it this afternoon
[10:24] <lag> ogra: No, I can't find any other devices that do this
[10:28] <ogra> gah
[10:36] <ogra> the plymouth splash looks really good on the panda :)
[12:39] <ogra> lag, could you paste the Hardware line of a beagle XM for me ?
[12:39] <ogra> lag, from /proc/cpuinfo
[12:42] <lag> Yup - 2 mins
[12:42] <ogra> hrw, your openjdk build, how did you do the testbuild, in a clean chroot ?
[12:42] <hrw> ogra: no - in normal BB system
[12:42] <ogra> lag, no hurry, anytime you find the time is fine
[12:42] <ogra> hrw, definate 2normal BB system"
[12:42] <ogra> s/2/\"
[12:42] <lag> It's okay - I'm waiting for an email from linux-hotplug
[12:42] <hrw> ogra: quite up-to-date maverick
[12:43] <ogra> openjdk needs itself to register the ca certificates but the lucid openjdk seems to segfault here, what openjdk version did you have installed for the build ?
[12:44] <ogra> (keytool is a java app and calls the former openjdk while installing the build deps)
[12:44] <hrw> ogra: I did "apt-get build-dep openjdk-6", then "apt-get source openjdk-6", "cd openjdk-6-*;debuild -b -uc -us"
[12:44] <ogra> hmm
[12:44] <hrw> ogra: did not looked at versions etc
[12:45] <ogra> LANG=C LC_ALL=C keytool -importcert -trustcacerts -keystore $KEYSTORE -providerClass sun.security.pkcs11.SunPKCS11 -providerArg '${java.home}/lib/security/nss.cfg' -noprompt -storepass "$storepass" -alias "$alias" -file "$cacertdir/$pem" > $log 2>&1
[12:45] <ogra> thats the line that segfaults
[12:45] <ogra> and openjdk ships /usr/lib/jvm/java-6-openjdk/jre/bin/keytool
[12:46] <ogra> (which /usr/bin/keytool links to through an alternative)
[12:46] <hrw> keytool error: java.lang.RuntimeException: Usage error, sun.security.pkcs11.SunPKCS11 is not a legal command
[12:46] <ogra> i dont get how it could build for you while it doesnt on the buildd
[12:46] <hrw> ogra: want shell access to that beagle?
[12:47] <ogra> no
[12:47] <ogra> so it doesnt segfault for you apparently but just complains
[12:48] <ogra> does apt-get install --reinstall ca-certificates-java work for you without any errors ?
[12:57] <hrw> Setting up ca-certificates-java (20100412) ...
[12:57] <hrw> Processing triggers for initramfs-tools ...
[12:58] <ogra> very weird
[12:59] <hrw> http://hrw.pastebin.com/4ZSwj2zP
[12:59] <ogra> on the buildd /var/lib/dpkg/info/ca-certificates-java.postinst fails
[13:00] <hrw> root@beagle:/mnt/hrw/UBUNTU# /var/lib/dpkg/info/ca-certificates-java.postinst configure
[13:00] <hrw> creating /etc/ssl/certs/java/cacerts...
[13:00] <hrw> done.
[13:01] <hrw> http://hrw.pastebin.com/7KqebZ5e shows ver
[13:04] <rsalveti> morning
[13:06] <ogra> hrw, aha ... Setting up default-jre-headless (1.6-38) ...
[13:06] <ogra> from the build log
[13:07] <ogra> ogra@osiris:~/Devel/branches/jasper-initramfs-0.10$ apt-cache show ca-certificates-java|grep Depends
[13:07] <ogra> Depends: ca-certificates (>= 20090814), openjdk-6-jre-headless (>= 6b16-1.6.1-2) | java6-runtime-headless
[13:08] <ogra> ogra@osiris:~/Devel/branches/jasper-initramfs-0.10$ apt-cache search java6-runtime-headless
[13:08] <ogra> default-jre-headless - Standard Java or Java compatible Runtime (headless)
[13:08] <ogra> openjdk-6-jre-headless - OpenJDK Java runtime, using Hotspot JIT (headless)
[13:08] <ogra> sun-java6-jre - Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files)
[13:08] <ogra> so for whatever reason default-jre-headless gets installed on the buildd instead of openjdk-6-jre-headless
[13:17] <ogra> hrw, the versions in http://hrw.pastebin.com/4ZSwj2zP cant be right
[13:17] <ogra> hrw, 6b20~pre1-0ubuntu2 didnt build
[13:18] <ogra> where did you get it from ?
[13:18] <ogra> smells like you have your testbuild installed now
[13:18] <ogra> the last one that built on the buildd was 6b18-1.8-2ubuntu2
[13:19] <hrw> I built and installed
[13:20] <ogra> yeah, i need to know what version was used during installation of ca-certificates-java
[13:21] <ogra> which indeed came in with your apt-get build-dep
[13:21] <hrw> probably 6b18
[13:22]  * ogra doesnt get why it didnt segfault for you
[13:48] <rsalveti> ogra: do you know if for maverick we have different kernel trees for omap? or both omap3 and omap4 should work with the ti-omap4 branch?
[13:48]  * rsalveti looking at maverick's kernel
[13:49] <ogra> the omap3 binary is built from the normal ubuntu tree
[13:49] <lool> rsalveti: I asked recently, and omap3 was broken in the omap4 branch
[13:49] <ogra> omap4 comes from the ti-omap4 branch
[13:49] <ogra> rsalveti, omap4 is maintained by cooloney, omap3 by lag and mpoirier
[13:50] <rsalveti> oh, ok, so different branches for both
[13:50] <rsalveti> or it should all work at the same branch?
[13:50] <ogra> well, only a different branch for omap4 actually
[13:50] <rsalveti> it's just that I just saw one ti-omap4 branch at the gitweb
[13:51] <ogra> the big target is that omap4 goes to mainline at some point, then both binaries will be built from the ubuntu branch
[13:51] <ogra> but since omap4 is over 700 patches that will take a while
[13:51] <rsalveti> oh, sure :-)
[13:51] <ogra> and is unlikely to happen for maverick
[13:51] <rsalveti> got it now, at least for omap 3 we're in a better situation
[13:51] <rsalveti> now the problem is just omap4
[13:52] <rsalveti> yeah, don't think so
[13:52] <ogra> so currently TI takes the ubuntu maverick branch and rebases their patches on top of that
[13:52] <ogra> for omap4
[13:52] <ogra> which makes it being a bit behind in versioning
[13:52] <npitre> ukleinek: I don't get why a non working image would be built
[13:52] <npitre> ukleinek: see my rational in my answer
[13:53] <npitre> ukleinek:  uboot needs to be fixed
[13:53] <rsalveti> ogra: yeah, right
[13:53] <rsalveti> tons of patches, maybe for 36 or 37
[13:53] <ogra> right
[13:55] <rcn-ee> note: basic panda support is in tmlind's tree for 36.. not sure if it boots, waiting for ups myself..
[13:55] <ogra> rcn-ee, "basic" isnt want we need for maverick :)
[13:56] <ogra> also the tree we use is blaze+panda capable
[13:56] <rsalveti> rcn-ee: yeah, just saw the commits
[13:56] <rcn-ee> yeah, but not everyone use the default maverick kernel. ;)
[13:57]  * rsalveti is looking forward to put my hands at a panda board
[13:57] <ogra> rcn-ee, well ...
[13:57] <ogra> rsalveti, no fun yet ... multiple hangs etc
[13:58] <rsalveti> 700 patches, I believe maverick will be much more than the basic
[13:58] <ogra> definately
[13:58] <rcn-ee> yay, sounds like fun.. ;)  just like my custom imx515 board...
[13:58] <hrw> rsalveti: at any pandaboard or at own pandaboard?
[13:58] <rsalveti> ogra: hangs are always fun, at some way haha :-)
[13:58] <ogra> heh
[13:59] <rsalveti> hrw: the omap4 pandaboard :-)
[14:00] <hrw> rsalveti: by 'any' I meant 'not own'
[14:01] <lag> ogra: That's not true
[14:01] <lag> I am working on omap3 & omap4
[14:01]  * ogra hangs his head in shame 
[14:02] <ogra> rsalveti, correction: lag woprks on *all important kernels* :)
[14:02] <lag> Now you're talking
[14:03] <amitk> rcn-ee: what custom imx515 board?
[14:03] <amitk> rcn-ee: want to send me patches to add board support? ;)
[14:12] <hrw> amitk: someone offered efikamx few days ago...
[14:12] <amitk> hrw: the board or code?
[14:13] <hrw> boards
[14:14] <hrw> #linaro:02:10 < zumbi> if someone fancies an efikamx board to test out linaro, let me know
[14:14] <hrw> Saturday 3rd July
[14:15] <rsalveti> hrw: oh, sorry :-) do you know when pandaboard will be public? like beagleboard
[14:15] <hrw> rsalveti: nope
[14:16] <amitk> rsalveti: should be Q4
[14:16] <amitk> hrw: Do you know if the efiamx comes with documentation to enable in mainline?
[14:17] <armin76> Q4? wow
[14:18] <armin76> amitk: it doesnt
[14:20] <amitk> armin76: pity. I don't want to spend time on it then
[14:26] <hrw> amitk: no idea
[14:55] <ukleinek> npitre: I'm not sure anymore about ZRELADDR, IIRC something was broken with ZBOOT_ROM images for U-Boot
[14:58] <lag> ogra: Sorry for the delay - I had to make and re-flash a new card
[14:58] <lag> ogra: Hardware        : OMAP3 Beagle Board
[14:58] <ogra> perfect
[14:58] <ogra> same as C4
[14:59]  * ogra is happy he doesnt need to special case for XM
[14:59] <lag> :)
[14:59] <lag> I'm pleased you're pleased
[14:59] <ogra> :)
[14:59] <lag> perisa
[15:00] <lag> Doh
[15:00] <lag> Actually: lol & ogra
[15:00] <lag> I need a word ;)
[15:00]  * ogra pulls up the dictionary
[15:00] <lag> You've wasted a working day!
[15:00] <ogra> a long one or rather a short one ?
[15:00] <lag> Leading me up the garden path
[15:01] <lag> REF: /lib/udev/rules.d/80-drivers.rules, DRIVER!="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -b $env{MODALIAS}"
[15:01] <lag> Do you know what that means?
[15:01] <lag> lool*
[15:02] <lag> lool, ogra: Do you subscribe to linux-hotswap?
[15:02] <ogra> if DRIVER is set run modprobe ?
[15:02] <lag> NOOOOOOOOOOOOOOOo
[15:02] <ogra> lag, nope, i'm no kernel guy
[15:02] <lag> It doesn't mean that
[15:02] <lag> It's what you told me it meant
[15:02] <ogra> so what does it mean ?
[15:02] <lag> Arhgggggggggggggggggggggggggg
[15:02] <lag> :)
[15:02] <ogra> educate me :)
[15:04] <ogra> ugh, it means if DRIVER is *not* set, right ?
[15:04] <lag> It means: This rule is skipped only if DRIVER is set
[15:04] <lag> Hang on
[15:05] <lool> lag: Oh right, DRIVER!=, I missed this bit
[15:05] <ogra> right, i see that now, if DRIVER is not set but MODALIAS exists in the environment, call modprobe
[15:06] <lag> Follow this: http://www.spinics.net/lists/hotplug/msg03946.html
[15:06] <lool> lag: I read DRIVER=
[15:06]  * ogra too
[15:06] <lag> Arrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
[15:06] <ogra> :(
[15:06]  * lag crys
[15:06] <lool> lag: But the MODALIAS bit is ok, right?
[15:06]  * lag cries*
[15:06] <lag> Follow that link I posted
[15:06] <lag> This has cost me a day :(
[15:07] <lool> lag: But the upside is that we're all three educated on what DRIVER is used for, and you have a path forward!
[15:07] <lag> I guess there's always an upside
[15:07] <ogra> and your MODALIAS is wrong i'D say
[15:07] <lag> Why is it wrong?
[15:07] <ogra> "platform:"
[15:08] <lag> What should it be?
[15:08] <ogra> the module name
[15:08] <lool> Uh no
[15:08] <ogra> thats what modprobe -b calls in the rule above
[15:08] <lag> The real MODALIAS is: platform:syslink
[15:08] <lag> I ****'ed out the syslink
[15:08] <ogra> and the module name is syslink
[15:09] <lool> that's ok, you just need to modalias the .ko now
[15:09] <ogra>  /sbin/modprobe -b platform:syslink will error out, no ?
[15:09] <lool> ogra: Well not if some module has an alias for platform:syslink ?
[15:10] <ogra> in sysfs ?
[15:10] <lool> no, in the .ko
[15:10] <ogra> i.e. where would modprobe get that from ?
[15:10] <lool> ogra: modinfo e1000e|grep alias
[15:10] <ogra> ah
[15:10] <ogra> oh, right
[15:11] <lag> grep MODALIAS /var/log/udev
[15:11] <ogra> yeah yeah :)
[15:11]  * ogra admits again that he's no kernel guy
[15:12]  * lag goes to work
[15:12]  * lag takes a big breath then --^
[15:15]  * ogra goes to eat some icecream
[15:19] <lag> lool: The driver is called syslink_ipc.ko
[15:19] <lag> module == driver
[15:19] <lag> MODALIAS=platform:syslink_ipc
[15:20] <lag> Surely there should be an association?
[15:20] <lag> KERNEL[946692859.898376] add      /devices/platform/syslink_ipc (platform)
[15:20] <lool> lag: That doesn't work?
[15:20] <lag> No
[15:20] <lag> KERNEL[946692859.898376] add      /devices/platform/syslink_ipc (platform)
[15:20] <lag> UDEV_LOG=3
[15:20] <lag> ACTION=add
[15:20] <lag> DEVPATH=/devices/platform/syslink_ipc
[15:20] <lag> SUBSYSTEM=platform
[15:20] <lag> MODALIAS=platform:syslink_ipc
[15:20] <lag> SEQNUM=735
[15:20] <lag> That is my uevent
[15:20] <lag> But udev isn't loading the module
[15:20] <lool> lag: But platform:syslink_ipc != syslink_ipc
[15:21] <lag> Correct
[15:21] <lool> lag: Try modprobe platform:syslink_ipc for yourself
[15:21] <lool> And modinfo syslink_ipc
[15:21] <lag> ubuntu@panda:~$ modinfo syslink_ipc
[15:21] <lag> filename:       /lib/modules/2.6.34-901-omap4/kernel/drivers/dsp/syslink/multicore_ipc/syslink_ipc.ko
[15:21] <lag> license:        GPL
[15:21] <lag> author:         Texas Instruments
[15:21] <lag> srcversion:     7329950ABDD680C3701426C
[15:21] <lag> depends:        syslink_proc,omap_notify,syslink_proc4430,syslink_platform,notify_ducatidriver,syslink_ipu_pm
[15:21] <lag> vermagic:       2.6.34-901-omap4 SMP preempt mod_unload ARMv7
[15:21] <lag> parm:           ipc_name:Device name, default = syslink_ipc (charp)
[15:21] <lag> parm:           ipc_major:Major device number, default = 0 (auto) (int)
[15:21] <lag> parm:           ipc_minor:Minor device number, default = 0 (auto) (int)
[15:21] <lool> You probably want an actual alias then
[15:21] <lool> I think you need to define that in your kernel module
[15:22] <lag> So an alias | and entry in udev rules?
[15:22] <lool> You shouldn't need an entry in udev
[15:22] <lag> OR
[15:22] <lool> AIUI, udev runs modprobe platform:syslink_ipc but that fails to find anything
[15:22] <lool> lag: Right, but you probably dont want an udev rule, just an alias
[15:23] <lag> I don't know how to do that
[15:23]  * lag looks
[15:23] <lool> Or you change the kernel to emit another event which triggers the load, perhaps another rule would match; I think the modalias is the easiest path
[15:24] <lag> MODULE_ALIAS("platform:" DRV_NAME);
[15:24] <lag> Bingo!
[15:25] <lool> Eh right, was grepping for something similar in drivers/, but I should have looked in arch/arm
[15:25] <lool> arch/arm/mach-omap2/mailbox.c has another instance
[15:26] <lag> That was in /drivers
[15:27] <ukleinek> lag: linux/mod_devicetable.h #defines PLATFORM_MODULE_PREFIX, not sure using it is worth though
[15:27] <lool> I mean it would have been quicker to grep arch/arm
[15:28] <lag> #define PLATFORM_MODULE_PREFIX	"platform:"
[15:28] <lag> Lol
[15:28] <lool> ukleinek: Not widely used it seems (drivers/base/platform.c)
[15:28] <lag> MODULE_ALIAS(PLATFORM_MODULE_PREFIX, DRV_NAME);#
[15:28] <lag> :)
[15:28] <ukleinek> lag: no , please
[15:28] <lag> ?
[15:28] <ukleinek> lool: yeah, I know, just stumbled over it some time ago
[15:28] <ukleinek> MODULE_ALIAS(PLATFORM_MODULE_PREFIX DRV_NAME);
[15:29] <lag> Oh, I see
[15:29] <lag> I'm not going to use it anyway
[15:29] <lag> I was just messing :)
[15:30] <lag> My first attempt is the most common
[17:55] <robschi> I'm trying to install ubunt-arm on the beagleboard via netinstall. Unfortunately, my usb-nic-adapter (it is a moschip type) is not recognized as a network device, although it worls perfectly on a x86 linux system. Where can I find the kernel sources/patches and kernel config in order tu build my own uImage file?
[17:56] <hrw> try maverick first?
[17:59] <rsalveti> robschi: do you know the module responsible for it at x86 already?
[17:59] <ogra_cmpc> there is a fix for it but the netinst image hasnt been regenerated yet
[18:00] <ogra_cmpc> either do a server install or use maverick
[18:00] <ogra_cmpc> or wait for lucid .1
[18:02] <robschi> rsalveti: lsmod replies with things like
[18:02] <robschi> mii                     4032  3 mcs7830,usbnet,r8169
[18:02] <npitre> ukleinek: I never used ZBOOT_ROM with U-Boot
[18:03] <npitre> ukleinek: I think U-Boot is getting too much in the way for that feature
[18:04] <robschi> server install does not work, becaus the installer insists on using a cd-rom drive
[18:04] <GrueMaster> robschi: I had filed a bug on this in Lucid, but The number (and status) currently escapes me.
[18:04]  * npitre thinks that U-Boot is often too much in the way, period.
[18:04] <ogra_cmpc> robschi, server install was tested by several people, it should just work
[18:06] <ogra_cmpc> robschi, did you follow https://wiki.ubuntu.com/ARM/BeagleServerInstall ?
[18:06] <robschi> ogra_cmpc: yes, i did
[18:07] <ogra_cmpc> thats strange, the released image was heavily tested
[18:07] <sebjan> lag: I have my syslink modules auto-loading finally :). The implementation is not clean yet, but the mechanism is functional at least. I'll send you my changes so that we can discuss them together.
[18:08] <lag> I have also finished :)
[18:08]  * ogra_cmpc thinks lag found the right solution too today :)
[18:08] <robschi> ogra_cmpc: i'm installing over serial port, but this should not influence the behaviour of the installer, or does it?
[18:08] <ogra_cmpc> snap ....
[18:09] <sebjan> lag: cool :)
[18:09] <lag> What did you do?
[18:09] <ogra_cmpc> robschi, as long as the boot.scr stays intact
[18:10] <ogra_cmpc> (and you dont drop the preseed values from the kernel cmdline)
[18:11] <robschi> ogra_cmpc: i will check this again.
[18:11] <sebjan> lag: I'll send you a patch shortly, I am doing some quick reformtating and squashes. But is basically is what we talked about and what you dealed about here this afternoon ("platform:")
[18:12] <lag> Oh, you thought you'd sneak in there with my info - cheeky!
[18:13] <sebjan> lag: I have worked on this in dotted line since last week, and sure would have spent some time on this platform thing :)
[18:15] <sebjan> lag: but I am sure the patch needs re-disgn to put things in proper files at least
[18:15] <lag> So which patch should we use? I can submit mine either today or tomorrow morning if you like?
[18:15] <lag> My code is only a few lines
[18:15] <lag> I think it's 10 lines of code
[18:18] <sebjan> lag: I am ok to use yours. Please wait until I send you mine so that we can cross-check what we did is correct. I'send send you my patch in a few minutes.
[18:18] <lag> No problem sebjan
[18:26] <sebjan> lag: I just sent it to you
[18:26] <lag> I received it
[18:27] <lag> sebjan: I think platform_device_alloc() is deprecated
[18:29] <sebjan> lag: ok, I did not check that (the device creation part is a rought copy/paste from some syslink code)
[18:34] <lag> sebjan: http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=commitdiff;h=b8bec3a6239f0d9d23250eb0265bd56f77198384;hp=05cd276ae6bfe20745244f2285fab2b3d40ca1e3
[18:36] <robschi> ogra_cmpc: yes, the bootargs in boot.scr have not been correct, because I bootet the system manually without boot.scr. Now it installs fine. Thank you for your help.
[18:37] <lag> sebjan: I have to go - speak tomorrow
[18:37] <sebjan> lag: ok, me to, talk to you tomorrow
[18:38] <lag> Have a good night all
[18:38]  * lag out
[18:39] <markos_> anyone knows if maverick gcc supports -mfloat-abi=hard?
[18:40] <hrw> hrw@home:~/xdeb$ arm-linux-gnueabi-gcc hello.c -mfloat-abi=hard
[18:40] <hrw> /usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/bin/ld: error: /tmp/cckGhdno.o uses VFP register arguments, a.out does not
[18:40] <hrw> /usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/bin/ld: failed to merge target specific data of file /tmp/cckGhdno.o
[18:41] <hrw> markos_: you need to rebuild all software with it iirc
[18:42] <hrw> hrw@home:~/xdeb$ arm-linux-gnueabi-gcc -mfloat-abi=hard test.c -o test.o -c
[18:42] <markos_> hrw: I know, the question is if it supports it, previously it didn't
[18:42] <markos_> the error msg you gave is a good sign :)
[18:43] <markos_> previously it just said "not supported"
[18:43] <markos_> previously = karmic
[18:43] <armin76> markos_: well, iirc you can't make gcc not support it
[18:43] <hrw> http://pastebin.com/TXTBgRij is assembly of generated source
[18:43] <armin76> it was included on gcc-4.5, so...
[18:43] <markos_> armin76: with an old gcc version you can :)
[18:44] <hrw> http://pastebin.com/2S6ztE87 is source used
[18:44] <ssvb> markos_: codesourcery != gcc :)
[18:45] <markos_> ssvb: I know, I was just curious if I could use maverick's gcc instead of codesourcery if it supported hardfp
[18:46] <markos_> hrw: what flags did you use (for comparison)
[18:46] <hrw> markos_: hrw@home:~/xdeb$ arm-linux-gnueabi-gcc -mfloat-abi=hard test.c -o test.o -c -s^C
[18:46] <hrw> arm-linux-gnueabi-objdump -D test.o
[18:47] <lool> markos_: The gcc-4.4 we prepare for maverick armel has CodeSourcery patches (gcc-linaro)
[18:47] <markos_> ok, just wanted to check optimizations settings
[18:47] <markos_> lool: great to know
[18:47] <hrw> basically each FSF gcc release has some of codesourcery patches ;)
[18:49] <ssvb> lool: does gcc-4.4 show good performance?
[18:50] <markos_> ssvb: here I get up to 35% faster than softfp in pure fp benchmarks -using codesourcery
[18:50] <hrw> markos_: hardfp contra softfp?
[18:51] <ssvb> in my limited benchmarks, gcc-4.4 has major performance regressions on arm platform for some tests when compared to gcc 4.3 and 4.5
[18:52] <markos_> hrw: yes
[18:52] <hrw> markos_: on A9 it is less difference afaik but who has A9...
[18:53] <armin76> hrw: me :D
[18:53] <markos_> hrw: http://www.powerdeveloper.org/forums/viewtopic.php?p=13602#13602
[18:53] <markos_> hrw: i don't have an a9 (yet) to test hardfp
[18:54] <markos_> perhaps the difference is smaller, I don't know
[18:54] <ssvb> markos_: yes, I know :) I also have seen the speedup on some artificial benchmarks that I did myself
[18:55] <ssvb> is ubuntu going to use -mfloat-abi=hard ?
[18:56] <hrw> ssvb: there were some discussions about making such rebuild for tests
[18:56] <hrw> irc
[18:56] <hrw> iirc
[18:57] <ssvb> good
[18:57] <ogra_cmpc> ubuntu itself will likely not change in maverick, in maverick+1 we might take as default what linaro develops atm
[18:57] <ogra_cmpc> since they do the toochain changes during maverick
[18:57] <ogra_cmpc> and test them etc
[19:04] <markos_> ssvb: know of any way to detect the current abi on a system?
[19:04] <markos_> or in a file for that matter
[19:06] <ssvb> markos_: what do you mean?
[19:06] <ssvb> markos_: via gcc predefined macros?
[19:07] <ssvb> markos_: you can use 'readelf -a' to get abi of some binary
[19:09] <markos_> ssvb: that's what I wanted yes
[19:09] <ssvb> binaries using hard vfp will have "Tag_ABI_VFP_args: VFP registers"
[19:10] <hrw> yep
[19:10] <lool> ssvb: I would be interested in discussing your performance regressions
[19:11] <markos_> ssvb: cool thanks
[19:11] <lool> ssvb: I'm animating the toolchain WG in Linaro, I'd love if we could check your performance regressions against our Linaro toolchains
[19:12] <lool> ssvb: I know 4.5 is much better than 4.4, and I believe Linaro 4.4 / CodeSourcery 4.4 has much of 4.5 improvements
[19:12] <ssvb> lool: http://hardwarebug.org/2009/08/05/arm-compiler-shoot-out/
[19:12] <ogra_cmpc> lool, "animating" ?
[19:12] <ogra_cmpc> like http://www.youtube.com/watch?hl=de&v=QAue4hnH8-A ?
[19:12] <ssvb> I generally don't trust random blogs, but it matches the results of my own benchmarks
[19:13] <ssvb> in some cases gcc 4.4 produces code which is up to 30% slower
[19:13] <markos_> ssvb: so I guess a way to detect is a system is softfp/hardfp would simply grep Tag_ABI_VFP_args: VFP registers in /lib/libc.so.6
[19:15] <ssvb> lool: and what is very easy to verify, gcc 4.4 always generates bigger binaries (maybe it's one of reasons why it is so bad for some applications)
[19:17] <ssvb> lool: both gcc 4.3 and 4.5 generate code which is either a lot faster than 4.4 or show about the same performance
[19:17] <ssvb> lool: and 4.5 is faster than 4.3
[19:22] <lool> ssvb: thanks for sharing tihs link
[19:22] <lool> ssvb: Ok, well I will bring these up at our next meeting, I think it's good feedback
[19:23] <lool> ssvb: we carry the CodeSourcery patchset in Linaro GCC, so it's rather good for us it seems
[19:23] <lool> But the RVCT tests are interesting too
[19:32] <ssvb> lool: ffmpeg may be not a very good example because it's coding style is not so typical
[19:32] <ssvb> but my own benchmarks included pixman library (its regression tests) and a simple C++ roguelike game :)
[19:32] <ssvb> I have not tried thumb2 though, maybe it would show some totally different results
[19:33] <ssvb> lool: what do you generally use to evaluate toolchain performance?
[19:33] <hrw> have a nice rest of day
[19:41] <armin76> ssvb: hello world :D
[19:42] <lool> ssvb: In my experience, it's hard to get definitive informationon who uses what benchmarks
[19:42] <lool> ssvb: Kind of secret sauce
[19:42] <lool> ssvb: So in Linaro we aim at building tools to measure more things, such as size of binaries
[19:42] <lool> ssvb: thumb2 is really important, the size difference might be just enough to fit in cache, and make a huge difference
[19:43] <markos_> lool: but you lose performance with thumb2
[19:43] <lool> markos_: A very small amount, and it's decreasing with new SoCs
[19:44] <lool> markos_: And it's only lose if you don't consider cache/memory pressure
[19:44] <lool> plus, storage loading times
[19:44] <markos_> I see
[19:44] <lool> it all adds up, it's not much but ...
[19:45]  * ssvb wonders if gcc can (or does) generate arm code for "hot" functions
[19:45] <ssvb> it would make a lot of sense
[19:46] <lool> I think you can annotate fhes,e or use compiler flags for source files, but I'm not sure you can do that at runtime with gcc yet, while I think it is possible with LLVM, but I have no experience with it
[19:46] <ukleinek> npitre: apropos of u-boot, we at pengutronix try to make it better with barebox.  At least I like it better
[19:47] <ssvb> I guess mixing arm and thumb2 intelligently may provide some really good results
[19:47] <lool> ssvb: BTW I'm not sure you can build ffmpeg with thumb2
[19:47] <lool> but it's not expected to make a big difference anyway
[19:48] <lool> ssvb: i think we switched to ARM for ffmpeg due to so much handcoded assembly that it would be hard to fix
[19:48] <ssvb> lool: http://hardwarebug.org/2009/03/25/thumbs-up/ :)
[19:53] <lool> eh
[19:56] <robclark> fwiw, it depends on if it is inline asm or just separate complete functions implemented in arm asm..
[19:57] <robclark> it is no problem to call arm functions from thumb code
[19:57] <lool> I think it's just a lot of places with assembly which need to be reviewed
[19:59] <robclark> ahh, gotcha
[19:59] <ssvb> I think some selected applications and libraries just need good performance, so they may be better compiled for arm just for this reason
[20:00] <robclark> btw, on a related topic..  I recommend -O3 when you are building libfaac..
[20:00] <robclark> seemed to help a lot for me.. like 2x+
[20:01] <robclark> (the faac code uses a lot of floating point.. not sure if that makes much difference in how effective the compiler optimizations are..)