[07:37] <siji> hi all
[07:39] <persia> Hey siji.  You7ve been looking for me when I haven't been around.
[07:39] <siji> persia, hi
[07:39] <siji> yes
[07:40] <siji> i have finished the xbmc build on natty
[07:40] <siji> but it's giving some runtime error
[07:40] <siji> python: can't open file '/usr/local/share/xbmc/FEH.py': [Errno 2] No such file or directory
[07:41] <persia> Is there some FEH.py file somewhere?
[07:41] <siji> frm xbmc IRC , they were telling that something wrong with build
[07:41] <siji> yes it's there
[07:41] <persia> Also, for questions like that, it's better to just ask the question, and whoever is around will answer.
[07:41] <persia> It's there, and in that location?
[07:41] <siji> yes I asked .. but no respond :(
[07:42] <siji> ya, but according to xmbc irc the build will never look for such file
[07:42] <siji> for starting xbmc
[07:42] <persia> Very strange.
[07:43] <siji> so i guess smthing is wrong in my conf. parameter
[07:43] <persia> It sometimes happens that things work differently, but usually that's intentional.  If upstream says the file should never be used, I'd recommend repeating the process of making it happen, documenting each step along the way, and submitting that as a bug upstream.
[07:43] <siji> persia, sure will do
[07:44] <persia> They might tell you something in Ubuntu is broken, but they'll probably tell you what is broken, and we can make sure that gets fixed.
[07:45] <siji> persia, just want to confirm my build process is also proper
[07:45] <persia> Alternately, they may find something broken in the configuration, or be surprised by some strange build process thing that only shows up if certain things are done.
[07:45] <siji> ya am trying to get some help frm xbmc developers
[07:45] <siji> regd.build process
[07:46] <siji> I have generated natty image using rootstock
[07:46] <siji> then frm the host PC chroot 'ed to that image and built xbmc there
[07:47] <siji> and make install  prefix folder copied to my beagleboard natty
[07:47] <siji> Hope this method will work
[07:48] <persia> It might.  I would have just built it on the beagleboard directly.  Fussing with some other computer can only complicate things.
[07:48] <siji> ok
[07:49] <siji> btw, will it possible to increase the natty image size
[07:49] <siji> in rootstock i have defined 1.2GB , now it's telling no space left
[07:49] <persia> Yeah, but.
[07:49] <siji> (anyway, i have started the rootstock with 8GB)
[07:50] <persia> You'd need to create a new image file, format it with a new filesystem, and move the files.
[07:50] <siji> persia, i think better to create new rootstock image right
[07:50] <persia> Certainly easier :)
[07:50] <siji> ok
[07:51] <siji> another doubt is about vdpau
[07:52] <siji> I have defined --disable vdapu , while building XBMC
[07:52] <siji> since it was giving some error which is related to this
[07:52] <siji> So this video decoder is necessary for omap ?
[07:52] <siji> or it's need only for nvidia
[07:54] <siji> cores/VideoRenderers/RenderManager.h: In member function ‘void CXBMCRenderManager::AddProcessor(CVDPAU*)’:
[07:54] <siji> cores/VideoRenderers/RenderManager.h:114:20: error: ‘class CLinuxRendererGLES’ has no member named ‘AddProcessor’
[07:54] <persia> No idea :)  I like to pretend all hardware is identical (although I'm not always successful)
[07:54] <siji> ok
[07:54] <siji> fine
[07:54] <persia> That looks like a more general error, that probably needs investigation.
[07:55] <siji> ok, it resolved by adding --disable-vdpau
[07:55] <persia> Maybe some issue with templates generation in preprocessing.  Maybe some ifdef that isn't clean on ARM.  But *something*, because that's the class of error that should make xbmc not work at all.
[07:56] <siji> persia, ok
[07:56] <persia> Well, it was hidden with --disable-vdpau.  Hidden and solved are different (although hidden is fine for most folk)
[07:56] <siji> ok :)
[08:07] <siji> persia, something off topic
[08:07] <siji> have you aware of exfat filesysem
[08:07] <siji> Which is patented my MicroSoft
[08:08] <siji> I read somewhere that samsung is paying 15$ per each phone to Microsoft , because of this filesystem
[08:12] <brendand> as far as i know the only thing special about it is that it's 64-bit
[08:13] <persia> I've never heard about it.
[08:13] <siji> oh I missed some point, this exfat is used by android I think
[09:05] <malfet> hi all
[09:05] <malfet> can somebody help me understand logic behind arm assembly sequence
[09:15] <janimo> malfet, which sequence in particular?
[09:16] <malfet> janimo, "mov     r2, sp; bic     r4, r2, #8128;  bic     r4, r4, #63; "
[09:16] <malfet> Why there are two bic instructions?
[09:17] <malfet> (code snippet about is from objdumped kernel_init)
[09:17] <janimo> malfet, the immediate values that can be put in bic (and other ARM intructions that accept such constants) are restricted
[09:17] <janimo> so they can be expressed in a limited number of bits
[09:18] <janimo> so if you want a value that is not expressible as a sum of power of twos you may need to use more than one instructions
[09:18] <malfet> oh, so bic is encoded as #BIC_OP|#REGA|#REGB|#IMM|#IMM_SHIFT?
[09:19] <janimo> malfet, do not know off the top of my head but since you are limited to 32 (or 16 for thumb) bits for an instruction you cannot fit a full 32 bit constant there as you need space for the opcode and other metadata
[09:19] <janimo> malfet, the ARM docs described this in much detail
[09:20] <janimo> so 8128 can be put there easily as it is exactly 2^13
[09:20] <janimo> well not exactly actually
[09:21] <malfet> janimo, got it. thanks a lot for explanaiton
[09:21] <janimo> malfet, was a bit vague but this is the general idea :)
[09:21] <malfet> forgot that all ARM instructions are conditional, so there is not enough space for 16-bit imm (like on ppc/mips)
[09:24] <janimo> malfet, right, after refreshing my memory, 12 bit values, but only those obtainable by a 8 bit value plus an up to 4 bit rotate
[09:25] <malfet> another newbie questions: r1-r3 doesn't have to be preserved across function calls?
[09:25] <malfet> or is it true only for aapcs abi?
[09:25] <janimo> malfet, are registers used for arguments, not preserved AFAIK. r0 is return value
[09:26] <janimo> this is what I know from the ABIs I used and from the asm code I saw
[09:26] <malfet> ok
[09:26] <janimo> I am not even sure anything is preserved automatically across calls. One needs to store load explicitly if needed
[09:27] <dmart> malfet, janimo: In Thumb-2 (i.e., on ARMv7) you can have most of the same immediate constants that you can have in ARM
[09:29] <malfet> looks like ABI mandates r4-r11 to be preserved across the calls
[09:29] <dmart> In Thumb-2, you can have constants of the form 000000xy 00xy00xy xy00xy00 and xyxyxyxy, as well as an 8-bit value shifted to any bit position.  However, Thumb-2 doesn't allow constants where the value is rotated across the end of the word (i.e,. 0xC000000E is allowed in ARM, but not in Thumb-2)
[09:30] <malfet> interesting
[09:30] <dmart> malfet: You can find docs describing the procedure call standard on infocenter.arm.com
[09:31] <malfet> reading thru it now
[09:31] <malfet> thanks
[09:32] <dmart> malfet: Your understanding sounds correct though -- across a function call, r4-r11,sp must be preserved; r0-r3,r12,lr can be clobbered; r0-r3 are used for arguments, r0 for the return (r0-r1 for 64-bit values).  Extra arguments are passed on the stack if needed
[13:26] <YuLin> Is there any existed directfb-ubuntu distro release?
[14:02] <ScottK> persia: I was wondering if you had any suggestions about how to pursue fixing https://launchpadlibrarian.net/75437592/buildlog_ubuntu-oneiric-armel.vlc_1.1.11-1ubuntu1_FAILEDTOBUILD.txt.gz
[15:38] <slangasek> rsalveti: hmm!  happy to follow, but I hadn't received any notice of the qemu-linaro release
[15:42] <rsalveti> slangasek: at linaro-announce, posted yesterday :-)
[15:42] <rsalveti> fresh news
[15:44] <slangasek> ah... not on that list, Peter has notified me directly in the past