Reload

**** BEGIN LOGGING AT Tue Jul 15 02:59:56 2008 Jul 15 03:03:03 are there plans to upgrade the Garage servers? Jul 15 03:08:32 Yes, rm_you. Jul 15 03:09:01 https://wiki.maemo.org/Task:Fast_Server Jul 15 03:09:15 Probably a month or so away Jul 15 03:09:22 dependent on the Finnish vacation period ending. Jul 15 03:13:13 how does one determine idle time on maemo? Jul 15 03:13:26 where idle time is the amount of time there hasn't been user input? Jul 15 03:22:10 normally on X, you would ask the xss Jul 15 03:24:19 rm_you: I'm thinking of reflashing my n800. You wrote earlier "you should flash now" "and then put your root on SD". Where is root-on-SD described? Jul 15 03:24:43 ~boot-sd Jul 15 03:24:44 rumour has it, boot-sd is https://wiki.maemo.org/Booting_from_a_flash_card Jul 15 03:25:06 thanks Jul 15 03:26:41 timeless: ^ Jul 15 04:27:35 what is the largest size media card you can buy for the n810? Jul 15 04:27:39 4gb? Jul 15 04:27:59 8GB currently Jul 15 04:28:04 Maybe 16GB now, actually. Jul 15 04:29:32 * dougt googles Jul 15 04:32:47 i wonder if fry's has any. Jul 15 04:32:53 * dougt will try tomorrow. Jul 15 04:37:09 hey GeneralAntilles, have you ever heard of a problem between the n810 devices and various routers? Jul 15 04:37:24 Crappy routers that don't properly support PSM, yes. Jul 15 04:37:30 PSM? Jul 15 04:37:36 power saving mode Jul 15 04:37:57 talk to me about this? i see this _ALL_OF_THE_TIME_ Jul 15 04:38:08 i am using a air port extreme. Jul 15 04:38:14 mac router. Jul 15 04:38:19 ahaha...ah, the pain of apple routers Jul 15 04:38:25 I had to deal with one at a previous job Jul 15 04:38:47 turn power saving on your n8x0 to "off" or "intermediate" in the connection settings -> advanced dialog Jul 15 04:38:59 Beware, it'll kill battery life. Jul 15 04:39:17 i don't care about battery life. Jul 15 04:39:22 or, replace your router Jul 15 04:39:27 yeah. Jul 15 04:39:31 draft-n is fast. Jul 15 04:39:47 but yeah. Jul 15 04:44:38 dougt, make sure your airport is up to the latest software/firmware version available for it, too Jul 15 04:45:15 thanks in advance guys. You have saved me a 2 minute walk daily from my desk to over where the router is. Jul 15 04:53:50 * dougt take thanks back! Jul 15 04:53:52 :-) Jul 15 06:10:54 GeneralAntilles: how do I repackage a deb file? I have the modified control and data tar.gz, what compression method is deb? Jul 15 06:17:57 oh man, defcon is making me cut it very close on funding Jul 15 06:18:58 jga23: ar -r packagename.deb debian-binary control.tar.gz data.tar.gz Jul 15 06:28:01 solmumaha: thanks Jul 15 06:34:14 solmumaha: the control.tar.gz has a . directory in there, how would I make an archive with that? Jul 15 06:34:49 solmumaha: basically what I'm trying to do is change the requirements for subversion to use libssl0.9.8 Jul 15 06:37:03 It may just be easier to recompile it in the diablo sdk: http://repository.maemo.org/extras/pool/chinook/free/source/s/subversion/ Jul 15 06:39:00 I haven't had a chance to set up my scratchbox on my new laptop Jul 15 06:41:18 My scratchbox is tied up atm, but here is the depends line changed from libssl0.9.7 to 0.9.8: http://www.mediafire.com/?z3byw2l9ewl Jul 15 06:41:31 You may need to symlink libssl if it doesn't work. Jul 15 06:44:36 thanks qwerty12 Jul 15 06:48:35 qwerty12: got it Jul 15 06:48:45 cool Jul 15 06:48:50 had to symlink libssl and libcrypto Jul 15 07:16:16 morning Jul 15 07:25:29 hello Jul 15 07:27:04 Guys - if anyone will be at Black Hat or Defcon and wants to meet with Maemo's Nokia side security guys, let me know. Jul 15 07:35:39 http://www.b3tards.com/u/aaeae71fb400d28f0864/crash800.jpg Jul 15 07:38:45 Deka: someone crashed against a Google tag? Jul 15 07:38:54 Ya Jul 15 07:39:33 lol Jul 15 07:39:52 Ya, those dang things are everywhere now Jul 15 07:41:06 I heard someone actually built one so that it is visible in aerial photos, so you can see it in the satellite view Jul 15 07:43:02 If you built, say decss or such or even cp big enough, would they censor it? Jul 15 07:44:20 or a copyright text Jul 15 07:45:02 Hrm, we could really use a Hacker Edition article for the wiki. Jul 15 07:51:56 Jaffa, poke. Jul 15 07:56:23 hi all, where I can find developer of gpe-pim for maemo? Jul 15 07:57:27 The packager should be in the pkg headers Jul 15 07:57:53 And devs in the sources Jul 15 07:59:23 (Graham Cobb?) Jul 15 07:59:52 do you know him? Jul 15 08:00:04 No Jul 15 08:00:07 XTLi: Graham visits this channel sometimes. Jul 15 08:00:26 XTLi: Do you have a maemo specific question/problem? Jul 15 08:00:43 No? Jul 15 08:00:57 Hrhr there asked Jul 15 08:00:59 Ehm, that was for hrhr ;) Jul 15 08:01:09 :) Jul 15 08:01:22 Sorry, pre-coffee here :D Jul 15 08:02:19 In-coffee + flapjack here :) Jul 15 08:02:48 Should start getting something done Jul 15 08:06:57 X-Fade, I think I want a .install for Extras-devel. Jul 15 08:07:15 GeneralAntilles: Look closer ;) Jul 15 08:07:41 GeneralAntilles: I think it is already there? Jul 15 08:08:14 https://garage.maemo.org/extras-assistant/install/extras-devel.install Jul 15 08:08:15 Not there Jul 15 08:08:20 * GeneralAntilles doesn't have better ideas. Jul 15 08:08:32 what is extras devel for? dev packages to compile on the NIT ? Jul 15 08:08:46 tank-man, it's a testing repository. Jul 15 08:08:56 alpha, pre-alpha and beta stuff. Jul 15 08:08:58 i see Jul 15 08:09:12 GeneralAntilles: It is there now ;) Jul 15 08:10:16 Perfect, thanks. Jul 15 08:12:26 X-Fade, crashanddie and jott were both asking about the possibility of using git for Garage projects. Jul 15 08:12:43 But since they're both too lazy to file an enhancement request like I told them to, I'm poking you directly. Jul 15 08:13:23 GeneralAntilles: That is a massive task.. Jul 15 08:14:05 Oh? Jul 15 08:14:55 Morning, all Jul 15 08:14:58 GeneralAntilles: Intergrate it in garage, sourcecode viewer, account management, security measures, commit mails etc.. Jul 15 08:15:16 And it's pointless toolwankery and advocacy. Jul 15 08:15:28 Ha Jul 15 08:15:33 For the purposes which Garage is intended for, svn is absolutely the right choice, IMHO Jul 15 08:15:46 Jaffa: Well, git itself is really cool when doing distributed development. Jul 15 08:16:07 And merging and tracking changes it a lot better than svn. Jul 15 08:16:30 X-Fade: but Garage isn't distributed development: it's centralised development (by defn) Jul 15 08:16:34 GeneralAntilles: you poked me, btw? Jul 15 08:16:51 Yeah, I'm just pondering over 770Flasher -> Tablet Flasher. Jul 15 08:17:04 Jaffa: Well, you can have a central branch. But git is really cool in preventing bitrot of a non-committed patch. Jul 15 08:17:26 GeneralAntilles: I'm playing with getting a small OS X partition up to do just that *cough* Jul 15 08:17:34 Ha Jul 15 08:17:45 But my previous efforts had no networking so it got blown away through misuse. Jul 15 08:18:09 If it works, I'll dust off XCode and try and even do it properly Jul 15 08:18:59 Ooh, fanoush is gonna open a Garage project for community kernels. Jul 15 08:19:10 GeneralAntilles: He already did. Jul 15 08:19:13 X-Fade: sorry, I have question about gpe contacts and it localization Jul 15 08:19:33 I'm not too keen on svn either. Jul 15 08:19:37 maemo.org has really been moving along nicely in the last few months. :D Jul 15 08:19:59 Seems it's a common choice. Certainy nicer than cvs in many ways Jul 15 08:20:00 hrhr: I think you can ask your question on -developers. Graham certainly reads that. Jul 15 08:20:53 Getting some prebuilt N800 and N810 kernels into Extra-devel would be pretty cool. Jul 15 09:21:32 * lcuk_work wiggles his wires about Jul 15 09:21:43 Anybody knows what the penalty for -mabi=softfp vs -mabi=hard is, when using -mfpu=vfp? Jul 15 09:22:17 zap, doesnt that depend upon the amount of fp you are doing in your program Jul 15 09:22:44 zap: yeah, depends on totally what you are doing, but: http://tuomas.kulve.fi/blog/2008/05/17/gcc-options-and-floating-point/ Jul 15 09:23:00 that does some very simple fp calculations only Jul 15 09:23:07 kulve: cool, I was looking for your page but forgot the url :) Jul 15 09:24:04 kulve, cool page :) Jul 15 09:24:12 kulve: hmm, why no benchmark for -mfpu-vfp -mabi=hard ? Jul 15 09:24:36 ah, I see: "vfp.c:1: sorry, unimplemented: -mfloat-abi=hard and VFP" Jul 15 09:24:41 %-O Jul 15 09:24:42 :) Jul 15 09:26:08 zap, with the thumb/full modes if i have a few modules with specific fp functions can i compile those modules using full vfp but leave the rest compiled to use thumb? Jul 15 09:26:13 if that makes sense Jul 15 09:26:34 I'm not sure fpu can be accessed in thumb mode Jul 15 09:27:14 thats what i mean, and thats the default for general code isnt it? smallest binary and all that Jul 15 09:28:10 hmmm i applied to Frantisek's kernel project at the garage (to become a member of the group) and i automatically became an admin Jul 15 09:28:13 is that normal? Jul 15 09:28:35 lol trickie, it depends what they accept you as Jul 15 09:28:44 i think i almost let GeneralAntilles become god Jul 15 09:28:50 he he Jul 15 09:29:11 trickie: No, the admin has to manually set your role. Jul 15 09:29:44 ok, so maybe he made me one... i have told him before that I have a few patches for the project Jul 15 09:30:05 lcuk_work: I don't have experience with thumb code anyway Jul 15 09:30:18 trickie: You could interpret it as a cry for help ;) Jul 15 09:30:20 but it's not default anyway Jul 15 09:30:25 trickie, patch the entire program with void main(){ while(1){ printf("Trickie rulez!!!\n"); } } Jul 15 09:30:37 he he Jul 15 09:30:57 X-Fade: yeah he seems busy now... got a new family member... Jul 15 09:31:04 ill try and get some time to put into it Jul 15 09:31:07 kulve: so it looks like there's no point to use -mfpu=vfp at all? Jul 15 09:31:35 trickie: It would be really cool if we can provide community kernels in extras-devel ;) Jul 15 09:31:45 for sure Jul 15 09:31:46 zap, i thought it was: at least for nokia released source - and the context switch between full/thumb takes time so its better to stay in thumb. not sure where i read that and i might be wrong Jul 15 09:32:04 zap: even if it's now default, it might not be in the next toolchain.. Jul 15 09:32:09 bbl Jul 15 09:32:09 lcuk_work: thumb mode has very limited use, and I never seen on any platform it to be the default Jul 15 09:32:45 lcuk_work: it's like 16-bit mode on x86; every CPU has it but almost nobody uses it Jul 15 09:32:58 thumb isnt limited, its simply 16bit opcode: like 68k. its just not got all the super cool do 10 related things per opcode stuff Jul 15 09:33:15 (that fullmode has) Jul 15 09:33:20 it is limited because you can access only R0-R7 in thumb mode Jul 15 09:33:30 and limited access to R14 and R15 Jul 15 09:33:31 exactly, like 68k Jul 15 09:33:43 well I don't know 68k Jul 15 09:34:04 * lcuk_work feels comfortable with thumb Jul 15 09:34:14 not being able to use all registers is what I call limited Jul 15 09:35:09 its very hard to make use of the 32bit opcodes to their fullest and so you still end up wasting time by needing to use 64bits of code to do what 32 would manage Jul 15 09:35:32 but anyway, i understand - when it works, it works well Jul 15 09:41:14 http://tuomas.kulve.fi/blog/2007/02/14/n800-and-gcc-options/ http://syslog.movial.fi/archives/46-N800-VFP-or-not-to-VFP.html Jul 15 10:01:07 lcuk_work: 90% applications will gain from more registers Jul 15 10:02:06 and 32-bit ARM has a very nice instruction set, don't see why not use it Jul 15 10:03:59 read the post i put, things use thumb by default Jul 15 10:04:15 ? Jul 15 10:04:23 this can't be true Jul 15 10:05:26 do a 'file /bin/busybox' Jul 15 10:05:40 it says ELF 32-bit LSB executable, ARM, blah Jul 15 10:06:05 although of course they could switch to thumb mode after init Jul 15 10:06:21 you can have an ELF with 32bit alignment by all means Jul 15 10:06:29 that does not mean the cpu operating mode Jul 15 10:07:01 32bit alignment was recommended even in amiga days, its simp[ly the fastest way to access memory Jul 15 10:07:01 hi, where can i get information about the different distributions? I have a new n810 with os2008, but not the newest. and i am totally confused Jul 15 10:07:43 lcuk_work: when it says 32-bit it means 32-bit instructions Jul 15 10:08:15 I think "recommended" is an understatement :-) Jul 15 10:08:16 On a 64-bit CPU: /bin/bash: ELF 64-bit LSB executable, x86-64 Jul 15 10:08:31 lol wnd Jul 15 10:08:43 lcuk_work: besides, looking at the file with my own eyes I clearly see it's not thumb Jul 15 10:09:30 zap, what file? its entirely possible things have changed since the kulve etc investigations up there Jul 15 10:09:38 /bin/busybox\ Jul 15 10:09:41 or you are looking at your own file Jul 15 10:09:59 hmm, the beginning looks ARM 32-bit but then comes something strange Jul 15 10:10:34 lcuk_work: file is a utility to determine file type Jul 15 10:11:09 prometoys, wikipedia is a good start. . . . Jul 15 10:11:32 yes, but i thought an ELF was a container file and the sections within contain different kinds of data: a 32bit ELF can contain data and code blocks using totally different modes Jul 15 10:13:05 yes thats true, and gcc mixes 32-bit and thumb code Jul 15 10:13:13 you can go back and forth at any point Jul 15 10:14:47 yes agreed: at the function level you can choose which mode it needs to be. but look at the links: when compiled in vfp (ie not thumb) things run a bit faster at the expense of memory and space. Jul 15 10:15:27 space is the big one here Jul 15 10:15:36 well at least I can say thumb is not the default for the compiler: the binaries compiled by me are clearly 32-bit Jul 15 10:16:42 if you are still looking at the container then yes, but i would hazard a guess that even a fully compiled thumb binary would be marked as 32bit Jul 15 10:17:21 nope, I'm looking at the hexdump of the executable (via mc on tablet). 32-bit code has a very specific look Jul 15 10:17:42 most 32-bit commands begins with E Jul 15 10:18:00 those are the condition bits iirc Jul 15 10:18:24 "I no longer really see the hex anymore. All I see is 32b, thumb, data..." Jul 15 10:18:41 did you see the woman in the red dress? Jul 15 10:19:09 get gcc to export asm and look properly, i gotta go Jul 15 10:19:43 maemopad+ is also pure 32-bit Jul 15 10:19:55 so even if busybox is thumb, it was explicitly set in gcc options Jul 15 10:20:35 libc is 32-bit as well Jul 15 10:40:07 "The VFP architecture also supports execution of short vector instructions allowing SIMD (Single Instruction Multiple Data) parallelism" Jul 15 10:40:16 damnit, what's the gain from DSP then :) Jul 15 10:46:36 Six legged robotic sheep with grass mowing jaws and gps Jul 15 10:46:57 Somehoe I already know how it is gonna end... Jul 15 10:47:30 is this a new Ultimate Weapon from Pentagon? Jul 15 10:48:11 we already seen the four-legged Dog That You Can Bump Jul 15 10:48:14 as long as the enemy is grass then the military will win ;) Jul 15 10:48:23 no, it is created by some arts prof from philadelphia Jul 15 10:48:44 zap, i agree by the way the SIMD instructions are cool Jul 15 10:48:51 reported to make "most amusing sounds" Jul 15 10:49:12 probably something like KILL ALL HUMANS Jul 15 10:49:47 lcuk: arm simd or intel simd? Jul 15 10:49:55 hehe Jul 15 10:50:05 "Do Androids Dream of Electric Sheep"? Jul 15 10:50:11 arm, if i could have used them simply my blitter would be even faster Jul 15 10:50:20 this is something to ask google about Jul 15 10:50:48 lcuk_work: DSP and CPU shares the same bus for access to video RAM? Jul 15 10:51:08 video ram is standard memory Jul 15 10:51:45 lcuk: I did not find them useful:( Jul 15 10:51:47 the lcd controller has DMA access to it (but its not quick enough) Jul 15 10:51:57 had to do blending but no luck Jul 15 10:52:38 RST38h, my blitter wanted to take the largest 128bit blocks first, followed by 64bits and continuing down to the last single byte Jul 15 10:52:46 mmmh, interesting if VFP registers can hold 64-bit integer values Jul 15 10:52:49 lcuk: the key question is how fast vram is? let us say you write a program in asm that reads 16kb in a loop 10000 time Jul 15 10:53:03 this would allow to push 64 bits at once over the bus, which could be a little faster than pushing 32 bits twice Jul 15 10:53:04 how long does it take vs sdram? Jul 15 10:53:09 every time i attempted to move more than 32bits software segfaulted Jul 15 10:53:29 what's vram? Jul 15 10:53:31 RST38h: these 16k will end up in CPU cache Jul 15 10:53:40 sdram is a "shitload" slower than the internal 2420 memory Jul 15 10:53:43 VRAM is video RAM - an old msx acronym :) Jul 15 10:53:44 zap: just learn to stmia :) Jul 15 10:53:58 zap: the on-omap stuff, or on the lcd controller though? Jul 15 10:54:01 zap: not if you read them randomly Jul 15 10:54:07 RST38h: I'm not sure stmia is anything more than several str's Jul 15 10:54:25 in fact reading them in 32-byte intervls should avoid cache Jul 15 10:54:28 you cannot "read" the data directly back from the lcd can you? its a consumer only Jul 15 10:54:37 zap: it is faster Jul 15 10:54:39 the only real benchmark Jul 15 10:54:45 RST38h: then cool Jul 15 10:54:54 lcuk_work: do you use stmia in your benchmark? Jul 15 10:54:59 is to map a certain memory size Jul 15 10:55:06 lcuk: shitload is how much? Jul 15 10:55:25 and the read/write through it, while incrementing the value you write into it Jul 15 10:55:26 2 times? 3 times? Jul 15 10:55:31 the 2420 has 5mb onboard memory that so far is essentially unused. i want to put the pvr/dsp/iva framebuffer there and blit out to main memory as required after processing Jul 15 10:55:41 zap, nope? Jul 15 10:55:49 how many cpu clocks does it take to fill a cache line from vram? Jul 15 10:55:54 lcuk_work: then possibly you could gain a couple extra FPS Jul 15 10:56:18 RST38h: lcuk says VRAM == RAM on OMAPs Jul 15 10:56:31 no i couldnt, even doing no drawing and just calling the framebuffer refresh ioctl gives 25fps Jul 15 10:56:34 zap: it is the same thing Jul 15 10:56:42 i get same if i draw the screen 4 times Jul 15 10:56:58 I am calling it vram because it is primarily used for screen buffer Jul 15 10:57:06 * lcuk_work is GPU constrained Jul 15 10:57:07 lcuk_work: framebuffer refresh is executed in fb driver? Jul 15 10:57:27 yes, the ioctl tells the LCD controller to start transferring data Jul 15 10:57:40 ? Jul 15 10:57:48 ah, I see Jul 15 10:58:10 so 25fps is the constraint of the LCD -> RAM bus Jul 15 10:58:20 not CPU -> RAM Jul 15 10:58:29 yes, anything faster and you overwrite memory and get tearing Jul 15 10:58:39 no, the cpu can draw the screen plenty fast enough Jul 15 10:58:55 tearing is fine Jul 15 10:59:00 so VRAM is actually not RAM, right? Jul 15 10:59:02 at least with me Jul 15 10:59:18 zap: you are mistaking several concepts Jul 15 10:59:26 I want to understand Jul 15 10:59:28 RST38h, :) depends on what you are doing of course. tearing with page of text is not acceptable Jul 15 10:59:35 I feel a broken ring in the chain somewhere Jul 15 10:59:45 a glitch in the matrix Jul 15 10:59:48 zap: 1. memory interface to cpu Jul 15 10:59:52 yes Jul 15 11:00:00 zap: 2. primary memory usage Jul 15 11:00:06 ? Jul 15 11:00:12 what you mean by this Jul 15 11:00:13 * lcuk_work goes again Jul 15 11:00:22 zap: 3. physical memory design Jul 15 11:01:14 anyone seen the doctor horrible thingy ? Jul 15 11:01:15 if I understand correctly, if there's some ioctl that tells the LCD controller to pump data out of RAM to video RAM, then video RAM is physically located elsewhere Jul 15 11:01:35 zap: in pc world there once was a fashion to call dual port sdram "vram@ Jul 15 11:01:36 zap, well, it wouldn't have to, per se Jul 15 11:01:52 otherwise the CPU could pump the data itself, and it would be faster Jul 15 11:02:11 zap: but for the rest of us vram is something that stores video buffer Jul 15 11:02:13 yeah, but that would use CPU cycles Jul 15 11:02:26 zap: hardware wise it is probably sram Jul 15 11:02:48 RST38h: you think it is mapped somewhere to physical address space? Jul 15 11:02:57 crashanddie: we could use DSP for that, for example Jul 15 11:03:10 although I have no idea how ti squeezed 5mb sram on chip Jul 15 11:03:18 zap, the LCD contains its own private memory and is not accessible from the omap2420 or any user software Jul 15 11:03:21 zap: it should be Jul 15 11:03:29 probably 0x05000000 Jul 15 11:03:39 it simply pulls a block of memory allocated from main memory Jul 15 11:03:44 that is where arms like to have video Jul 15 11:03:54 so RST38h contradicts what lcuk says Jul 15 11:04:11 I am making a conjecture Jul 15 11:04:21 lcuk may know better Jul 15 11:04:23 there is a block of normal memory allocated to act as a framebuffer though Jul 15 11:04:30 %-O Jul 15 11:04:34 this is the block the the LCD pulls from main memory and displays Jul 15 11:04:38 lcd memory is NOT omap vram Jul 15 11:04:45 lcuk_work: how often? Jul 15 11:04:54 everytime the ioctl is called Jul 15 11:05:26 okay so 'framebuffer' from CPU point of view is just a block of normal SRAM Jul 15 11:05:35 malloc'd Jul 15 11:05:56 then you just set up the LCD controller to copy data from here to its internal RAM Jul 15 11:05:57 right? Jul 15 11:06:09 normal standard data on the ddr as far as i know, the SRAM is internal to the 2420 and not used if i remember rightly Jul 15 11:06:55 hmm, if so, perhaps SRAM could be used for framebuffer :) Jul 15 11:07:10 this will give a whole 5 extra Mb to apps Jul 15 11:07:13 no because the LCD could not access it (since its outside the 2420 Jul 15 11:07:18 aha Jul 15 11:07:18 not malloced Jul 15 11:07:26 RST38h: kmalloc'd Jul 15 11:07:31 sram is at a fixed address Jul 15 11:07:47 BUT, if we can start to use the IVA and pvr i would like to use that 5mb as framebuffer and get the IVA pumping it back out so the lcd can see it Jul 15 11:08:10 ok, I'm going to try and interrupt a bluez developer conversation, so maybe they'll help me :P Jul 15 11:08:21 I would really like to use those 5mb as sram. can I ? Jul 15 11:08:25 crashanddie: put on your iron helm Jul 15 11:08:31 lcuk_work: That would then imply 2 sets of memcpy operations rather than 1 Jul 15 11:08:36 RST38h, i dunno, i was looking the other night Jul 15 11:08:49 zap, that's not exactly to help with bluetooth problems, is it :P Jul 15 11:08:54 its interesting in that its superquick and could be used to pull off some nice tricks Jul 15 11:09:23 crashanddie: that will minimize the radio noise, so perhaps it could Jul 15 11:09:24 lardman: what does it matter - the iva isnt used yet and we should be able to use that to transfer: we wouldnt be taking anything away from the system as it stands Jul 15 11:10:08 bluetooth is funny. Some people were talking about piconets with 8 computers and what not... Bloody hell, it's fucking hard enough to make more than 2 bluetooth things maintain a connection to eachother, let alone 7 Jul 15 11:10:10 hmm, if SRAM is just at a different physical address from DRAM, I don't see why kernel can't use it Jul 15 11:10:28 DRAM? Jul 15 11:10:30 yes, its an extra step, but would be worth doing: process 3d quickly into SRAM RGB buffer, use IVA to translate to YUV and push it into normal memory space, update LCD Jul 15 11:10:37 Where's the DRAM other than in the DSP? Jul 15 11:10:53 lardman: DRAM == DDR RAM in my case :) Jul 15 11:11:20 hmm, my mistake, I was thinking DARAM Jul 15 11:11:28 and is this talk of SRAM actually SARAM Jul 15 11:11:46 you wear pink DSP glasses Jul 15 11:12:03 lardman, i dont know its name: on the 2420 specs it says 5mb memory onboard for streaming multimedia app Jul 15 11:12:07 or something like that Jul 15 11:12:22 ok, so some random memory :) Jul 15 11:12:25 lcuk_work: thats what you were meaning as 5mb SRAM? Jul 15 11:12:34 5-Mb internal SRAM boosts streaming media performance Jul 15 11:12:37 yes Jul 15 11:12:39 5 mega bits that is Jul 15 11:12:41 http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=4671&navigationId=11990&templateId=6123 Jul 15 11:12:54 yes - its enough for a framebuffer whether bits or bytes Jul 15 11:13:17 I was refering about to an earlier comment about it being fitted on the chip Jul 15 11:13:26 s/about/back Jul 15 11:13:27 and as far as i can tell is just another under utilized piece of silicon Jul 15 11:13:55 so how do you use it? :-) Jul 15 11:14:22 i dunno yet Jul 15 11:14:31 ok so how I see it, even if we can use IVA, it will render to normal RAM, and then you have to tell LCD to pump data out to VRAM Jul 15 11:14:46 yes, with this hardware there is no way round that Jul 15 11:15:06 and DRAM -> LCD is bottlenecked at 25fps for a full frame? Jul 15 11:15:13 the "Display Controller" block is not used in N8x0, is it? Jul 15 11:15:20 no Jul 15 11:15:37 ShadowJK_, yes, a full YUV frame, important distinction Jul 15 11:15:41 zap: IVA doesn't render, it processes Jul 15 11:15:43 aj Jul 15 11:15:46 ah* Jul 15 11:15:53 lardman: how's that different? Jul 15 11:15:55 What's IVA? that powervr thing? Jul 15 11:15:59 oh Jul 15 11:16:06 indeed I was meaning powervr Jul 15 11:16:06 lcuk_work: look at the vanilla kernel source and see how they use the inbuilt framebuffer Jul 15 11:16:17 IVA is a image processor - it converts between formats ,it scales etc Jul 15 11:16:19 I'll be back Jul 15 11:16:20 ShadowJK_: Imaging Video Accelerator Jul 15 11:16:24 ah Jul 15 11:16:40 and it comes that with current hw architecture IVA is mostly useless as well? Jul 15 11:16:47 Is IVA what's used for Xvideo? Jul 15 11:16:51 yes Jul 15 11:16:58 ShadowJK_: it's a processor + hw coprocessors + some memory buffers to do various image/video processing (whatever you write the code for) Jul 15 11:17:09 ShadowJK_: but it's not used atm Jul 15 11:17:19 ah okay, the LCD does YUV->RGB too Jul 15 11:17:19 totally useless - but will be vital i think to getting the 3d RGB rendered frame out of 2420 and into main memory as YUV Jul 15 11:17:25 who handles YUV -> RGB then? Jul 15 11:17:28 ShadowJK_: no, the lcd controllercan do scaling and rotation and it's used Jul 15 11:17:28 aha Jul 15 11:17:46 hm Jul 15 11:17:52 IVA does YUV->RGB? Jul 15 11:18:02 ShadowJK_: whatever code you write Jul 15 11:18:05 IVA is designed for RGB->YUV Jul 15 11:18:16 hmm Jul 15 11:18:17 but no other way around? Jul 15 11:18:21 have a look lardman Jul 15 11:18:24 I think it was lcuk who said the LCD controller can take YUV? Jul 15 11:18:37 nice fast rgb<->yuv conversions built in Jul 15 11:18:38 ShadowJK_: yes, it can take a variety of formats Jul 15 11:18:48 lcuk_work: where are you reading this? Jul 15 11:19:07 well my logic is that if LCD controller is totally separate from the OMAP, then IVA won't gave too much gain Jul 15 11:19:18 Right, so you wouldn't want to use the IVA for YUV->RGB then, because that'd increase the amount of data you'd have to push through the bottleneck to the LCD Jul 15 11:19:37 you'd do RGB->YUV Jul 15 11:19:38 but you can use it for RGB -> YUV Jul 15 11:19:59 If you don't mind the chroma subsampling I guess :-) Jul 15 11:20:09 most users won't Jul 15 11:20:23 the pixels are so small anyway.. Jul 15 11:21:05 What other things except the powervr stuff is dead weight at the moment because of tight ass specs? :-) Jul 15 11:21:13 the IVA Jul 15 11:21:30 just finding it lard Jul 15 11:21:35 lcuk_work: np Jul 15 11:22:04 and perhaps the 5Mb SRAM lcuk is talking about? Jul 15 11:22:14 yes, that too Jul 15 11:22:26

Reload: