| 00:02:17 | | Join Rob2223 [0] (~Miranda@p4FDCBA5F.dip.t-dialin.net) |
| 00:06:08 | | Quit Rob2222 (Ping timeout: 272 seconds) |
| 00:06:09 | | Quit ecio1 (Read error: Connection reset by peer) |
| 00:06:39 | | Join ecio [0] (~ecio@244-108.202-68.tampabay.res.rr.com) |
| 00:17:41 | | Quit MaadMan (Quit: Verlassend) |
| 00:20:03 | | Join phanboy4 [0] (~benji@gate-20.spsu.edu) |
| 00:23:39 | Unhelpful | saratoga: that's what i was thinking, if the CPU is running at about 2x bus speed then presumably it can only load about every other cycle... perhaps a few fetches can queue depending on how things work but obviously it can't transfer data 2x as fast as the bus. |
| 00:24:41 | Unhelpful | but nicely-scheduled loads on arm9tdmi should only take 1c... i wonder if you can even avoid stalling for memory latency if the load is scheduled early enough? |
| 00:26:09 | | Quit Llorean (Read error: Connection reset by peer) |
| 00:27:53 | saratoga | Unhelpful: i know on ARM7TDMI the best you can hope to do is hide the load latency by doing a slow multiply right before hand |
| 00:27:57 | saratoga | i don't know about arm9 |
| 00:28:41 | saratoga | i can't remember how well seperated teh cache and load/store hardware are |
| 00:28:56 | Unhelpful | saratoga: i thought arm7tdmi was pretty much strictly in-order? |
| 00:28:58 | saratoga | i guess it probably does keep fetching the rest of the cache line after a load though |
| 00:29:24 | saratoga | unhelpful: its in order yes, but a mul takes 5 clocks or so, so if you issue a mul, then a load, both can be done in parallel and still retire in order |
| 00:29:37 | saratoga | i don't think it locks the load/store hardware while doing the mul |
| 00:30:00 | Unhelpful | also load on arm7 has 3c throughput :/ |
| 00:30:09 | saratoga | isn't it 2c? |
| 00:30:26 | Unhelpful | don't think so, no. |
| 00:30:31 | saratoga | one clock to load the instruction, then one clock to load the register? |
| 00:30:38 | saratoga | i thought it only stalled because of the 32 bit wide bus |
| 00:30:45 | saratoga | and a load only takes 64 bits |
| 00:30:55 | saratoga | so i would expect it to sustain a load every other cycle |
| 00:30:58 | saratoga | best case |
| 00:31:36 | Unhelpful | ASDG gives load as being 3c to execute |
| 00:32:02 | saratoga | latency or throughput? |
| 00:32:10 | Unhelpful | arm7tdmi doesn't have nearly as many nice 1c pipelined instructions, aside from basic ALU stuff. |
| 00:32:11 | saratoga | i thought on the last cycle you could start issuing the next load |
| 00:32:31 | Unhelpful | the ASDG tables are all throughput, latency if any goes in a notes column. |
| 00:32:38 | saratoga | if not thats really stupid, since the LDM takes 1 +N cycles IIRC |
| 00:33:10 | Unhelpful | 2+N - so LDM 1 reg == LDR |
| 00:33:43 | saratoga | ah |
| 00:33:55 | saratoga | whats the link for this I should review it |
| 00:34:02 | saratoga | i obviously can't remember what i've read |
| 00:35:01 | Unhelpful | docstoc and google books both have ASDG, google books as rather a lot of pages not available though. |
| 00:35:50 | | Quit ender` (Quit: We know the speed of light... so, what's the speed of darkness?) |
| 00:35:51 | Unhelpful | the fact that timing tables for everything from arm7tdmi to arm11 are all in a row at the end makes it a really wonderful reference for this |
| 00:36:04 | saratoga | hmm my player turned off mid test_codec |
| 00:36:27 | saratoga | is there a way to tell rockbox to not use the idle power off while in USB charge mode? |
| 00:37:41 | | Quit petur (Quit: zzzzz) |
| 00:38:38 | Unhelpful | saratoga: it shouldn't during test_codec, but amiconn and i both had trouble with this happening on PP during high-profile APE testing. |
| 00:39:29 | | Join karashata [0] (~karashata@74-220-162-11.wightman.ca) |
| 00:41:23 | saratoga | yeah maybe I should have removed APE |
| 00:41:43 | | Quit bmbl (Quit: Bye!) |
| 00:41:46 | Unhelpful | his theory was that 1) power management gets confused when codec doesn't yield often enough or 2) sustained running at max clock might actually be draining the battery, even on charger. |
| 00:42:37 | saratoga | its not doing that on e200v1 |
| 00:42:48 | saratoga | i can run it with no battery at all off of USB power |
| 00:43:03 | saratoga | and it only draws 120mA with the screen on and the CPU boosted |
| 00:44:00 | Unhelpful | per ASDG arm7tdmi has a 3-stage pipeline and generally instruction execution times don't depend on preceding/following instructions. can't do other things during those up-to-5c multiplies. :/ |
| 00:44:22 | stripwax | saratoga/mt - looks like cook uses clip_to_15 but I thought that wasn't needed (I thought dsp did all that) |
| 00:45:18 | saratoga | stripwax: its not |
| 00:45:33 | saratoga | we have a patch somewhere to remove it but it made the codec prefetch abort |
| 00:45:37 | saratoga | we had no idea why |
| 00:45:51 | saratoga | but yes it should be removed |
| 00:46:07 | stripwax | hah. ok. also the implementation of clip |
| 00:46:11 | Unhelpful | is this a range limit on output or are some internal values being clipped and then used for further calculation? |
| 00:46:24 | stripwax | _to_15 in dsp is only two instructions; in codeclib it's 5. |
| 00:47:51 | stripwax | Unhelpful - output. |
| 00:49:04 | Unhelpful | stripwax: i count 3c - y = x >> 15, test y = x >> 31, do clip |
| 00:49:15 | | Quit Omlet (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 00:50:18 | stripwax | Unhelpful - I have no idea what you just said :) teq %0, %0, asr #31 ; eorrne %0, %1, %0, asr #31 ; where %1 = 0xffff7fff |
| 00:50:58 | stripwax | oh. um. hang on. maybe it is three :-p |
| 00:51:12 | stripwax | anyway, point is, it's less than five :-) |
| 00:51:49 | Unhelpful | stripwax: i'm looking in dsp_arm.S. you can do this clip operation in 3c if you can maintain a constant in a register for it, or 4c if not, but i could *not* get gcc to achieve either of these w/ C code. |
| 00:52:29 | stripwax | ah. yep. by '3c' you mean 3 cycles? sorry, just didn't understand what you were saying that's all. yep |
| 00:54:04 | Unhelpful | stripwax: sorry, yes. 3 cycles. it looks like the inline in codeclib could be made at least 1 cycle shorter. |
| 00:54:40 | stripwax | right. it's only used in one tight loop, i'm sure you can keep the mask in a register |
| 00:55:03 | stripwax | i.e. output_math in cook_fixpoint.h |
| 00:55:19 | stripwax | but eliminating it altogether is a better approach in any case |
| 00:57:31 | *** | Saving seen data "./dancer.seen" |
| 00:57:55 | Unhelpful | the one in codeclib seems to use some rather non-obvious methods... two tests? mov %1, %0, asr #15; teq %1, %0, asr #31; eorne %2, %0, asr #31; w / mask in %2, input/output in %0, tmp %1. |
| 00:58:36 | stripwax | saratoga - i couldn't see any patch in tracker, somewhere else? |
| 00:59:26 | stripwax | Unhelpful - yeah we just want to eliminate it. afaict only cook uses it, and that shouldn't. |
| 00:59:26 | Unhelpful | also, why subs/adds when the output is discarded? cmp/cmn would make the codeclib 5 cycles but avoid use of other registers. |
| 00:59:46 | | Quit BlakeJohnson86 (Quit: Leaving.) |
| 00:59:55 | | Join Rob2222 [0] (~Miranda@p4FDCB06B.dip.t-dialin.net) |
| 01:00 |
| 01:00:26 | | Join BlakeJohnson86 [0] (~bjohnson@2002:1876:a27b:0:227:13ff:fe65:1262) |
| 01:01:31 | | Join Guest23293 [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 01:01:58 | | Quit n17ikh (Disconnected by services) |
| 01:02:00 | | Quit Guest23293 (Client Quit) |
| 01:02:16 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 01:02:28 | | Quit stripwax (Quit: http://miranda-im.org) |
| 01:03:46 | | Quit Rob2223 (Ping timeout: 272 seconds) |
| 01:08:02 | saratoga | stripwax: probably passed on IRC or gtalk |
| 01:08:09 | saratoga | mt and i both had commit so we didn't use the tracker |
| 01:08:29 | saratoga | the patch should have been trivial though, just change the DSP bits and drop teh clip function |
| 01:08:40 | | Quit koniiiik_ (Ping timeout: 276 seconds) |
| 01:10:15 | saratoga | TheSeven: http://pastebin.com/m108d0c98 |
| 01:10:19 | saratoga | probably going to commit this |
| 01:10:23 | saratoga | very helpful for test codec |
| 01:10:27 | saratoga | or maybe just put it in the wiki |
| 01:14:36 | saratoga | heh wiki adds a .txt to my perl script |
| 01:20:18 | | Join iq [0] (~chatzilla@unaffiliated/iq) |
| 01:20:20 | iq | Hi |
| 01:20:27 | saratoga | TheSeven: would you mind posting the raw test_codec logs so I can update the wiki? |
| 01:21:07 | saratoga | bah this is making me want to fix aac-he so that test_codec is quicker . . . |
| 01:21:08 | TheSeven | r24711 noeabi: http://pastie.org/834326 |
| 01:21:20 | TheSeven | r24786 noeabi: http://pastie.org/834332 |
| 01:21:48 | TheSeven | r24786 eabi: http://pastie.org/834822 |
| 01:27:53 | saratoga | TheSeven: added |
| 01:28:31 | saratoga | opps bug in my parser |
| 01:30:16 | | Quit avacore (Ping timeout: 252 seconds) |
| 01:30:18 | iq | My clip+ booloader build is failing, any known issues ? |
| 01:30:38 | | Quit hebz0rl (Quit: Ex-Chat) |
| 01:32:33 | TheSeven | failing in terms of what? compilation errors? can you pastebin them? |
| 01:32:42 | | Join avacore [0] (nobody@1008ds1-rdo.0.fullrate.dk) |
| 01:35:46 | iq | http://www.pastebin.com/m4cb5479 |
| 01:37:56 | saratoga | delete the build directory and try again |
| 01:38:09 | iq | ok |
| 01:38:49 | saratoga | i am baffled by this perl problem with TheSeven's log |
| 01:39:40 | saratoga | print "$key"; does nothing but print "$key\n" works fine |
| 01:40:37 | iq | http://www.pastebin.com/m69495a56 |
| 01:40:46 | TheSeven | what if you just remove the quotes? |
| 01:41:44 | TheSeven | why should [u]modsi3 use floating point? |
| 01:42:51 | saratoga | what revision is this? |
| 01:43:29 | | Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) |
| 01:43:36 | gevaerts | iq: was that compiler built by rockboxdev.sh? |
| 01:44:46 | iq | gevaerts: I downloaded the VMWare image. So whatever was in there. |
| 01:44:49 | saratoga | heh perl's chomp can't handle windows line endings |
| 01:44:50 | saratoga | awesome |
| 01:45:16 | saratoga | iq: try running rockboxdev.sh to rebuild the compilers |
| 01:45:30 | saratoga | theres directions on the wiki |
| 01:45:35 | iq | saratoga: ok |
| 01:45:37 | gevaerts | yes, it does look like a dodgy compiler install |
| 01:45:48 | saratoga | its possible the vmware tool chain can't build for the clip+ for whatever reason |
| 01:46:39 | iq | I was able to build the rockbox without errors. |
| 01:46:50 | saratoga | but not for the clip+ |
| 01:46:56 | iq | And I was able to build Clip bootloader as well. It is just problem with Clip+ bootloader. |
| 01:47:07 | iq | saratoga: yes for Clip+ |
| 01:47:56 | | Quit nimak (Ping timeout: 252 seconds) |
| 01:48:42 | | Quit mt (Ping timeout: 240 seconds) |
| 01:48:48 | saratoga | iq: i don't even think its possible to build for the clip+ |
| 01:49:19 | iq | saratoga: okay, I will take your word for that, I just got involved with it today :) |
| 01:50:01 | iq | running rockboxdev.sh - will report later. |
| 01:50:21 | | Join nima [0] (~nima@adsl-75-45-238-211.dsl.sfldmi.sbcglobal.net) |
| 01:55:58 | saratoga | WMA on the 2G is a full 20% faster with the new mdct lib |
| 01:56:00 | saratoga | thats amazing |
| 01:58:21 | saratoga | strangely most other codecs got a much smaller improvement |
| 01:58:25 | saratoga | i wonder why WMA is so special |
| 01:58:49 | TheSeven | wasn't wma extraordinarily slow before? (compared to other targets) |
| 01:59:07 | TheSeven | how is the vorbis : mp3 : wma ratio for nano2g, and for other players? |
| 02:00 |
| 02:00:09 | TheSeven | iirc we did a test once where we removed the mdct calls from the wma codec in order to check what's causing that, and removing them made it behave much better in comparison |
| 02:00:27 | TheSeven | so it's rather obvious why this gains most from a faster mdct |
| 02:01:30 | | Join Strife89 [0] (~Strife89@adsl-220-102-6.mcn.bellsouth.net) |
| 02:04:02 | | Join AsaelReiter [0] (~d44c72e0@giant.haxx.se) |
| 02:07:11 | | Quit mirak_ (Quit: Ex-Chat) |
| 02:07:30 | iq | that's funny. I ran out of disk space on my Virtual Machine :) |
| 02:08:21 | Unhelpful | TheSeven: it needn't actually use the instructions, object files are flagged for certain features which may cause incompatibilities, whether those feature are exercised or not. try linking object files that use short enums with ones that don't, even if neither is built from code that uses enums. |
| 02:08:47 | iq | I will try checking out code in my Fedora and run rockboxdev.sh. Thanks for your help. bye for now |
| 02:08:50 | saratoga | TheSeven: theres 6 codecs all using the same MDCT |
| 02:09:04 | saratoga | i don't see why WMA should have been different then vorbis for instance |
| 02:09:14 | TheSeven | saratoga: looks like wma uses more of them / more often :-) |
| 02:09:43 | Unhelpful | saratoga: if a larger portion of WMA's time is spent on mdct then it will show a larger % increase from mdct improvement... |
| 02:10:23 | saratoga | they both use the MDCT more or less the same |
| 02:11:31 | | Quit iq (Quit: ChatZilla 0.9.86 [Firefox 3.5.5/20091102152451]) |
| 02:11:54 | Unhelpful | saratoga: in terms of number of MDCTs to decode X samples? how complex are the non-mdct parts? even if they spend as much *time* in MDCT if vorbis spends more time in its other code it will see less improvement in % terms |
| 02:12:12 | saratoga | they started taking almost identical decode times |
| 02:12:43 | saratoga | but WMA apparently got 11MHz faster, while vorbis only about 5 |
| 02:13:13 | saratoga | only thing i can think of is that long blocks are somehow a lot slower then short blocks, and vorbis uses a lot more long blocks then wma |
| 02:14:22 | saratoga | time to compare PP and see if thats teh same . . . |
| 02:14:49 | saratoga | what the fuck I didn't get a test_codec log |
| 02:14:57 | saratoga | and it ran through to completion |
| 02:15:16 | * | TheSeven also had that sometimes |
| 02:15:29 | TheSeven | seems to happen if you insert usb while test_codec is still running |
| 02:18:50 | saratoga | does fdprintf not write to the file immediately? |
| 02:20:16 | Unhelpful | saratoga: well surely complexity is >linear wrt block size? |
| 02:20:46 | TheSeven | saratoga: iirc it had something to do with writing the directory entry for it |
| 02:20:46 | saratoga | yes, n*logn |
| 02:20:55 | TheSeven | the log itself is probably somewhere on the storage |
| 02:21:08 | saratoga | but i wouldn't expect two codecs at the same bitrate to use tremendously different block sizes |
| 02:21:34 | TheSeven | after disconnecting, rockbox might panic because it tries to finish whatever was left storing it, and things have changed during the usb connection |
| 02:21:43 | Unhelpful | they might, i'm sure their long/short block selection is entirely different |
| 02:24:08 | saratoga | TheSeven: thanks, found it on the disk in a lost fragment |
| 02:24:08 | | Quit ecio (Read error: Connection reset by peer) |
| 02:25:21 | | Join ecio [0] (~ecio@244-108.202-68.tampabay.res.rr.com) |
| 02:25:23 | saratoga | TheSeven: any idea how to make test_codec more robust against lost data? |
| 02:25:31 | saratoga | the plugin didn't even crash so I'm surprised this happened |
| 02:25:35 | saratoga | it seemed to complete normally |
| 02:25:47 | TheSeven | it's probably still running in the background or something |
| 02:25:54 | TheSeven | or it just didn't close the log file handle |
| 02:26:46 | TheSeven | i don't know exactly what's going on inside, but this definitely isn't the first time such a thing happened... |
| 02:27:41 | TheSeven | and iirc the fat code doesn't do any write caching (or it would at least flush it prior to an unmount caused by usb connection), so it must be the plugin that's at fault here |
| 02:28:35 | saratoga | Unhelpful: my recovered logs indicate that on PP WMA and Vorbis get identical speed ups |
| 02:28:48 | saratoga | so its not the transform, but something special about the nano2g |
| 02:28:58 | | Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp) |
| 02:29:09 | saratoga | perhaps we inadvertently fixed something else |
| 02:31:42 | | Join ecio1 [0] (~ecio@244-108.202-68.tampabay.res.rr.com) |
| 02:31:42 | | Quit ecio (Read error: Connection reset by peer) |
| 02:36:06 | saratoga | WMA is now 1.74 times as fast as it was on Stripwax's original test 4 days after it was committed |
| 02:36:43 | saratoga | and about 3.75 times as fast as the very first time I tried to play a WMA file in rockbox on my Sansa |
| 02:42:14 | Unhelpful | 1.74 *times* as fast? yikes. |
| 02:44:48 | | Join Uretti [0] (~chickaan@cpc4-warw14-2-0-cust208.know.cable.virginmedia.com) |
| 02:47:42 | saratoga | the first factor of two speed up was so much easier, took me a day or so and all I had to do was add some IRAM and assembly optimized MUL functions :) |
| 02:47:57 | saratoga | the next factor of 1.75 took me 2.5 years . . . |
| 02:48:35 | saratoga | i just noticed theres an open source DTS codec, so in theory we could add libdca as a codec |
| 02:48:43 | saratoga | though i guess no one wants to use DTS in rockbox |
| 02:50:07 | Unhelpful | saratoga: on beast. in mpegplayer. ;) |
| 02:50:42 | saratoga | yeah |
| 02:50:51 | saratoga | ac3 would make a lot of sense for mpegplayer |
| 02:51:00 | saratoga | since its a valid mpeg audio codec and its way faster then mp3 |
| 02:51:14 | saratoga | and also for doing dvds on the beast :) |
| 02:51:21 | Unhelpful | mpegplayer on beast might conceivably play VOBs straight from DVD if it had AC3 and DTS audio support |
| 02:51:27 | Unhelpful | yes, that is what i was thinking mostly. |
| 02:51:43 | Unhelpful | maybe support DVD-ROM drive via USB host? ;) |
| 02:52:18 | * | Unhelpful grumbles about how slow and/or useless mlas is on arm :/ |
| 02:52:29 | | Quit Tomis (Quit: Tomis) |
| 02:53:03 | saratoga | would closing the log and reopening it between files make it less likely to be corrupted in test_codec? |
| 02:53:03 | Unhelpful | it's as slow as a mul and an adds, *and* adds would set carry on the add result... although it would not set anything useful from the mul result |
| 02:53:13 | saratoga | i don't really understand why a file gets lost in the first place |
| 02:53:26 | Unhelpful | i would think so, i looked into that earlier and couldn't find any evidence that we had an fsync :/ |
| 02:55:30 | | Quit Strife89 (Quit: Reboot to investigate BIOS fan settings.) |
| 02:57:33 | *** | Saving seen data "./dancer.seen" |
| 02:57:49 | | Join moos [0] (moos@rockbox/staff/moos) |
| 02:59:06 | saratoga | Unhelpful: think this will help? http://pastebin.com/m43149808 |
| 03:00 |
| 03:00:51 | Unhelpful | saratoga: i'd think so, but i don't really know why it should in the case that test_codec completes without hanging. |
| 03:01:06 | Unhelpful | i don't really know why anything should go wrong in that case. :/ |
| 03:01:38 | | Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 03:01:53 | saratoga | could be a codec error or something |
| 03:01:54 | | Join Strife89 [0] (~Strife89@adsl-220-102-6.mcn.bellsouth.net) |
| 03:02:54 | notByan | I just noticed that in my new bleeding edge build, my ipod 5G line out now uses volume control and EQ |
| 03:03:02 | notByan | whats with that? |
| 03:03:29 | saratoga | that sounds like a bug |
| 03:03:36 | saratoga | when was the last build that didn't do it? |
| 03:04:20 | notByan | I only have bleeding edge because I like to make a small edit on the source code |
| 03:04:25 | saratoga | actually I bet I know |
| 03:04:28 | saratoga | "Allow volume control down to -90 dB for WM8758 (e.g. iPod Video). (FS #10082)" |
| 03:04:28 | notByan | I don't really keep up to date with it |
| 03:04:36 | saratoga | sounds likely to be the commit in question |
| 03:04:56 | TheSeven | saratoga: this one shouldn't have anything to do with the eq, but it would have been my first quess, too |
| 03:05:13 | TheSeven | but this was before 3.5 |
| 03:05:27 | saratoga | "When lowering the volume below -57dB the lineout is also affected." |
| 03:05:43 | TheSeven | notByan: does this also happen with the 3.5 release? |
| 03:05:46 | saratoga | well that seems easy enough to work around, don't lower the volume below -57dB |
| 03:05:58 | notByan | saratoga: but.. the EQ? |
| 03:06:16 | | Join Tomis [0] (~Tomis@70.134.99.142) |
| 03:06:33 | saratoga | line out always used EQ |
| 03:06:38 | saratoga | if thats what you're asking |
| 03:07:15 | notByan | TheSeven: I have no idea, as I said, I've been using bleedge edge cause I need to build it to make the small cahgne anyway |
| 03:07:18 | notByan | saratoga: you sure... |
| 03:07:22 | notByan | cause I could've sworn.. |
| 03:07:44 | saratoga | EQ is done in software like a mile upstream of the DAC |
| 03:08:00 | notByan | weird |
| 03:08:05 | saratoga | changes the output line on the DAC has no impact on how DSP software in rockbox works |
| 03:08:06 | notByan | I must be crazy then |
| 03:08:24 | saratoga | only thing i can think of that might be confusing here is that theres some hardware bass boost on the DAC or something |
| 03:08:26 | Unhelpful | a device couldn't support (software) EQ on one output and not another unless there were two DACs |
| 03:08:32 | TheSeven | saratoga: aren't we also using hardware eqs on some targets at least? |
| 03:08:47 | saratoga | maybe, but i think thats not even available from the EQ screen |
| 03:09:27 | notByan | I am very tempted to put my old build on here and see what happens |
| 03:09:27 | TheSeven | iirc (and i have only very briefly looked at that kind of stuff) on devices that support it, the more trivial eq settings are mapped to the hw eq |
| 03:10:22 | saratoga | if the hardware adjustments don't impact the line out I doubt thats possible to adjust in software |
| 03:10:23 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.3.50) |
| 03:11:06 | notByan | btw, I guess I was talking about the treble and bass settings in sound settings |
| 03:11:07 | notByan | not the EQ |
| 03:11:16 | notByan | I didn't even realize there was a seperate EQ menu |
| 03:11:19 | saratoga | yeah those are hardware |
| 03:11:31 | notByan | should they be effected the line out? |
| 03:11:32 | notByan | cause they are |
| 03:11:41 | notByan | effecting* |
| 03:12:36 | * | TheSeven doesn't see how this could change, as it is done in hardware... or is there a separate set of regs for this stuff on lineout which we are accidentally writing? can't really imagine that though... |
| 03:12:43 | * | Unhelpful imagines that may depend on the DAC etc |
| 03:12:45 | | Quit phanboy4 (Read error: Connection reset by peer) |
| 03:13:37 | TheSeven | well, he didn't change his dac, obviously... |
| 03:14:13 | | Quit GeekShadow (Read error: Connection reset by peer) |
| 03:14:17 | TheSeven | notByan: if possible, you should try the 3.5 build. this would help narrowing down where that issue is coming from. |
| 03:14:33 | notByan | yeah, sure |
| 03:14:45 | Unhelpful | TheSeven: i mean that whether it "should" effect line out would depend on the DAC and possibly its configuration. |
| 03:15:25 | notByan | so, help me understand something, where in hardware is the treble and bass stuff being EQ'ed? |
| 03:16:25 | notByan | I am gonna try my old build real quick and see if it happens there |
| 03:16:48 | saratoga | try pre 3.5 |
| 03:16:52 | saratoga | that has the DAC changes in it already |
| 03:17:09 | notByan | old build is pre 3.5 |
| 03:17:51 | saratoga | apps\plugins\fft needs to go away |
| 03:18:08 | saratoga | can you just do ../codecs/lib from inside a plugin or will that not work? |
| 03:18:48 | notByan | I don't think I even updated the apps/plugins/fft last time |
| 03:18:50 | notByan | hrm >_> |
| 03:19:09 | saratoga | notByan: I wasn't referring to you |
| 03:19:14 | notByan | oh |
| 03:19:52 | notByan | hrm, I guess I was crazy |
| 03:20:06 | notByan | but.. this release sounds much better.. |
| 03:20:35 | notByan | I thought it was in my head |
| 03:20:37 | notByan | but it definately does |
| 03:20:55 | notByan | r24513M-100204 |
| 03:21:00 | | Quit ecio1 (Read error: Connection reset by peer) |
| 03:21:06 | | Quit DerPapst (Quit: Leaving.) |
| 03:21:25 | * | notByan switches again to makes ure |
| 03:22:02 | | Quit TheSphinX^ (Ping timeout: 240 seconds) |
| 03:22:10 | | Join ecio [0] (~ecio@244-108.202-68.tampabay.res.rr.com) |
| 03:24:25 | | Quit n17ikh (Remote host closed the connection) |
| 03:25:37 | | Join TheSphinX^ [0] (~cold@p54A5C1AA.dip.t-dialin.net) |
| 03:26:23 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 03:32:33 | | Quit AsaelReiter (Quit: CGI:IRC) |
| 03:48:01 | JdGordon | teru: pong |
| 03:52:36 | teru | JdGordon: it seems like that file descriptor for font file doesn't seems to be closed when reloading skin file. |
| 03:53:17 | JdGordon | nuts, and I see why |
| 03:53:52 | CIA-8 | New commit by jdgordon (r24803): make sure font fd's get closed when a new skin is loaded |
| 03:56:12 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
| 03:59:48 | | Quit efyx_ (Remote host closed the connection) |
| 04:00 |
| 04:09:47 | | Quit TheSeven (Disconnected by services) |
| 04:09:59 | | Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) |
| 04:10:09 | | Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) |
| 04:11:48 | | Quit TheSphinX^ (Quit: XChat) |
| 04:15:44 | | Quit Strife89 (Read error: Connection reset by peer) |
| 04:20:43 | | Quit Res1 (Ping timeout: 240 seconds) |
| 04:32:32 | | Quit Adnyxo (Remote host closed the connection) |
| 04:33:19 | | Quit SeismicMike (Quit: Hwyl) |
| 04:44:52 | | Join Barahir_ [0] (~jonathan@gssn-5f756d1d.pool.mediaWays.net) |
| 04:47:30 | | Quit Barahir (Ping timeout: 240 seconds) |
| 04:57:37 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:01:46 | | Quit xavieran (Ping timeout: 256 seconds) |
| 05:26:04 | | Join qcjn [0] (~qcjn@modemcable013.166-83-70.mc.videotron.ca) |
| 05:29:53 | qcjn | hi, i 've got a sansa e280 V2, i like it, but one thing i don't like is the way the music is handled. I'd prefer to be able to see it, just as folder, would be easier to find. So i was wondering if rockbox does that, and if i'll lose the features like the radio, and recording that's on my sansa ? |
| 05:31:09 | S_a_i_n_t | qcjn: you can give Rockbox a 'trial run' by downloading the simulator |
| 05:31:29 | qcjn | oh, yeah, thats great |
| 05:31:44 | qcjn | i m on ubuntu |
| 05:31:53 | qcjn | does it work on ubuntu |
| 05:32:15 | S_a_i_n_t | Ah...not sure about that actually... |
| 05:32:33 | qcjn | anyway, i still have xp, but it s so slow |
| 05:32:36 | notByan | it likely does.. but I don't think there are binaries available for linux |
| 05:32:51 | | Quit karashata (Quit: The fluffy dragon has left completely!) |
| 05:33:02 | S_a_i_n_t | If you have XP too...than I don;t see a problem :D |
| 05:33:24 | qcjn | it s just that i don't use it anymore, it s to slow |
| 05:34:08 | notByan | anyway, rockbox has a files menu that lets you browse folders and manage music that way |
| 05:34:21 | moos | qcjn: http://www.rockbox.org/wiki/WhyRockbox if it helps |
| 05:34:33 | S_a_i_n_t | and no, you won't lose recording or FM radio IIRC |
| 05:34:48 | qcjn | ok, great |
| 05:35:14 | moos | you can even records the radio ;) |
| 05:35:36 | qcjn | great |
| 05:35:45 | qcjn | where is the simulator |
| 05:36:55 | moos | rasher.dk/rockbox/simulator/">http://rasher.dk/rockbox/simulator/ here it is |
| 05:37:05 | moos | not up to date, but enough to see |
| 05:37:10 | robin0800 | qcjn: in extras on the front page |
| 05:37:17 | S_a_i_n_t | it's at 3.5 IIRC |
| 05:37:30 | qcjn | ok |
| 05:37:35 | notByan | qcjn: if you have wine, you should able to run it that way |
| 05:37:45 | qcjn | oh, yeah |
| 05:38:23 | notByan | it uses sdl, which works natively on linux, so it should work flawlessly in wine |
| 05:39:15 | qcjn | i don't know what is sdl, cause i almost never uses wine, cause usually people uses it mostly for games, and i don't play games |
| 05:41:06 | | Join xavieran [0] (~xavieran@ppp118-209-53-186.lns20.mel4.internode.on.net) |
| 05:41:49 | notByan | sdl is a cross platform graphics library |
| 05:41:53 | moos | qcjn: just try on the device! Nothing to lose, and you have dualboot, and in last case yiu can remove it and goes back to evil original firmware ;) |
| 05:42:30 | qcjn | it s dualboot ! incredible, wow |
| 05:42:54 | qcjn | there s some sort of grub at start up ? |
| 05:43:07 | moos | yup check the manual, just to hold a key on boot to load sansa crap |
| 05:43:13 | | Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net) |
| 05:43:40 | qcjn | wow, men it s great, |
| 05:43:55 | moos | http://download.rockbox.org/daily/manual/rockbox-sansae200v2/rockbox-build.html |
| 05:44:09 | moos | Rockbox rules the world!!! ;) |
| 05:45:02 | * | S_a_i_n_t thinks if RB *wasn't* any better than the OF...noone would use it, and we wouldn;t be here :D |
| 05:45:18 | qcjn | well i ve installed it, about 2 years ago on my daughter in law's sansa, and she liked it |
| 05:46:44 | qcjn | cause her firmware was doomed...but since i wasn't using it, and in fact wasn't using my sansa...i didn't try it myself |
| 05:47:30 | moos | S_a_i_n_t: ...since years and years now |
| 05:48:47 | S_a_i_n_t | I cant imaging *not* using RB on my iPods now...it turns them from "fashion crap" into an actual, functional DAP :D |
| 05:49:02 | S_a_i_n_t | IMO |
| 05:50:04 | qcjn | well since it s dual boot... i think you just found a new user :) |
| 05:50:09 | Farthen | S_a_i_n_t: so now it is a fashionable AND functional player ;-) |
| 05:50:18 | moos | S_a_i_n_t: next step, you will buy your futur DAPs because rockbox suport.... :) |
| 05:50:49 | S_a_i_n_t | next step?...Ha! that's the *current* step! |
| 05:51:08 | moos | you already had your ipod, no? |
| 05:51:21 | S_a_i_n_t | a few of them.. |
| 05:51:28 | S_a_i_n_t | but I bought *more* :P |
| 05:52:08 | moos | you will no more buy an DAP if not Rcbx, or at least hope to ;) |
| 05:52:36 | moos | weee then !!! \o/ you are on the matrix dude |
| 05:52:56 | | Quit robin0800 (Remote host closed the connection) |
| 05:54:09 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
| 05:57:35 | | Quit robin0800 (Remote host closed the connection) |
| 05:57:55 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
| 06:00 |
| 06:02:05 | | Join phanboy4 [0] (~benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 06:02:13 | | Quit Barahir_ (Ping timeout: 264 seconds) |
| 06:07:29 | | Join Llorean [0] (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net) |
| 06:07:29 | | Quit Llorean (Changing host) |
| 06:07:30 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 06:09:10 | | Quit Sajber^ (Quit: Leaving.) |
| 06:10:36 | | Quit linuxguy3 (Ping timeout: 264 seconds) |
| 06:12:28 | | Join linuxguy3 [0] (~timj@adsl-75-57-163-40.dsl.emhril.sbcglobal.net) |
| 06:19:56 | | Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.4.40) |
| 06:20:35 | | Quit S_a_i_n_t (Ping timeout: 245 seconds) |
| 06:21:19 | | Join ucchan [0] (~ucchan@softbank219205175105.bbtec.net) |
| 06:21:57 | | Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.4.40) |
| 06:23:40 | | Quit Farthen (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
| 06:25:00 | | Quit planetbeing (Ping timeout: 264 seconds) |
| 06:27:38 | qcjn | waht is DAP ? |
| 06:27:55 | qcjn | digital audio player ? |
| 06:33:43 | | Quit CGL (Quit: Ya está, ahora solo a configurar XD) |
| 06:35:55 | ucchan | There is asking. Is there developper who can change my (username: Uchida) right of Flyspray ? |
| 06:36:15 | ucchan | I want you to change right of "close task" to "yes". (see FS #10424) |
| 06:39:07 | S_a_i_n_t | qcjn: yes, DAP = Digital Audio Player |
| 06:40:57 | | Quit ucchan (Quit: Leaving...) |
| 06:42:23 | qcjn | thanks |
| 06:42:58 | | Quit phanboy4 (Read error: Connection reset by peer) |
| 06:43:42 | | Join phanboy4 [0] (~benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 06:55:55 | | Part toffe82 |
| 06:56:23 | | Quit anewuser (Quit: http://xrl.us/WinterChipV =ooo ϢINTER ϾHIP 5iVE is OOON!!) |
| 06:56:25 | | Join kramer3d [0] (~kramer@unaffiliated/kramer3d) |
| 06:56:59 | | Join ucchan [0] (~ucchan@softbank219205175105.bbtec.net) |
| 06:57:40 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:02:50 | | Quit ucchan (Quit: Leaving...) |
| 07:03:48 | saratoga | is there someway in a plugin to get the SVN version number? |
| 07:03:57 | saratoga | test_codec should really print that in the logs |
| 07:07:20 | | Quit robin0800 (Remote host closed the connection) |
| 07:16:51 | | Join karashata [0] (~karashata@74-220-162-11.wightman.ca) |
| 07:17:10 | mc2739 | saratoga: I think so, battery_bench does it. |
| 07:18:19 | | Quit panni_ (Read error: Connection reset by peer) |
| 07:19:40 | * | S_a_i_n_t finds FS #11042 and decides this is indeed a *damn* good idea... |
| 07:21:47 | | Quit kramer3d (Quit: Leaving) |
| 07:32:56 | | Quit froggyman (Quit: kthnxbai) |
| 07:34:23 | | Join Horschti [0] (~Horscht2@xbmc/user/horscht) |
| 07:37:15 | | Quit Horscht (Ping timeout: 245 seconds) |
| 07:44:53 | | Join Barahir [0] (~jonathan@gssn-5f755b83.pool.mediaWays.net) |
| 07:53:26 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 08:00 |
| 08:00:16 | qcjn | thanks guy's . i'll beback surely |
| 08:01:09 | | Quit qcjn (Quit: Ex-Chat) |
| 08:12:57 | | Quit Barahir (Ping timeout: 252 seconds) |
| 08:26:14 | amiconn | saratoga: Close and reopen is definitely overkill. Calling fsync() is enough |
| 08:28:05 | amiconn | And unrelated to that, you can make perl chomp() handle \r\n if you set $/ to \r\n before. But it's probably better to use a regular expression here |
| 08:29:40 | amiconn | Unhelpful: dvd vob support wouldn't require any other audio codec than ac3, 'cause an ac3 track is mandatory afaik |
| 08:42:49 | saratoga | amiconn: why does that help? |
| 08:42:57 | saratoga | i don't really understand the problem |
| 08:44:25 | amiconn | The fat, directory entry is only updated on file close, or when calling fsync |
| 08:44:44 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 08:45:05 | amiconn | If test_codec crashes or otherwise ends without closing its log file, you get a zero-byte file now, because test_codec does neither |
| 08:46:16 | amiconn | For some reason test_codec may cause (low bat?) shutdown on PP devices using the PCF5060x PMU, even if there is no actual low bat condition |
| 08:47:34 | amiconn | Hmm, actually not only this PMU is affected |
| 08:48:09 | amiconn | I observe this effect on my Sansa c200v1, iPod Photo and Mini G2 |
| 08:48:18 | amiconn | The H10 (small) is unaffected for some reason |
| 08:49:16 | saratoga | amiconn: i had test_codec quite normally and still got a 0 byte file |
| 08:49:26 | saratoga | so i assume theres some bug in test_codec itself |
| 08:49:33 | amiconn | It's reproducible by testing ape -c5000. That's why there are no values for PP5022 |
| 08:49:46 | saratoga | yes I saw that as well, but i got it even with APE removed |
| 08:50:01 | amiconn | (cause neither c200 nor Mini G2 work - the PP5020 value is tested on H10) |
| 08:50:41 | amiconn | You don't need to remove all ape, just the -c5000 file |
| 08:50:59 | saratoga | when I dumped the disk to get the lost file, the entire test codec log was there |
| 08:51:07 | saratoga | so it finished everything, it just somehow never closed the file |
| 08:51:08 | stripwax | I get a zero-byte file if I connect USB without selecting 'quit' from the test_codec menu. I guess test_codec doesn't regard usb connect as a normal way to exit. |
| 08:51:27 | saratoga | hmm that should be easy to fix |
| 08:51:41 | amiconn | test_codec doesn't have proper usb handling. It's a test plugin after all |
| 08:51:47 | stripwax | :) |
| 08:52:33 | amiconn | I didn't observe zero-byte test_codec log files on normal exit so far |
| 08:52:34 | | Quit saratoga (Quit: Page closed) |
| 08:52:44 | amiconn | But then I don't use the log feature that often |
| 08:53:43 | amiconn | Calling fsync() is proably still a good idea, because of potential codec crashes |
| 08:54:10 | * | amiconn has no real idea how to track this weird bug down |
| 08:56:30 | stripwax | any chance there's some built-in protection to prevent running at full boost for long periods of time? |
| 08:57:15 | stripwax | or is it demonstrably test |
| 08:57:17 | stripwax | oops |
| 08:57:24 | stripwax | or is it demonstrable test_codec only |
| 08:57:43 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:00:51 | amiconn | TheSeven: I've updated SoundCodecMonkeysAudio from your pasted test results |
| 09:07:40 | | Quit mt (Ping timeout: 245 seconds) |
| 09:24:03 | | Join TopyMobile__ [0] (~topy@f048243022.adsl.alicedsl.de) |
| 09:28:17 | | Quit TopyMobile_ (Ping timeout: 260 seconds) |
| 09:35:59 | | Join stoffel [0] (~quassel@p57B4ECED.dip.t-dialin.net) |
| 09:39:19 | | Quit CaptainKwel (Ping timeout: 272 seconds) |
| 10:00 |
| 10:06:41 | | Quit phanboy4 (Ping timeout: 248 seconds) |
| 10:17:05 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 10:18:03 | * | S_a_i_n_t has some BIG issues with alternating sublines... |
| 10:21:07 | pixelma | JdGordon: there is something very fishy about the FMSs. I get the same problem with an own .fms on my M5 by the way (can't stop the radio anymore, other controls work), I set the .fms through the Theme settings menu now if that makes a difference - maybe related: there is something weird about applying the setting |
| 10:21:12 | S_a_i_n_t | *issue being, when a viewport is loaded, but not displayed (ie. if it's conditional is not met). when it *is* displayed any alternating sublines that it contains are displayed 'en-mass'. That is to say, if the vieport is not visible for say 1 minute, and it has alternating sublines which display every 10 seconds...when the viewport *is* displayed, it will display all 6 alternations before it resumes normal function. |
| 10:24:23 | S_a_i_n_t | I can provide a WPS that proves this quite effectively. |
| 10:30:01 | pixelma | didn't you tell about this earlier? And is there a tracker entry for this? |
| 10:31:12 | pixelma | hmmm... and while my theme uses sublines and alternating sublines, there are none of the latter in conditional viewports so I haven't seen this |
| 10:32:28 | S_a_i_n_t | pixelma: at the time I first brought this up, I wasn;t sertain that it wasn't my code at fault...but not I am (kinda...) |
| 10:32:42 | S_a_i_n_t | I'm surprised noone else has noticed it though... |
| 10:32:58 | S_a_i_n_t | s/not/now/ |
| 10:34:37 | pixelma | I think I read a report in the forums (but maybe that was you, don't know). I usually test those things with WPSs etc. that only contain the few lines which are needed to demonstrate a bug or test a new tag. |
| 10:34:49 | | Join flydutch [0] (~flydutch@host154-132-dynamic.15-87-r.retail.telecomitalia.it) |
| 10:35:37 | S_a_i_n_t | http://www.datafilehost.com/download-4e4ea2f3.html <- if anyone wants to see it for themself, or if anyone can see an obvious flaw in my code. |
| 10:36:03 | S_a_i_n_t | pixelma: don't think it was me...pretty sure it wasn't actually. |
| 10:36:45 | S_a_i_n_t | if you use the WPS I posted (Nano 1/2g), put hold on for a minute or so, then take it off. |
| 10:36:53 | pixelma | reduces potential other causes of error and makes it easier to read for someone who wants to work with it. E.g. my current test .fms only contains %Tn (current preset name)... |
| 10:44:55 | | Join Barahir [0] (~jonathan@gssn-5f756a81.pool.mediaWays.net) |
| 10:47:22 | | Join tuma [0] (~tuma@e82-103-228-224.elisa-laajakaista.fi) |
| 10:50:13 | tuma | if I have understood correctly, time stretching should be functioning from 3.4 or 3.5, right? I have enabled this feature, but it seems not to work (tried mp3 and spx files) |
| 10:51:16 | tuma | I tried with default configuration, with only difference that this feature was enabled |
| 10:54:44 | Llorean | What are you expecting it to do if you don't set the rate? |
| 10:55:28 | | Join pamaury [0] (~pamaury@sal63-1-82-243-96-220.fbx.proxad.net) |
| 10:56:13 | tuma | of course I set also pitch rate, right |
| 10:57:46 | *** | Saving seen data "./dancer.seen" |
| 10:58:03 | tuma | and as a effect I get pitch going up/down (fast playback with higher pitch) |
| 11:00 |
| 11:00:46 | tuma | although I would assume fast playback with normal pitch, if I have understood this feature corretly. |
| 11:02:36 | pamaury | mc2739: are you there ? |
| 11:09:14 | tuma | is there anyone that has been using time stretching? I would like to know if it works for someone. |
| 11:10:06 | S_a_i_n_t | tuma: it works perfectly for me... |
| 11:10:14 | stripwax | tuma - have you check the relevant manual section? rather than assume how it works. |
| 11:10:38 | tuma | I actually once read that, but maybe I should double-check |
| 11:12:26 | tuma | yes, i re-checked section 6.10 in manual. http://download.rockbox.org/daily/manual/rockbox-sansae200/rockbox-buildch6.html#x9-1140006.10 |
| 11:12:49 | tuma | should be straight-forward |
| 11:13:04 | tuma | and I believe I have tried to use it correctly. |
| 11:13:28 | stripwax | And did you reboot after enabling the Timestretch option? |
| 11:13:56 | tuma | yes |
| 11:14:16 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 11:14:24 | S_a_i_n_t | tuma: which target? |
| 11:14:34 | tuma | sansa e200 (e280) |
| 11:14:38 | tuma | v1 |
| 11:16:35 | stripwax | tuma - have you read section 4.3.3 too? and put it into separate speed/pitch mode? |
| 11:17:30 | * | stripwax observes that the manual section 4.3.3 doesn't actually tell you HOW to put it into separate speed/pitch mode. sigh. |
| 11:18:06 | stripwax | tuma - I don't know which button you need for e280, on ipod video I press Down. then, scroll affects the pitch while left/right affect the speed |
| 11:18:16 | tuma | oh |
| 11:19:32 | stripwax | oh wait yeah it does. First row in the table! for e280 it's the Rec button |
| 11:19:42 | * | stripwax needs some caffeine. for his eyes. |
| 11:20:39 | tuma | thanks! |
| 11:21:38 | stripwax | tuma - works? |
| 11:24:11 | tuma | yes it does |
| 11:24:19 | * | stripwax \o/ |
| 11:25:36 | S_a_i_n_t | pixelma: I cut it back as far as I can (and still reproduce the problem), HOLD toggles the viewports. |
| 11:25:37 | S_a_i_n_t | http://www.datafilehost.com/download-b2ea5774.html |
| 11:26:32 | linuxstb | amiconn: My recollection is that NTSC DVD players *must* support LPCM and AC-3, and PAL players *must* support LPCM, AC-3 and MP2. |
| 11:27:17 | amiconn | Ah yes, lpcm needs to be supported as well. I don't know about mp2 (but then mpegplayer already does support mp1/2/3) |
| 11:27:31 | tuma | stripwax: really, not very intuitive this feature... have to read the manual very carefully to use it |
| 11:27:34 | tuma | :P |
| 11:27:50 | stripwax | tuma - feel free to submit a patch for the manual! :-p |
| 11:28:05 | tuma | maybe I should=) |
| 11:28:14 | linuxstb | amiconn: But in practice, I don't think you'll find many DVDs with only MP2 (or only LPCM). Even music DVDs seem to have AC-3 in addition to any LPCM track. |
| 11:28:37 | tuma | maybe pitch screen could also hint about mode switching |
| 11:28:54 | tuma | there's plenty of space on screen |
| 11:29:10 | | Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) |
| 11:29:12 | pixelma | depends on the screen... |
| 11:29:13 | amiconn | Well my dvd recorder can (optionally) produce dvds with just lpcm at the highest quality setting (1 hour on single layer) |
| 11:29:39 | pixelma | and the font you uses |
| 11:29:40 | amiconn | For all other quality levels it always uses ac3 2.0 |
| 11:30:48 | linuxstb | LPCM is pretty easy to decode and play. I have some code somewhere to do it. |
| 11:31:13 | | Join dantje [0] (~dvg@HSI-KBW-095-208-155-207.hsi5.kabel-badenwuerttemberg.de) |
| 11:35:18 | | Quit karashata (Quit: The fluffy dragon has left completely!) |
| 11:39:01 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 11:40:10 | TheSeven | stripwax: did you see my results from yesterday? |
| 11:40:14 | tuma | stripwax: actually I have submitted two small (but for me, important) patches to the code and they have got no attention at all. so I am not sure if small and rather small-significance patches get applied easily |
| 11:41:50 | stripwax | tuma - which FS#s? |
| 11:42:10 | stripwax | TheSeven - your pdf? yeah, I saw that, really cool. Decent speed up from new MDCT on nano2g too, which is reassuring |
| 11:42:47 | TheSeven | yes - the wma speedup is a bit suspicious though ;-) |
| 11:43:06 | stripwax | Would be great it we could systemise that even more and just have it viewable from wiki - pick a target, pick a date range ... |
| 11:43:21 | tuma | FS #10482 and FS #10483 |
| 11:43:22 | stripwax | TheSeven - suspicious? not at all! |
| 11:43:23 | TheSeven | that's what i suggested |
| 11:43:33 | stripwax | TheSeven - ah! heh |
| 11:43:52 | TheSeven | [22:36]* TheSevenwonders if it would be worth the effort to 1) add the device, build type and revision to the test-codec output, 2) make a website where one can upload the logs, 3) make an analyzer tool for the gathered results :-) |
| 11:44:28 | stripwax | yeah, it's a great idea. and even if we only get results for all targets once per release, it's still great data |
| 11:44:54 | TheSeven | the wma speedup suggests that you accidentally fixed something else at the same time :-) |
| 11:45:18 | TheSeven | everything else gained like 4 or 5 MHz, while WMA gained 11 |
| 11:46:23 | | Join DerPapst [0] (~DerPapst@p5797C72D.dip.t-dialin.net) |
| 11:47:15 | stripwax | TheSeven - WMA uses smaller block sizes than Vorbis, iirc. the new ifft uses cache optimally (in the sense that recurses depth-first rather than breadth-first). maybe WMA blocksizes mostly fit in cache and get bigger benefits as a result? old mdct was breadth first |
| 11:47:41 | stripwax | I certainly didn't explicitly fix anything in WMA :) |
| 11:51:07 | TheSeven | actually this kind of behavior seems to be nano2g-specific |
| 11:51:44 | TheSeven | wma used to be slower than it should be in comparison to other targets and other codecs, and now it has seen this weird speedup, while wma on other targets also got one in the ~5MHz range. |
| 11:51:58 | | Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 11:52:22 | TheSeven | [11:49]<TheSeven>actually this kind of behavior seems to be nano2g-specific |
| 11:52:23 | TheSeven | [11:50]<TheSeven>wma used to be slower than it should be in comparison to other targets and other codecs, and now it has seen this weird speedup, while wma on other targets also got one in the ~5MHz range. |
| 11:52:25 | TheSeven | so you say this might be related to caches? that could be an explanation, as nano2g has only 2x4K of cache |
| 11:54:24 | | Quit stripwax (Ping timeout: 264 seconds) |
| 11:55:01 | stripwax_ | yep, could be. |
| 11:55:05 | | Nick stripwax_ is now known as stripwax (~Miranda@87-194-34-169.bethere.co.uk) |
| 12:00 |
| 12:00:02 | tuma | bye for now! and thanks again, stripwax, S_a_i_n_t |
| 12:00:03 | | Quit tuma (Quit: leaving) |
| 12:02:55 | pixelma | hmm, got a few IMA-ADPCM files which play in Rockbox now but the length is displayed wrong (just 0:01) |
| 12:15:10 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 12:16:40 | pixelma | AlexP: in your FMS test, did you use the menu entry to set the .fms or did you still edit the .cfg? |
| 12:23:29 | AlexP | pixelma: both I think |
| 12:24:29 | AlexP | JdGordon: Could your latest commit fix an issue where the wrong font is used on the remote? |
| 12:25:32 | AlexP | I haven't tried yet, but as you may guess my testing on H140 has hit an issue :) |
| 12:26:37 | pixelma | do you just have one fms to test or could you try setting another (through the menu)? |
| 12:27:37 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 12:30:43 | AlexP | pixelma: I just have one, but I could write a quick other to test |
| 12:30:51 | AlexP | I take it you are having issues with it? |
| 12:33:33 | AlexP | It'll have to be a bit later today though, I'll let you know |
| 12:34:39 | | Quit leavittx (Remote host closed the connection) |
| 12:35:02 | pixelma | there are some very weird effects - on my OndioFM as well as on my M5 - first the setting seems to apply correctly but then trouble start, it's a bit longish to explain here, I really need to put it on the tracker |
| 12:35:40 | pixelma | on both I can't stop the radio anymore |
| 12:38:36 | pixelma | and since there are also problems with the setting being kept or not (or being able to chose a new .fms), I wonder if it is related |
| 12:40:39 | | Join Highlander_ [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) |
| 12:43:53 | | Quit Highlander (Ping timeout: 240 seconds) |
| 12:50:43 | | Quit avacore (*.net *.split) |
| 12:50:43 | | Quit kadoban (*.net *.split) |
| 12:50:43 | | Quit Guest82304 (*.net *.split) |
| 12:50:44 | | Quit rasher (*.net *.split) |
| 12:52:19 | | Join kadoban [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) |
| 12:54:43 | | Join feisar [0] (jljhook@irkki.fi) |
| 12:55:12 | | Nick feisar is now known as Guest34960 (jljhook@irkki.fi) |
| 12:56:04 | | Join avacore [0] (nobody@1008ds1-rdo.0.fullrate.dk) |
| 12:57:48 | *** | Saving seen data "./dancer.seen" |
| 12:59:07 | | Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) |
| 12:59:07 | | Quit rasher (Changing host) |
| 12:59:08 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 13:00 |
| 13:01:17 | CIA-8 | New commit by teru (r24804): FS #11017: add Playlist Catalog and Properties item to database's context menu. |
| 13:03:52 | pixelma | AlexP: including the weirdness that the patch's hardcoded fms works and doesn't give me trouble with the controls |
| 13:14:24 | | Join AsaelReiter [0] (~d44c72e0@giant.haxx.se) |
| 13:18:12 | AsaelReiter | Is there a way to create a diff with the differences between two diff files? |
| 13:21:34 | TheSeven | apply them and diff the results |
| 13:23:15 | AsaelReiter | theseven: thanks |
| 13:23:36 | AsaelReiter | I hoped that there is a simpler way |
| 13:24:42 | | Join Farthen [0] (~chatzilla@p50988dd0.dip0.t-ipconnect.de) |
| 13:29:16 | CIA-8 | New commit by b0hoon (r24805): Packard Bell Vibe 500: Enable recording. |
| 13:34:19 | pixelma | AlexP: and which targets did you test on? |
| 13:34:20 | TheSeven | is there a way to change the name of the .rockbox dir? |
| 13:34:37 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 13:35:05 | TheSeven | i would like to have different installations for a "production rockbox" and a testing one |
| 13:36:11 | stripwax | TheSeven - you could keep a copy of both (prod.rockbox, testing.rockbox) and copy the one you want to .rockbox? There's no way to select at boot time which to point to |
| 13:36:18 | TheSeven | a quick grep shows that there seem to be quite a few places where ".rockbox" is hardcoded |
| 13:36:33 | AlexP | pixelma: S60, and I'm trying H120, but there are some font issues so I haven't got to the fms yet |
| 13:37:02 | TheSeven | stripwax: if i could patch the main binary to use one or the other directory, this should work, as i would like to have 2 main binaries anyways |
| 13:37:05 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 13:37:27 | TheSeven | i.e. i would have 2 complete installations that don't need to know anything about each other |
| 13:37:39 | | Quit AsaelReiter (Quit: CGI:IRC) |
| 13:37:40 | | Quit piotrekm (Read error: Connection reset by peer) |
| 13:37:57 | | Join piotrekm [0] (~piotrek@addu179.neoplus.adsl.tpnet.pl) |
| 13:37:57 | | Quit piotrekm (Changing host) |
| 13:37:57 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 13:38:13 | stripwax | TheSeven - and then use ROLO to switch between them? |
| 13:38:24 | stripwax | i.e. without having to patch bootloader too |
| 13:38:24 | TheSeven | no, that would be done at bootloader level |
| 13:38:28 | stripwax | oh |
| 13:39:01 | TheSeven | i'm not using the rockbox bootloader, so this won't be an issue |
| 13:39:17 | TheSeven | iloader can do that out of the box |
| 13:40:09 | stripwax | gotcha. Well, I don't know of a built-in way to do that, you may just need to put in a #define for it, set it as a config option, and replace the hardcoded occurrences with the symbol. |
| 13:40:45 | TheSeven | there *is* a define for that (in the makefile, even), but it doesn't seem to be used consistently :-/ |
| 13:42:29 | stripwax | oh, ugh. |
| 13:42:48 | TheSeven | gah, i'm going to fix that configure bug now, this is really annoying |
| 13:43:24 | TheSeven | aha, another rbdir=".rockbox" in .configure... :-/ |
| 13:43:35 | TheSeven | seems to be only a default though |
| 13:47:23 | CIA-8 | New commit by theseven (r24806): Make configure remember that it is supposed to use the EABI toolchain when make reconf is run |
| 13:57:39 | | Quit thegeek (Read error: Connection reset by peer) |
| 14:00 |
| 14:02:21 | | Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 14:09:36 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 14:11:58 | | Quit shai (Quit: Leaving) |
| 14:25:47 | | Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 14:32:05 | | Quit n17ikh (Ping timeout: 276 seconds) |
| 14:32:54 | CIA-8 | New commit by teru (r24807): remove unused fields from struct gui_synclist. |
| 14:34:43 | | Quit dantje (Quit: Ex-Chat) |
| 14:37:20 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 14:38:35 | pamaury | I'm investigating "FS #10913 - File Browser not updated properly upon microSD insert/removal with dircache enabled" and I think I found out the issue. It seems that there is a synchronization problem with SYS_FS_CHANGED: depending on the order in which the thread treat the message is important. Perhaps we need something like this: a first message to inform threads that need internal structure update, then a ack, and then the final t |
| 14:38:35 | pamaury | rigger message ? |
| 14:38:57 | pamaury | *-depending |
| 14:48:13 | pamaury | nobody interested ? |
| 14:57:45 | | Join CGL1 [0] (~CGL@190.207.226.111) |
| 14:57:49 | *** | Saving seen data "./dancer.seen" |
| 14:58:28 | | Quit Highlander_ (Quit: Quitte) |
| 14:58:49 | | Part CGL1 |
| 14:59:00 | | Join CGL [0] (~CGL@190.207.226.111) |
| 15:00 |
| 15:07:46 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 15:10:13 | * | amiconn just tested his theory that IRAM on PP5020 (not 5022) is not strictly single cycle |
| 15:10:46 | amiconn | It is correct - and the extra latency even depends on the cpu clock |
| 15:12:36 | kugel | pamaury: I don't see an obvious other way to do it |
| 15:13:17 | amiconn | Accessing the same address over and over is single cycle. Striding across iram isn't |
| 15:13:41 | | Quit CGL (Quit: Saliendo) |
| 15:13:47 | * | amiconn will test various patterns to find out what's going on exactly |
| 15:13:51 | pamaury | kugel: the problem I see with what I propose is that now, all threads have to monitor a new message and ack, even the one which are not "interested" in hotswap |
| 15:13:53 | | Join CGL [0] (~CGL@190.207.226.111) |
| 15:14:44 | stripwax | amiconn - meaning ldm even more important on pp5020 than on pp5022? |
| 15:14:54 | amiconn | No |
| 15:15:12 | kugel | what threads are involved? maybe the initial post could go to the dircache thread directly which then does SYS_FS_CHANGED? |
| 15:15:18 | | Quit teru (Quit: Quit) |
| 15:15:20 | amiconn | Meaning that PP5020 needs very careful decisions what should go into iram and what shouldn't |
| 15:15:52 | Bagder | maybe stable and unstable should rather be in two columns on the front page, to make it less tall |
| 15:16:01 | amiconn | It means iram is *not* always equally fast or faster as dram, taking the cache into consideration |
| 15:18:01 | pamaury | kugel: to me, that's the most logical way. Currently, the ata/mmc/sd/... code emits the SYS_FS_CHANGED message whereas it has nothing to do with FS. The SYS_FS_CHANGED should be sent by the FS code. |
| 15:18:44 | | Join likemindead [0] (~633a72d3@gateway/web/freenode/x-okjazhaqvgknbjru) |
| 15:19:54 | likemindead | My iPod (4th Gen/Color) won't mount in Xubuntu 9.10. How can I do that manually? I want to upgrade to Rockbox 3.5 :D |
| 15:21:27 | | Part likemindead |
| 15:21:28 | stripwax | likemindead - if it doesn't mount even after booting to apple firmware and/or apple diskmode, then that sounds like a Xubuntu question not a rockbox question.. |
| 15:21:37 | stripwax | oh. well. seeya. |
| 15:22:51 | | Quit kugel (Ping timeout: 265 seconds) |
| 15:26:09 | | Join Omlet [0] (omlet05@183.116-244-81.adsl-dyn.isp.belgacom.be) |
| 15:26:40 | mt | stripwax: Is the todo on fasterMDCT up to date ? |
| 15:26:44 | mt | Oh and .. \o/ .. for merging :) |
| 15:26:56 | stripwax | mt - yep, I believe so, I updated it yesterday |
| 15:27:05 | stripwax | and \o/ thanks :_) |
| 15:27:21 | mt | great ! |
| 15:28:09 | | Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) |
| 15:30:02 | gevaerts | Bagder: personally I'd like the table to be less tall, but I'm a bit worried that it would be more confusing that way |
| 15:30:22 | Bagder | yeah, quite possibly |
| 15:31:32 | | Join Schmogel [0] (~Miranda@p3EE2068D.dip0.t-ipconnect.de) |
| 15:34:14 | | Join Sajber^ [0] (~Sajber^@93-252.anonymous.at.anonine.com) |
| 15:36:41 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 15:37:04 | | Quit mc2739 (Ping timeout: 246 seconds) |
| 15:39:08 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 15:39:28 | | Join tuma [0] (~tuma@e82-103-228-224.elisa-laajakaista.fi) |
| 15:40:14 | kugel | pamaury: hm, that would make it harder to close/not even start the dircache thread if it's disabled though (what I would like to see in the future) |
| 15:40:54 | kugel | who can fix the sidebar in the forums? |
| 15:41:06 | pamaury | kugel: true but that is not logical currently |
| 15:41:42 | kugel | :? |
| 15:41:58 | | Quit stoffel (Ping timeout: 246 seconds) |
| 15:42:56 | pamaury | the ata code has nothing to do with the file system code so why should the ata code trigger a FS changed ? |
| 15:48:55 | kugel | right |
| 15:48:57 | kugel | I agree |
| 15:54:55 | pamaury | I will think about it, perhaps there is a simple solution to this problem |
| 15:56:04 | | Join TheSphinX^ [0] (~cold@p5DD393B5.dip.t-dialin.net) |
| 16:00 |
| 16:00:51 | kugel | Torne: would it be useful to align skin allocations to 16bytes for dma? |
| 16:01:15 | kugel | for images for example, but I can imagine it's not worth it |
| 16:03:44 | kugel | JdGordon: this bidirectional skin buffer makes resizing on boot hard |
| 16:04:03 | | Part fleebailey33 |
| 16:11:32 | TheSeven | gevaerts: is it normal that a pebble-build doesn't have a backdrop with default settings? |
| 16:11:49 | gevaerts | hm |
| 16:12:07 | gevaerts | it shoudln't really change anything there |
| 16:12:11 | | Quit TheSphinX^ (Ping timeout: 252 seconds) |
| 16:14:03 | TheSeven | skin buffer too small or something? |
| 16:14:16 | TheSeven | i saw something in the patch that sets it to 16K |
| 16:14:50 | kugel | how can I get a file listing a the directory, and if I get it search for a file ".skin_buffer_XXXX" where X is a number, and if I have that file how would I parse the XXXX number? |
| 16:15:04 | * | kugel is obviously a fs operation noob |
| 16:15:18 | TheSeven | oh, on the wps most things are also missing |
| 16:15:36 | Unhelpful | kugel: as in dma transfer from disk? |
| 16:15:45 | kugel | Unhelpful: yes |
| 16:16:09 | Unhelpful | that's not the right buffer to resize for that. ;) |
| 16:16:25 | Unhelpful | erm, align, rather. |
| 16:16:45 | TheSeven | hm, stkov usb when trying to do a screendump :-/ |
| 16:17:15 | TheSeven | damn, ftl dead again |
| 16:17:45 | kugel | Unhelpful: ? |
| 16:18:02 | TheSeven | i really need to work on a more stable ftl recovery method... |
| 16:18:24 | Unhelpful | kugel: the bmp loader doesn't read from disk directly to the address at which the bmp data will be stored, it uses an on-stack read buffer. |
| 16:18:32 | kugel | we clearly we need a pet name for the nano2g that involves stkov! |
| 16:18:58 | kugel | Unhelpful: ah got it |
| 16:20:07 | Unhelpful | this is done, and is not really a great loss, because from-file bmp data must go through various transformations before use. |
| 16:21:04 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 16:22:46 | Unhelpful | so what you'd want to do is make the read buffer cacheline-aligned and disk-block-sized (i believe these are the requirements?) |
| 16:22:55 | Unhelpful | and then you'll have even more stkov :D |
| 16:28:00 | | Join TheSphinX^ [0] (~cold@p5DD3B9A0.dip.t-dialin.net) |
| 16:30:15 | TheSeven | somebody wants to write an ftl recovery tool? |
| 16:31:32 | pamaury | What does it consists in ? |
| 16:33:32 | TheSeven | scanning the whole flash, generating a block map from the decentral set of control data (in the spare bits of the individual pages), trying to forcibly mount the ftl and check to which degree this is still possible, then comparing the central block map tables to the decentral data we gathered and fix the central table. |
| 16:33:32 | | Quit ecio (Read error: Connection reset by peer) |
| 16:33:47 | | Join ecio [0] (~ecio@244-108.202-68.tampabay.res.rr.com) |
| 16:34:30 | TheSeven | what might be a bit more tricky is recovering from a state where it was interrupted in a middle of some control data write |
| 16:35:27 | pamaury | Wow, I can't understand anything ;) Anyway, I haven't got a flash target around so that would be difficult to write :) |
| 16:35:53 | TheSeven | it an fsck-like task ;-) |
| 16:36:37 | CIA-8 | New commit by stripwax (r24808): Unroll and optimise channel coupling for arm gives 0.6Mhz speed for vorbis on pp(ipod video) |
| 16:36:52 | stripwax | oddly, unrolling it made it fractionally worse on coldfire |
| 16:37:30 | pamaury | I've never written an fsck-like thing ! And I would not be able to test it ;) Although I'm 200% sure I would do it right the first time ^^ |
| 16:39:28 | TheSeven | gevaerts: how would i try your starfield pebble btw? |
| 16:39:50 | gevaerts | TheSeven: %P|starfield| in the wps should do the trick |
| 16:40:07 | * | TheSeven has never even looked at a wps before |
| 16:41:07 | gevaerts | if you just want to try pebbles, you can make a wps with only that line |
| 16:41:15 | TheSeven | ok |
| 16:41:31 | gevaerts | it won't be a very interesting wps then, but it should work :) |
| 16:41:54 | Unhelpful | did i miss the part where we had real work happening on visplugins? |
| 16:42:13 | pixelma | %P once was used for something else |
| 16:43:48 | gevaerts | Unhelpful: depends on what you call "real work" :) |
| 16:44:36 | TheSeven | "*PANIC* Stkov ¤¤" |
| 16:44:52 | TheSeven | when trying to move a file |
| 16:45:06 | TheSeven | i really like this... |
| 16:45:18 | gevaerts | pixelma: I picked that because it appeared to be unused. The "pebble" concept isn't anywhere near ready for commit though (if it ever will be), so there's still some time to discuss this :) |
| 16:45:20 | Unhelpful | gevaerts: so the "pebbles" are TSR? or are they just stopped/started when their viewport is displayed? |
| 16:45:42 | Unhelpful | it seems the latter might be best since they could just be "regular" plugins then... |
| 16:46:05 | Unhelpful | ie, starfield would draw into a viewport when given a pointer to one on startup? |
| 16:46:15 | pamaury | TheSeven: how many stkov do you experience per day ? :) |
| 16:46:20 | gevaerts | Unhelpful: I think they're somewhere in between |
| 16:46:24 | TheSeven | usually none |
| 16:46:41 | TheSeven | but today i have started digging in some areas where i haven't been before (and thus haven't fixed them yet) |
| 16:47:18 | gevaerts | Unhelpful: they have a function that's called on startup so they can initialise things, and they have a function that's called whenever they should redraw their viewport |
| 16:47:19 | * | TheSeven grumbles at gevaerts |
| 16:47:30 | * | gevaerts is innocent! |
| 16:47:52 | * | TheSeven blames gevaerts |
| 16:48:02 | pamaury | TheSeven: What did gevaerts do? |
| 16:48:07 | TheSeven | this: + snprintf(filename,MAX_PATH,"/.rockbox/pebbles/%s.pebble",temp); |
| 16:48:24 | gevaerts | TheSeven: I've had data aborts and illegal instructions using that patch, but never a stack overflow! |
| 16:48:58 | TheSeven | gevaerts: i haven't even managed to make a pebble start yet, those stkovs are all different issues on my way up to that point |
| 16:50:04 | gevaerts | Unhelpful: normal plugins can't work for visualisation as long as drawing isn't supposed to happen outside of the GUI thread |
| 16:51:19 | gevaerts | TheSeven: I'd advise to start with the "test_pebble" pebble, that one actually works on some targets |
| 16:51:35 | * | TheSeven first needs to fix that hardwired path anyways |
| 16:51:36 | pixelma | gevaerts: I just wondered why it seemed a familiar tag. It was used to preload a bitmaps for use as progressbar which is now unified to one %pb tag. There won't be problems with old WPS still using it because these will be broken due to the old %pb syntax anyway. The worst that could happen is someone gets confused who has to deal with a really old WPS |
| 16:52:30 | amiconn | Hmm, bad news about the PP5020 |
| 16:53:18 | amiconn | Of its 96KB of IRAM, only the first 24KB (one quarter) is single cycle, the rest has one waitstate on access |
| 16:53:41 | gevaerts | Should we keep the Ondio SP red? I don't think it's likely to shrink enough for rombox in the near future, and this way there's no current build for people to use |
| 16:53:43 | amiconn | Looks like they moved the PP5002's cache bug to IRAM in PP5020 |
| 16:54:21 | TheSeven | hmm, "boot changed" detection also doesn't work with a nonstandard rockbox base dir |
| 16:55:10 | | Join stooo [0] (~sto@e181177203.adsl.alicedsl.de) |
| 16:55:17 | * | kugel has semi-working resizable skin buffer |
| 16:55:27 | pamaury | TheSeven: why do you need a nonstandard rockbox base dir ? You boot nano2g on sd ? |
| 16:55:59 | TheSeven | no, but i kinda have a "production build" and an "experimental (pebble) build" on it |
| 16:56:49 | TheSeven | btw, the clock pebble works |
| 16:56:56 | TheSeven | the starfield one locks up :-/ |
| 16:56:58 | kugel | TheSeven: BOOTDIR is important, not ROCKBOX_DIR |
| 16:57:53 | *** | Saving seen data "./dancer.seen" |
| 16:59:19 | kugel | now I just need to make growing work, i.e. parse a skin and ask for reboot if it doesn't fit |
| 17:00 |
| 17:01:46 | kugel | parse all skins actually, that's the hard part :( |
| 17:03:56 | | Quit piotrekm (Quit: piotrekm) |
| 17:04:07 | gevaerts | kugel: you could of course just resize-on-fail, and then have people reboot seven times before it works |
| 17:04:18 | Unhelpful | gevaerts: so a regular plugin could *be* a visplugin if its drawing code is isolated in a function, and it exports some extra header data? |
| 17:04:38 | kugel | gevaerts: yea, being bloody annoying is cool :) |
| 17:04:49 | gevaerts | Unhelpful: that might be doable. I'm not sure if it makes sense though |
| 17:05:19 | kugel | I need two passes, one to get the size and one to actually parse it |
| 17:05:24 | Unhelpful | gevaerts: well, people already seem to like some visualization-type things as normal plugins. it seems to me it could make sense. |
| 17:05:53 | Unhelpful | why exactly "must" all draws happen in the GUI thread? |
| 17:05:53 | * | kugel adds a 30k buffer which should be enough to do size+parse in the first run, and load images in the second |
| 17:07:06 | | Quit mt (Ping timeout: 256 seconds) |
| 17:09:30 | gevaerts | Unhelpful: this needs thinking. One difference between visualisation plugins and regular plugins as they exist today is that most or all plugins assume a fixed screen==viewport size, which (in some cases at least) is a performance gain. Ideally we'd want at least some of those to allow for different viewports to work with the .sbs of course |
| 17:09:32 | | Join froggyman [0] (~sopgenort@pool-72-69-220-42.chi01.dsl-w.verizon.net) |
| 17:10:55 | gevaerts | Anyway, yet again I don't feel like spending too much time on that sort of thing as long as I don't know if the entire concept of non-fixed-address plugins works |
| 17:13:45 | CIA-8 | New commit by tomers (r24809): Brickmania: Use predefined macro definition when possible |
| 17:13:49 | kugel | the filesize isn't a good estimate for the space an image needs inram, is it? |
| 17:14:07 | | Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) |
| 17:14:49 | kugel | a non-resized bmp image that is |
| 17:16:27 | Unhelpful | kugel: not really, no. |
| 17:16:45 | kugel | gr |
| 17:16:52 | Unhelpful | bmp rows are padded in files, and bmp can be > or <16-bit. |
| 17:17:01 | kugel | so I really need to load them in the first pass for their size? |
| 17:17:49 | kugel | well, accuracy doesn't matter too much |
| 17:18:03 | kugel | as long as they are never bigger than the file size |
| 17:18:28 | kugel | could they be bigger? |
| 17:18:46 | amiconn | Of course |
| 17:19:48 | kugel | can you explain that please? do you mean for instance when I load a mono bitmap on a color screen? |
| 17:20:09 | amiconn | BMP files can be 1/4/8/16/24/32bpp |
| 17:20:28 | amiconn | So if you load a 4-bit BMP, it will become bigger in-memory on colour targets |
| 17:21:15 | amiconn | Same for 1-bit and 8-bit of course |
| 17:21:45 | amiconn | If you're loading mono bitmaps, they will always become smaller, except on mono targets |
| 17:22:29 | amiconn | I mean mono bitmaps in rockbox format, and the exception is wrong |
| 17:22:39 | | Quit CGL (Remote host closed the connection) |
| 17:22:50 | kugel | so, mono bitmaps don't get bigger? |
| 17:23:01 | | Join CGL1 [0] (~CGL@190.207.226.111) |
| 17:23:24 | kugel | do I really need to worry about 4/8. do we even support loading those? I've never seen them in reality I think |
| 17:23:27 | amiconn | They can get bigger as well, due to pixel packing |
| 17:23:31 | | Quit CGL1 (Remote host closed the connection) |
| 17:23:37 | amiconn | Yes we do support them |
| 17:24:44 | amiconn | If you load e.g. a 32x1 pixel 1-bit BMP as mono bitmap, it will become 8x on-disk size (ignoring the header) in memory |
| 17:25:01 | | Join CGL1 [0] (~CGL@190.207.226.111) |
| 17:25:18 | | Join iq [0] (~chatzilla@unaffiliated/iq) |
| 17:25:20 | iq | Hi |
| 17:25:49 | amiconn | In order to predict in-memory size you need at least the bmp header, and the destination format (mono or native) |
| 17:27:40 | | Quit CGL1 (Client Quit) |
| 17:27:59 | | Join stoffel [0] (~quassel@p57B4ECED.dip.t-dialin.net) |
| 17:28:00 | kugel | would it be worth it reading only the header instead of full loading? |
| 17:28:05 | | Join CGL [0] (~CGL@190.207.226.111) |
| 17:28:24 | | Quit CGL (Read error: Connection reset by peer) |
| 17:28:31 | | Join CGL [0] (~CGL@190.207.226.111) |
| 17:34:29 | * | kugel will worry about that later |
| 17:35:42 | | Join Buschel [0] (~ab@p54A3AA47.dip.t-dialin.net) |
| 17:36:36 | | Quit iq (Quit: ChatZilla 0.9.86 [Firefox 3.5.5/20091102152451]) |
| 17:41:03 | | Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) |
| 17:42:07 | | Quit tuma (Quit: leaving) |
| 17:46:16 | | Join iq [0] (~iq@unaffiliated/iq) |
| 17:49:22 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 17:49:49 | | Part stooo |
| 17:56:10 | | Join ifonefox [0] (~irchon@166.137.6.166) |
| 17:57:11 | | Quit ifonefox (Remote host closed the connection) |
| 17:58:13 | | Quit funman (Quit: free(random());) |
| 17:59:11 | | Quit dfkt (Read error: Connection reset by peer) |
| 18:00 |
| 18:00:52 | | Quit GeekShadow (Quit: The cake is a lie !) |
| 18:02:59 | TheSeven | gevaerts: around? |
| 18:03:07 | gevaerts | yes |
| 18:03:14 | TheSeven | i fixed the starfield pebble :-) |
| 18:03:18 | TheSeven | or rather the core |
| 18:03:21 | gevaerts | Ooh! |
| 18:03:52 | gevaerts | What was wrong? |
| 18:04:03 | TheSeven | pebble.c, lines 104 to 108... do you see it? |
| 18:04:51 | TheSeven | post-mortem memory dumps are very helpful to track down that kind of issues :-) |
| 18:04:59 | gevaerts | yes, probably |
| 18:05:09 | gevaerts | off-by-one? |
| 18:05:21 | TheSeven | no, it will only patch every second GOT entry |
| 18:05:21 | | Join mitk [0] (~tomekk@chello089078013146.chello.pl) |
| 18:05:36 | TheSeven | you're incrementing i both in the for statement and in the loop body :-P |
| 18:05:41 | gevaerts | ouch! |
| 18:05:46 | * | gevaerts is an idiot |
| 18:05:57 | gevaerts | It was a while loop at some point |
| 18:06:09 | TheSeven | yes, i figured that it must have been :-) |
| 18:06:15 | amiconn | PP5020 IRAM behaviour is even more weird |
| 18:06:40 | amiconn | The first quarter (24KB) is zero-wait for the CPU, but one waitstate for the COP |
| 18:06:57 | | Quit stripwax (Quit: http://miranda-im.org) |
| 18:07:12 | amiconn | For the second 24KB it's the opposite - zero-wait for COP, one waitstate for the CPU |
| 18:07:25 | amiconn | The rest (48KB) is one waitstate for both |
| 18:08:14 | amiconn | Somehow portalplayer has messed up the crossbar switch |
| 18:09:01 | amiconn | Now we just need to find a sane way to deal with this</sarcasm> |
| 18:12:46 | gevaerts | TheSeven: I guess that clears the last hurdle. These things are clearly doable, at least on ARM |
| 18:13:23 | TheSeven | gevaerts: i looked at a disassembly of that pebble and almost fell off my chair |
| 18:13:34 | gevaerts | that bad? |
| 18:13:54 | TheSeven | remove -fPIC, remove the GOT and the code patching it altogether, and i bet it will still work :-D |
| 18:14:04 | TheSeven | and faster / smaller / less code, of course |
| 18:14:20 | TheSeven | the way they're calling functions is just crazy |
| 18:14:25 | gevaerts | the code itself, yes, but the data section? |
| 18:14:54 | TheSeven | hm yes, the data might need to be relocated |
| 18:15:20 | TheSeven | but why aren't they using sane branches, if they know the exact (relative) target address at compile time? |
| 18:16:02 | amiconn | They don't |
| 18:16:11 | CIA-8 | New commit by tomers (r24810): Brickmania: Hopefully prevent dissappearing of the ball |
| 18:16:25 | gevaerts | hm, my clock pebble is broken apparently |
| 18:16:31 | amiconn | At least not if the target is in another module (source file) or section |
| 18:17:19 | pamaury | tomers is on a brickmania fixing spree :) |
| 18:17:32 | | Quit robin0800 (Remote host closed the connection) |
| 18:17:41 | tomers | pamaury: yeah :-) |
| 18:17:48 | amiconn | If you put the restriction that pebbles must not use iram (but that probably already applies) you could compile without -mlong-calls |
| 18:17:58 | amiconn | Maybe this will improve code generation |
| 18:18:32 | pamaury | tomers: did you use another trick to prevent the ball from disappearing or did you eventually fix the intersection code ? |
| 18:18:58 | tomers | pamaury: It was not the intersection code that was buggy, it was the check of collisions |
| 18:19:55 | tomers | In this commit I fixed a case where the ball hit the floor, but code flow continued to check whether it hit the left wall, then moving it a bit and modifying its speed |
| 18:21:00 | tomers | but actually I'm not sure what caused it to hang in an infinite loop or alternatively to keep moving to ball to infinity ~ (-infinity, +infinity) actually |
| 18:21:26 | tomers | I just found one wrong thing and committed. This is why I wrote 'hopefully' :-) |
| 18:22:37 | | Quit topik (Ping timeout: 260 seconds) |
| 18:22:48 | * | gevaerts decides to test on m68k |
| 18:22:57 | tomers | There's still the bug of D2 not able to save game state well - and I don't think it's a bug in Brickmania, rather some bug with consequent multiple writes to a file descriptor... |
| 18:24:52 | amiconn | Does the D2 use the SD card as primary filesystem? |
| 18:25:02 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 18:25:34 | tomers | amiconn: yes, because the internal storage is read-only |
| 18:25:37 | gevaerts | amiconn: yes, if it boots from SD at least |
| 18:26:33 | | Quit CGL (Remote host closed the connection) |
| 18:28:45 | | Join CGL1 [0] (~CGL@190.207.226.111) |
| 18:29:03 | | Quit CGL1 (Remote host closed the connection) |
| 18:29:08 | | Join CGL1 [0] (~CGL@190.207.226.111) |
| 18:29:15 | | Quit CGL1 (Remote host closed the connection) |
| 18:29:56 | | Join CGL1 [0] (~CGL@190.207.226.111) |
| 18:30:45 | | Quit CGL1 (Client Quit) |
| 18:31:27 | | Join CGL [0] (~CGL@190.207.226.111) |
| 18:32:31 | | Join toffe82 [0] (~chatzilla@ppp-71-130-78-24.dsl.frs2ca.pacbell.net) |
| 18:32:46 | | Part mitk ("Ex-Chat") |
| 18:33:53 | | Join funman [0] (~fun@28.167.72-86.rev.gaoland.net) |
| 18:33:54 | | Quit funman (Changing host) |
| 18:33:54 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 18:37:45 | TheSeven | gevaerts: and please fix that hardcoded path... |
| 18:37:54 | TheSeven | just use snprintf(filename,MAX_PATH, ROCKBOX_DIR "/pebbles/%s.pebble",temp); |
| 18:38:07 | TheSeven | (skin_parser.c:557) |
| 18:38:54 | | Quit iq (Remote host closed the connection) |
| 18:44:17 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 18:44:24 | | Quit Farthen (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
| 18:45:43 | kugel | hm, it almost works :/ |
| 18:46:27 | kugel | images are only a tad bit corrupted :( |
| 18:49:54 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
| 18:50:24 | kugel | backdrop, static images and volume bars seem to work |
| 18:53:52 | * | TheSeven would like to know what's wrong with the backdrop and some other graphics in that pebble build |
| 18:57:27 | TheSeven | just lack of space... |
| 18:57:41 | TheSeven | gevaerts, why did you shrink the skin buffer in the pebble patch? |
| 18:57:46 | gevaerts | did I? |
| 18:57:55 | *** | Saving seen data "./dancer.seen" |
| 18:57:57 | TheSeven | -#define SKIN_BUFFER_SIZE (MAIN_BUFFER + REMOTE_BUFFER) + \ |
| 18:57:58 | TheSeven | - (WPS_MAX_TOKENS * sizeof(struct wps_token)) |
| 18:58:00 | TheSeven | +//#define SKIN_BUFFER_SIZE (MAIN_BUFFER + REMOTE_BUFFER) + \ |
| 18:58:01 | TheSeven | +// (WPS_MAX_TOKENS * sizeof(struct wps_token)) |
| 18:58:03 | TheSeven | +#define SKIN_BUFFER_SIZE 0x2000 |
| 18:58:06 | | Quit Strife89|Desktop (Quit: Booting into Windows to do maintenance.) |
| 18:58:07 | gevaerts | oops |
| 19:00 |
| 19:01:41 | | Join phanboy4 [0] (~benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 19:03:41 | | Quit kugel (Read error: Operation timed out) |
| 19:03:53 | Unhelpful | gevaerts: so basically what you're doing now is loading pebbles into the buffer at whatever address they can get, and assuming that all ARM code is relocatable? |
| 19:04:46 | gevaerts | Unhelpful: the code is compiled with -fPIC, which gives me a .got section that has all addresses I need to change in it |
| 19:05:06 | gevaerts | So it's basically a very primitive relocation format |
| 19:05:48 | Unhelpful | ah. how messy is handling the relocs? |
| 19:06:44 | gevaerts | three lines of code |
| 19:07:02 | TheSeven | trivial from the loader side - a huge mess for the compiler (and the code generated by it) |
| 19:07:38 | TheSeven | what about ELF / PE / whatever executables and a proper relocator? |
| 19:08:25 | Unhelpful | TheSeven: elf apparently has an appalling number of reloc types for ARM :/ |
| 19:08:35 | gevaerts | The consensus seems to be that ELF is too complex, but that COFF might be doable |
| 19:08:46 | TheSeven | coff is rather trivial |
| 19:08:59 | gevaerts | However, nobody seems to be doing it, so I decided to go ahead to wake things up :) |
| 19:09:01 | TheSeven | i haven't seen anything but reloc type 3 being used there |
| 19:10:10 | Unhelpful | TheSeven: how nasty *is* this code, exactly? so much ARM code is already PIC due to the use of relative addressing for jump, constant loads, etc. |
| 19:10:40 | | Join Grahack [0] (~Grahack@ip-252.net-81-220-6.versailles.rev.numericable.fr) |
| 19:10:43 | TheSeven | well, the jumps *aren't* relative if you use -fPIC |
| 19:11:03 | TheSeven | they load the destination address from the GOT instead of just using a relative jump -.- |
| 19:12:58 | gevaerts | Maybe -mno-gotplt helps? I'm not sure if I understand what it does |
| 19:13:46 | TheSeven | http://pastie.org/835605 |
| 19:14:26 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 19:15:12 | Unhelpful | TheSeven: ideally we'd like to see references within the plugin done by offset, with relocs only when offsets are out-of-range or to things in core (if we're doing relocs, relocs for direct jump into core would be nice-to-have. ;P) |
| 19:16:47 | Unhelpful | although direct-bl for calls into core might not be a practical relocation scheme anyway... |
| 19:16:54 | TheSeven | a total of 32 bytes (6 instr + 2 data) and two memory loads for something that could be a single BL instruction |
| 19:18:04 | TheSeven | the core calls are still better than the internals calls in the pebble! |
| 19:19:04 | Unhelpful | TheSeven: well, how would we produce a binary that has reloc data that we can use, without -fPIC? |
| 19:19:35 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 19:19:53 | JdGordon | AlexP: I wouldnt expect it to, whats the issue? |
| 19:19:59 | JdGordon | pixelma: arg, thats damn wierd |
| 19:19:59 | TheSeven | i don't undestand why the compiler is generating that crap in the first place. this simply isn't needed for anything, as long as the call is within the same module |
| 19:20:08 | JdGordon | kugel: why would that make it any harder to size? |
| 19:20:21 | kugel | because you need to know the end |
| 19:20:33 | * | DerPapst is annoyed by this feature introduced in r24696 (Clickable Sim Buttons). If the sim is active and i accidenty scroll with the mousewheel it recives some strange button presses (even with −−nobackground) and stops playback as a consequence. and after that the sim doesn't react to any button presses via recived the keyboard. |
| 19:20:56 | kugel | anyway, I have it almost working |
| 19:21:20 | gevaerts | TheSeven: have you tried without -mlong-calls? |
| 19:22:06 | Unhelpful | TheSeven: per manual PIC code "accesses all constant addresses through a global offset table"... if all means *all* then apparently it is assuming that even things in the same module may move relative to each other? |
| 19:22:43 | TheSeven | Unhelpful: afaict the compiler emits the code in a way that inhibits this (only a single section) |
| 19:23:10 | JdGordon | kugel: ? the end is start+size? whats so hard about that? |
| 19:23:21 | Unhelpful | woo, found the stupid bug in this divider. :D |
| 19:23:27 | kugel | JdGordon: the size is unknown.. |
| 19:23:34 | Unhelpful | ...now to write it in ARM :/ |
| 19:24:11 | JdGordon | then you are creating the buffer too early |
| 19:24:28 | kugel | JdGordon: you can't just use the entire audio buffer and then cap it after skin parsing |
| 19:24:32 | * | Unhelpful ponders doing evil things with the carry flag... |
| 19:24:51 | kugel | because giving the whole audio buffer means it will put stuff at the start and at the end of the audio buffer |
| 19:24:59 | JdGordon | sure |
| 19:25:32 | TheSeven | why does one even need a GOT? |
| 19:25:33 | kugel | "sure"? |
| 19:25:46 | TheSeven | why can't they just pc-relative values instead? |
| 19:25:56 | gevaerts | TheSeven: -funit-at-a-time makes a big size difference (128 for starfield.pebble). Can you have a look at the code? |
| 19:26:14 | JdGordon | what happened to storeing the them size in the .cfg and if that size is bigger than the current theme require reboot? and if its unkown just use a really large buffer? |
| 19:26:18 | TheSeven | gevaerts: where in that weird make file do i place that best? |
| 19:26:23 | Unhelpful | TheSeven: those are range-limited. reasonably for jumps, but more tightly for loads. |
| 19:26:40 | gevaerts | TheSeven: at the end of PEBBLEFLAGS in apps/pebbles/pebbles.make |
| 19:26:44 | TheSeven | Unhelpful: ldr Rx, =difference, add Rx, Rx, PC |
| 19:26:46 | kugel | JdGordon: that's all much harder than just grabbing the entire audio buffer and cap it |
| 19:26:52 | TheSeven | still a lot faster than the GOT crap |
| 19:27:13 | JdGordon | kugel: but then you have to stop playback to reload a theme? |
| 19:27:19 | JdGordon | imo thats the wrong way to do it |
| 19:27:30 | kugel | what's the wrong way? |
| 19:27:55 | JdGordon | also, what happened to figuring out the required size during parse time and only continue loading if it fits? |
| 19:28:04 | Unhelpful | TheSeven: faster still would be not using PIC... gcc would then emit code that loads the values from nearby constant pools, and as long as we retain reloc info we could fix it up. |
| 19:28:04 | kugel | that's what I do right now |
| 19:29:13 | JdGordon | so just change it to default to a large value if its unknown, or the .cfg value + extra for known and you're done |
| 19:29:26 | kugel | that's what I do right now |
| 19:29:29 | TheSeven | Unhelpful: the constant pools are close enough to be loaded via LDR Rx, [PC,#whatever] |
| 19:29:42 | kugel | I'm just saying it's harder than it needs to be |
| 19:30:18 | JdGordon | its exactly as hard as it should be |
| 19:30:18 | kugel | image loading is broken I think. it should fail to parse if an image can't be loaded |
| 19:30:34 | JdGordon | using the whole buffer means having to stop playback which is lame |
| 19:30:46 | kugel | you don't understand me |
| 19:31:14 | kugel | using the whole buffer at boot, then load skins into it. for changing skins afterwards use the existing one (and ask for reboot if needed) |
| 19:31:23 | kugel | that would be simple and nice |
| 19:31:25 | TheSeven | btw, why isn't the linker cabable of inserting thunks for out-of-range relative branches? |
| 19:31:36 | TheSeven | then we could disable that long-call mess altogether |
| 19:31:46 | kugel | TheSeven: ...eabi is doing that :) |
| 19:31:56 | | Quit Uretti (Read error: Connection reset by peer) |
| 19:32:10 | TheSeven | i'm using eabi, and it doesn't seem to do it |
| 19:32:22 | kugel | have you removed -mlong-calls? |
| 19:33:07 | TheSeven | not manually, but why isn't that done on eabi by default? |
| 19:33:29 | kugel | it should. but if it's doing long calls it's buggy :) |
| 19:33:46 | gevaerts | TheSeven: -mlong-calls is enabled by CFLAGS I think |
| 19:34:43 | kugel | print GCCOPTS to be sure |
| 19:35:28 | kugel | TheSeven: weren't you able to remap memory? you don't need long calls at all then |
| 19:35:50 | | Quit stripwax (Quit: http://miranda-im.org) |
| 19:35:54 | TheSeven | no, the 940t doesn't have an mmu |
| 19:36:13 | kugel | but wasn't there a trick? |
| 19:36:17 | gevaerts | that also wouldn't help for all targets |
| 19:37:02 | kugel | configure should only add -mlong-calls if it's no eabi build but it appears to be broken if you still get them |
| 19:37:07 | TheSeven | kugel: we had a trick to do uncached reads/writes, but not for remapping |
| 19:37:18 | | Quit anewuser (Quit: http://xrl.us/WinterChipV =ooo ϢINTER ϾHIP 5iVE is OOON!! omg 7 days left =oo) |
| 19:37:27 | TheSeven | yes, i can't find where it sets that flag, but it is set in my makefile |
| 19:38:37 | * | JdGordon accuses AlexP of sabotaging his weekend! |
| 19:38:50 | JdGordon | multifonts on the remote worked when it was commited! |
| 19:39:03 | kugel | configure, line 263+ |
| 19:39:53 | TheSeven | ugh |
| 19:40:40 | kugel | JdGordon: image loading is broken, parsing should fail if it can't be loaded |
| 19:41:22 | kugel | load_skin_bitmaps always returns true |
| 19:41:35 | CIA-8 | New commit by theseven (r24811): Fix configure to not use -mlong-calls when configuring for EABI |
| 19:42:01 | JdGordon | kugel: so fix it? |
| 19:42:13 | kugel | trying.. |
| 19:42:14 | TheSeven | wow, that has been a stupid bug |
| 19:42:23 | TheSeven | weird that nobody had noticed this before |
| 19:42:45 | * | kugel hides |
| 19:42:56 | | Join iq [0] (~iq@unaffiliated/iq) |
| 19:42:57 | * | TheSeven wonders how much his core binary will shrink now |
| 19:43:04 | kugel | about 50k |
| 19:43:28 | * | TheSeven was already a little un-impressed by seeing a 2K binsize reduction when enabling eabi |
| 19:48:28 | | Join karashata [0] (~karashata@74-220-162-11.wightman.ca) |
| 19:49:51 | kugel | JdGordon: %X|-| is valid? |
| 19:50:01 | JdGordon | shouldnt be |
| 19:50:05 | JdGordon | not anymore |
| 19:50:10 | JdGordon | did that get left in somewhere? |
| 19:50:15 | | Join Blue_Dude [0] (~chatzilla@adsl-235-206-131.mco.bellsouth.net) |
| 19:50:30 | JdGordon | - is set as default, but that line shouldnt be valid |
| 19:50:40 | | Join Frakenstein [0] (~Frakenste@74-136-164-84.dhcp.insightbb.com) |
| 19:50:49 | kugel | I'm a bit confused by "if (backdrop[0] == '-')" in skin_backdrop_load |
| 19:50:57 | kugel | ah ok |
| 19:51:43 | TheSeven | kugel: yes, 56K binsize decrease |
| 19:55:21 | Blue_Dude | kugel: Thanks for the playlist viewer screen fix yesterday. |
| 19:56:42 | Unhelpful | TheSeven: funny-i-could-swear-i-did-that-ages-ago. :/ |
| 19:57:01 | Blue_Dude | BTW, still looking for feedback on making a new delete hotkey for the tree view. Some discussion a day or two on that. It's something I'd use a lot but I'm not 100% sure how much anyone else would get from it. |
| 19:57:09 | TheSeven | Unhelpful: yes, you did it, but it was broken |
| 19:57:29 | TheSeven | look at the diff i just commited ;-) |
| 19:57:30 | Unhelpful | TheSeven: thanks for fixing then. :) |
| 19:57:58 | | Quit stoffel (Remote host closed the connection) |
| 19:58:13 | * | Unhelpful wonders how tired he must've been when he wrote that |
| 19:58:40 | TheSeven | the nasty thing about that is that it just fails silently |
| 19:59:21 | JdGordon | Blue_Dude: one click delete? |
| 19:59:59 | Unhelpful | TheSeven: test pretty much always does ;) |
| 20:00 |
| 20:00:34 | * | gevaerts is confused |
| 20:00:38 | Blue_Dude | JdGordon: more like one click to confirm-delete. |
| 20:03:52 | kugel | perl needs { } for single line ifs? |
| 20:04:21 | kugel | Blue_Dude: I wouldn't use it a lot and would rather see insert on the rec button |
| 20:04:46 | kugel | Blue_Dude: I thought I was the only one annoyed by that :) |
| 20:04:51 | JdGordon | kugel: perl needs {} for ALL ifs |
| 20:05:45 | Unhelpful | kugel: yah, it's one of its more annoying deviations from "just copy C's syntax" that for/if/while require braces. |
| 20:06:27 | | Join darkham [0] (~ubuntu@host71-216-dynamic.117-80-r.retail.telecomitalia.it) |
| 20:07:15 | funman | I have put my hands on the patches to linux kernel which add as352x and as353x targets |
| 20:07:41 | JdGordon | woo! |
| 20:07:53 | JdGordon | does this mean I shold go buy another clip+? |
| 20:07:54 | funman | they both add a bunch of new files, some of them have the gplv2 licence header, some others have a more restrictive header which prohibits reproduction without the written consent of AMS |
| 20:08:28 | funman | well the MMC/SD driver for as353x is clearly suited for clip+, but i must check the licence of this file |
| 20:09:26 | funman | it's gplv2, so everything is fine \o/ |
| 20:09:51 | | Join kimi-sharamin [0] (~karashata@74-220-162-11.wightman.ca) |
| 20:10:11 | CIA-8 | New commit by jdgordon (r24812): remote multifont fixes. it shoud be working again (blame AlexP! he made me break it last week!) |
| 20:10:31 | Unhelpful | funman: that seems too easy ;) |
| 20:10:45 | | Quit karashata (Ping timeout: 268 seconds) |
| 20:11:00 | CIA-8 | New commit by kugel (r24813): Fix wpsbuild to properly generate "-" for theme related settings (to get the default values/no file for filename settings). |
| 20:11:08 | funman | i think sharing the whole patch file with devs is easier than removing the bits which say "reproduction prohibited", but then i must ask the devs to not look at these parts until we sort out if we can use them or not |
| 20:11:42 | JdGordon | do we still have the ams contact? |
| 20:11:54 | funman | i have the mail of that marketing person |
| 20:11:56 | Bagder | JdGordon: unfortunately not |
| 20:12:07 | | Join saratoga [0] (~463f90ed@gateway/web/freenode/x-hszyhocvfybjjxkx) |
| 20:12:07 | Bagder | they seem to have abandoned us |
| 20:12:07 | JdGordon | :( |
| 20:12:27 | funman | this guy had sent me the as353x datasheet (after several mails/delay though) |
| 20:12:42 | Bagder | aha, that's good |
| 20:13:20 | Blue_Dude | kugel: I wonder how easy it would be to have a user-assignable hotkey. Insert or delete (or anything else in a context menu) depending on user preference? |
| 20:13:27 | kugel | does anyone know why read_bmp_file multiplies error return values with fd? |
| 20:13:53 | JdGordon | Blue_Dude: thats the way I'd like to see it done, but apparently it falls into "no configurable keys/menus" which means never going to happen |
| 20:14:18 | * | JdGordon stares daggers at the people who know who they are about this |
| 20:14:34 | Blue_Dude | What does this: "no configurable keys/menus" mean? |
| 20:14:37 | kugel | I thought we changed our minds about it? |
| 20:14:51 | Blue_Dude | What's a quickscreen then? |
| 20:15:08 | funman | note, those files which have the restrictive header also have a "MODULE_LICENSE("GPL"); line at the bottom |
| 20:15:37 | kugel | so they cheat? |
| 20:16:03 | funman | I checked the patches sent by Thomas Luo 4 years ago to linux-arm-kernel mailing list for as352x |
| 20:16:16 | funman | some were exactly the files I have, but with a correct GPLv2 header |
| 20:16:36 | funman | I would think it's probably an old habit of using that kind of headers, on the advice of their lawyers |
| 20:16:43 | saratoga | if they say GPL anywhere on them I would assume we can at least rewrite them for rockbox, if not use them verbatium |
| 20:16:57 | gevaerts | We can't use them verbatim |
| 20:17:01 | kugel | Unhelpful: do you know? |
| 20:17:05 | iq | Hi, I am compiling for Clip+. I am able to build the bootloader and simulator but can not compile the RockBox - getting error: http://www.pastebin.com/m506857c4 |
| 20:17:20 | saratoga | i don't think rockbox builds for the clip+ |
| 20:17:22 | funman | iq: rockbox doesn't build for clip+ yet, since the bootloader isn't finished |
| 20:18:19 | iq | ok - I guess I'll have to wait then. |
| 20:18:26 | saratoga | so how hard will it be to get an SD driver using these sources? |
| 20:18:44 | funman | i would expect quite easy |
| 20:19:05 | saratoga | do they cover other parts of the chip like clocks and power management? |
| 20:19:21 | funman | i guess everything is in here |
| 20:19:33 | funman | usb, i2c, sound, clocks ... |
| 20:19:52 | saratoga | ! |
| 20:20:17 | Unhelpful | kugel: do i know? |
| 20:20:23 | kugel | "does anyone know why read_bmp_file multiplies error return values with fd?" |
| 20:20:42 | funman | since it's not clear to me how i can redistribute it, i'll send it to interested devs if they don't put it online, at least until we sort how that restrictive header works together with gpl |
| 20:21:01 | saratoga | yes that seems reasonable |
| 20:21:18 | saratoga | if they didn't put it out in the open we probably shouldn't redistribute it anyway |
| 20:21:24 | saratoga | well publically redistribute |
| 20:21:33 | Unhelpful | kugel: i'm not looking at it right now, but doesn't it do something like -(fd *10 + const)? |
| 20:21:35 | saratoga | if only so they help us when we ask about the Clip++ |
| 20:21:42 | funman | parts of as352x at least were sent to a public ML so at least those are ok |
| 20:21:56 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 20:21:57 | | Quit pixelma (Disconnected by services) |
| 20:22:11 | saratoga | might as well just treat it like the other AMS docs for now |
| 20:22:13 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 20:22:13 | | Quit amiconn (Disconnected by services) |
| 20:22:15 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 20:22:26 | Unhelpful | i think the idea is to return both some constant indicating where the error happened, and also the fd. |
| 20:22:39 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 20:24:50 | kugel | so I can see it by the constant? |
| 20:24:54 | kugel | it=the error |
| 20:25:13 | kugel | if (error % 10) ... ? |
| 20:25:23 | | Join Lear [0] (chatzilla@rockbox/developer/lear) |
| 20:25:32 | funman | i'll start deciphering the linux code and fill the missing holes in the Clipv2/Clip+ SD driver, unless someone else wants to do it |
| 20:29:34 | CIA-8 | New commit by kugel (r24814): Fix the mechanism to fail to parse skins if images fail to load and fix having no backdrop at all (neither %X nor backdrop setting, DancePuffDuo was ... |
| 20:30:10 | kugel | funman: I can't imagine anyone would want to (except FlynDice maybe) :) |
| 20:31:18 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 20:31:46 | funman | ah: there was some errors in reverse engineering :/ |
| 20:33:15 | | Join stooo [0] (~sto@e181177203.adsl.alicedsl.de) |
| 20:39:29 | kugel | JdGordon: I think I found the reason for the increased boot time, the sbs is parsed multiple times even if the theme has none |
| 20:40:27 | JdGordon | it should be parsed max once |
| 20:41:03 | JdGordon | skin_data_load() will happen max twice, the first will be an instant recall |
| 20:42:47 | | Quit mc2739 (Ping timeout: 252 seconds) |
| 20:43:09 | kugel | does the wps need to be parsed before the rsbs? |
| 20:43:23 | * | gevaerts finally finds what he was doing wrong |
| 20:43:30 | kugel | or could I swap them (and put the skin loading within FOR_NB_SCREENS()) |
| 20:44:22 | JdGordon | the sbs MUST be parsed first for each screen |
| 20:44:29 | JdGordon | otherwise order doesnt matter |
| 20:44:39 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 20:45:26 | JdGordon | hmm, I meant the screens sbs must be parsed before any other skins on that screen |
| 20:45:31 | JdGordon | so yes, you could but it in a loop |
| 20:46:21 | saratoga | what does the linux source refer to the as3525v2 as ? |
| 20:47:06 | CIA-8 | New commit by Buschel (r24815): Optimization for cook codec. Rework sample output to be able to use highly optimized dsp routines. Moved some functions to iram. Speeds up codec by ... |
| 20:47:17 | TheSeven | btw, what's holding back the switch to eabi? is it still buggy on some targets? |
| 20:47:45 | | Join stoffel [0] (~quassel@p57B4ECED.dip.t-dialin.net) |
| 20:48:19 | funman | saratoga: not sure if there is linux code for this one |
| 20:48:47 | saratoga | so its just the as3525 and the as353x? |
| 20:48:58 | funman | i believe AMS just updated the as3525 with some components present in the as353x (SDMMC, VIC, as3514) |
| 20:49:11 | funman | as352x, there is also as3527 code |
| 20:49:17 | funman | do you want them ? |
| 20:50:10 | TheSeven | gevaerts: on eabi without -mlong-calls the pebble code is sane |
| 20:51:15 | funman | btw original submission of (parts of) as352x linux patches are on http://lists.arm.linux.org.uk/lurker/mindex/linux-arm-kernel@20061206.130000.00000000.en.html (without follow up to changes/informations requested by the arm linux developers) |
| 20:52:30 | gevaerts | TheSeven: nice! |
| 20:52:51 | gevaerts | In the meantime, I've (finally!) managed to put the rb pointer back automatically |
| 20:53:22 | saratoga | funman: sure |
| 20:53:43 | moos | JdGordon kugel: maybe an opportunity to look at disabling the copy of rsbs for tagets that doesn't have one |
| 20:54:08 | JdGordon | ? |
| 20:54:09 | | Quit darkham (Quit: Sto andando via) |
| 20:55:29 | moos | I meant that .rsb files are still there for tagets that don't have remote, sure that need an easy fix |
| 20:56:03 | kugel | if (setting[0] && setting[0] != 0xff && setting[0] != '-') #-> "warning: comparison is always true due to limited range of data type" |
| 20:56:08 | kugel | ??? |
| 20:56:28 | JdGordon | wtf is the check for 0xff? |
| 20:56:42 | JdGordon | thats there on a few settings but I dont think is still needed |
| 20:57:16 | kugel | no idea, it's there since I looked at it for the first time |
| 20:57:19 | | Quit iq (Quit: Leaving) |
| 20:57:29 | saratoga | funman: if you have a link handy, would you gtalk it to me? i have to head out |
| 20:57:43 | saratoga | i'll probably be useless for this port but i'd still like to look it over |
| 20:57:44 | moos | kugel: nice that you noticed a slowdown on boot, since JdGordon doesn't/don't want :p |
| 20:57:48 | funman | i'll send it by mail |
| 20:57:55 | JdGordon | kugel: I'm pretty sure we can remove that.. I tihnk its from when the config was on disk |
| 20:57:58 | *** | Saving seen data "./dancer.seen" |
| 20:58:17 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 20:58:49 | | Join ansuz [0] (~ansuz@dsl093-172-019.pit1.dsl.speakeasy.net) |
| 20:58:56 | FlynDice | funman: no time right now but I see your comments above with great interest ;-) |
| 20:59:09 | saratoga | thanks |
| 20:59:12 | funman | FlynDice: you're a recipient of the mail as well ;) |
| 20:59:39 | FlynDice | funman: You Da man!! |
| 20:59:47 | | Quit stooo (Quit: Leaving.) |
| 20:59:53 | kugel | I'm not :( |
| 20:59:56 | saratoga | might as well add kugel, mt |
| 20:59:59 | saratoga | :) |
| 21:00 |
| 21:00:06 | | Quit saratoga (Quit: Page closed) |
| 21:00:08 | funman | kugel: you were already ;) |
| 21:00:54 | JdGordon | Bagder: oh, can you add uchida to the devs group on flysrpay? |
| 21:03:31 | | Quit BlakeJohnson86 (Quit: Leaving.) |
| 21:06:41 | | Join iq [0] (~iq@unaffiliated/iq) |
| 21:07:40 | | Join BlakeJohnson86 [0] (~bjohnson@2002:1876:a27b:0:227:13ff:fe65:1262) |
| 21:08:02 | * | gevaerts enjoys watching his starfield wps :) |
| 21:08:45 | kugel | funman: the mail came later. thanks! |
| 21:10:07 | | Join perfectdrug [0] (~marko@p5B0EED52.dip.t-dialin.net) |
| 21:10:22 | funman | iq: did you run the rockbox bootloader on your clip+ ? |
| 21:12:14 | | Quit BlakeJohnson86 (Remote host closed the connection) |
| 21:12:47 | gevaerts | pebbles don't work on m68k :\ |
| 21:13:03 | gevaerts | or at least, they need more effort |
| 21:14:36 | ThomasAH | funman: were you be able to decode the hex numbers (csd?) now? |
| 21:19:07 | iq | funman, no, I have not. I thought it is incomplete? |
| 21:20:27 | funman | ThomasAH: yes, my app was buggy, they describe a 100% normal SD card |
| 21:20:57 | ThomasAH | funman: so SD vs. SDHC? |
| 21:20:58 | funman | iq: yes it's incomplete, and there have been 2 clip+ bricked already, so I was wondering if you had tried it successfully |
| 21:21:11 | funman | ThomasAH: 2GB is SD and 4/8GB are SDHC |
| 21:21:51 | ThomasAH | funman: so as expected, right? |
| 21:21:59 | funman | yep |
| 21:22:01 | iq | funman, we can't unbrick a Clip+, right? |
| 21:22:10 | | Join BlakeJohnson86 [0] (~bjohnson@2002:1876:a27b:0:227:13ff:fe65:1262) |
| 21:22:31 | funman | iq: i don't think we can, perhaps if you manage to solder a jtag adaptor, but definitely not in a simple way |
| 21:23:28 | ThomasAH | iq: my clip+ 8gb survived the bootloader ... so I think it is 2 bricked vs. 3 non-bricked now |
| 21:23:57 | funman | i think it's even 4 non-bricked |
| 21:24:05 | iq | ThomasAH, what procedure you followed to load it ? |
| 21:24:28 | funman | iq: i think it's detailed on SansaAMS wiki page (mkamsboot) |
| 21:25:37 | iq | funman, so everyone followed the same procedure and we have a little over 50% success rate. |
| 21:25:38 | ThomasAH | iq: I built the boot loader with the old arm compiler (not -eabi or how it is called), built mkamsboot, then ./mkamsboot clppa-original.bin bootloader-clipplus.sansa clppa-patched.bin |
| 21:25:40 | TheSeven | is it just bricking devices randomly, or did you manage to track down what had happened? |
| 21:25:40 | | Quit stoffel (Remote host closed the connection) |
| 21:26:08 | funman | iq: yes, although the code in mkamsboot changed, and the current code worked 100% of the times it was tried |
| 21:26:09 | ThomasAH | iq: then copied clppa-patched.bin as clppa.bin to the internal memory root dir |
| 21:26:10 | | Quit Grahack (Quit: Tu m'as vu ?) |
| 21:26:23 | | Nick kimi-sharamin is now known as karashata (~karashata@74-220-162-11.wightman.ca) |
| 21:26:24 | funman | TheSeven: we don't know what happened |
| 21:26:39 | | Quit karashata (Quit: The fluffy dragon has left completely!) |
| 21:26:39 | TheSeven | and they just don't power on any more, or what do they do? |
| 21:26:46 | funman | for JdGordon's clip, the code might have used r5 or r3 but i don't remember |
| 21:26:46 | TheSeven | no DFU on those things? |
| 21:26:57 | funman | afaik no |
| 21:27:04 | TheSeven | where is the bootloader stored? nor? nand? |
| 21:27:14 | funman | nand |
| 21:27:18 | TheSeven | is there an internal bootrom or is it booting directly from nand? |
| 21:27:27 | TheSeven | (via steppingstone) |
| 21:27:29 | funman | on e200v2 you can access the first sectors of the SD card where it's stored, but only on this one |
| 21:27:30 | * | ThomasAH was able to flash two versions of the boot loader without problems and back to plain OF |
| 21:28:29 | funman | TheSeven: i don't know how it works in the details, only that the OF is stored on the first sectors of the SD (i believe it's loaded to memory by the ROM bootloader) |
| 21:28:56 | TheSeven | so they're using those embedded microsd chips? |
| 21:29:07 | | Join Farthen [0] (~chatzilla@e179232003.adsl.alicedsl.de) |
| 21:29:17 | funman | there is a nand chip which is read/written by a MMC/SD controller |
| 21:29:40 | funman | probably to avoid wear leveling in software |
| 21:29:54 | funman | and since they are sandisk they don't have to pay royalties for the controller |
| 21:29:59 | JdGordon | I'm happy to post my clip to anyone for an autopsy |
| 21:29:59 | TheSeven | heh, hardware ftl. funny. why don't they integrate that into one chip, like those microsd things do? |
| 21:30:26 | funman | TheSeven: aren't the microsd just a nand chip + a controller? |
| 21:30:35 | TheSeven | yes, but in one package |
| 21:31:13 | | Join Kitr88 [0] (~Kitr88@BSN-182-25-211.dial-up.dsl.siol.net) |
| 21:31:28 | funman | on e200v2 you can access the OF as a usb mass storage if you connect 2 pads together |
| 21:31:44 | JdGordon | I tried that and didnt have any lucjk |
| 21:31:51 | iq | ThomasAH, where you got clppa-patched.bin ? |
| 21:31:56 | funman | I believe you can achieve the same thing by connecting 2 pins of the nand chip (I read this method on s1mp3.org) |
| 21:32:12 | funman | if i do that on my fuzev1 or clivp1 i have an usb mass storage but with 0 sectors |
| 21:32:19 | ThomasAH | iq: this is generated by mkamsboot |
| 21:32:49 | ThomasAH | (the third argument is the target file name) |
| 21:33:02 | TheSeven | funman: in theory yes, but the sd controller will probably not like it |
| 21:33:40 | TheSeven | if anything, i would jam the communication between the CPU and the SD controller |
| 21:33:46 | funman | if this method (shorting directly the nand pins) doesn't work on e200v2 then it could mean we didn't find the correct pads on other models |
| 21:34:03 | funman | perhaps the OF is stored on the nand, and also somewhere else |
| 21:34:19 | TheSeven | funman: all of this stuff will only help if the bootrom has a recovery mode |
| 21:34:30 | CIA-8 | New commit by kugel (r24816): Properly generate (with "Save Theme Settings") and handle filename settings with "-". |
| 21:34:34 | CIA-8 | New commit by kugel (r24817): Shorten settings_skins_apply() and correct some checks. |
| 21:34:34 | TheSeven | could it be possible to tap all the sd signals? |
| 21:34:36 | CIA-8 | New commit by kugel (r24818): Don't be too wasteful and only reparse skins when actually needed. |
| 21:34:46 | | Quit Kitar|st (Ping timeout: 246 seconds) |
| 21:35:10 | funman | the boot procedure is detailed in the as3525 datasheet, you want to have a look? |
| 21:35:44 | | Quit Kitr88 (Ping timeout: 260 seconds) |
| 21:35:44 | funman | http://www.austriamicrosystems.com/eng/content/download/16763/295720 |
| 21:35:53 | funman | page 22 7.1.6 boot concept |
| 21:37:29 | funman | XPC[3:1] is all 0 on my clipv1, that would mean boot device is "SPI master ST M25Pxx serial Nor Flash" |
| 21:38:07 | funman | e200v2 probably trigger the "USB boot promer" |
| 21:38:37 | funman | "if there is no bootable device" is probably the case when the NAND can't be read |
| 21:39:19 | TheSeven | well, the jtag of that thing is even documented! |
| 21:40:37 | | Join Kitar|st [0] (Kitr88@BSN-182-10-163.dial-up.dsl.siol.net) |
| 21:42:13 | | Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 21:43:05 | TheSeven | funman: are there any pcb scans of clip+? |
| 21:43:36 | funman | there is ABI pictures but i could scan mine if you need bigger resolution |
| 21:44:07 | funman | http://www.anythingbutipod.com/archives/images/sansa-clip-disassembled/sandisk-sansa-clip-disassembled-12.jpg and 13.jpg |
| 21:44:38 | funman | oh, sorry I misread, it's only clipv1 |
| 21:44:56 | funman | i haven't seen a clip+ opened |
| 21:45:27 | ThomasAH | I think I have somewhere on ABI |
| 21:45:47 | | Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-nclbbcioflrutssu) |
| 21:46:15 | * | ThomasAH checks his notes |
| 21:46:35 | saratoga | heh the patches show CCU_GPIOA through CCU_GPIOP |
| 21:46:39 | saratoga | i wonder how many are on the clip |
| 21:46:41 | iq | ThomasAH, clppa-original.bin is the clppa.bin from clipplus01.02.09.zip ? |
| 21:46:43 | saratoga | + |
| 21:46:48 | funman | saratoga: for as353x ? |
| 21:46:54 | saratoga | yeah |
| 21:47:00 | | Join petur [0] (~peter@d54C6F9B2.access.telenet.be) |
| 21:47:00 | | Quit petur (Changing host) |
| 21:47:00 | | Join petur [0] (~peter@rockbox/developer/petur) |
| 21:47:07 | funman | i only saw GPIOA through D |
| 21:47:09 | funman | iq: yes |
| 21:47:46 | iq | BTW, I checked out the code this morning (CST GMT-6) - so hopefully I will have the good bootloader, right :) ? |
| 21:47:58 | ThomasAH | http://www.anythingbutipod.com/archives/2009/08/sandisk-sansa-clip-plus-disassembly.php |
| 21:48:19 | ThomasAH | iq: yes, manually renamed to avoid mistakes :) |
| 21:48:19 | funman | the bootloader isn't important at this time, mkamsboot is the part which can brick. And if you checked it out today it's the code which worked on my Clip+ |
| 21:49:10 | iq | Okay, so now I have "clppa-patched.bin" |
| 21:49:44 | funman | iq: be sure you are ready to risk bricking your Clip+ before copying it! |
| 21:50:06 | iq | funman, so you won't send me a new Clip+ :) ? |
| 21:50:52 | iq | it is $40... so if it will help in the testing then i can risk. |
| 21:50:54 | funman | no, only my gratitude :) |
| 21:51:31 | iq | Now i need to figure out how to access the internal memory. |
| 21:52:02 | ThomasAH | TheSeven: did you notice the URL? http://www.anythingbutipod.com/archives/2009/08/sandisk-sansa-clip-plus-disassembly.php |
| 21:52:05 | funman | you need to set USB mode to MSC first i think |
| 21:52:18 | saratoga | in the CGU code: "0 /* removed in V2 */ " |
| 21:52:20 | iq | ThomasAH, Hopefully I won't be needing this - LOL |
| 21:52:25 | funman | http://www.anythingbutipod.com/archives/images/sansa-clip-plus/sandisk-sansa-clip-plus-disassembly-15.jpg < i wonder if the small chip is the FM |
| 21:52:42 | funman | saratoga: they removed a device ? |
| 21:54:12 | saratoga | they removed some registers apparently |
| 21:54:20 | iq | I have changed the USB mode. But I still see my Music and other folders when I connect it to my machine. |
| 21:54:34 | funman | iq: then just copy clppa.bin there and unplug |
| 21:55:09 | ThomasAH | iq: (next to music, not into :)) |
| 21:55:18 | iq | mv clppa-patched.bin clppa.bin |
| 21:55:27 | ThomasAH | iq: noooooooo! :) |
| 21:55:34 | * | ThomasAH suggests cp |
| 21:55:41 | iq | ok |
| 21:55:44 | funman | it looks like the controller supports several cards, perhaps there isn't 2 separate controllers for internal storage and µSD slot like on as3525 |
| 21:55:56 | ThomasAH | (for forensic if it fails) |
| 21:56:04 | iq | ThomasAH, start over ? |
| 21:56:06 | AlexP | I'm not sure I accept responsibility, but ta for fixing :) I'll try it out shortly |
| 21:56:09 | AlexP | @JdGordon |
| 21:56:17 | JdGordon | :) |
| 21:56:21 | saratoga | there are registers for setting the SD card communication voltages |
| 21:56:25 | saratoga | didn't we have an issue with that |
| 21:56:27 | ThomasAH | iq: no, just cp back to your PC |
| 21:56:44 | iq | ok |
| 21:57:19 | iq | ThomasAH, it is 15MB |
| 21:57:20 | funman | saratoga: iirc it was the arm core voltage |
| 21:58:10 | iq | ThomasAH, Copied, now unplug from the machine and power cycle ? |
| 21:58:26 | iq | of course unmount first |
| 21:58:28 | funman | iq: no need to power cycle, update will begin immediately |
| 21:58:44 | | Quit TopyMobile__ (Quit: TopyMobile__) |
| 21:58:48 | iq | here goes my $40 |
| 21:58:49 | ThomasAH | iq: umount, unplug, wait :) |
| 21:59:05 | iq | Firmware upgrade in progress |
| 21:59:07 | | Join TopyMobile [0] (~topy@f048243022.adsl.alicedsl.de) |
| 21:59:14 | iq | Update completed |
| 21:59:22 | iq | Black screen :) |
| 21:59:31 | ThomasAH | iq: turn it on |
| 21:59:45 | iq | it says RockBox and dmg -> |
| 21:59:59 | iq | dma -> |
| 22:00 |
| 22:00:05 | ThomasAH | iq: dma ... though I saw the same :) |
| 22:00:16 | iq | so now what LOL |
| 22:00:47 | iq | seems like it worked okay, right ? |
| 22:00:58 | ThomasAH | iq: ok, to boot into OF again, turn off by holding the power button for >10sec, then turn on with Home button pressed |
| 22:01:06 | ThomasAH | iq: yes |
| 22:01:08 | iq | ok |
| 22:01:11 | funman | home or left button, any of the 2 should work |
| 22:01:21 | ThomasAH | so 2 to 4 now :) |
| 22:01:27 | funman | to 5 ! |
| 22:01:33 | ThomasAH | funman: 5? |
| 22:01:41 | iq | Now I am back to the sansa firmware :) |
| 22:01:54 | funman | you, iq, FlynDice, me, and someone else who was present on irc |
| 22:02:02 | saratoga | comments look great, theres all sorts of stuff about power use, recommended clock dividers, etc |
| 22:02:15 | Schmogel | <- was number 4 |
| 22:02:22 | iq | funman, ThomasAH, thanks - it was fun ... what next :) |
| 22:02:28 | ThomasAH | funman: ah, how could I forget someone else :) |
| 22:02:37 | funman | iq: copy the original clppa.bin to remove the bootloader |
| 22:03:10 | iq | funman, Is it optional ? |
| 22:03:11 | ThomasAH | iq: first show it around to impress people :) |
| 22:03:23 | iq | ThomasAH, yeah :) |
| 22:04:50 | | Quit cjcopi (Ping timeout: 268 seconds) |
| 22:08:00 | | Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
| 22:08:08 | iq | Now I need to write a Hello World |
| 22:09:39 | | Join Lear [0] (chatzilla@rockbox/developer/lear) |
| 22:10:17 | ThomasAH | iq: adjust http://pastie.org/829514.txt :) |
| 22:11:05 | Lear | Just enabled dircache on my e200 after having it disabled for a while. Now I get stack overflow on boot... Anyone else seen that? |
| 22:11:14 | Lear | Using gcc 4.4.3 btw. |
| 22:11:33 | TheSeven | pamaury? |
| 22:12:01 | TheSeven | Lear: what is the maximum directory depth you have? |
| 22:12:23 | | Join cjcopi [0] (~craig@charon.craig.copi.org) |
| 22:12:57 | | Quit TheSphinX^ (Quit: XChat@Linux) |
| 22:13:09 | Lear | Well, I do have a test folder for a total depth of 12. :) Otherwise not much. |
| 22:13:53 | TheSeven | up to ~20 should be supported with that stack size |
| 22:14:01 | iq | ThomasAH, just apply this patch ? |
| 22:14:29 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100202165920]) |
| 22:14:43 | CIA-8 | New commit by stripwax (r24819): Get a few more % speedup on ARM (measured on ipod video) - improve imdct full final symmetries using ldm/stm and simple register swapping. Also, add ... |
| 22:14:47 | ThomasAH | iq: no, look at it to see where printf("Hello World!"); would fit :) |
| 22:15:06 | iq | ThomasAH, oh okay :) |
| 22:16:16 | AlexP | JdGordon: If you have 2 minutes could you do a quick sync of the fms patch? |
| 22:17:55 | CIA-8 | New commit by stripwax (r24820): Eep, didn't mean to commit those other files |
| 22:18:07 | CIA-8 | New commit by Buschel (r24821): Further work on cook codec. Rounding is not needed when using a large fract part in the internal sample representation. Move quantization array to ... |
| 22:18:44 | saratoga | "The ratio between bus clock and mpmc clock can either be 1:1 or 1:2. However + * this value cannot be changed dynamically because this would cause MPMC failure." |
| 22:19:02 | saratoga | well that would explain why we can't seem to switch memory clock dividers |
| 22:19:20 | | Quit tomers (Ping timeout: 252 seconds) |
| 22:20:13 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 22:20:25 | saratoga | so i guess if we want to clock the DRAM higher then 64MHz on AMS we need to do it early on before we've actually loaded anything important into DRAM |
| 22:20:33 | saratoga | is the bootloader in DRAM or IRAM? |
| 22:21:47 | stripwax | Is anything still using use tremor mdct_backward() ? |
| 22:22:19 | funman | saratoga: dram for clipv2 (and fuzev2 i guess), iram for others |
| 22:22:31 | saratoga | stripwax: no it can go |
| 22:22:46 | saratoga | funman: ok then it should be possible to increase the clock |
| 22:22:53 | | Quit knine (Ping timeout: 252 seconds) |
| 22:23:14 | funman | saratoga: before memory_init() would be the right place |
| 22:23:37 | funman | sdram_init()*, memory_init() isn't in the bootloader |
| 22:24:55 | S_a_i_n_t | Anyone feel like doing a quick check of a WPS to see if they get the same issues with sublines that I'm getting? |
| 22:25:09 | S_a_i_n_t | http://www.datafilehost.com/download-08770d85.html |
| 22:26:27 | | Join stooo [0] (~sto@e181177203.adsl.alicedsl.de) |
| 22:26:34 | S_a_i_n_t | ...apply hold, let it play for 1 min or so, take hold off. Sublines *should* go crazy. |
| 22:26:43 | S_a_i_n_t | *unless I've gone insane. |
| 22:30:36 | | Quit petur (Quit: router reboot) |
| 22:30:45 | Lear | TheSeven: I upped the stack to DEFAULT_STACK_SIZE + 0x400, debug menu says 80% usage after boot. |
| 22:32:17 | | Join petur [0] (~peter@d54C6F9B2.access.telenet.be) |
| 22:32:17 | | Quit petur (Changing host) |
| 22:32:17 | | Join petur [0] (~peter@rockbox/developer/petur) |
| 22:35:30 | TheSeven | S_a_i_n_t: heh, that's indeed waird |
| 22:35:31 | moos | wow the build table is full of colors! :) |
| 22:35:32 | * | stripwax is going to fix red just as soon as he figures out what happened with his last commit |
| 22:35:33 | TheSeven | weird* |
| 22:36:35 | Buschel | stripwax: shall I commit the fix? |
| 22:36:52 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 22:37:50 | TheSeven | kugel: did you notice the yellow btw? |
| 22:38:40 | | Quit Omlet (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 22:38:50 | S_a_i_n_t | TheSeven: thanks so much! I can add it to the tracker now :p |
| 22:39:01 | | Join sudoman [0] (~sudoman@static-151-204-226-99.bos.east.verizon.net) |
| 22:39:21 | S_a_i_n_t | I'm surprised noone's noticed it prior to now... |
| 22:39:24 | TheSeven | i don't quite get what's happening, but something is weird, yes |
| 22:39:40 | CIA-8 | New commit by Buschel (r24822): Make mdct compilable again for non-ARM targets. |
| 22:39:46 | | Quit stooo (Ping timeout: 265 seconds) |
| 22:39:49 | TheSeven | scrolling text going mad isn't really something new, saw that in some other places, too |
| 22:40:08 | stripwax | Buschel - does that fix the ARM targets? sorry, mine is still (re)building |
| 22:40:12 | kugel | TheSeven: no, thanks. will have a look |
| 22:40:30 | S_a_i_n_t | despite the viewport not being 'displayed'...it's still 'running in the background'? that's my guess... |
| 22:40:40 | S_a_i_n_t | allbeit wrong ;p |
| 22:41:00 | Buschel | stripwax_: it fixes the build for non-ARM (including PC-Sim) |
| 22:41:20 | Buschel | stripwax: you have deleted a brace too much |
| 22:41:47 | | Join CaptainKewl [0] (~jason@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) |
| 22:41:51 | stripwax | S_a_i_n_t - perhaps it just records a timestamp for when it last updated. so when the viewport is enabled, it has an old timestamp, and it (rapidly) catches up but along the way updating the text? |
| 22:41:52 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 22:42:09 | S_a_i_n_t | TheSeven: it only happens if the VP is conditional...otherwise, its fine. |
| 22:42:16 | Buschel | stripwax_: btw, CLIP_TO_15 is not used by any codec anymre |
| 22:42:22 | Buschel | *anymore |
| 22:43:17 | S_a_i_n_t | stripwax: that seems to fit, have you seen it happen? it alternates at pprox 0.1sec intervals. |
| 22:44:19 | stripwax | Buschel - ah, I'd forgotten that clean builds don't show up in the compact build table (was freaking out and thought everything had broken!). Thanks for the fix, yep, you're right. Feel free to remove CLIP_TO_15 too (arm and cf, I guess) |
| 22:44:46 | stripwax | S_a_i_n_t - I haven't, but I think something similar was discussed a while back, possibly in Bugs tracker? |
| 22:45:43 | TheSeven | S_a_i_n_t: it switches after scrolling *twice* for me |
| 22:46:05 | S_a_i_n_t | i'd looked, but couldn't find it if it is there...i had a forum thread on the topic going for a while, but it died. |
| 22:46:53 | S_a_i_n_t | TheSeven: it's at 10 second intervals...2mins on hold=12 switches. |
| 22:47:09 | S_a_i_n_t | 1min=6 |
| 22:47:13 | S_a_i_n_t | etc. |
| 22:47:32 | S_a_i_n_t | well, for me anyway. |
| 22:48:49 | CIA-8 | New commit by gevaerts (r24823): Disable rombox on ondio SP. It can be reenabled if the binsize goes down again. |
| 22:49:14 | S_a_i_n_t | thats a big *if* |
| 22:51:20 | CIA-8 | New commit by gevaerts (r24824): remove incorrect cast |
| 22:52:07 | | Quit tmzt (Ping timeout: 246 seconds) |
| 22:52:13 | | Quit linuxguy3 (Read error: Operation timed out) |
| 22:52:35 | | Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
| 22:52:59 | * | amiconn slaps kugel with his 13 yellow points |
| 22:53:13 | kugel | amiconn: I was notified already |
| 22:53:23 | gevaerts | I just committed the un-yellower |
| 22:53:30 | | Join tmzt [0] (~tmzt@adsl-99-164-34-42.dsl.akrnoh.sbcglobal.net) |
| 22:53:44 | pamaury | TheSeven: yes ? |
| 22:53:59 | TheSeven | something's still wrong with the dircache |
| 22:54:09 | TheSeven | 12 levels => stkov |
| 22:54:20 | pamaury | hum, stkov ? |
| 22:54:25 | | Join linuxguy3 [0] (~timj@adsl-75-57-163-40.dsl.emhril.sbcglobal.net) |
| 22:54:34 | kugel | gevaerts: heh, I think it's incorrect |
| 22:54:34 | TheSeven | see the lines above my ping |
| 22:54:43 | kugel | because I had warnings on my machine without this cast |
| 22:55:00 | | Quit iq (Remote host closed the connection) |
| 22:55:17 | gevaerts | kugel: hm, wait |
| 22:55:53 | kugel | statusbar_position is an int, not an enum. we changed that in global_settings due to since the enum caused failure with eabi builds |
| 22:56:15 | pamaury | It's a shame that Lear just quit the chan |
| 22:56:22 | gevaerts | it's still an enum if HAVE_REMOTE_LCD |
| 22:56:51 | pamaury | TheSeven: aparently, mc2739 also reported a problem with a stkov in dircache at boot time, I will investigate this |
| 22:57:35 | Unhelpful | TheSeven: funny, hasn't pamaury been optimizing dircache stack/memory usage? |
| 22:57:41 | kugel | gevaerts: oh, that's the bug I think |
| 22:57:48 | gevaerts | I'm on it |
| 22:58:01 | *** | Saving seen data "./dancer.seen" |
| 22:58:23 | kugel | I mean, it should probably be an enum. maybe the setting should be casted in statusbar_position() |
| 22:58:38 | | Quit flyback (Quit: Leaving) |
| 22:58:42 | mc2739 | pamaury: Hi, you had questions about FS #11043? |
| 22:58:50 | gevaerts | well, it should be the same everywhere |
| 22:59:04 | amiconn | gevaerts just negated the yellows... |
| 22:59:19 | gevaerts | on average it's now correct :) |
| 23:00 |
| 23:00:06 | S_a_i_n_t | TheSeven: i have charge monitoring on nano2g now...was that you? i swear it didn't work for me before...or, i 'un-broke' something. |
| 23:00:26 | TheSeven | charge monitoring in terms of what? |
| 23:00:47 | TheSeven | i only calibrated the battery gauge a bit |
| 23:00:54 | S_a_i_n_t | wps %cp etc. tags. |
| 23:01:06 | CIA-8 | New commit by funman (r24825): as3525v2: full list of registers + description |
| 23:01:10 | CIA-8 | New commit by funman (r24826): sd-as3525v2: detail MCI_CTRL bits |
| 23:01:16 | CIA-8 | New commit by funman (r24827): sd-as3525v2: describe CTYPE bit |
| 23:01:19 | CIA-8 | New commit by funman (r24828): sd-as3525v2: name interrupt bits (no description yet) |
| 23:01:24 | CIA-8 | New commit by funman (r24829): sd-as3525v2: command register bits |
| 23:01:31 | CIA-8 | New commit by funman (r24830): sd-as3525v2: MCI_FIFOTH bits |
| 23:01:33 | TheSeven | S_a_i_n_t: don't think i changed something regarding those |
| 23:01:35 | CIA-8 | New commit by funman (r24831): sd-as3525v2: MCI_HCON bits |
| 23:01:39 | CIA-8 | New commit by funman (r24832): sd-as3525v2: no limits on the amount of sectors to transfer |
| 23:01:56 | funman | (no functional changes) |
| 23:01:56 | TheSeven | erm, funman, want to hit 24500? :-P |
| 23:02:14 | funman | nah, 123456 ;) |
| 23:02:53 | | Quit stripwax (Quit: http://miranda-im.org) |
| 23:04:27 | S_a_i_n_t | hmmmm, i swear someone did *something*, as %bp & %bc work on my 2g suddenly. weird, but awesome ;D |
| 23:05:34 | CIA-8 | New commit by gevaerts (r24833): statusbar_position should also return enum statusbar_values if it's a macro |
| 23:05:50 | CIA-8 | New commit by Buschel (r24834): Remove CLIP_TO_15 from codeclib. Remove tabs. |
| 23:06:22 | | Join flyback [0] (~teac@c-98-219-129-239.hsd1.pa.comcast.net) |
| 23:10:57 | | Join iq [0] (~iq@unaffiliated/iq) |
| 23:11:19 | | Quit petur (Remote host closed the connection) |
| 23:13:06 | | Quit bluebrother (Ping timeout: 246 seconds) |
| 23:14:57 | | Join bluebrother [0] (~dom@f053152212.adsl.alicedsl.de) |
| 23:14:57 | | Quit bluebrother (Changing host) |
| 23:14:57 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 23:19:54 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
| 23:22:59 | saratoga | FlynDice: looking at the datasheet it seem to me I can adjust the DRAM clock either by: |
| 23:23:04 | saratoga | 1) moving PCLK to a different sources and then setting pclk div1 to reduce it back to 64MHZ for everything else (but leave it higher for mem_clck) |
| 23:23:49 | funman | isn't mem_clk limited to 90MHz ? |
| 23:23:50 | saratoga | 2) using the built in Clock ratio, CLK register to set the ARM memory controller to double the clock it gets |
| 23:23:55 | saratoga | yeah it is |
| 23:24:17 | saratoga | FlynDice: i think you mentioned trying one of these, which was it? |
| 23:24:27 | pamaury | mc2739: yes |
| 23:24:50 | pamaury | mc2739: what is the maximum directory depth of your file sysytem tree ? |
| 23:25:14 | mc2739 | pamaury: no more than 6 deep |
| 23:25:53 | pamaury | hum, the stkov is in dircache thread ? Are your sure of that ? Because a stkov in dircache at boot time is rather strange |
| 23:25:57 | saratoga | hmm though the patches i have make it sound like only #1 is used |
| 23:27:15 | mc2739 | pamaury: yes, when it does boot, the dircache stack is at 97% or 99%. The stkov will happen right after disconnect and then again on reboot. |
| 23:27:34 | pamaury | on which device ? |
| 23:28:28 | mc2739 | pamaury: e280v1 |
| 23:29:13 | pamaury | That's incredible, I also have a e280 and have a directory depth of 20. And I can't see anything in my code which would depend on anything else :( |
| 23:29:16 | | Join Strife89|PalmTX [0] (~upirc@adsl-154-22-249.mcn.bellsouth.net) |
| 23:30:11 | funman | are there recursive functions ? |
| 23:30:37 | | Quit Strife89|PalmTX (Client Quit) |
| 23:30:40 | | Join JdGordon_ [0] (~jd@m540e36d0.tmodns.net) |
| 23:31:03 | pamaury | There is one recursive function (sab_process_dir). The number of recursive calls is the directory depth |
| 23:32:25 | | Join Strife89|PalmTX [0] (~upirc@adsl-154-22-249.mcn.bellsouth.net) |
| 23:34:11 | S_a_i_n_t | Hmmmm, bugger....Plugin/pictureflow gives "*PANIC* Stkov main" on Nano2g |
| 23:34:13 | S_a_i_n_t | :( |
| 23:34:16 | | Quit Strife89|PalmTX (Client Quit) |
| 23:34:25 | saratoga | right now we run the PCLK off a 248MHz PLL with a 1/4 multiplier, we could instead run the DRAM off it with a 1/3 multiplier (83MHz) and the PCLK off that with a 1/2 multiplier (41MHz) |
| 23:34:40 | saratoga | unfortunately that slows down all the peripherals, and i'm not sure if their drivers will be ok with it |
| 23:34:55 | saratoga | to keep the pclk the same i think we'd need to change the PLL |
| 23:35:09 | kugel | gevaerts: thanks for looking into it |
| 23:35:17 | S_a_i_n_t | r24803 that is... |
| 23:35:40 | bertrik | saratoga, it has two PLLs so that provides some extra freedom of choice |
| 23:36:10 | saratoga | bertrik: i think the pclk and memory clock must use the same PLL |
| 23:36:26 | saratoga | they're both muxed by PCLK_SELECT |
| 23:36:27 | | Quit sudoman (Quit: sudoman) |
| 23:36:44 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
| 23:37:08 | saratoga | for now i'm just curious if the system would even boot at a lower pclk, ignoring performance |
| 23:38:57 | * | pamaury just noticed something really strange in his code |
| 23:39:05 | bertrik | saratoga, which clock is the memory clock, mpmc_clk? |
| 23:39:23 | saratoga | bertrik: correct |
| 23:39:34 | saratoga | MultiPortMemoryController iirc |
| 23:40:36 | | Join Strife89|PalmTX [0] (~upirc@adsl-154-22-249.mcn.bellsouth.net) |
| 23:41:16 | saratoga | i actually dont' understand how you're expected to get a 64MHz PCLK and a 90MHz MEM_CLK when all they give you is a 1/1, 1/2, 1/3 ... divider |
| 23:42:03 | pamaury | TheSeven, mc2739: I could have an explaination ! I happily dereferencing a NULL pointer :/ |
| 23:42:24 | TheSeven | that shouldn't cause a stkov though, should it? |
| 23:42:56 | kugel | Unhelpful: is it safe to load a bitmap twice using the same bitmap struct? |
| 23:42:58 | kugel | save |
| 23:43:04 | kugel | whatever :p |
| 23:43:23 | pamaury | TheSeven: on my device, it runs like a charm ! so I perhaps the result is more or less undefined |
| 23:43:43 | kugel | this second pass is still buggy |
| 23:43:46 | TheSeven | kugel: safe was right |
| 23:43:56 | kugel | yea, I figured :) |
| 23:45:14 | funman | they didn't implement DMA in as353x SD/MMC driver |
| 23:45:28 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 23:45:51 | | Quit Farthen (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
| 23:46:19 | | Quit FOAD (Ping timeout: 246 seconds) |
| 23:47:44 | | Join FOAD [0] (~dok@dinah.blub.net) |
| 23:48:51 | | Quit S_a_i_n_t (Quit: PC Restart...BBS) |
| 23:48:56 | CIA-8 | New commit by pamaury (r24835): Fix a dircache NULL-pointer dereference. |
| 23:49:24 | pamaury | TheSeven, mc2739: could you try with this new version ? Perhaps it helps things |
| 23:49:57 | CIA-8 | New commit by funman (r24836): sd-as3525v2: describe interrupt mask bits ... |
| 23:50:01 | CIA-8 | New commit by funman (r24837): sd-as3525v2: panic in case of error in the isr ... |
| 23:50:02 | TheSeven | pamaury: i didn't get any stkovs... |
| 23:50:20 | pamaury | true, I mixed up things :) |
| 23:52:32 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.199) |
| 23:52:40 | kugel | funman: sd transfers don't work yet, do they? |
| 23:52:44 | funman | nope |
| 23:56:41 | | Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 23:58:27 | funman | there are no errors or data transfer over interrupts, but there are interrupts anyway |
| 23:58:35 | funman | i must check the status of each interrupt |
icon identifies that the person is a core developer (has commit access).