00:00:29 | | Quit S_a_i_n_t (Ping timeout: 268 seconds) |
00:02:25 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.18) |
00:02:59 | | Quit ender` (Quit: Connection Reset by Gypsies with Wire Cutters) |
00:20:25 | saratoga | the MS encoder can mix WMA Pro and WMA Voice into a single WMA file |
00:20:40 | saratoga | i guess switching between them as it goes |
00:34:28 | saratoga | mt: heres some sample WMA Pro files made from the rockbox test track: http://duke.edu/~mgg6/rockbox/wmapro/ |
00:34:54 | mt | saratoga: Thanks ! |
00:35:16 | saratoga | they're all wma pro 10 in 'quality vbr' mode and '24 bit' |
00:37:50 | mt | Is that encoder free to use ? I want to add some metadata and see how they're handled |
00:38:18 | saratoga | mt: yes its free |
00:38:37 | saratoga | theres a command line interface to it here: http://www.citizeninsomniac.com/WMV/#WMCmd |
00:39:07 | saratoga | you need to install the WME9 linked from that page before it'll work |
00:39:36 | saratoga | the command line tool can edit the metadata, but using WMP might be easier |
00:39:49 | saratoga | the command line tool is rather complicated to use |
00:40:38 | saratoga | the command i used to make those wma files was something like : cscript.exe Wmcmd.vbs -a_mode 2 -a_codec WMAPRO -a_setting Q95_44_2_ 24 -input sample.wav -output out.wma |
00:41:48 | | Quit MethoS- (Read error: Connection reset by peer) |
00:42:04 | saratoga | anyone with a coldfire player feel like testing something? |
00:44:02 | mt | saratoga: Thanks .. I'll try WME9 first |
00:45:17 | | Join MethoS- [0] (~clemens@134.102.106.250) |
00:45:58 | stripwax | saratoga - mmmm..? |
00:46:54 | saratoga | stripwax: would you try FS #11256 with this file: http://download.rockbox.org/test_files/true_audio.tta |
00:47:10 | saratoga | and report if it works (and if its real time) |
00:47:33 | | Quit Topy44 (Ping timeout: 248 seconds) |
00:48:11 | stripwax | ah, test and build .. don't have time right now to build anything. |
00:48:29 | saratoga | i can build it |
00:48:38 | saratoga | which player? |
00:48:39 | stripwax | i'd imagine it would be realtime on iriver h120, if it's 138% on ipod video |
00:48:51 | saratoga | yeah but its good to check for endianness too |
00:48:56 | stripwax | true |
00:50:02 | saratoga | code looks good, and hes properly scheduled for ARM9 in various places in the asm |
00:50:23 | stripwax | is that his asm? |
00:50:45 | saratoga | yeah |
00:51:09 | stripwax | is he ever around on irc? |
00:51:12 | saratoga | although I wonder if doing mla r1, r2, r3, r1 over and over again has a stall because r1 is accumulated from and to |
00:51:59 | saratoga | yeah last night |
00:52:11 | saratoga | hes in japan so about 3AM US time is best |
00:52:30 | saratoga | can you try an h120 build? |
00:53:00 | stripwax | yep, if you have it already. otherwise will have to wait (basically I'm going to bed) |
00:53:17 | saratoga | http://duke.edu/~mgg6/rockbox/rockbox.7z |
00:53:29 | mt | saratoga: Yeah, metadata tags are parsed properly. |
00:53:41 | saratoga | mt: sounds good |
00:54:13 | * | mt heads to sleep |
00:55:19 | amiconn | saratoga: Iirc arm9 and higher does special handling for back-to-back mla and friends |
00:55:49 | saratoga | amiconn: do you recall what the restrictions are? |
00:56:17 | amiconn | It's in the respective maunals (instruction cycles and interlocks) |
00:57:07 | saratoga | i think it should be ok, since the accumulate doesn't happen until after the stall for the multiply, so the registers should have already been updated |
00:57:27 | saratoga | for some reason i can never understand the arm reference manual's timing charts |
00:57:29 | stripwax | saratoga - is that .tta supposed to show up as "(ERR) true_audio" in the playlist viewer? |
00:57:41 | saratoga | no it should not |
00:58:04 | amiconn | (ERR) means the track couldn't be buffered successfully |
00:58:04 | saratoga | so it won't play at all? |
00:58:16 | | Join Topy44 [0] (~topy@my.fastsh.it) |
00:58:28 | saratoga | did i pick the wrong memory size for your player somehow? |
00:58:44 | stripwax | nothing happens when I play that track |
00:58:49 | amiconn | My guess is a problem with metadata reading |
00:58:50 | stripwax | everything else seems to work fine |
00:59:19 | saratoga | ok so probably some kind of endianness issue |
00:59:27 | amiconn | Probably endian related |
00:59:35 | stripwax | seems to have killed database update also, from the way the disk is flashing, it's in a loop |
00:59:35 | * | amiconn slow |
00:59:49 | saratoga | not surprising given that its an x86 oriented codec |
01:00 |
01:01:04 | stripwax | what endianness does ipod have? |
01:01:19 | saratoga | little |
01:01:29 | saratoga | almost all arm devices are little, just like x86 |
01:01:53 | saratoga | so actually pretty soon everything will be little endian and we won't have to care anymore |
01:02:29 | | Quit Topy44 (Ping timeout: 248 seconds) |
01:02:56 | saratoga | tta uses ID3 for metadata, so that should be endian safe |
01:04:58 | * | amiconn has a suspicion |
01:05:38 | amiconn | apps/metadata/tta.c already uses get_long_le() resp. get_short_le() |
01:05:57 | amiconn | An extra letoh16() resp. letoh32() will make the result wrong on big endian |
01:06:09 | stripwax | ping me if you have a fix you would like me to test. I might not be around on irc much this week but i'll check the logs |
01:06:19 | | Quit stripwax (Read error: Connection reset by peer) |
01:06:24 | amiconn | But that's exactly what that patch is doing when processing the tta header |
01:08:14 | saratoga | amiconn: so what, drop the letoh16 from the channels and bps parse? |
01:09:24 | amiconn | From channels, frequency, length, bps... everything that uses GET_HEADER() |
01:10:00 | jhMikeS | Llorean: what do you mean? at this moment the auto-speed has no explicit setting available to code but it could. there are bits that can be set by software that are interpreted by DVFS as CPU load. |
01:10:38 | amiconn | That also includes ID, further up |
01:12:27 | * | amiconn guesses the thing won't be realtime on cf as-is |
01:13:24 | * | S_a_i_n_t wonders what the Fuze runs at boosted out of interest... |
01:13:34 | saratoga | 248MHz IIRC |
01:13:36 | | Join Topy44 [0] (~topy@my.fastsh.it) |
01:13:40 | S_a_i_n_t | thankyou. |
01:13:44 | saratoga | or 240 if its a v2 |
01:14:12 | saratoga | stripwax: (for the logs) can you try this test build http://duke.edu/~mgg6/rockbox/rockbox-h1x0.7z |
01:14:21 | saratoga | or anyone else who feels like testing on coldfire |
01:14:36 | S_a_i_n_t | just wondering about the guy on the forums that puts Rockboy problems solely down to boosting. |
01:14:44 | S_a_i_n_t | Shouldn't it run boosted anyway? |
01:15:05 | amiconn | The filter is something where cf emac should help a lot |
01:20:09 | S_a_i_n_t | (clarify) Errrr, lack of boosting rather. |
01:20:24 | saratoga | S_a_i_n_t: yes, looking at the code one of the first things it does is boost |
01:21:58 | S_a_i_n_t | I thought so, but I can't look at my checkout from here abd didn't wanna say "Um, you're crazy" without conforming it forst. |
01:22:14 | amiconn | If the filter values (except sum) stay within 16 bit range, speed could be improved even further on cf and armv6+ |
01:22:20 | S_a_i_n_t | -spelling errors :) |
01:23:57 | | Quit DerPapst (Ping timeout: 276 seconds) |
01:23:59 | amiconn | That's the opposite of what I did with the ape filters. They were 16 bit to begin with - I changed that to 32 bit for armv4 only (because on armv4 the unstuffing consumes more cycles than what is saved by loading only half the amount of data) |
01:24:32 | S_a_i_n_t | I don't think I've ever seen rockboy running what I'd call "fine", so I think he may just be remembering things wrong, or playing GameBoy on a DAP was a new & exciting thing and didn't seem as choppy as it actually is. Especially saying the sound was fine seemed weird to me, I find even if the fps is good the sound is terrible. |
01:26:36 | | Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
01:27:53 | saratoga | so no one is around who can test a CF build? |
01:30:32 | | Join DerPapst [0] (~Alexander@p5797CBFB.dip.t-dialin.net) |
01:30:57 | | Quit mikroflops_ (Ping timeout: 260 seconds) |
01:38:44 | | Quit DerPapst (Quit: Leaving.) |
01:42:54 | | Quit bieber (Remote host closed the connection) |
01:43:57 | | Quit krazykit (Read error: Connection reset by peer) |
01:47:44 | | Join krazykit [0] (~kkit@adsl-76-251-232-26.dsl.ipltin.sbcglobal.net) |
01:47:53 | *** | Saving seen data "./dancer.seen" |
01:53:58 | | Join kushal [0] (~kushal@12.238.101.250) |
01:56:14 | | Quit kugel (Remote host closed the connection) |
01:59:30 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
02:00 |
02:11:56 | | Quit liar (Ping timeout: 252 seconds) |
02:17:50 | | Quit kushal (Quit: Ex-Chat) |
02:19:16 | S_a_i_n_t | JdGordon: Going through the logs...not *so* much a fan of the "%Xx[x]" idea myself, but I can see where it would help readability...and probably make it a lot easier to parse. |
02:19:47 | S_a_i_n_t | I'm just *so* used to "%Xxx" now, it would take some major getting used to. |
02:24:51 | | Join Rob2223 [0] (~Miranda@p4FDCA3A7.dip.t-dialin.net) |
02:25:36 | | Quit efyx (Remote host closed the connection) |
02:28:22 | | Quit krabador (Remote host closed the connection) |
02:28:40 | | Quit Rob2222 (Ping timeout: 265 seconds) |
02:31:29 | | Quit M3DLG (Quit: RAGE QUIT) |
02:34:23 | S_a_i_n_t | Though, I guess...if it's going to happen, [ ]'s are probably the most sensible container for the tags. |
02:34:42 | S_a_i_n_t | s/sensible/readable/ |
02:46:28 | | Join flatrose [0] (~flatrose@ppp91-77-234-156.pppoe.mtu-net.ru) |
02:49:43 | | Join kio [0] (~kyonos@ool-4577aad5.dyn.optonline.net) |
02:50:44 | | Quit ps-auxw (Ping timeout: 248 seconds) |
02:55:11 | | Join TechnoKat [0] (~TechnoCat@c-98-223-163-190.hsd1.in.comcast.net) |
03:00 |
03:00:48 | | Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) |
03:05:44 | | Join hebz0rl_ [0] (~hebz0rl@dslb-088-065-218-109.pools.arcor-ip.net) |
03:08:11 | | Join ischeria1 [0] (~ischeriad@p5B0A0ECA.dip0.t-ipconnect.de) |
03:09:15 | | Quit hebz0rl (Ping timeout: 264 seconds) |
03:11:19 | | Quit ischeriad (Ping timeout: 252 seconds) |
03:15:24 | | Join itsnotabigtruck [0] (~itsnotabi@mcn21551.urh.illinois.edu) |
03:16:27 | itsnotabigtruck | not a lot going on here atm, eh |
03:16:41 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
03:24:46 | | Part itsnotabigtruck |
03:26:18 | | Quit jhulst (Quit: Read error: EOF) |
03:33:58 | | Quit flatrose (Remote host closed the connection) |
03:38:43 | Llorean | jhMikeS: I was noticing in one plugin (fft) that the speed changing seemed visible - the scrolling wouldn't move at a constant speed. I'm not sure if that was because of the auto-speed or not though, but I seem to remember it scrolling smoothly before, so I was wondering if that might be the case. |
03:43:35 | n1s | saratoga: fwiw on arm1136 (the beast) mla takes 2 cycles and has 4 cycle result latency but the manual states that "For a subsequent multiply accumulate the result is available one cycle earlier than for all other uses of the result." so to me it sounds like a one cycle stall between consecutive mla instrs |
03:45:23 | saratoga | n1s: so theres one cycle stall (i guess due to the 16 bit wide multiplier) and then immediately after that the multiplier can be used to evaluate the last product? |
03:45:43 | | Join Boldfilter [0] (~Boldfilte@adsl-178-248-46.jax.bellsouth.net) |
03:47:55 | *** | Saving seen data "./dancer.seen" |
03:49:52 | n1s | hmm, but Rn is also a late reg and not required untill the second cycle of the instr so if you just do straight multiply-accumulate into the same reg it should be stall free |
03:50:13 | n1s | yeah, pretty sure it's not staling on arm11 at least |
03:50:15 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
03:50:58 | saratoga | n1s: its weird arm doesn't distribute some kind of calculator tool for these things that will tell you how many cycles something would take on a given core |
03:51:02 | saratoga | i've seen them for mips |
03:51:18 | n1s | that would be very nice indeed |
03:51:29 | | Quit adnyxo (Ping timeout: 276 seconds) |
03:55:24 | n1s | arm9E seems to be the same and arm9tdmi the same as arm7tdmi as far as mla timings and interlocks |
03:55:51 | | Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) |
03:55:52 | n1s | eh arm9E seems to be the same as arm11, in this regard |
03:55:54 | saratoga | n1s: arm9E has the mutliplier from arm11 |
03:56:01 | n1s | makes sense |
03:56:33 | saratoga | yeah >= 9E has the 16 bit multiplier, while arm7tMi has the "fast M" multiplier which is actually a really slow 8 bit one |
03:56:50 | saratoga | donno when they finally designed a 32 bit |
03:56:53 | saratoga | multiplier |
03:57:07 | n1s | maybe that's in v7? |
04:00 |
04:01:01 | | Quit kio (Quit: Leaving) |
04:04:45 | | Quit pixelma (Disconnected by services) |
04:04:46 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
04:04:49 | | Quit amiconn (Disconnected by services) |
04:04:51 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
04:05:05 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
04:05:13 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
04:10:30 | | Quit Blue_Dude (Ping timeout: 260 seconds) |
04:10:59 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
04:23:39 | jhMikeS | Llorean: In FFT the spectral view jittered even before the auto speed was implemented. It's easy to disable in kernel-gigabeat-s.c (remove dvfs_dptc_start) just to prove it. :) |
04:24:29 | | Part TechnoKat ("Leaving") |
04:26:13 | Llorean | jhMikeS: Okay. It just seemed really noticeable to me and I didn't seem to remember it before. But I'll take your word for it. :) |
04:28:10 | jhMikeS | I don't think it's the auto speed doing that. |
04:29:06 | Llorean | Okay. |
04:29:07 | * | jhMikeS is repeating himself for some reason :\ |
04:30:55 | Llorean | Other than that the S seems to be working better than ever. :) |
04:31:43 | * | jhMikeS likes good news :) |
04:37:17 | * | jhMikeS will double check this little fft thing |
04:43:42 | jhMikeS | still jitters the same fixed at 264 |
04:43:50 | Llorean | Okay |
04:44:34 | | Quit TheSeven (Ping timeout: 260 seconds) |
04:48:07 | | Quit MethoS- (Read error: Connection reset by peer) |
04:48:09 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
04:48:38 | | Part Boldfilter |
04:48:53 | | Join Forsaken_Boy [0] (~chatzilla@24.139.156.136) |
04:48:55 | | Nick Forsaken_Boy is now known as Forsaken (~chatzilla@24.139.156.136) |
04:51:36 | | Quit Forsaken (Client Quit) |
04:58:53 | | Join Barahir_ [0] (~jonathan@frnk-590fc9a3.pool.mediaWays.net) |
05:00 |
05:02:01 | | Quit Barahir (Ping timeout: 240 seconds) |
05:04:36 | | Quit S_a_i_n_t () |
05:08:41 | | Quit hebz0rl_ (Quit: Ex-Chat) |
05:15:14 | | Join Forsaken [0] (~chatzilla@24.139.156.136) |
05:20:51 | | Join funman [0] (~fun@rockbox/developer/funman) |
05:23:36 | funman | mt: you can change a commit log with svn properties |
05:36:45 | | Quit Horscht (Quit: Verlassend) |
05:41:16 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.18) |
05:47:59 | *** | Saving seen data "./dancer.seen" |
05:49:20 | CIA-5 | New commit by funman (r25924): as3525v2: disable adjustable CPU frequency ... |
05:51:54 | | Join itsnotabigtruck [0] (~itsnotabi@mcn21551.urh.illinois.edu) |
05:57:00 | | Quit Strife89 (Quit: Bedtime! XD) |
05:58:51 | itsnotabigtruck | anyone here? |
06:00 |
06:03:29 | S_a_i_n_t | 117 people in fact |
06:03:43 | itsnotabigtruck | 116 of which are idling :p |
06:03:54 | itsnotabigtruck | anyway, i'm itsnotabigtruck from the openzdk crew |
06:03:56 | Llorean | itsnotabigtruck: Well you haven't asked an on-topic question |
06:04:05 | Llorean | You can't expect 40 people who may be around to all say "yes" any time someone askes that. |
06:04:46 | itsnotabigtruck | and it appears there was a bit of talk after our launch about porting rockbox to gen1 zunes |
06:05:04 | Llorean | There's definitely some interest in it, though I don't think any developer has actually expressed a desire to work on it yet. |
06:05:25 | itsnotabigtruck | and thought i'd check in and see if anyone has done any experimentation w/r/t a port of rockbox targeting the zune 30 (or at least getting it out of wince, anyway) |
06:05:28 | Llorean | The main question was whether a bootloader was possible, since it seems possible a lot of our GigabeatS port code might provide a good starting place if one is. |
06:06:19 | itsnotabigtruck | you were one of the people who dropped by #zbdf a couple weeks ago, right? @llorean |
06:06:34 | S_a_i_n_t | *ahem*...OFFTOPIC |
06:06:46 | funman | itsnotabigtruck: can you run code in supervisor mode? |
06:07:08 | itsnotabigtruck | you can definitely run code in kernel mode |
06:07:19 | itsnotabigtruck | in wince 5.0 that's as simple as an api call (SetKMode(TRUE)) |
06:08:16 | itsnotabigtruck | not sure if that's quite the same thing |
06:09:35 | Llorean | itsnotabigtruck: Last I'd heard HaRET was still of interest, but that someone had made a basic attempt at using it and failed. |
06:10:22 | itsnotabigtruck | zivan56? |
06:11:11 | itsnotabigtruck | he didn't give a lot of detail about what he actually did in testing |
06:11:20 | Llorean | I don't remember who. |
06:11:24 | Llorean | I just remember seeing it mentioned. |
06:11:37 | itsnotabigtruck | http://forums.rockbox.org/index.php?topic=24538.msg165856#msg165856 this post right here |
06:11:38 | Llorean | My interest is pretty casual - I don't own one and am pretty satisfied with my existing pile of players. |
06:11:46 | itsnotabigtruck | heh, fair enough |
06:12:54 | funman | itsnotabigtruck: you can check the CPU mode from CPSR |
06:13:50 | itsnotabigtruck | i'm not too experienced with that area @funman but i can only assume that once you're in the kernel then getting into supervisor mode wouldn't be much of a problem |
06:14:17 | itsnotabigtruck | unless the os runs outside of supervisor mode (?) |
06:15:36 | itsnotabigtruck | i don't have a working zune 30 anymore so i can't test directly, i do have an hd however (which has an apx2600 and ce6 vs an i.mx31L and ce5) |
06:15:45 | | Quit Forsaken (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) |
06:15:59 | topik | funman: does it matter if i run a current svn bootloader for the clip+ or should i revert to something older to get rid of the many crashes i'm having? |
06:17:56 | funman | topik: bootloader should have no effect |
06:18:53 | funman | itsnotabigtruck: i suppose kernel mode is supervisor mode, just wanted to confirm |
06:19:19 | itsnotabigtruck | it might not be @funman, i'm doing a bit of research atm |
06:19:39 | topik | ok, will update to 25924 now. hopefully it will cut down on the 'undefined instruction' and 'data abort' festival i had yesterday |
06:19:41 | funman | topik: you mean r25900 caused new problems ? |
06:20:01 | topik | i posted some of the errors i had to the forum yesterday |
06:20:22 | itsnotabigtruck | anyhow, clearly apps like haret work on ce5, and i suppose that's what matters |
06:20:53 | funman | topik: which nick do you use on the forum? |
06:21:04 | topik | 7o9 |
06:21:11 | funman | itsnotabigtruck: what's haret? |
06:21:22 | Llorean | funman: HaRET is a Linux bootloader for CE5 |
06:21:36 | Llorean | It's used to boot Linux on several windows mobile PDAs/Phones |
06:21:48 | Llorean | Rebooting from within the OS even. |
06:21:50 | funman | topik: well these errors are not new |
06:22:02 | topik | the amount of it are new to me |
06:22:21 | funman | topik: just see if you still have problems with last commit |
06:22:32 | topik | yep, installing now. will report my experiences |
06:23:17 | funman | Llorean: itsnotabigtruck: well then i guess next step for rockbox on zune is to write a bootloader (or modify haret to load a rockbox binary?) |
06:23:42 | funman | itsnotabigtruck: can you read original zune firmware, to reverse engineer needed drivers? (like lcd) |
06:24:23 | itsnotabigtruck | yep @funman there's a firmware dump guide with download links on the zune dev wiki @ http://zunedevwiki.org/wiki/development/firmware_dump |
06:24:26 | saratoga | assuming its the older Zunes, we've already got drivers for them |
06:24:41 | saratoga | the original zune uses nearly identical hardware as the gigabeat S |
06:25:13 | Llorean | saratoga: The older Zunes are the only ones where there's kernel mode access currently (unless the situation as changed) so are the most likely target between the two anyway. |
06:25:34 | itsnotabigtruck | @llorean you can still access kernel mode on the hd, it's just more complicated |
06:25:43 | Llorean | itsnotabigtruck: Ah, last I'd heard it was only user mode. |
06:25:45 | itsnotabigtruck | you have to make and load a driver (a la windows proper) |
06:26:01 | saratoga | the drivers don't need to be signed? |
06:26:11 | itsnotabigtruck | nope |
06:26:50 | n1s | heh |
06:28:20 | itsnotabigtruck | also haret already exists for ce5, whereas it would require extensive mods for ce6 |
06:28:33 | itsnotabigtruck | as the kernel was pretty much completely redone |
06:28:57 | saratoga | what does haret actually do? |
06:30:00 | S_a_i_n_t | JdGordon: Around? |
06:30:09 | saratoga | i assumed that once you had root access the kernel doesn't matter at all, since you're just going to blow it away and reinit the hardware yourself |
06:30:17 | itsnotabigtruck | i haven't really examined the source but afaik it puts itself into kernel mode, loads the zimage into ram, cleans up the processor state and jumps into the image |
06:30:41 | itsnotabigtruck | it also has various commands for scribbling into ram interactively etc. |
06:32:12 | funman | saratoga: root access is still usermode |
06:32:44 | saratoga | so root != kernel mode? |
06:33:14 | itsnotabigtruck | well ce doesn't really have any concept of user accounts so there really isn't such a thing as root |
06:33:47 | itsnotabigtruck | on ce5 there's untrusted and trusted mode, as far as i can tell everything runs in trusted mode |
06:34:31 | S_a_i_n_t | Torne: In the past two days I've had about 10 instances of "Need to hard-reset to turn the player on", which to me is *really* odd. |
06:35:01 | funman | saratoga: nope, for example on linux root can be forbidden to do some kernel stuff (like loading new modules) |
06:35:31 | itsnotabigtruck | interesting, i wasn't aware of that |
06:38:42 | joeyg | the SDCFG value i found to use tcctool with the cowon s9 was incorrect |
06:38:47 | joeyg | i found a working one |
06:38:55 | joeyg | who should i contact to get tcctool updated quickly? |
06:39:01 | joeyg | or should i just submit a patch myself? |
06:39:23 | joeyg | for the log-searchers, the correct value was 0xaaac7800 |
06:39:27 | S_a_i_n_t | linuxstb is the tcctool guy AFAIK |
06:42:05 | funman | joeyg: so how did it work if it was incorrect? |
06:42:39 | | Quit n1s (Quit: Lämnar) |
06:43:03 | joeyg | not sure, must have been a fluke |
06:43:37 | joeyg | my timing values were incorrect, but for some reason i was able to unbrick my S9 the first time |
06:44:21 | | Quit joeyg (Quit: blew out my kernel, have to reboot) |
06:45:04 | itsnotabigtruck | anyway, does anyone here have a 1st/2nd gen zune that they're interested in experimenting on? |
06:45:20 | funman | itsnotabigtruck: perhaps it's best to ask on the forum ? |
06:45:27 | itsnotabigtruck | probably doesn't help that ms only sold them in the us and canada, and i get the impression that much of the rockbox dev effort is concentrated outside of north america |
06:45:33 | itsnotabigtruck | true, true |
06:46:56 | | Join apoelstra [0] (~apoelstra@S010600236999fec1.vs.shawcable.net) |
06:47:01 | | Nick apoelstra is now known as joeyg (~apoelstra@S010600236999fec1.vs.shawcable.net) |
06:48:36 | funman | you want to turn existing zune owners into rockbox developers, not the reverse ;) |
06:49:23 | itsnotabigtruck | i know i'm not extremely interested in experimenting on my hardware, i already killed one z30 with haret :p |
06:50:33 | itsnotabigtruck | besides, i'm far more knowledgable re user mode development, i.e. not hacking on bootloaders :( |
06:54:36 | | Quit CaptainKewl (Remote host closed the connection) |
07:00 |
07:02:38 | | Quit saratoga (Quit: Page closed) |
07:05:41 | | Quit bmbl (Quit: Bye!) |
07:10:45 | | Join Buschel [0] (~ab@p54A3EAA9.dip.t-dialin.net) |
07:15:56 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
07:16:07 | | Join esperegu [0] (~quassel@145.116.15.244) |
07:19:45 | | Part itsnotabigtruck |
07:20:39 | pixelma | funman: AFAIK changing a commit message afterwards needs the svn post commit hook enabled/installed/whatever and I only saw talk that this is not the case for Rockbox SVN if things haven't changed lately |
07:21:49 | funman | pixelma: there's no link with post commit hooks, but some features need to be enabled: http://subversion.apache.org/faq.html#change-log-msg |
07:22:30 | funman | there is a post commit hook already, it's the thing which sends the email, trigger new builds, and causes 'svn commit' not to return immediately |
07:23:33 | funman | ah it's the "pre-revprop-change" hook |
07:23:39 | funman | (which needs to be enabled) |
07:40:24 | | Join stoffel [0] (~quassel@p57B4AA54.dip.t-dialin.net) |
07:48:00 | *** | Saving seen data "./dancer.seen" |
07:52:35 | | Join Forsaken [0] (~chatzilla@24.139.156.136) |
07:53:42 | | Quit Forsaken (Client Quit) |
07:55:00 | topik | funman: seems my clip+ is a lot more stable now. it's been running for an hour and a half which is a record in recent history |
07:57:42 | funman | seems to work here too, let's wait some days |
07:58:17 | funman | i committed this because I have seen crashes with CPU boosted. Although there could have been a bug which caused the counter to reach 0 and cause boosting/unboosting cycles again |
08:00 |
08:00:19 | | Quit Buschel () |
08:03:28 | | Quit antil33t (Read error: Connection reset by peer) |
08:03:31 | linuxstb | joeyg: I've built a new Windows tcctool binary with that SDCFG value - http://linuxstb.cream.org/tcctool.exe Has anyone apart from you successfully used that value yet? |
08:12:18 | | Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) |
08:13:30 | | Join bmbl [0] (~Miranda@vpn224-97.fh-bielefeld.de) |
08:13:31 | | Quit bmbl (Changing host) |
08:13:31 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
08:16:18 | | Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
08:21:07 | topik | it does seem power consumption is a lot higher though |
08:21:44 | funman | topik: afaik it should reduce runtime from 19h~ to 15h~ |
08:22:12 | funman | i'm running benches on all models, both to see the consumption and to see if they succeed without crashing at all |
08:25:47 | | Join ender` [0] (krneki@foo.eternallybored.org) |
08:28:11 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
08:34:21 | | Quit esperegu (Ping timeout: 240 seconds) |
08:39:23 | amiconn | Hmm, no saratoga nor stripwax :\ |
08:39:32 | | Join esperegu [0] (~quassel@145.116.15.244) |
08:49:43 | | Join petur [0] (~petur@rockbox/developer/petur) |
08:56:40 | | Join Orion777 [0] (~IceChat7@c-71-204-140-208.hsd1.ca.comcast.net) |
08:58:13 | | Quit funman (Quit: free(random());) |
08:58:22 | Orion777 | will rockbox affect the songs already on my player |
08:58:41 | Llorean | Not normally unless it's an apple formatted ipod that needs reformatting |
08:59:21 | Orion777 | what about a partially support one. |
08:59:32 | linuxstb | Orion777: What player have you got? |
08:59:34 | Orion777 | i have a fuze v2 and there's been alot of progress |
08:59:52 | Orion777 | just wondering if i can go back to OF without problems |
09:00 |
09:00:02 | Orion777 | so i don't have to transfer all my songs to the hd and back |
09:00:07 | linuxstb | Things should be OK, but it's always wise to have a backup of your music files... |
09:01:03 | Orion777 | if its dual boot now that means i can use rockbox or normal |
09:01:13 | Orion777 | the normal menus for my player |
09:01:22 | linuxstb | Yes |
09:01:43 | Orion777 | is the rockbox eq better than the standard eq usually |
09:02:10 | Orion777 | mainly i'm trying to improve the sound |
09:02:53 | scorche | it is generally much more customisable than "standard EQs" |
09:02:55 | linuxstb | Probably only you can say if the Rockbox EQ sounds better. It's likely to be different to Sandisks's though... |
09:05:34 | | Join flydutch [0] (~flydutch@host224-59-dynamic.5-87-r.retail.telecomitalia.it) |
09:06:43 | | Quit esperegu (Read error: Connection reset by peer) |
09:07:10 | * | amiconn 's guesstimation from last night turned out to be correct |
09:07:22 | | Join esperegu [0] (~quassel@145.116.15.244) |
09:08:48 | | Quit esperegu (Remote host closed the connection) |
09:10:31 | | Join B4gder [0] (~daniel@rockbox/developer/bagder) |
09:19:58 | | Join DerPapst [0] (~Alexander@dslb-088-069-158-132.pools.arcor-ip.net) |
09:29:33 | | Quit Orion777 (Ping timeout: 246 seconds) |
09:33:04 | | Quit arbingordon (Quit: `) |
09:33:42 | | Quit BHSPitMonkey (Quit: Ex-Chat) |
09:40:42 | | Join solexx [0] (~jrschulz@e176113172.adsl.alicedsl.de) |
09:41:19 | | Quit solexx_ (Read error: Operation timed out) |
09:42:08 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
09:48:03 | *** | Saving seen data "./dancer.seen" |
09:49:14 | | Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) |
09:51:02 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
09:57:12 | | Quit stoffel (Ping timeout: 246 seconds) |
09:58:24 | | Join |DaMaGeD| [0] (~dam@85.26.234.193) |
09:59:19 | | Quit |DaMaGeD| (Client Quit) |
10:00 |
10:01:29 | | Join loveless [0] (~loveless@2a01:198:3a5:0:216:cbff:feb9:8c8d) |
10:03:41 | | Join KoRn_Thoughtless [0] (~korn_thou@c-24-20-222-88.hsd1.or.comcast.net) |
10:16:30 | | Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) |
10:24:51 | | Quit Kitar|st (Ping timeout: 240 seconds) |
10:30:47 | | Join Kitar|st [0] (~Kitar_st@BSN-182-88-133.dial-up.dsl.siol.net) |
10:37:10 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
10:40:25 | | Join funman [0] (~fun@rockbox/developer/funman) |
10:43:38 | pamaury | I hate how MTP breaks at each new release of {libmtp,ubuntu,fucking-dbus-stupidity,rythmbox} ! |
10:44:43 | Zagor | which breaks? rockbox mtp or linux mtp? |
10:45:26 | scorche | Zagor: i may be having a brain freeze here, but has anything happened with regards to mentor summit reimbursement? |
10:45:52 | pamaury | Zagor: I don't know ! I'm investigating :( |
10:45:56 | funman | i would guess the 'industry standard test' for MTP is "does windows media player work with it?" |
10:46:20 | Zagor | scorche: I was under the impression we finished that up a while ago? |
10:46:48 | | Quit mt (Ping timeout: 252 seconds) |
10:46:50 | scorche | Zagor: we could have, but i seem to not remember that at the moment - could be i just need to sleep |
10:47:51 | dfkt | linuxstb: http://iaudiophile.net/forums/showpost.php?p=290739&postcount=49 <−− not sure what to make of that... |
10:48:37 | scorche | Zagor: i dont see it in my paypal, at least...do you recall the means used to transfer the reimbursement? |
10:48:55 | funman | dfkt: joeyg already reported it this morning |
10:49:02 | Zagor | scorche: I think we did a bank transfer |
10:49:07 | dfkt | funman, ah ok |
10:49:12 | linuxstb | dfkt: joeyg was here earlier and mentioned that. See the logs from earlier today ( http://www.rockbox.org/irc/ ) |
10:49:29 | Zagor | scorche: I can't reach my bank right now, but I'll check later |
10:50:12 | | Quit loveless (Quit: loveless) |
10:50:21 | scorche | Zagor: i do not see records of any bank transfer in my main account either |
10:50:49 | dfkt | funman, by the way - is there now a v2 bootloader for the clip+, or rather a newer one than the v1 in svn? |
10:51:00 | Zagor | scorche: ok. I'll look on my side tonight. |
10:51:06 | wodz | funman: I just tested with HZ set to 50 and I don't see any difference so I guess kernel tick is fast |
10:51:17 | scorche | Zagor: thanks |
10:51:39 | funman | dfkt: i sent v2.0 bootloader to B4gder, just waiting for him to put them on the download server |
10:51:51 | dfkt | funman, thanks! |
10:51:55 | funman | wodz: okay, what do you think of profiling? |
10:51:59 | | Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) |
10:52:34 | B4gder | I'll fix them during the day I hope |
10:52:50 | ThomasAH | funman: Do I assume correctly that testing patch 952230 (mmu) with boosting disabled is no longer needed since you got crashes with that patch applied? |
10:53:36 | wodz | funman: I glanced at wiki page about profiling and I don't see the potential to use it in this case. From what I understood I can compare two implementations of some parts of code with profiling but not the code itself |
10:53:37 | funman | ThomasAH: yes, better test current svn since i disabled this function completely to confirm that there are unrelated crashes |
10:54:36 | ThomasAH | funman: ok |
10:54:47 | funman | wodz: perhaps http://www.rockbox.org/tracker/task/11176?string=thread can help? |
10:55:21 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
10:55:49 | wodz | funman: As You see in comments I looked it |
10:55:51 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
10:56:15 | wodz | funman: the data it provides are rather meaningless |
10:57:24 | funman | if a thread took too many ticks compared to others i guess you would have noticed it |
10:58:16 | funman | ah i notice profiling is only for specific functions |
10:58:33 | wodz | funman: but when decoding codec thread always hits the highest score |
10:58:42 | | Join mt [0] (~mtee@rockbox/developer/mt) |
10:58:50 | funman | hm well that sounds normal |
10:58:58 | wodz | funman: I checked this on my mini 1G which runs ok |
11:00 |
11:00:07 | funman | is PCM 'decoding' slow as well ? |
11:00:46 | wodz | You mean wav play? |
11:00:51 | funman | yep |
11:01:27 | wodz | last time I checked it was ok - I mean player runs boosted when rebuffering and than it goes unboosted |
11:02:10 | * | pamaury doesn't understand why something on his computer want to reset his mtp device after it started working... probably a fucking conflict between several software |
11:04:07 | funman | wodz: can you access the previous value of program counter when the CPU is interrupted? |
11:05:14 | wodz | funman: You mean backtrace? |
11:05:16 | funman | to know which function was executing before the interrupt |
11:05:47 | wodz | funman: I think no |
11:06:03 | funman | i guess for complete backtrace you have to store each function call so it would be more complex, but at least knowing which function is executed would help |
11:06:30 | wodz | well in theory this should be in exception frame stored on the stack |
11:06:38 | | Quit bmbl (Quit: Bye!) |
11:07:10 | funman | well except from compare profilings between mini 1G and MPIO i don't know what you could do |
11:08:03 | wodz | I mean the current value of PC is stored on stack when exception is processed |
11:08:17 | | Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) |
11:09:23 | funman | what about this: retrieve the value on each tick interrupt, store it in a fixed size buffer say, (HZ*60*5) for 5 minutes |
11:09:33 | JdGordon | S_a_i_n_t: pong |
11:09:54 | | Quit mt (Ping timeout: 252 seconds) |
11:10:01 | funman | run codec, write log to disk, and retrieve the function name for each PC value, and see if a function is well ahead of the others |
11:11:18 | funman | btw: button_hold() -> ?true:false isn't needed |
11:11:19 | | Quit dfkt (Ping timeout: 245 seconds) |
11:11:31 | funman | afaik any integer will be promoted to bool |
11:12:02 | | Join mt [0] (~mtee@rockbox/developer/mt) |
11:13:25 | pamaury | JdGordon: I'm trying your patch and there are several things that are not great :) |
11:13:46 | | Quit komputes_ubuntu (Ping timeout: 264 seconds) |
11:14:04 | funman | wodz: what is the purpose of lcd_initialized? it is never set to false, and no lcd functions should run before lcd_init_device() ? |
11:14:19 | JdGordon | pamaury: hehe |
11:14:28 | JdGordon | back in 30 or so though.. tucker time |
11:14:54 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
11:14:59 | wodz | funman: it was taken from m3 lcd driver code. I didn't think of it much |
11:15:20 | funman | wodz: in set_cpu_frequency(), a comment says PLL locking can take up to 10ms, did you measure it? |
11:15:32 | | Quit dfkt_ (Disconnected by services) |
11:16:12 | funman | also iirc lcd performance is pretty fast no? |
11:16:16 | wodz | funman: This is what datasheet for cf5249 sais. Nothing can be done with this |
11:16:19 | | Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) |
11:16:26 | wodz | funman: lcd is pretty fast yes |
11:16:49 | funman | well if RAM & CPU are fast there must be a piece of code slowing things down ! |
11:17:01 | | Quit mt (Ping timeout: 240 seconds) |
11:17:48 | wodz | funman: moreover this piece of code is specific to MPIO port since performance penelty is not observed on other CFs |
11:18:26 | wodz | BUT pixelma measured mem performance on M5 and results are surprising |
11:18:51 | funman | what were the results again? |
11:19:13 | | Join mt [0] (~mtee@rockbox/developer/mt) |
11:19:52 | * | pamaury is pretty sure that somehow, libmtp is messing up with mtp sessions but doesn't have the courage look at the code once more |
11:20:26 | pixelma | the lcd init things in the M3 driver sound like they could have to do with the fact that the main unit M3 doesn't have a display and you can only attach an lcd remote (not necessary though) |
11:20:50 | wodz | test_mem gives on MPIO: unboosted write 95kB/s, ubusted read 55 kB/s, boosted write 267kB/s and boosted read 154kB/s. Pixelma posted some results on IRC from iaudio M5 "bufsize: 514048, write ticks: 15 (267 kB/s), read ticks: 26 (154 kB/s) - no change when boosted or unboosted" |
11:21:07 | | Join stoffel [0] (~quassel@p57B4AA54.dip.t-dialin.net) |
11:22:05 | funman | there were some changes to test_mem last days, perhaps worth testing again ? |
11:22:38 | funman | wodz: is the MPIO still slow if you force boosting? |
11:23:44 | wodz | funman: what do You mean still slow? To play mp3 it needs 105-108MHz according to buffering thread debug menu |
11:24:13 | | Quit TheSeven (Ping timeout: 245 seconds) |
11:24:29 | wodz | so it decodes realtime but runs mostly boosted which is not the case on other CFs |
11:24:51 | funman | wodz: debug menu -> cpu frqeuency and increase the counter |
11:25:09 | | Join mitk [0] (~mitk@195.117.162.130) |
11:25:26 | funman | if decoding is much faster then it'll point to a problem in set_cpu_frequency() |
11:25:47 | wodz | I don't understand |
11:25:57 | | Join mt_ [0] (~mtee@41.233.149.210) |
11:26:00 | | Quit mt (Ping timeout: 260 seconds) |
11:26:15 | | Nick mt_ is now known as mt (~mtee@41.233.149.210) |
11:26:49 | funman | if set_cpu_frequency() is slow, then removing unboosted->boosted or boosted->unboosted transitions should make decoding much faster |
11:27:15 | | Quit komputes_ubuntu (Quit: I haven't slept for ten days, because that would be too long.) |
11:27:48 | wodz | and? |
11:28:09 | wodz | set_cpu_frequency() is the same on all CFs |
11:28:43 | funman | really? i was wondering why it wasn't in a common file |
11:28:55 | | Join komputes_ubuntu [0] (~komputes@ubuntu/member/komputes) |
11:29:08 | funman | the difference between boosted & unboosted mem speed on m3 and mpio would point to a difference |
11:29:16 | funman | *between 2 CFs |
11:30:10 | wodz | funman: But I have some doubts about results from M5 |
11:30:42 | wodz | funman: results from MPIO are in simple proportion to cpu/bus frequency |
11:31:00 | wodz | and this is what I expected |
11:31:41 | funman | i see mpio changes adclk |
11:32:01 | wodz | this is for ADC |
11:32:17 | funman | only for default freq though? |
11:32:27 | funman | ah no sorry, i misread |
11:33:18 | wodz | this controlls how often ADC interrupt fires (adclk/4096) |
11:33:52 | funman | mpio changes CSCR3 but m5 changes CSCR1 ? |
11:33:57 | funman | (for LCD) |
11:34:04 | wodz | yes |
11:34:16 | wodz | lcd is connected to different chipselect |
11:35:06 | funman | which performance does test_codec give if you force CPU boosting like i suggested? |
11:35:36 | wodz | test_codec always run boosted |
11:35:49 | | Quit KoRn_Thoughtless () |
11:35:51 | funman | hm right |
11:36:31 | funman | so, memory speed is the same than M5 (in test_codec at least) |
11:37:01 | funman | you said test_codec numbers didn't change with HZ set to 50 ? |
11:37:29 | funman | isn't the difference with M5 test_codec numbers like twice slower? |
11:37:31 | | Join bmbl [0] (~Miranda@vpn224-8.fh-bielefeld.de) |
11:37:32 | | Quit bmbl (Changing host) |
11:37:32 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
11:38:27 | wodz | I didn't run test_codec with HZ 50. |
11:38:54 | funman | did you test with boosting % in buffering thread debug menu ? |
11:39:04 | wodz | yes |
11:39:37 | funman | IMO it is not very reliable |
11:39:53 | Torne | S_a_i_n_t: Weird. You're the only one having the problem still that I know of :) |
11:40:25 | funman | CPU can be boosted during nearly a full tick without being noticed by this menu (provided it isn't boosted at the time of the tick) |
11:41:14 | wodz | sure but from what I know people see almost no % boosted when playing mp3 on other CFs |
11:48:06 | *** | Saving seen data "./dancer.seen" |
11:50:51 | | Nick komputes_ubuntu is now known as komputes (~komputes@ubuntu/member/komputes) |
11:51:04 | | Quit bmbl (Ping timeout: 260 seconds) |
11:59:00 | GodEater | has Torne's fix for the ipod powering itself on randomly been commited yet? |
11:59:35 | gevaerts | I think so |
11:59:47 | JdGordon | pamaury: that patch was only proof-of-concept.. obviously not commitable :) |
12:00 |
12:00:32 | gevaerts | Zagor: does http://pastebin.com/9Jam30TN look correct ? |
12:00:39 | gevaerts | It avoids some false reds |
12:01:58 | funman | could it be printed anyway? |
12:03:41 | Torne | GodEater: i reverted the change that caused that, yes |
12:04:01 | Torne | GodEater: i'm clearing IRAM on shutdown instead, which shouldn't be able to *cause* any problems |
12:06:50 | | Join watto [0] (~watto@193.203.81.165) |
12:14:42 | GodEater | so update to current build should stop my ipod turning on randomly? |
12:15:38 | | Quit CGL (Remote host closed the connection) |
12:16:15 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
12:16:23 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
12:17:53 | Torne | GodEater: yes |
12:18:29 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
12:20:57 | CIA-5 | New commit by funman (r25925): wmafixed.h: remove double declaration |
12:25:48 | | Quit Zambezi (Changing host) |
12:25:48 | | Join Zambezi [0] (Zulu@unaffiliated/zambezi) |
12:28:09 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
12:35:09 | JdGordon | we need a better way of knowing which screens info is probably wanted.... current_screen() is terrible to know if we should be showing the radio tokens or music tokens in the sbs |
12:35:15 | JdGordon | ditto for rec toeksn |
12:36:17 | kugel | a current_music() token (the function exists already) should probably be added |
12:36:44 | kugel | or was it called last_music()? |
12:36:58 | wodz | Testing my FS #11254 I saw that usb icon is not centered on screen. Is it my patch problem, sim problem or general problem? |
12:37:02 | JdGordon | not really a token, some like %pb are used in both |
12:37:19 | JdGordon | wodz: it could be the theme you are using... |
12:37:59 | wodz | I tested default builds of sim for different targets |
12:39:52 | | Join M3DLG [0] (~M3DLG@212.183.140.23) |
12:42:44 | | Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) |
12:43:11 | pamaury | JdGordon: there is bug in you screen if one select HID->battery only, the HID driver is loaded anyway (easy to fix). I also disabled the splash screens because they prevented the usb connection sometimes |
12:43:39 | JdGordon | hid->battery only shouldnt be there i think? |
12:43:57 | pamaury | JdGordon: it should be renamed to "no hid" |
12:43:59 | pamaury | JdGordon: I also don't understand why you poll in usb.c, why don't you send back a message to the usb thread when the choice is made |
12:44:09 | pamaury | JdGordon: are there zillions of warning :) |
12:44:15 | pamaury | *there are |
12:44:19 | JdGordon | what type of warnings? |
12:44:54 | JdGordon | I didnt use another event because I'm not sure how to cleanly send the event back |
12:45:53 | | Quit dfkt (Ping timeout: 245 seconds) |
12:47:08 | | Quit M3DLG (Ping timeout: 245 seconds) |
12:47:10 | | Quit dfkt_ (Ping timeout: 240 seconds) |
12:47:52 | pamaury | JdGordon: functions calls without prototypes |
12:48:16 | JdGordon | like i said, quick and dirty :) i'll have a play now to clean it up |
12:48:49 | JdGordon | pixelma: I dont suppose you've played with the fm default skin yet? |
12:48:57 | * | JdGordon is ready to commit that |
12:49:09 | funman | linuxstb: do shorten and flac decoders share the same directory only because of golomb.h and bistream.{c,h} ? |
12:51:30 | pamaury | JdGordon: you can wait a bit before cleaning, I have done modifications, I'll pastebin it later |
12:51:48 | JdGordon | mods to your code or mine? |
12:52:33 | pamaury | mods to your code |
12:52:47 | pamaury | (and mine also about MTP) |
12:52:52 | funman | linuxstb: oh i see shorten was added by lowlight, not by you |
12:53:39 | Zagor | gevaerts: how does a note line look? |
12:55:26 | | Join ucchan [0] (~ucchan@softbank126102048040.bbtec.net) |
12:56:13 | JdGordon | ok, I've just changed it to not poll... testing to see if it actually still works |
12:58:07 | linuxstb | funman: They're both from ffmpeg, so yes, I guess they shared the directory to avoid duplicating things. But that was a long time ago, so maybe we wouldn't do it the same way today (e.g. common things could be moved to the codec lib, which didn't exist back then). |
12:58:35 | | Quit kugel (Remote host closed the connection) |
12:59:04 | pamaury | JdGordon: there's no reason for this to not work, just split case USB_INSERTED in case USB_INSERTED: another case USB_USB_SELECTION_ACK or something like that |
12:59:18 | JdGordon | pretty much what I've done :) |
12:59:20 | pamaury | or SYS_USB_ATTACH_ACK |
13:00 |
13:03:34 | | Quit komputes (Ping timeout: 264 seconds) |
13:03:34 | gevaerts | Zagor: I'm trying to find out again :) |
13:03:36 | pamaury | JdGordon: also, why when I select MTP in the screen for example and then select "connect", the screen does not disappear until next button press ? |
13:04:14 | JdGordon | because I think it needs to force a redrw on the previous screen.. should be a simple fix |
13:04:24 | JdGordon | grr... its no worky |
13:12:08 | JdGordon | we need a vertical centering tag in the wps... |
13:13:20 | CIA-5 | New commit by uchida (r25926): chunksize decreases 4 bytes regardless wave/wave64. |
13:16:20 | * | JdGordon thinks about how he can use the skin engine to draw the lists |
13:21:33 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
13:24:18 | gevaerts | Zagor: path/to/file.c:999: note: some text |
13:31:20 | funman | gevaerts: would the line still be displayed ? |
13:31:44 | gevaerts | funman: that patch has no influence on what is shown as far as I can see |
13:33:13 | | Join dfkt [0] (~dfkt@unaffiliated/dfkt) |
13:37:25 | funman | linuxstb: what is the condition of libffmpegFLAC/decoder.c:262 ? in ffmpeg it's simply if (s->bps > 16) |
13:38:05 | funman | disabling the ARM asm and using C here gives a tiny speedup on Clipv1 (my sample decodes in 52 ticks instead of 53, i can't measure longer files due to small buffer of clipv1) |
13:39:46 | | Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) |
13:40:49 | | Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) |
13:43:38 | | Quit mikroflops (Ping timeout: 246 seconds) |
13:44:55 | | Quit kugel (Remote host closed the connection) |
13:48:10 | *** | Saving seen data "./dancer.seen" |
13:51:43 | | Quit ucchan (Quit: Leaving...) |
14:00 |
14:00:37 | funman | a 45s files on fuzev1 decode in 3 ticks faster |
14:01:10 | funman | test_codec gives the same result on 3 runs, but I still would like to make sure my file is executing this case |
14:01:49 | funman | it's a 16 bps file |
14:06:15 | funman | preglow: ping ^ |
14:09:08 | linuxstb | funman: I think that condition is just deciding if the result will overflow 32-bit arithmentic - so it chooses a 32-bit or 64-bit codepath. Our flac decoder can be compiled standalone (see Makefile.test in the libffmpegFLAC directory) if you want to add some printfs for testing. |
14:10:11 | funman | just wondering why it is different from ffmpeg, it seems you made the change but it's not in svn log |
14:11:33 | linuxstb | funman: Are you comparing with current ffmpeg, or the version we used for Rockbox in 2005? |
14:11:39 | funman | both |
14:19:08 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
14:20:41 | funman | hm it looks like it was added in FFmpeg after you first committed it, but in a different way |
14:21:55 | funman | anyone want to benchmark http://pastie.org/953594 before I remove the asm code? |
14:21:58 | linuxstb | funman: Yes, I was just coming to the same conclusion... |
14:30:17 | | Join Schmogel [0] (~Miranda@p3EE22C93.dip0.t-ipconnect.de) |
14:30:59 | | Join M3DLG [0] (~M3DLG@212.183.140.2) |
14:35:43 | funman | i'll try with eabi |
14:36:29 | CIA-5 | New commit by wodz (r25927): HD200 - Reduce wait states when writing to lcd. |
14:36:45 | funman | wodz: is the LCD still readable when backlight is off? |
14:37:00 | CIA-5 | New commit by wodz (r25928): HD200 - Remove checks if driver is initialized. lcd_init_device() is always called first. |
14:37:31 | wodz | funman: yes |
14:38:22 | pixelma | greyscale and monochrome displays usually are |
14:38:39 | pixelma | LCDs |
14:41:39 | wodz | pixelma: Could You run again test_mem on M5? Running tests on my MPIO I had once the situation that device was boosted all the time, test_mem printed equal results for boosted and unboosted |
14:44:09 | | Part LinusN |
14:50:34 | | Quit mt (Read error: Connection reset by peer) |
14:54:58 | | Join Exqb [0] (~qb@bsd.talaf.org) |
14:56:23 | funman | using eabi gcc, there's no difference between C & asm version. |
14:56:58 | wodz | amiconn: You were right - reading routine in ata-as-mpio.S is broken while writing seems to work ok. |
14:57:08 | pixelma | wodz: today in the evening |
14:57:23 | wodz | pixelma: thanks |
14:59:11 | | Join mt [0] (~mtee@rockbox/developer/mt) |
15:00 |
15:01:22 | joeyg | linuxstb: no, nobody except me has used the SDCFG value - but for what it's worth, I used it about six times last night |
15:01:42 | CIA-5 | New commit by funman (r25929): flac: remove ARM assembly ... |
15:03:26 | linuxstb | joeyg: OK. I would like someone else to confirm it before making another release though. Feel free to point people to that tcctool.exe I posted earlier. |
15:06:33 | joeyg | sure thing |
15:06:33 | | Quit antil33t (Read error: Connection reset by peer) |
15:06:39 | | Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) |
15:06:44 | CIA-5 | New commit by wodz (r25930): HD200 - add support for the device in greylib |
15:07:41 | | Quit M3DLG (Ping timeout: 240 seconds) |
15:11:29 | | Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
15:14:11 | funman | mc2739: +3hours runtime on e200v2 in 2 months, not bad ;) |
15:14:16 | | Join evilnick [0] (~0c140464@rockbox/staff/evilnick) |
15:16:30 | | Quit komputes (Ping timeout: 264 seconds) |
15:16:55 | mc2739 | funman: yes, that is very good, but still a little bit to go to match or exceed the OF |
15:18:44 | funman | my clipv1 needs ~ the same current than your e200v2 |
15:18:54 | funman | but bertrik's one needs ~ the same than my fuzev1 (a bit lower) |
15:19:06 | funman | perhaps we can find something there |
15:20:09 | funman | i should bench the OF on my fuze to check but it seems on it we match the OF |
15:20:32 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
15:20:46 | funman | my fuzev1 needs 37mA (rockbox) and on your e200v2 OF needs 38.4 |
15:21:07 | mc2739 | wasn't the difference on the clip something to do with the backlight? |
15:21:33 | funman | hm no i think it had no effect |
15:21:45 | funman | and afaik bertrik's clip didn't need this change |
15:22:18 | mc2739 | what battery capacity did you use for that calculation? |
15:22:35 | | Quit komputes (Read error: Connection reset by peer) |
15:22:41 | funman | e200v2? 730mAh |
15:22:55 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
15:23:25 | funman | BATTERY_CAPACITY_DEFAULT in config/sansae200v2.h |
15:23:25 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
15:24:05 | mc2739 | ok, my e200v2 has a 750mah, same battery as e200v1, but it may not be the standard for the v2 (I bought mine refurbed) |
15:24:35 | funman | hm ok |
15:24:45 | CIA-5 | New commit by wodz (r25931): HD200 - Disable asm optimised reads as it showed to be broken. Enable asm optimised writes. test_disk was failing because of broken read routine. |
15:25:31 | funman | current use is closer to 46mA then, not 45 |
15:26:58 | CIA-5 | New commit by funman (r25932): as3525(v1) : correct CPU_FREQ |
15:31:04 | | Quit joeyg (Quit: go to work) |
15:31:20 | | Quit wodz (Quit: Leaving) |
15:44:34 | | Join MrShlee [0] (~Default@219-90-153-181.ip.adam.com.au) |
15:45:46 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
15:45:53 | | Join ezzieyguywuf [0] (~wolfie@cpe-173-095-153-154.nc.res.rr.com) |
15:47:20 | ezzieyguywuf | I thought this would be a good place to ask: are there any linux media players that have as much functionality as rockbox does on my dap? i.e. inserting whole folders "next" or "last" etc? |
15:47:20 | kugel | funman: have you checked arm7? |
15:47:20 | ezzieyguywuf | I'm trying out mpd, which is pretty awesome, but doesn't give me the flexibility I'm used to on my dap :-P |
15:48:08 | kugel | these asm optimizations often have a strong effect for arm7 but not for arm9+ |
15:48:08 | funman | mc2739: could you run http://pastie.org/953693 and paste the output of debug menu -> ioport? |
15:48:08 | funman | kugel: nope i have no arm7 |
15:48:08 | | Part Zagor |
15:48:11 | *** | Saving seen data "./dancer.seen" |
15:48:37 | | Quit mitk (Quit: Leaving) |
15:48:50 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
15:51:31 | | Join bluebrother [0] (~dom@g224237034.adsl.alicedsl.de) |
15:51:31 | | Quit bluebrother (Changing host) |
15:51:31 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
15:53:12 | funman | the registers are identical between my fuzev1 & clipv1, safe for ADC, RTC, and ID |
15:53:19 | S_a_i_n_t | ezzieyguywuf: That question would probably be better suited for #rockbox-community if anything |
15:53:28 | S_a_i_n_t | At least it wouldn;t be off-topic there. |
15:53:33 | ezzieyguywuf | S_a_i_n_t: yep, I'll head over there thanks |
15:54:47 | | Quit bluebroth3r (Ping timeout: 248 seconds) |
15:54:51 | amiconn | funman: Are you sure gcc isn't slower than asm? arm7tdmi behaviour is probably quite different from fuze |
15:55:15 | amiconn | There is a reason why this asm exists... |
15:56:27 | funman | amiconn: yes, please check the logs |
15:56:29 | | Part ezzieyguywuf |
15:57:17 | amiconn | hm? |
15:57:22 | amiconn | [15:47:48] <funman> kugel: nope i have no arm7 |
15:57:33 | | Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) |
15:57:57 | amiconn | To me that looks like you disabled the asm for all arm targets, based on performance figures from fuze *only* |
15:58:51 | funman | it is exactly what i did, and i told that in the commit log |
15:59:04 | funman | 15:54 < amiconn> funman: Are you sure gcc isn't slower than asm? |
15:59:17 | funman | http://www.rockbox.org/irc/log-20100510#13:38:05 |
15:59:45 | amiconn | Yes, and my point is that this is bad |
16:00 |
16:00:08 | amiconn | While gcc isn't slower on your fuze, it might very well be slower on arm7tdmi (e.g. PP) |
16:00:14 | funman | I thought if it was armv4 code there wouldn't be differences if it's run on armv5 |
16:00:28 | funman | well or any version of armv4 |
16:00:51 | amiconn | I assure you that there are even differences between arm9 (v4) and arm7 (v4) |
16:01:02 | amiconn | Let alone v5 or v6 |
16:01:21 | funman | i only thought about new instructions |
16:01:24 | amiconn | Pipelining is quite different |
16:01:39 | amiconn | And execution time of the same instructions is also quite different |
16:01:50 | funman | so we would need benchs on arm7tdmi and armv6 ? |
16:02:21 | kugel | at least arm7 I'd say |
16:02:42 | amiconn | On arm 4, a single load is 3 (!) cycles, and ldmia needs n+2 cycles. On arm9 (v4 or v5) a single load is single cycle, and ldm is n cycles |
16:03:03 | funman | btw i thought flac was slower when using eabi, but here (after upgrading to gcc 4.4.3) it was a tiny bit faster |
16:03:15 | amiconn | That's just one example out of many differences |
16:03:34 | amiconn | s/arm 4/arm7/ |
16:04:09 | amiconn | That means on arm9 it's almost the same whether you use ldm, on arm7 it's crucial |
16:04:22 | funman | can you bench it? |
16:04:30 | amiconn | On arm11 in turn it becomes crucial again |
16:04:35 | kugel | funman: it's slower on arm7, nobody has checked arm9 so far I believe. it'll be faster with -O2 (currently flac is build with -O only) |
16:04:43 | funman | amiconn: i won't touch the asm anyway |
16:05:28 | amiconn | I'm quite sure it has been benched when it was added |
16:05:36 | amiconn | Imo it should just be reactivated |
16:06:13 | funman | what's the point of assembly routines if they aren't faster? |
16:06:21 | funman | (than C) |
16:06:43 | amiconn | They almost certainly *are* faster on arm7 |
16:06:51 | funman | how much? |
16:06:56 | kugel | can't someone just bench it? |
16:07:00 | amiconn | Otherwise they wouldn't have been added in the first place |
16:07:19 | funman | gcc could have gone smarter since |
16:07:21 | amiconn | Back when the flac codec was new, the only arm targets were arm7tdmi (i.e. PP) |
16:07:28 | amiconn | It's still the same gcc |
16:07:30 | amiconn | 4.0.x |
16:08:08 | funman | if someone give me numbers i'll reactivate it for arm7 |
16:09:31 | funman | anyone with a clipv1 which runs longer than 8 hours with current build? |
16:09:54 | funman | or anything more recent than r25900 |
16:14:28 | | Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) |
16:14:58 | amiconn | funman: "03.55.15 # <preglow> went from 20% to 4% boost at 21/75mhz for a -8 flac file" |
16:15:02 | mc2739 | funman: http://imagebin.ca/view/MsGhT6C.html |
16:15:23 | amiconn | That's from http://www.rockbox.org/irc/log-20060303 |
16:15:58 | amiconn | Err http://www.rockbox.org/irc/log-20060306 |
16:16:18 | | Quit Battousai (Read error: Operation timed out) |
16:17:29 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
16:18:42 | JdGordon | so lets say, hypothetically, that the skin engine could be used to draw the individual items in the list... would a single viewport be enough to do it (Similar to how the playlist viewier in the wps works)... |
16:19:11 | JdGordon | The single viewport would move but everything inside it would be relative to that, so the text and icons would line up correctly |
16:19:43 | JdGordon | it could then use some smarts to decide to draw in a grid or list mode |
16:22:37 | JdGordon | the only problem I can see with using only a single viewport is you are very limited to text placement |
16:23:11 | * | kugel would like the skinning/theming to mature a bit before new additions |
16:23:17 | JdGordon | unless a centre vertically tag is added, and/or bottom align tag |
16:29:34 | JdGordon | it also needs the obvious "draw the damn icon from the icon code instead of the wps code" thing |
16:29:48 | funman | amiconn: what does test_codec say? |
16:30:27 | funman | boost % in the bufferign thread isn't a reliable performance counter, i'm not even sure why it's here |
16:30:36 | | Quit mc2739 (Ping timeout: 246 seconds) |
16:32:30 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
16:33:16 | funman | mc2739: thanks! btw check your date setting i think it's a bit off ;) |
16:34:39 | funman | mc2739: interesting, the 'design version' (at 0x20) is different |
16:35:04 | | Join apoelstra [0] (~apoelstra@S010600236999fec1.vs.shawcable.net) |
16:35:08 | | Nick apoelstra is now known as joeyg (~apoelstra@S010600236999fec1.vs.shawcable.net) |
16:37:27 | funman | no other difference (except ID, RTC, ADC, backlight brightness, and HP volume) |
16:37:51 | | Quit Battousai (Remote host closed the connection) |
16:39:58 | | Join MethoS- [0] (~clemens@134.102.106.250) |
16:42:32 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
16:46:40 | | Quit rvvs89 (Changing host) |
16:46:40 | | Join rvvs89 [0] (ivo@pdpc/supporter/base/rvvs89) |
16:48:02 | mc2739 | funman date setting is fine, screendump format is ddmmyy-hhmmss |
16:50:33 | funman | oops i was misreading the RTC registers |
16:52:15 | mc2739 | oh, I thought you saw something funny in the filename of the screendump |
16:53:47 | | Join Orion777 [0] (~IceChat7@c-71-204-140-208.hsd1.ca.comcast.net) |
16:54:35 | Orion777 | other than .rockbox what do I need in my root directory? |
16:54:53 | gevaerts | some audio files might be useful |
16:55:15 | Orion777 | i know but I read i'm supposed to have a bin file there |
16:55:17 | Torne | Orion777: it depends what player you have. |
16:55:29 | Torne | on some players the bootloader is a file that goes in the root directory |
16:55:36 | Torne | on others, the bootloader is installed some other way |
16:55:50 | Orion777 | its a fuze and it says i need fuzpa.bin file but one was pre-patched or something |
16:56:06 | Orion777 | the link is broken |
16:56:54 | Torne | You shouldn' tbe downloading a pre-patched copy of the fuze firmware; that's a copyright violation |
16:57:05 | Torne | the installation instructions explain how to make one |
16:57:24 | Torne | (or the automatic installer will do it for you) |
16:57:37 | Orion777 | oh ok, it was in a forum |
16:57:50 | Orion777 | i'll look at the manual |
17:00 |
17:00:58 | | Join Forsaken_ [0] (~chatzilla@24.139.156.136) |
17:03:51 | | Quit Forsaken_ (Client Quit) |
17:03:58 | | Quit Orion777 (Quit: A fine is a tax for doing wrong. A tax is a fine for doing well) |
17:05:07 | | Part Zagor |
17:08:11 | | Join halmi [0] (~netbook@188.20.253.186) |
17:08:37 | amiconn | funman: I can't test atm. Back then test_codec didn't exist |
17:11:14 | | Join Hillshum [0] (~hillshum@75-165-237-188.slkc.qwest.net) |
17:13:28 | funman | amiconn: it can wait, please also test eabi when you do |
17:13:38 | funman | (if no one beats you to it) |
17:15:12 | | Quit ansuz (Remote host closed the connection) |
17:15:56 | funman | ranma: any measured battery performance with your modified rockbox ? (re: forum) |
17:19:53 | ranma | Unfortunately no. Didn't measure today, but when I first tried setting those bits to output it had no effect on power draw, low/high level didn't seem to matter. |
17:20:29 | ranma | I just wanted to repeat reading the GPIO state with the proper io port this time :) |
17:21:33 | funman | ok ^^ |
17:21:38 | ranma | I should try measuring again to see if the changed DRAM settings have any effect (IIRC you enabled some dynamic clock bit?) |
17:21:43 | funman | btw do you have a recent battery bench? (post 25900) |
17:21:53 | | Quit Battousai (Remote host closed the connection) |
17:22:33 | funman | well i guess instant power use would be enough |
17:22:59 | * | funman slaps himself repeatedly for not reading your last sentence |
17:23:00 | | Quit parafin (Quit: So long and thanks for all the fish) |
17:23:04 | | Join parafin [0] (parafin@paraf.in) |
17:23:18 | | Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) |
17:23:33 | funman | yes in r25900 i changed a setting of memory controller: (one of the numerous?) SDRAM clock is disabled when there is no operation |
17:24:28 | funman | i think now on some models we're very close to the OF, i must check my Fuze but i don't want to leave the comp running all night ;) |
17:25:11 | | Quit dfkt (Ping timeout: 260 seconds) |
17:27:37 | ranma | 20mA idling with display off |
17:28:03 | funman | hm i never benched idling |
17:28:35 | ranma | Around 30mA playing mp3 with display off |
17:29:04 | funman | that's pretty low, lower than clip/fuze/e200v2 |
17:29:53 | ranma | Different multimeter though than last time (cheap 1000 Yen multimeter I bought in Akihabara) |
17:29:57 | funman | lowest is fuze at 37, clip/e200v2 at 45 |
17:33:57 | funman | bertrik: can you try http://pastie.org/953693 on your clip and look in debug menu -> io port? (i removed the last 2 spaces), and then compare to what i got on mine: http://pastie.org/953854 ? |
17:35:10 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
17:37:11 | ranma | Interesting, with my locally patched version I now get around 25mA/35mA |
17:39:37 | | Quit lpereira (Quit: Leaving.) |
17:41:26 | | Quit B4gder (Quit: It is time to say moo) |
17:42:04 | funman | what do you mean by "B6 is LCD reset" |
17:42:19 | | Join dockimble [0] (~dockimble@77.227.1.24) |
17:44:05 | | Quit Battousai (Remote host closed the connection) |
17:45:42 | | Join toffe82 [0] (~chatzilla@12.169.218.14) |
17:47:06 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
17:47:24 | ranma | funman: GPIO B6 seems to be connected to LCD reset. Setting it to output and writing 0 resets the display controller. |
17:48:02 | ranma | 'Display sometimes shuts down' may be because it's an input in svn, so the reset pin is floating... |
17:48:15 | *** | Saving seen data "./dancer.seen" |
17:48:59 | dockimble | has there been any work on possibly using rockboxed mp3 players as external sound cards? |
17:49:02 | ranma | Don't know if that's valid for the other revision too. |
17:49:15 | funman | ranma: perhaps it's visible in the OF |
17:49:38 | funman | dockimble: yes, usb audio |
17:50:06 | funman | I don't know the state of it though (it doesn't seem to be in svn yet) |
17:50:21 | dockimble | does it work? |
17:51:00 | ranma | Hmm, can't cross-check with OF for current draw, the drop of the cheap multimeter is too high, it just shuts down with 'battery low' |
17:52:11 | | Quit JohannesSM64 (Max SendQ exceeded) |
17:52:23 | | Join Bullet` [0] (~Bullet`@AMontsouris-159-1-54-29.w92-128.abo.wanadoo.fr) |
17:53:59 | | Part Bullet` |
17:55:18 | | Quit bluebrother (Ping timeout: 246 seconds) |
17:56:32 | | Quit petur (Quit: buggerit) |
17:56:40 | | Quit Exqb (Quit: BitchX: the IRC client with hair on it's balls) |
17:56:58 | | Join bluebrother [0] (~dom@g226070208.adsl.alicedsl.de) |
17:56:58 | | Quit bluebrother (Changing host) |
17:56:58 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
17:57:19 | | Quit pamaury (Ping timeout: 240 seconds) |
18:00 |
18:00:00 | | Quit halmi (Quit: halmi) |
18:01:53 | | Join jl-- [0] (~ca9c0af6@giant.haxx.se) |
18:03:42 | | Quit jl-- (Client Quit) |
18:05:33 | | Quit freddy_ (Ping timeout: 240 seconds) |
18:06:25 | | Quit MrShlee (Quit: Leaving) |
18:06:53 | ranma | funman: In lcd_init in OF, b6 is set to out and 0 (reset) |
18:08:26 | | Join stooo [0] (~sto@f051073118.adsl.alicedsl.de) |
18:10:00 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
18:11:03 | CIA-5 | New commit by ranma (r25933): See 0x429c in OF (lcd_init), B6 is lcd reset line. ... |
18:12:24 | | Quit Hillshum (Ping timeout: 246 seconds) |
18:17:14 | ranma | funman: Looking at the OF there is a third hardware variant for C200v2 determined by A1 strap value? |
18:19:31 | | Join domonoky1 [0] (~Domonoky@g229125145.adsl.alicedsl.de) |
18:21:25 | funman | what is 'strap value' |
18:21:38 | | Quit domonoky (Ping timeout: 260 seconds) |
18:22:07 | funman | btw there is 2 LCD drivers and 2 FM pinout for the fuzev2, but only 1 of each has been seen until now |
18:22:21 | funman | so don't rule out test code being run in production |
18:22:47 | ranma | pullup or pulldown on an (usually output) GPIO, so that it you configure it as input, your can read 1 bit of information. :) |
18:28:15 | | Part stooo |
18:29:06 | | Quit komputes (Ping timeout: 260 seconds) |
18:32:39 | | Join watto1 [0] (~watto@193.203.81.165) |
18:33:17 | | Join Horscht [0] (~Horscht2@xbmc/user/horscht) |
18:34:35 | CIA-5 | New commit by alle (r25934): Convert quotes to fancy ones in the license text as well |
18:35:09 | | Quit stoffel (Ping timeout: 246 seconds) |
18:35:46 | | Join Barahir [0] (~jonathan@frnk-590fc9a3.pool.mediaWays.net) |
18:38:13 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
18:38:38 | | Join M3DLG [0] (~M3DLG@212.183.140.34) |
18:40:18 | | Quit watto (*.net *.split) |
18:40:18 | | Quit flydutch (*.net *.split) |
18:40:18 | | Quit Barahir_ (*.net *.split) |
18:41:19 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
18:41:46 | topik | funman: cpu_freq was wrong/broken on as3525v1 too? |
18:42:11 | funman | no, my change was only cosmetics |
18:42:43 | funman | this value is written to a variable, but then the first call to set_cpu_frequency() will change it before we get the chance to read it |
18:43:44 | topik | ah ok. my clip+ hasn't crashed since r25924. with the display on (so i can read crash messages) it drains fast though |
18:44:02 | funman | still running here too |
18:45:01 | funman | which makes me think the crashes I have seen while CPU was boosted came while i played stuff from µSD |
18:45:24 | funman | test_disk ran ok but i didn't modify it to test µSD |
18:46:47 | topik | how come that before you disabled set_cpu_frequency it was throwing 'undefined instruction' errors? was something missing? |
18:47:56 | funman | well, bugs |
18:48:35 | topik | i'm trying to understand what "undefined instruction" means :) |
18:48:42 | funman | afaict memory was sometimes misread after modifying CGU_PERI/CGU_PROC |
18:49:00 | funman | it means that the value loaded from memory can't be decoded as an instruction |
18:49:51 | | Join webguestFuze [0] (~46228d92@giant.haxx.se) |
18:50:28 | | Quit DerPapst (Quit: Leaving.) |
18:50:39 | topik | that makes sense |
18:52:20 | kugel | that's the code version of data abort basically |
18:53:44 | funman | 2 reports on ABI that FM doesn't work on clip+ |
18:53:48 | funman | not detected |
18:53:56 | topik | i stopped writing those down. they were too many. trying to execute something that's not an instruction sounds like a sure way towards gloom |
18:54:59 | * | amiconn grumbles about funman |
18:55:09 | | Join Hillshum [0] (~hillshum@75-165-237-188.slkc.qwest.net) |
18:55:32 | pixelma | reminds me a bit of the early days of c200 radio support - sometimes it was just not detected until you started the radio once in the OF |
18:55:42 | | Join DerPapst [0] (~Alexander@p5099d40e.dip0.t-ipconnect.de) |
18:56:04 | funman | amiconn: what's wrong? |
18:56:40 | funman | pixelma: ah, nice to know. did it require rebooting fast enough to rockbox? |
18:57:01 | preglow | funman: hey, why remove perfectly working asm code? |
18:57:22 | funman | preglow: well did you read the commit log? |
18:57:22 | amiconn | Yeah, that's what I'm grumbling about as well |
18:57:39 | preglow | tiny bit slower, yes |
18:57:48 | preglow | but the code was there, and it's slower now, doesn't matter how much slower |
18:57:57 | funman | no, it's faster now. |
18:58:05 | preglow | i find that really unlikely |
18:58:07 | amiconn | While providing (imo) enough evidence that this asm is a good thing, I'm now essentially forced to run a speed test |
18:58:16 | preglow | what target? |
18:58:16 | * | amiconn is building |
18:58:25 | funman | it's mentioned in the log. |
18:58:31 | preglow | if c is faster on ipods, i'll eat a hat or two |
18:58:50 | amiconn | And I pointed you to the log that shows on PP the asm is significantly better |
18:58:58 | * | amiconn will soon have percentages |
18:59:00 | funman | doesn't show anything |
18:59:07 | | Quit DerPapst (Client Quit) |
18:59:14 | amiconn | 2006-03-06 *does* show it |
18:59:27 | funman | boost % doesn't show anything |
18:59:34 | preglow | please also test BOTH decode paths |
18:59:44 | pixelma | funman: no (the radio thing) |
18:59:49 | amiconn | preglow: hmm? |
19:00 |
19:00:10 | funman | preglow: i tested the one path which had an ASM version |
19:00:42 | preglow | two asm versions, afaik |
19:00:46 | preglow | i'll check, long time since i wrote that |
19:00:48 | funman | 24bit decoding has only a coldfire helper |
19:00:55 | pixelma | funman: it worked for a while then but sometimes it just vanished again. (guess some startup sequence was wrong or so) |
19:01:57 | preglow | weird, i remember coding one for arm as well :> |
19:02:41 | FlynDice | funman: Test_disk passed just fine when I tested write & verify on uSD for 4 bit bus and that was after you moved the boosting to uncached mem as I recall. |
19:03:01 | funman | FlynDice: i didn't move it, it was just a patch never committed |
19:03:24 | FlynDice | ah well then....... nevermind |
19:03:55 | preglow | but yeah, i'd expect that asm to be faster on both arm7 and arm9tdmi |
19:04:01 | preglow | more so on arm7, ofc |
19:04:21 | funman | preglow: i've given numbers on irc today |
19:04:28 | preglow | timestamp? |
19:04:39 | funman | 13:38 |
19:05:00 | amiconn | On arm9 I think it won't matter much |
19:05:40 | amiconn | But the asm is most definitely faster on arm7tdmi (I'm about to get exact numbers for funman), and I guess it might also be faster on arm11 |
19:05:51 | amiconn | (will test that as well) |
19:05:59 | | Quit webguestFuze (Quit: CGI:IRC (EOF)) |
19:06:32 | preglow | can't remember how the pipeline is set up on arm9 atm |
19:06:42 | | Quit M3DLG (Ping timeout: 252 seconds) |
19:06:54 | | Quit S_a_i_n_t () |
19:07:29 | amiconn | Arm9 pipeline is pretty much the same for v4 and v5. v5 just has those few extra instructions |
19:08:14 | preglow | all i remember is that arm7 pretty much never overlaps instruction, while some of the newer archs do and have dependencies as a result |
19:08:32 | preglow | which i didn't think about at all when arm7tdmi was all there was |
19:08:44 | preglow | or know about, for that matter :> |
19:09:34 | | Join halmi [0] (~netbook@188.20.253.186) |
19:09:43 | preglow | ah, nvm, remember now |
19:10:34 | amiconn | sure |
19:11:05 | amiconn | It can be somewhat irritating that the importance of ldm/stm changes in a weird way across arm versions |
19:11:11 | preglow | yeah |
19:11:18 | preglow | it's important as hell on arm7tdmi |
19:11:36 | preglow | but afaik matters little, or can even be bad if you don't load many regs, on some other |
19:13:30 | amiconn | It doesn't really matter on arm9 (both v4 and v5), but then suddenly becomes important again on arm11 |
19:13:38 | | Quit komputes (Ping timeout: 240 seconds) |
19:14:02 | preglow | haha |
19:14:19 | preglow | well, if it doesn't matter it's not too bad |
19:14:26 | preglow | if it had a negative impact it would be more annoying |
19:16:06 | funman | there was no noticeable difference when using eabi gcc (difference less than 0.01s on a 45s file) |
19:16:10 | | Join dys [0] (~andreas@krlh-5f7358b4.pool.mediaWays.net) |
19:16:54 | funman | when using default gcc on the same file the difference was between 30ms and 40ms) |
19:17:33 | joeyg | compiling gcc and binutils is easier, and the gnu people claim to support eabi more |
19:17:54 | preglow | from what i've read, eabi is definitely a good thing |
19:20:38 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
19:20:49 | joeyg | i couldn't compile arm-elf-gcc without the rockbox patch (which I didn't notice for a while) because there were incompatibilities with the FPU instructions of gcc and newlib |
19:21:01 | joeyg | with eabi these kind of incompatibilities don't happen, from what ive read |
19:21:16 | joeyg | and for floating-point specifically, things are much faster |
19:22:38 | preglow | who needs that anyway :P |
19:22:42 | | Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) |
19:22:43 | | Quit scorche|sh (Ping timeout: 265 seconds) |
19:23:09 | | Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) |
19:23:11 | funman | gigabeast owners ? ;) |
19:24:13 | preglow | pft, disable it for power savings! |
19:24:22 | preglow | let them chug integers like the rest of us |
19:28:58 | | Join CGL [0] (~CGL@190.207.172.201) |
19:32:13 | | Quit dockimble (Quit: Leaving) |
19:32:20 | amiconn | Did anyone try building libmad with VFP for the beast? |
19:34:56 | CIA-5 | New commit by FlynDice (r25935): sd-as3525v2: Add delay after SD_SWITCH_FUNC to while switching to high speed timings and wait until after this switch to bring the card clock back up ... |
19:35:02 | CIA-5 | New commit by FlynDice (r25936): sd-as3525v2: Set LP bits in MCI_CLKENA for cards after they have been initialized. ... |
19:36:52 | | Join DataGhost [0] (~dataghost@17-18-ftth.onsnetstudenten.nl) |
19:36:52 | | Quit DataGhost (Changing host) |
19:36:52 | | Join DataGhost [0] (~dataghost@unaffiliated/dataghost) |
19:36:56 | amiconn | whoa... |
19:39:45 | | Join Buschel [0] (~ab@p54A3F612.dip.t-dialin.net) |
19:40:49 | amiconn | funman, preglow: FLAC speed C -> ASM |
19:41:34 | amiconn | iPod G2 (PP5002, ARM7TDMI, broken cache): 387.7% -> 587.5% realtime (51% faster) |
19:42:18 | amiconn | Mini G2 (PP5022, ARM7TDMI): 395,1% -> 605.3% realtime (53% faster) |
19:42:57 | amiconn | Gigabeat S (i.MX31, ARM1136): 2582% -> 4110% realtime (59% faster) |
19:43:22 | amiconn | funman: Is that enough evidence to show the ASM is better? </sarcasm> |
19:43:24 | Buschel | quite some speed up ;) so, better undo r25929? |
19:43:39 | amiconn | definitely |
19:44:00 | funman | amiconn: well i had no evidence to trust it |
19:44:36 | amiconn | Really, if it wouldn't have been faster, do you think preglow would have done it in the first place? |
19:44:54 | amiconn | Now you have, though |
19:44:57 | funman | testing showed it was not fast enough |
19:45:01 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
19:45:30 | | Quit stripwax (Client Quit) |
19:45:49 | amiconn | preglow: Interestingly enough it works rather well on the ARM11 pipeline |
19:45:55 | funman | amiconn: why all the ranting? |
19:46:53 | | Join captainewkl [0] (~2669ecc2@gateway/web/freenode/x-cgmdbodxidgpunbd) |
19:48:11 | funman | i just hope it's not a personal problem with me |
19:48:16 | amiconn | Because (imo) you rushed r25929 based on findings from a single arm target, ignoring that there are others, and there is usually a reason for asm blobs |
19:48:18 | *** | Saving seen data "./dancer.seen" |
19:49:00 | amiconn | The side effect is that we now have more meaningful numbers for the speedup |
19:49:15 | funman | well i got since the start that there are other targets |
19:49:26 | funman | no need for hours of sarcasm |
19:50:09 | funman | i wondered about putting a patch on flyspray but in my experience flyspray patches just get no testing and rot |
19:50:52 | funman | if you have spare arm7 targets and can bring one at devcon next time i'll test on it |
19:51:06 | Llorean | funman: I think the problem is that you assumed that the original code served no purpose based on a single test, rather than putting in a good faith effort to double check. |
19:51:34 | funman | i thought gcc got better, and i did several tests in fact |
19:51:37 | Llorean | Even without putting a patch on flyspray, what harm would it have caused to wait a few days and try several times to find testers? |
19:51:40 | kugel | gevaerts: I made some progress with the sim-target-tree |
19:51:46 | Llorean | funman: You did several tests on one target, though? |
19:51:47 | funman | i'd have forgotten then |
19:51:49 | funman | yeah |
19:51:54 | Llorean | That's "a single test" |
19:52:00 | Llorean | As in, a single test subject, at least |
19:52:03 | funman | well i have only one target |
19:52:05 | amiconn | funman: gcc can't have gotten better. We're using gcc 4.0.x for arm from the beginning |
19:52:36 | funman | well if x changed gcc changed? |
19:52:40 | Llorean | funman: Why was the ASM so harmful that it would be bad if you forgot to remove it? |
19:52:49 | amiconn | x is just bug fixes |
19:53:03 | funman | Sometimes assembly is faster, but C is always more |
19:53:04 | funman | readable and maintainable. |
19:53:23 | funman | i'm not a gcc developer |
19:53:33 | amiconn | s/Sometimes/Often/ |
19:53:45 | funman | amiconn: then go and change our contributing guidelines |
19:53:57 | gevaerts | kugel: great |
19:54:46 | kugel | gevaerts: it will be a bit tricky to use a proper target tree for the sim, but still include some files from the real target's tree (e.g. button-target.h) |
19:55:27 | kugel | also tricky is the location of main() for the sim, and the fact that the actual main runs from a thread separated from the sim main() |
19:55:30 | | Quit funman (Quit: free(random());) |
19:55:47 | | Join DerPapst [0] (~Alexander@p5797C16C.dip.t-dialin.net) |
19:56:05 | kugel | i would've been farther if my ide stopped crashing! |
19:56:21 | | Quit DataGhost (Ping timeout: 240 seconds) |
20:00 |
20:01:20 | | Quit JohannesSM64 (Max SendQ exceeded) |
20:02:30 | | Join elinenbe [0] (~d1c4c008@giant.haxx.se) |
20:02:35 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
20:05:15 | | Quit JohannesSM64 (Max SendQ exceeded) |
20:05:21 | | Join petur [0] (~petur@rockbox/developer/petur) |
20:06:30 | | Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) |
20:08:08 | preglow | funman: for the logs, as a general rule, assembly code will pretty much always be faster, it the coder has done his job well |
20:08:13 | preglow | amiconn: sweet numbers... |
20:08:40 | amiconn | Indeed |
20:08:42 | preglow | funman: so in general, if a test says asm slows something down, test again ;) |
20:08:50 | preglow | again/more/better |
20:08:54 | amiconn | I'm testing eabi right now (that also means gcc 4.4.3) |
20:09:27 | preglow | any reason we're not using 4.4.3? i think i remember it was pretty decent |
20:09:35 | amiconn | For the beast it's 15% faster than (old abi) gcc 4.0.3 - still significantly slower than asm |
20:09:54 | amiconn | We'll go 4.4.3 when going eabi |
20:10:03 | preglow | wonderful |
20:10:05 | amiconn | Most things work with eabi, some things need fixing |
20:10:17 | amiconn | The most notable thing that needs fixing is doom |
20:10:17 | preglow | as expected |
20:10:37 | amiconn | This is in fact not due to eabi as such, but due to eabi gcc defaulting to short enums |
20:11:06 | preglow | hm |
20:11:06 | amiconn | Doom makes the (silly) assumption that sizeof(enum blargh) == sizeof(int) |
20:11:16 | preglow | any language support to fix that, or do we need to go compiler flags? |
20:11:46 | amiconn | We could compile with long enums - but imo it would be much better to fix doom |
20:12:25 | amiconn | It would mean to compile the whole thing with long enums - if you compile just doom that way, the plugin won't be compatible with the core anymore |
20:14:09 | | Quit CGL (Remote host closed the connection) |
20:16:05 | amiconn | funman (for the logs): eabi (gcc 4.4.3) is ~15% faster than old abi on the beast, but even slower (!) than old abi on PP5022 (Mini G2) - by ~4% |
20:17:03 | * | amiconn thinks that PP would be better off with thumb for most C code, due to the memory interface |
20:19:31 | kugel | I doubt fixing doom is going to happen anytime soon |
20:23:26 | pixelma | we could also just get rid of doom ;) |
20:23:52 | * | kugel would actually prefer that |
20:24:06 | amiconn | kugel: Imo it's not even difficult - it's just a lot of work |
20:24:15 | amiconn | Iirc it's "just" the settings code |
20:24:32 | kugel | the settings code is easy to fix |
20:24:36 | * | amiconn wonders whether current prboom may even have that fixed already |
20:24:46 | kugel | I did that and I even got to the main menu, but it then crashed |
20:24:50 | amiconn | (iirc rockdoom is based on that) |
20:25:02 | kugel | the main menu=where you choose the difficulty, i.e. in-game |
20:26:00 | amiconn | Did you actually fix the enum types, or just add a high-value sentinel? |
20:26:28 | kugel | not sure right now |
20:27:14 | kugel | ah, I simply made them int :p |
20:28:24 | amiconn | Hmm. Just the settings code? |
20:28:40 | | Quit bmbl (Quit: Bye!) |
20:29:24 | kugel | amiconn: yes. this is just the settings "fixed" http://pastie.org/954121 |
20:29:48 | amiconn | So there are probably some more enums hiding in other parts :\ |
20:30:08 | amiconn | Enums which aren't handled properly wrt pointers, that is |
20:31:10 | amiconn | Hmm, also booleans of course |
20:31:28 | kugel | amiconn: debian has armel prboom packages |
20:32:13 | kugel | aww, linux generally uses long enums, doesn't it? |
20:32:48 | * | amiconn doesn't know |
20:35:07 | | Join arbingordon [0] (~w@unaffiliated/arbingordon) |
20:39:56 | preglow | it seems eabi is only faster for targets that pretend to use hardfloat |
20:39:59 | preglow | we always use softfloat |
20:41:27 | | Join webguest33 [0] (~5fd1aa3e@giant.haxx.se) |
20:41:51 | | Join flydutch [0] (~flydutch@host224-59-dynamic.5-87-r.retail.telecomitalia.it) |
20:43:29 | | Quit webguest33 (Client Quit) |
20:44:35 | amiconn | EABI has a fundamental advantage though: It has clean handling of long calls (inserting veneers if necessary), so we can do away with -mlong-calls and the STATICIRAM hackery |
20:46:39 | preglow | yeah, that's the part i'm excited about |
20:48:03 | | Nick dfkt_ is now known as dfkt (~dfkt@unaffiliated/dfkt) |
20:54:57 | amiconn | I think that most of the performance differences are not due to eabi vs. old abi, but rather due to the different gcc versions |
20:55:25 | preglow | most definitely |
20:55:38 | preglow | but eabi should give a good size difference |
20:56:32 | amiconn | Yeah, at least for targets where we're using long calls |
20:57:18 | amiconn | rockbox.ipod for Mini G2: old abi 542KB, eabi 486KB |
21:00 |
21:04:23 | | Quit Horscht (Quit: Verlassend) |
21:05:14 | | Quit robin0800 (Remote host closed the connection) |
21:05:28 | CIA-5 | New commit by amiconn (r25937): Revert r25929. Test have shown that the assembler code is more than 50% faster than the C code both on ARM7TDMI (tested on PP5002 and PP5022) and on ... |
21:09:22 | | Join wincent [0] (~wincent@f050128140.adsl.alicedsl.de) |
21:10:16 | | Quit JohannesSM64 (Quit: WeeChat 0.3.3-dev) |
21:10:47 | * | kugel votes for long enums and eabi *now* |
21:10:59 | kugel | short enums aren't worth the delay. nobody is going to do the work |
21:11:26 | | Join M3DLG [0] (~M3DLG@212.183.140.36) |
21:11:55 | kugel | according http://wiki.debian.org/ArmEabiPort linux does the same |
21:12:04 | CIA-5 | New commit by Buschel (r25938): Minor speed up (+3%) of iPod Video screen updates. |
21:13:28 | kugel | does anyone disagree? |
21:14:45 | Unhelpful | where do we actually still need to do the work? |
21:14:48 | | Quit Xerion (Quit: ) |
21:15:00 | amiconn | What about booleans? |
21:15:11 | Unhelpful | but yeah, going forward short enums will probably not be good for portability w/ POSIX software |
21:15:55 | kugel | amiconn: booleans aren't handled differently AFAIK. their also 1byte with the current abi |
21:16:06 | amiconn | Sure? |
21:16:11 | kugel | quite |
21:16:14 | amiconn | Then doom would probably crash |
21:16:34 | kugel | I've had sizeof(bool) == 1 a few times |
21:16:54 | kugel | it may still be luck that doom doesn't crash |
21:17:33 | kugel | I've not heard that eabi changes boolean behavior anywhere |
21:17:41 | amiconn | The doom settings code also assumes sizeof(bool) == sizeof(int). Your settings code patch shows that |
21:18:03 | kugel | and doom does not crash with -fno-short-enums, try it yourself |
21:18:28 | kugel | I only replaced bool for the sake of safety, I didn't have problems with particular bool variables |
21:18:51 | kugel | my patch shows nothing w.r.t. bool |
21:20:33 | | Join Horscht [0] (~Horscht2@xbmc/user/horscht) |
21:20:47 | | Quit Horscht (Client Quit) |
21:21:19 | * | Unhelpful thought bool was "whatever size is convenient/efficient" too, and generally was a platform int? |
21:21:46 | Unhelpful | also isn't bool in rockbox a typedef? |
21:23:58 | kugel | Unhelpful: it's whatever gcc wants it to be |
21:24:07 | Unhelpful | hrm, it's in a compiler-provided header, actually. #define bool _Bool :) |
21:24:13 | | Join Horscht [0] (~Horscht2@xbmc/user/horscht) |
21:24:36 | kugel | we get it from stdbool.h, which is not part if our source but (I think) of the gcc distribtion |
21:24:42 | amiconn | -bool rotate_screen=0; |
21:24:42 | amiconn | +int rotate_screen=0; |
21:24:48 | amiconn | Just one example |
21:25:01 | kugel | so what? |
21:25:10 | Unhelpful | _Bool must be compiler-defined? |
21:25:17 | kugel | I changed it, but it doesn't mean it was problematic |
21:25:30 | kugel | Unhelpful: _Bool is a c99 type |
21:25:35 | kugel | so I guess yes |
21:25:57 | Buschel | hmm, using 24MHz clock on svn builds does not reliably work anymore on PP502x targets. e.g. when switching to 24MHz by hand and trying to measure the fps rate via test_fps plugin. |
21:25:58 | amiconn | It probably is |
21:26:03 | * | amiconn needs to grep a bit |
21:26:11 | kugel | amiconn: just run doom without changes but -fno-short enums, and see yourself that it runs |
21:26:23 | Buschel | the plugin does not load due to the DMA change which is configured to run at speeds >24 MHz |
21:26:37 | amiconn | Did you run it on the Beast or e200 or another portrait screen target? |
21:26:45 | kugel | e200 and fuze |
21:26:59 | Buschel | ATA DMA read not working @24 MHz on svn builds -> is this acceptable? |
21:27:24 | kugel | Buschel: there's an error. there are no svn builds with 24MHz :) |
21:27:45 | kugel | which is why it probably is acceptable |
21:27:46 | Buschel | kugel: you can enable 24 MHz in the engineering menu |
21:27:53 | kugel | oh really? |
21:28:09 | Buschel | yes, but of course this a "hands off" menu for standard users |
21:29:25 | amiconn | kugel: The reason why I'm asking is the following: Doom doesn't use 'bool' - it uses 'boolean' all over |
21:29:47 | amiconn | And 'boolean' is an enum (!) when compiling doom as C - see doomtype.h |
21:30:04 | amiconn | The only exception is rotate_screen, because that was added by us |
21:30:46 | | Quit M3DLG (Ping timeout: 240 seconds) |
21:30:50 | kugel | would that matter if bool is 1 byte in the old abi too? |
21:30:59 | kugel | hm, I guess it does |
21:31:07 | amiconn | It would |
21:31:25 | amiconn | It could be that we're just lucky and alignment make it work |
21:31:34 | amiconn | But imo we shouldn't rely on that |
21:31:42 | amiconn | *makes |
21:32:13 | amiconn | bool size differs between architectures. It might also differ between arm old abi and eabi |
21:32:38 | amiconn | Iirc it is 1 byte on SH1 as well (but can be changed with a compiler option) and 4 byte on CF |
21:33:24 | kugel | well, if we do long enums that doom's bool is fixed by that too |
21:33:24 | Hillshum | 4 is a lot of bytes for dealing with a bool |
21:34:56 | amiconn | Hmm, no such compiler option |
21:34:57 | kugel | isn't it? |
21:35:01 | | Join stoffel [0] (~quassel@p57B4AA54.dip.t-dialin.net) |
21:36:06 | Unhelpful | we could redef bool == int ourselves ;) |
21:37:25 | amiconn | Well if we use 'boolean' instead of 'bool' in doom for rotate_screen *and* use long enums, it would work of course |
21:41:43 | kugel | so, let's do it |
21:41:53 | kugel | I don't think short enums is a huge advantage anyway |
21:42:20 | amiconn | Imo it is an advantage |
21:42:33 | kugel | yes, but not huge |
21:42:39 | amiconn | The question is just whether we should do it at the same time as the eabi switch |
21:42:59 | kugel | we can of course fix doom later |
21:43:02 | amiconn | Did you compare binsize and ram usage with and without short enums? |
21:43:11 | kugel | no |
21:43:58 | | Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) |
21:44:23 | | Quit kugel (Remote host closed the connection) |
21:45:44 | amiconn | Ah, gcc for osx has a command line switch: -mone-byte-bool |
21:45:54 | amiconn | Default is 4 bytes there, obviously |
21:46:10 | amiconn | (PPC only) |
21:47:20 | amiconn | Our doom code is quite different from latest prboom |
21:48:06 | amiconn | Prboom still has that wrong settings handling though - they extended settings, and replaced the (void*) with (int*) |
21:48:21 | *** | Saving seen data "./dancer.seen" |
21:48:25 | Unhelpful | compile with and without short enums and compare? easy enough to do. |
21:49:27 | | Part watto1 |
21:55:51 | amiconn | I'm just trying it, and found that it's not that simple |
21:55:55 | | Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) |
21:56:11 | amiconn | For this to work, libgcc needs to be built using long enums as well |
21:57:18 | amiconn | Otherwise it throws a lot of warnings, and the result will be inconsistent and probably crash |
21:57:39 | | Quit wombat23 (Ping timeout: 240 seconds) |
21:58:18 | | Quit n17ikh (Ping timeout: 276 seconds) |
22:00 |
22:03:36 | | Join Xerion_ [0] (~xerion@82-170-197-160.ip.telfort.nl) |
22:03:39 | | Quit Xerion (Ping timeout: 265 seconds) |
22:03:48 | | Nick Xerion_ is now known as Xerion (~xerion@82-170-197-160.ip.telfort.nl) |
22:04:11 | | Quit joeyg (Quit: WeeChat 0.3.0) |
22:05:43 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
22:06:20 | amiconn | Hmm, if this preliminary result can be trusted, -fno-short-enums reduces binsize a tiny bit (tested with a beast build) |
22:07:21 | amiconn | Just 80 bytes. RAM usage shrinks a little less (64 bytes), meaning 16 bytes bss increase |
22:08:03 | * | amiconn thinks we could indeed live with that, but rockboxbuild.sh and/or our arm patch needs fxing/ extension for -fno-short-enums |
22:09:29 | amiconn | Buschel: Btw, alternating registers shouldn't matter at all on PP - ARM7 has no interlocks like this |
22:10:13 | amiconn | It's interesting though that 2 regs/ copy instead of 4 regs is faster |
22:12:43 | Buschel | amiconn: the idea was to read next registers during the both are still written. this is the outcome |
22:13:14 | amiconn | Did you try reusing the same two registers? It should end up exactly the same |
22:15:43 | Buschel | I am not 100% sure and need to re-test |
22:17:48 | Buschel | building will take some time... |
22:23:09 | Buschel | amiconn: any idea why this is faster? |
22:23:18 | amiconn | The effect might indeed be writing in the background - but if it is, it's a memory controller thing. The core is synchronous |
22:24:52 | | Quit Hillshum (Ping timeout: 264 seconds) |
22:25:19 | | Quit stoffel (Remote host closed the connection) |
22:25:41 | | Quit domonoky1 (Read error: Connection reset by peer) |
22:25:55 | Buschel | also: when reading 4 regs and writing them and then read other 4 regs and writing then (so: 4:4 instead of 2:2:2:2) is exactly as fast as svn. |
22:27:29 | Buschel | what is a hint towards your expectation that using the same 2 regs will be as fast as svn with my change |
22:29:26 | * | amiconn wonders whether Buschel also tried 3-3-2 |
22:29:41 | | Join Hillshum [0] (~hillshum@75-165-237-188.slkc.qwest.net) |
22:29:51 | Buschel | amiconn: I tried. Faster than 4:4 but slower than 2:2:2:2 |
22:30:12 | Buschel | amiconn: btw, using the same two registers is the same than alternating them |
22:30:17 | Buschel | speed wise |
22:30:37 | mt | It seems for now I'll use AVCodecContext to hold the data for the wma pro decoder ... |
22:34:30 | amiconn | hmm, interesting indeed |
22:35:58 | CIA-5 | New commit by Buschel (r25939): No need to use alternating registers for dual register read/write sequence. Correct comment. |
22:36:23 | Buschel | r25939 to avoid misunderstanding of the code/changes |
22:37:29 | amiconn | Now you could also save the saving of r4 and lr, for a tiny bit of extra speedup |
22:38:12 | amiconn | Use r12 instead of lr for the data port |
22:38:53 | amiconn | Oh, of course you'd need to fix up the 4-word case as well |
22:39:16 | Buschel | I remember this to be slower for the 1:4 screen test. |
22:40:30 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
22:42:54 | amiconn | Really? |
22:43:25 | amiconn | That's weird - why would the same change cause a slowdown in the 4-word case if it causes a speedup in the main loop? |
22:44:31 | amiconn | Of course too many conditional instructions are bad - even if the condition isn't met, they will act like a 'nop' i.e. consume one cycle each |
22:45:19 | Buschel | because it will not peform the load/store and go just walk through (width/2 = 160, 160%16 = 0) |
22:45:41 | * | amiconn thinks that the tail can be optimized with a computed branch |
22:45:41 | Buschel | *just walk through |
22:45:43 | | Join apoelstra [0] (~apoelstra@S010600236999fec1.vs.shawcable.net) |
22:46:00 | | Join Ipsi [0] (~Ipsilon@adsl-69-104-40-127.dsl.scrm01.pacbell.net) |
22:46:28 | | Nick apoelstra is now known as joeyg (~apoelstra@S010600236999fec1.vs.shawcable.net) |
22:46:43 | Buschel | amiconn: is the lcd updated more in the 1:1 fassion or in updating non-1:1-rectangles? |
22:47:23 | Buschel | (weird sentence) |
22:48:08 | * | amiconn doesn't understand it |
22:48:20 | Buschel | :o) let me try again |
22:49:05 | Buschel | when using the gui -> are most of the lcd updates fullscreen or part screen? |
22:49:27 | Buschel | (hopefully better to understand) |
22:49:46 | amiconn | I don't know. |
22:50:10 | amiconn | There are probably all sorts of partial updates, depending on the theme, plus some fullscreen ones |
22:51:58 | Buschel | ok |
22:55:34 | amiconn | preglow: Are you planning to do something about the lack of arm asm for 24 bit flac? |
22:55:49 | Buschel | good night! |
22:55:53 | | Quit Buschel () |
22:58:15 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
23:00 |
23:12:55 | | Quit DerPapst (Quit: Leaving.) |
23:13:44 | pixelma | test_mem is weird at least on my M5 - the "boosted", "unboosted" doesn't seem to mean anything if I believe the other numbers (clock and DRAM/IRAM rd and wr - which change in a way that make sense) |
23:14:14 | pixelma | and sometimes it just exits without me doing anything and I don't see a pattern |
23:15:47 | | Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) |
23:23:04 | | Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
23:30:20 | | Quit petur (Remote host closed the connection) |
23:33:10 | | Join wodz [0] (~wodz@chello087206240004.chello.pl) |
23:38:03 | wodz | amiconn: Could You look at http://www.pastie.org/954462? I think it should fix unaligned reads |
23:39:36 | | Quit Xerion (Quit: ) |
23:48:25 | *** | Saving seen data "./dancer.seen" |
23:50:02 | wodz | In my opinion test_mem should use memcpy/memset to test memory operation speed. It can include also tests for DRAM<->IRAM copy (but don't know if this types of transfers are in use in rockbox) |
23:50:47 | | Quit M3DLG (Read error: Connection reset by peer) |
23:56:37 | | Join fml [0] (~chatzilla@port-83-236-234-85.static.qsc.de) |
23:57:34 | | Join bluebro [0] (~4d2c4024@gateway/web/freenode/x-weofialziviwrkbw) |
23:57:58 | fml | A note for Blue_Dude: now that the possible hotkey options are explicitly listed in the settings, I don't see the need for the flags HOTKEY_CTX_xxx. They can be dropped IMO. |
23:58:05 | | Quit bluebro (Changing host) |
23:58:05 | | Join bluebro [0] (~4d2c4024@rockbox/developer/bluebrother) |
23:58:28 | | Quit fml (Client Quit) |