--- Log for 21.02.110 Server: wolfe.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 9 days and 9 hours ago 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 # 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 # 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 # 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 # i don't know about arm9 00.28.41 # i can't remember how well seperated teh cache and load/store hardware are 00.28.56 # saratoga: i thought arm7tdmi was pretty much strictly in-order? 00.28.58 # i guess it probably does keep fetching the rest of the cache line after a load though 00.29.24 # 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 # i don't think it locks the load/store hardware while doing the mul 00.30.00 # also load on arm7 has 3c throughput :/ 00.30.09 # isn't it 2c? 00.30.26 # don't think so, no. 00.30.31 # one clock to load the instruction, then one clock to load the register? 00.30.38 # i thought it only stalled because of the 32 bit wide bus 00.30.45 # and a load only takes 64 bits 00.30.55 # so i would expect it to sustain a load every other cycle 00.30.58 # best case 00.31.36 # ASDG gives load as being 3c to execute 00.32.02 # latency or throughput? 00.32.10 # arm7tdmi doesn't have nearly as many nice 1c pipelined instructions, aside from basic ALU stuff. 00.32.11 # i thought on the last cycle you could start issuing the next load 00.32.31 # the ASDG tables are all throughput, latency if any goes in a notes column. 00.32.38 # if not thats really stupid, since the LDM takes 1 +N cycles IIRC 00.33.10 # 2+N - so LDM 1 reg == LDR 00.33.43 # ah 00.33.55 # whats the link for this I should review it 00.34.02 # i obviously can't remember what i've read 00.35.01 # 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 # 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 # hmm my player turned off mid test_codec 00.36.27 # 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 # 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 # yeah maybe I should have removed APE 00.41.43 Quit bmbl (Quit: Bye!) 00.41.46 # 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 # its not doing that on e200v1 00.42.48 # i can run it with no battery at all off of USB power 00.43.03 # and it only draws 120mA with the screen on and the CPU boosted 00.44.00 # 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 # 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 # stripwax: its not 00.45.33 # we have a patch somewhere to remove it but it made the codec prefetch abort 00.45.37 # we had no idea why 00.45.51 # but yes it should be removed 00.46.07 # hah. ok. also the implementation of clip 00.46.11 # is this a range limit on output or are some internal values being clipped and then used for further calculation? 00.46.24 # _to_15 in dsp is only two instructions; in codeclib it's 5. 00.47.51 # Unhelpful - output. 00.49.04 # 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 # 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 # oh. um. hang on. maybe it is three :-p 00.51.12 # anyway, point is, it's less than five :-) 00.51.49 # 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 # ah. yep. by '3c' you mean 3 cycles? sorry, just didn't understand what you were saying that's all. yep 00.54.04 # stripwax: sorry, yes. 3 cycles. it looks like the inline in codeclib could be made at least 1 cycle shorter. 00.54.40 # right. it's only used in one tight loop, i'm sure you can keep the mask in a register 00.55.03 # i.e. output_math in cook_fixpoint.h 00.55.19 # but eliminating it altogether is a better approach in any case 00.57.31 *** Saving seen data "./dancer.seen" 00.57.55 # 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 # saratoga - i couldn't see any patch in tracker, somewhere else? 00.59.26 # Unhelpful - yeah we just want to eliminate it. afaict only cook uses it, and that shouldn't. 00.59.26 # 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.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 # stripwax: probably passed on IRC or gtalk 01.08.09 # mt and i both had commit so we didn't use the tracker 01.08.29 # 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 # TheSeven: http://pastebin.com/m108d0c98 01.10.19 # probably going to commit this 01.10.23 # very helpful for test codec 01.10.27 # or maybe just put it in the wiki 01.14.36 # heh wiki adds a .txt to my perl script 01.20.18 Join iq [0] (~chatzilla@unaffiliated/iq) 01.20.20 # Hi 01.20.27 # TheSeven: would you mind posting the raw test_codec logs so I can update the wiki? 01.21.07 # bah this is making me want to fix aac-he so that test_codec is quicker . . . 01.21.08 # r24711 noeabi: http://pastie.org/834326 01.21.20 # r24786 noeabi: http://pastie.org/834332 01.21.48 # r24786 eabi: http://pastie.org/834822 01.27.53 # TheSeven: added 01.28.31 # opps bug in my parser 01.30.16 Quit avacore (Ping timeout: 252 seconds) 01.30.18 # My clip+ booloader build is failing, any known issues ? 01.30.38 Quit hebz0rl (Quit: Ex-Chat) 01.32.33 # 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 # http://www.pastebin.com/m4cb5479 01.37.56 # delete the build directory and try again 01.38.09 # ok 01.38.49 # i am baffled by this perl problem with TheSeven's log 01.39.40 # print "$key"; does nothing but print "$key\n" works fine 01.40.37 # http://www.pastebin.com/m69495a56 01.40.46 # what if you just remove the quotes? 01.41.44 # why should [u]modsi3 use floating point? 01.42.51 # 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 # iq: was that compiler built by rockboxdev.sh? 01.44.46 # gevaerts: I downloaded the VMWare image. So whatever was in there. 01.44.49 # heh perl's chomp can't handle windows line endings 01.44.50 # awesome 01.45.16 # iq: try running rockboxdev.sh to rebuild the compilers 01.45.30 # theres directions on the wiki 01.45.35 # saratoga: ok 01.45.37 # yes, it does look like a dodgy compiler install 01.45.48 # its possible the vmware tool chain can't build for the clip+ for whatever reason 01.46.39 # I was able to build the rockbox without errors. 01.46.50 # but not for the clip+ 01.46.56 # And I was able to build Clip bootloader as well. It is just problem with Clip+ bootloader. 01.47.07 # 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 # iq: i don't even think its possible to build for the clip+ 01.49.19 # saratoga: okay, I will take your word for that, I just got involved with it today :) 01.50.01 # 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 # WMA on the 2G is a full 20% faster with the new mdct lib 01.56.00 # thats amazing 01.58.21 # strangely most other codecs got a much smaller improvement 01.58.25 # i wonder why WMA is so special 01.58.49 # wasn't wma extraordinarily slow before? (compared to other targets) 01.59.07 # how is the vorbis : mp3 : wma ratio for nano2g, and for other players? 02.00.09 # 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 # 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 # that's funny. I ran out of disk space on my Virtual Machine :) 02.08.21 # 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 # I will try checking out code in my Fedora and run rockboxdev.sh. Thanks for your help. bye for now 02.08.50 # TheSeven: theres 6 codecs all using the same MDCT 02.09.04 # i don't see why WMA should have been different then vorbis for instance 02.09.14 # saratoga: looks like wma uses more of them / more often :-) 02.09.43 # 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 # 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 # 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 # they started taking almost identical decode times 02.12.43 # but WMA apparently got 11MHz faster, while vorbis only about 5 02.13.13 # 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 # time to compare PP and see if thats teh same . . . 02.14.49 # what the fuck I didn't get a test_codec log 02.14.57 # and it ran through to completion 02.15.16 # * TheSeven also had that sometimes 02.15.29 # seems to happen if you insert usb while test_codec is still running 02.18.50 # does fdprintf not write to the file immediately? 02.20.16 # saratoga: well surely complexity is >linear wrt block size? 02.20.46 # saratoga: iirc it had something to do with writing the directory entry for it 02.20.46 # yes, n*logn 02.20.55 # the log itself is probably somewhere on the storage 02.21.08 # but i wouldn't expect two codecs at the same bitrate to use tremendously different block sizes 02.21.34 # 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 # they might, i'm sure their long/short block selection is entirely different 02.24.08 # 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 # TheSeven: any idea how to make test_codec more robust against lost data? 02.25.31 # the plugin didn't even crash so I'm surprised this happened 02.25.35 # it seemed to complete normally 02.25.47 # it's probably still running in the background or something 02.25.54 # or it just didn't close the log file handle 02.26.46 # 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 # 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 # Unhelpful: my recovered logs indicate that on PP WMA and Vorbis get identical speed ups 02.28.48 # 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 # 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 # 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 # 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 # 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 # 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 # the next factor of 1.75 took me 2.5 years . . . 02.48.35 # i just noticed theres an open source DTS codec, so in theory we could add libdca as a codec 02.48.43 # though i guess no one wants to use DTS in rockbox 02.50.07 # saratoga: on beast. in mpegplayer. ;) 02.50.42 # yeah 02.50.51 # ac3 would make a lot of sense for mpegplayer 02.51.00 # since its a valid mpeg audio codec and its way faster then mp3 02.51.14 # and also for doing dvds on the beast :) 02.51.21 # mpegplayer on beast might conceivably play VOBs straight from DVD if it had AC3 and DTS audio support 02.51.27 # yes, that is what i was thinking mostly. 02.51.43 # 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 # would closing the log and reopening it between files make it less likely to be corrupted in test_codec? 02.53.03 # 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 # i don't really understand why a file gets lost in the first place 02.53.26 # 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 # Unhelpful: think this will help? http://pastebin.com/m43149808 03.00.51 # 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 # 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 # could be a codec error or something 03.01.54 Join Strife89 [0] (~Strife89@adsl-220-102-6.mcn.bellsouth.net) 03.02.54 # I just noticed that in my new bleeding edge build, my ipod 5G line out now uses volume control and EQ 03.03.02 # whats with that? 03.03.29 # that sounds like a bug 03.03.36 # when was the last build that didn't do it? 03.04.20 # I only have bleeding edge because I like to make a small edit on the source code 03.04.25 # actually I bet I know 03.04.28 # "Allow volume control down to -90 dB for WM8758 (e.g. iPod Video). (FS#10082)" 03.04.28 # I don't really keep up to date with it 03.04.36 # sounds likely to be the commit in question 03.04.56 # saratoga: this one shouldn't have anything to do with the eq, but it would have been my first quess, too 03.05.13 # but this was before 3.5 03.05.27 # "When lowering the volume below -57dB the lineout is also affected." 03.05.43 # notByan: does this also happen with the 3.5 release? 03.05.46 # well that seems easy enough to work around, don't lower the volume below -57dB 03.05.58 # saratoga: but.. the EQ? 03.06.16 Join Tomis [0] (~Tomis@70.134.99.142) 03.06.33 # line out always used EQ 03.06.38 # if thats what you're asking 03.07.15 # 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 # saratoga: you sure... 03.07.22 # cause I could've sworn.. 03.07.44 # EQ is done in software like a mile upstream of the DAC 03.08.00 # weird 03.08.05 # changes the output line on the DAC has no impact on how DSP software in rockbox works 03.08.06 # I must be crazy then 03.08.24 # 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 # a device couldn't support (software) EQ on one output and not another unless there were two DACs 03.08.32 # saratoga: aren't we also using hardware eqs on some targets at least? 03.08.47 # maybe, but i think thats not even available from the EQ screen 03.09.27 # I am very tempted to put my old build on here and see what happens 03.09.27 # 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 # 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 # btw, I guess I was talking about the treble and bass settings in sound settings 03.11.07 # not the EQ 03.11.16 # I didn't even realize there was a seperate EQ menu 03.11.19 # yeah those are hardware 03.11.31 # should they be effected the line out? 03.11.32 # cause they are 03.11.41 # 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 # well, he didn't change his dac, obviously... 03.14.13 Quit GeekShadow (Read error: Connection reset by peer) 03.14.17 # notByan: if possible, you should try the 3.5 build. this would help narrowing down where that issue is coming from. 03.14.33 # yeah, sure 03.14.45 # TheSeven: i mean that whether it "should" effect line out would depend on the DAC and possibly its configuration. 03.15.25 # so, help me understand something, where in hardware is the treble and bass stuff being EQ'ed? 03.16.25 # I am gonna try my old build real quick and see if it happens there 03.16.48 # try pre 3.5 03.16.52 # that has the DAC changes in it already 03.17.09 # old build is pre 3.5 03.17.51 # apps\plugins\fft needs to go away 03.18.08 # can you just do ../codecs/lib from inside a plugin or will that not work? 03.18.48 # I don't think I even updated the apps/plugins/fft last time 03.18.50 # hrm >_> 03.19.09 # notByan: I wasn't referring to you 03.19.14 # oh 03.19.52 # hrm, I guess I was crazy 03.20.06 # but.. this release sounds much better.. 03.20.35 # I thought it was in my head 03.20.37 # but it definately does 03.20.55 # 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 # teru: pong 03.52.36 # JdGordon: it seems like that file descriptor for font file doesn't seems to be closed when reloading skin file. 03.53.17 # nuts, and I see why 03.53.52 # New commit by 03jdgordon (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.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.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 # 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 # qcjn: you can give Rockbox a 'trial run' by downloading the simulator 05.31.29 # oh, yeah, thats great 05.31.44 # i m on ubuntu 05.31.53 # does it work on ubuntu 05.32.15 # Ah...not sure about that actually... 05.32.33 # anyway, i still have xp, but it s so slow 05.32.36 # 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 # If you have XP too...than I don;t see a problem :D 05.33.24 # it s just that i don't use it anymore, it s to slow 05.34.08 # anyway, rockbox has a files menu that lets you browse folders and manage music that way 05.34.21 # qcjn: http://www.rockbox.org/wiki/WhyRockbox if it helps 05.34.33 # and no, you won't lose recording or FM radio IIRC 05.34.48 # ok, great 05.35.14 # you can even records the radio ;) 05.35.36 # great 05.35.45 # where is the simulator 05.36.55 # http://rasher.dk/rockbox/simulator/ here it is 05.37.05 # not up to date, but enough to see 05.37.10 # qcjn: in extras on the front page 05.37.17 # it's at 3.5 IIRC 05.37.30 # ok 05.37.35 # qcjn: if you have wine, you should able to run it that way 05.37.45 # oh, yeah 05.38.23 # it uses sdl, which works natively on linux, so it should work flawlessly in wine 05.39.15 # 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 # sdl is a cross platform graphics library 05.41.53 # 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 # it s dualboot ! incredible, wow 05.42.54 # there s some sort of grub at start up ? 05.43.07 # 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 # wow, men it s great, 05.43.55 # http://download.rockbox.org/daily/manual/rockbox-sansae200v2/rockbox-build.html 05.44.09 # 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 # well i ve installed it, about 2 years ago on my daughter in law's sansa, and she liked it 05.46.44 # 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 # S_a_i_n_t: ...since years and years now 05.48.47 # 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 # IMO 05.50.04 # well since it s dual boot... i think you just found a new user :) 05.50.09 # S_a_i_n_t: so now it is a fashionable AND functional player ;-) 05.50.18 # S_a_i_n_t: next step, you will buy your futur DAPs because rockbox suport.... :) 05.50.49 # next step?...Ha! that's the *current* step! 05.51.08 # you already had your ipod, no? 05.51.21 # a few of them.. 05.51.28 # but I bought *more* :P 05.52.08 # you will no more buy an DAP if not Rcbx, or at least hope to ;) 05.52.36 # 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.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 # waht is DAP ? 06.27.55 # digital audio player ? 06.33.43 Quit CGL (Quit: Ya está, ahora solo a configurar XD) 06.35.55 # There is asking. Is there developper who can change my (username: Uchida) right of Flyspray ? 06.36.15 # I want you to change right of "close task" to "yes". (see FS#10424) 06.39.07 # qcjn: yes, DAP = Digital Audio Player 06.40.57 Quit ucchan (Quit: Leaving...) 06.42.23 # 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.02.50 Quit ucchan (Quit: Leaving...) 07.03.48 # is there someway in a plugin to get the SVN version number? 07.03.57 # 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 # 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.16 # 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 # saratoga: Close and reopen is definitely overkill. Calling fsync() is enough 08.28.05 # 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 # Unhelpful: dvd vob support wouldn't require any other audio codec than ac3, 'cause an ac3 track is mandatory afaik 08.42.49 # amiconn: why does that help? 08.42.57 # i don't really understand the problem 08.44.25 # 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 # 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 # 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 # Hmm, actually not only this PMU is affected 08.48.09 # I observe this effect on my Sansa c200v1, iPod Photo and Mini G2 08.48.18 # The H10 (small) is unaffected for some reason 08.49.16 # amiconn: i had test_codec quite normally and still got a 0 byte file 08.49.26 # so i assume theres some bug in test_codec itself 08.49.33 # It's reproducible by testing ape -c5000. That's why there are no values for PP5022 08.49.46 # yes I saw that as well, but i got it even with APE removed 08.50.01 # (cause neither c200 nor Mini G2 work - the PP5020 value is tested on H10) 08.50.41 # You don't need to remove all ape, just the -c5000 file 08.50.59 # when I dumped the disk to get the lost file, the entire test codec log was there 08.51.07 # so it finished everything, it just somehow never closed the file 08.51.08 # 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 # hmm that should be easy to fix 08.51.41 # test_codec doesn't have proper usb handling. It's a test plugin after all 08.51.47 # :) 08.52.33 # 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 # But then I don't use the log feature that often 08.53.43 # 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 # any chance there's some built-in protection to prevent running at full boost for long periods of time? 08.57.15 # or is it demonstrably test 08.57.17 # oops 08.57.24 # or is it demonstrable test_codec only 08.57.43 *** Saving seen data "./dancer.seen" 09.00.51 # 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.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 # 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 # *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 # I can provide a WPS that proves this quite effectively. 10.30.01 # didn't you tell about this earlier? And is there a tracker entry for this? 10.31.12 # 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 # 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 # I'm surprised noone else has noticed it though... 10.32.58 # s/not/now/ 10.34.37 # 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 # 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 # pixelma: don't think it was me...pretty sure it wasn't actually. 10.36.45 # 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 # 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 # 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 # I tried with default configuration, with only difference that this feature was enabled 10.54.44 # 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 # of course I set also pitch rate, right 10.57.46 *** Saving seen data "./dancer.seen" 10.58.03 # and as a effect I get pitch going up/down (fast playback with higher pitch) 11.00.46 # although I would assume fast playback with normal pitch, if I have understood this feature corretly. 11.02.36 # mc2739: are you there ? 11.09.14 # is there anyone that has been using time stretching? I would like to know if it works for someone. 11.10.06 # tuma: it works perfectly for me... 11.10.14 # tuma - have you check the relevant manual section? rather than assume how it works. 11.10.38 # I actually once read that, but maybe I should double-check 11.12.26 # 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 # should be straight-forward 11.13.04 # and I believe I have tried to use it correctly. 11.13.28 # And did you reboot after enabling the Timestretch option? 11.13.56 # yes 11.14.16 Join mt [0] (~mtee@rockbox/developer/mt) 11.14.24 # tuma: which target? 11.14.34 # sansa e200 (e280) 11.14.38 # v1 11.16.35 # 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 # 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 # oh 11.19.32 # 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 # thanks! 11.21.38 # tuma - works? 11.24.11 # yes it does 11.24.19 # * stripwax \o/ 11.25.36 # pixelma: I cut it back as far as I can (and still reproduce the problem), HOLD toggles the viewports. 11.25.37 # http://www.datafilehost.com/download-b2ea5774.html 11.26.32 # 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 # 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 # stripwax: really, not very intuitive this feature... have to read the manual very carefully to use it 11.27.34 # :P 11.27.50 # tuma - feel free to submit a patch for the manual! :-p 11.28.05 # maybe I should=) 11.28.14 # 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 # maybe pitch screen could also hint about mode switching 11.28.54 # 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 # depends on the screen... 11.29.13 # Well my dvd recorder can (optionally) produce dvds with just lpcm at the highest quality setting (1 hour on single layer) 11.29.39 # and the font you uses 11.29.40 # For all other quality levels it always uses ac3 2.0 11.30.48 # 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 # stripwax: did you see my results from yesterday? 11.40.14 # 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 # tuma - which FS#s? 11.42.10 # TheSeven - your pdf? yeah, I saw that, really cool. Decent speed up from new MDCT on nano2g too, which is reassuring 11.42.47 # yes - the wma speedup is a bit suspicious though ;-) 11.43.06 # 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 # FS#10482 and FS#10483 11.43.22 # TheSeven - suspicious? not at all! 11.43.23 # that's what i suggested 11.43.33 # TheSeven - ah! heh 11.43.52 # [22:36] * TheSeven wonders 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 # 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 # the wma speedup suggests that you accidentally fixed something else at the same time :-) 11.45.18 # 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 # 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 # I certainly didn't explicitly fix anything in WMA :) 11.51.07 # actually this kind of behavior seems to be nano2g-specific 11.51.44 # 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 # [11:49] actually this kind of behavior seems to be nano2g-specific 11.52.23 # [11:50] 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 # 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 # yep, could be. 11.55.05 Nick stripwax_ is now known as stripwax (~Miranda@87-194-34-169.bethere.co.uk) 12.00.02 # bye for now! and thanks again, stripwax, S_a_i_n_t 12.00.03 Quit tuma (Quit: leaving) 12.02.55 # 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 # 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 # pixelma: both I think 12.24.29 # JdGordon: Could your latest commit fix an issue where the wrong font is used on the remote? 12.25.32 # I haven't tried yet, but as you may guess my testing on H140 has hit an issue :) 12.26.37 # 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 # pixelma: I just have one, but I could write a quick other to test 12.30.51 # I take it you are having issues with it? 12.33.33 # 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 # 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 # on both I can't stop the radio anymore 12.38.36 # 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.01.17 # New commit by 03teru (r24804): FS#11017: add Playlist Catalog and Properties item to database's context menu. 13.03.52 # 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 # Is there a way to create a diff with the differences between two diff files? 13.21.34 # apply them and diff the results 13.23.15 # theseven: thanks 13.23.36 # I hoped that there is a simpler way 13.24.42 Join Farthen [0] (~chatzilla@p50988dd0.dip0.t-ipconnect.de) 13.29.16 # New commit by 03b0hoon (r24805): Packard Bell Vibe 500: Enable recording. 13.34.19 # AlexP: and which targets did you test on? 13.34.20 # 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 # i would like to have different installations for a "production rockbox" and a testing one 13.36.11 # 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 # a quick grep shows that there seem to be quite a few places where ".rockbox" is hardcoded 13.36.33 # 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 # 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 # 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 # TheSeven - and then use ROLO to switch between them? 13.38.24 # i.e. without having to patch bootloader too 13.38.24 # no, that would be done at bootloader level 13.38.28 # oh 13.39.01 # i'm not using the rockbox bootloader, so this won't be an issue 13.39.17 # iloader can do that out of the box 13.40.09 # 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 # there *is* a define for that (in the makefile, even), but it doesn't seem to be used consistently :-/ 13.42.29 # oh, ugh. 13.42.48 # gah, i'm going to fix that configure bug now, this is really annoying 13.43.24 # aha, another rbdir=".rockbox" in .configure... :-/ 13.43.35 # seems to be only a default though 13.47.23 # New commit by 03theseven (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.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 # New commit by 03teru (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 # 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 # rigger message ? 14.38.57 # *-depending 14.48.13 # 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.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 # It is correct - and the extra latency even depends on the cpu clock 15.12.36 # pamaury: I don't see an obvious other way to do it 15.13.17 # 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 # 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 # amiconn - meaning ldm even more important on pp5020 than on pp5022? 15.14.54 # No 15.15.12 # 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 # Meaning that PP5020 needs very careful decisions what should go into iram and what shouldn't 15.15.52 # maybe stable and unstable should rather be in two columns on the front page, to make it less tall 15.16.01 # It means iram is *not* always equally fast or faster as dram, taking the cache into consideration 15.18.01 # 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 # 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 # 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 # 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 # stripwax: Is the todo on fasterMDCT up to date ? 15.26.44 # Oh and .. \o/ .. for merging :) 15.26.56 # mt - yep, I believe so, I updated it yesterday 15.27.05 # and \o/ thanks :_) 15.27.21 # great ! 15.28.09 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 15.30.02 # 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 # 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 # 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 # who can fix the sidebar in the forums? 15.41.06 # kugel: true but that is not logical currently 15.41.42 # :? 15.41.58 Quit stoffel (Ping timeout: 246 seconds) 15.42.56 # 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 # right 15.48.57 # I agree 15.54.55 # 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.51 # Torne: would it be useful to align skin allocations to 16bytes for dma? 16.01.15 # for images for example, but I can imagine it's not worth it 16.03.44 # JdGordon: this bidirectional skin buffer makes resizing on boot hard 16.04.03 Part fleebailey33 16.11.32 # gevaerts: is it normal that a pebble-build doesn't have a backdrop with default settings? 16.11.49 # hm 16.12.07 # it shoudln't really change anything there 16.12.11 Quit TheSphinX^ (Ping timeout: 252 seconds) 16.14.03 # skin buffer too small or something? 16.14.16 # i saw something in the patch that sets it to 16K 16.14.50 # 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 # oh, on the wps most things are also missing 16.15.36 # kugel: as in dma transfer from disk? 16.15.45 # Unhelpful: yes 16.16.09 # that's not the right buffer to resize for that. ;) 16.16.25 # erm, align, rather. 16.16.45 # hm, stkov usb when trying to do a screendump :-/ 16.17.15 # damn, ftl dead again 16.17.45 # Unhelpful: ? 16.18.02 # i really need to work on a more stable ftl recovery method... 16.18.24 # 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 # we clearly we need a pet name for the nano2g that involves stkov! 16.18.58 # Unhelpful: ah got it 16.20.07 # 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 # 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 # and then you'll have even more stkov :D 16.28.00 Join TheSphinX^ [0] (~cold@p5DD3B9A0.dip.t-dialin.net) 16.30.15 # somebody wants to write an ftl recovery tool? 16.31.32 # What does it consists in ? 16.33.32 # 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 # 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 # 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 # it an fsck-like task ;-) 16.36.37 # New commit by 03stripwax (r24808): Unroll and optimise channel coupling for arm gives 0.6Mhz speed for vorbis on pp(ipod video) 16.36.52 # oddly, unrolling it made it fractionally worse on coldfire 16.37.30 # 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 # gevaerts: how would i try your starfield pebble btw? 16.39.50 # 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 # if you just want to try pebbles, you can make a wps with only that line 16.41.15 # ok 16.41.31 # it won't be a very interesting wps then, but it should work :) 16.41.54 # did i miss the part where we had real work happening on visplugins? 16.42.13 # %P once was used for something else 16.43.48 # Unhelpful: depends on what you call "real work" :) 16.44.36 # "*PANIC* Stkov ¤¤" 16.44.52 # when trying to move a file 16.45.06 # i really like this... 16.45.18 # 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 # gevaerts: so the "pebbles" are TSR? or are they just stopped/started when their viewport is displayed? 16.45.42 # it seems the latter might be best since they could just be "regular" plugins then... 16.46.05 # ie, starfield would draw into a viewport when given a pointer to one on startup? 16.46.15 # TheSeven: how many stkov do you experience per day ? :) 16.46.20 # Unhelpful: I think they're somewhere in between 16.46.24 # usually none 16.46.41 # 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 # 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 # TheSeven: What did gevaerts do? 16.48.07 # this: + snprintf(filename,MAX_PATH,"/.rockbox/pebbles/%s.pebble",temp); 16.48.24 # TheSeven: I've had data aborts and illegal instructions using that patch, but never a stack overflow! 16.48.58 # 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 # 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 # 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 # 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 # Hmm, bad news about the PP5020 16.53.18 # Of its 96KB of IRAM, only the first 24KB (one quarter) is single cycle, the rest has one waitstate on access 16.53.41 # 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 # Looks like they moved the PP5002's cache bug to IRAM in PP5020 16.54.21 # 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 # TheSeven: why do you need a nonstandard rockbox base dir ? You boot nano2g on sd ? 16.55.59 # no, but i kinda have a "production build" and an "experimental (pebble) build" on it 16.56.49 # btw, the clock pebble works 16.56.56 # the starfield one locks up :-/ 16.56.58 # TheSeven: BOOTDIR is important, not ROCKBOX_DIR 16.57.53 *** Saving seen data "./dancer.seen" 16.59.19 # now I just need to make growing work, i.e. parse a skin and ask for reboot if it doesn't fit 17.01.46 # parse all skins actually, that's the hard part :( 17.03.56 Quit piotrekm (Quit: piotrekm) 17.04.07 # kugel: you could of course just resize-on-fail, and then have people reboot seven times before it works 17.04.18 # 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 # gevaerts: yea, being bloody annoying is cool :) 17.04.49 # Unhelpful: that might be doable. I'm not sure if it makes sense though 17.05.19 # I need two passes, one to get the size and one to actually parse it 17.05.24 # 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 # 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 # 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 # 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 # New commit by 03tomers (r24809): Brickmania: Use predefined macro definition when possible 17.13.49 # 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 # a non-resized bmp image that is 17.16.27 # kugel: not really, no. 17.16.45 # gr 17.16.52 # bmp rows are padded in files, and bmp can be > or <16-bit. 17.17.01 # so I really need to load them in the first pass for their size? 17.17.49 # well, accuracy doesn't matter too much 17.18.03 # as long as they are never bigger than the file size 17.18.28 # could they be bigger? 17.18.46 # Of course 17.19.48 # can you explain that please? do you mean for instance when I load a mono bitmap on a color screen? 17.20.09 # BMP files can be 1/4/8/16/24/32bpp 17.20.28 # So if you load a 4-bit BMP, it will become bigger in-memory on colour targets 17.21.15 # Same for 1-bit and 8-bit of course 17.21.45 # If you're loading mono bitmaps, they will always become smaller, except on mono targets 17.22.29 # 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 # so, mono bitmaps don't get bigger? 17.23.01 Join CGL1 [0] (~CGL@190.207.226.111) 17.23.24 # 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 # They can get bigger as well, due to pixel packing 17.23.31 Quit CGL1 (Remote host closed the connection) 17.23.37 # Yes we do support them 17.24.44 # 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 # Hi 17.25.49 # 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 # 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.52 Quit GeekShadow (Quit: The cake is a lie !) 18.02.59 # gevaerts: around? 18.03.07 # yes 18.03.14 # i fixed the starfield pebble :-) 18.03.18 # or rather the core 18.03.21 # Ooh! 18.03.52 # What was wrong? 18.04.03 # pebble.c, lines 104 to 108... do you see it? 18.04.51 # post-mortem memory dumps are very helpful to track down that kind of issues :-) 18.04.59 # yes, probably 18.05.09 # off-by-one? 18.05.21 # no, it will only patch every second GOT entry 18.05.21 Join mitk [0] (~tomekk@chello089078013146.chello.pl) 18.05.36 # you're incrementing i both in the for statement and in the loop body :-P 18.05.41 # ouch! 18.05.46 # * gevaerts is an idiot 18.05.57 # It was a while loop at some point 18.06.09 # yes, i figured that it must have been :-) 18.06.15 # PP5020 IRAM behaviour is even more weird 18.06.40 # 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 # For the second 24KB it's the opposite - zero-wait for COP, one waitstate for the CPU 18.07.25 # The rest (48KB) is one waitstate for both 18.08.14 # Somehow portalplayer has messed up the crossbar switch 18.09.01 # Now we just need to find a sane way to deal with this 18.12.46 # TheSeven: I guess that clears the last hurdle. These things are clearly doable, at least on ARM 18.13.23 # gevaerts: i looked at a disassembly of that pebble and almost fell off my chair 18.13.34 # that bad? 18.13.54 # remove -fPIC, remove the GOT and the code patching it altogether, and i bet it will still work :-D 18.14.04 # and faster / smaller / less code, of course 18.14.20 # the way they're calling functions is just crazy 18.14.25 # the code itself, yes, but the data section? 18.14.54 # hm yes, the data might need to be relocated 18.15.20 # but why aren't they using sane branches, if they know the exact (relative) target address at compile time? 18.16.02 # They don't 18.16.11 # New commit by 03tomers (r24810): Brickmania: Hopefully prevent dissappearing of the ball 18.16.25 # hm, my clock pebble is broken apparently 18.16.31 # At least not if the target is in another module (source file) or section 18.17.19 # tomers is on a brickmania fixing spree :) 18.17.32 Quit robin0800 (Remote host closed the connection) 18.17.41 # pamaury: yeah :-) 18.17.48 # 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 # Maybe this will improve code generation 18.18.32 # tomers: did you use another trick to prevent the ball from disappearing or did you eventually fix the intersection code ? 18.18.58 # pamaury: It was not the intersection code that was buggy, it was the check of collisions 18.19.55 # 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 # 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 # 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 # 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 # 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 # amiconn: yes, because the internal storage is read-only 18.25.37 # 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 # gevaerts: and please fix that hardcoded path... 18.37.54 # just use snprintf(filename,MAX_PATH, ROCKBOX_DIR "/pebbles/%s.pebble",temp); 18.38.07 # (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 # hm, it almost works :/ 18.46.27 # images are only a tad bit corrupted :( 18.49.54 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 18.50.24 # 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 # just lack of space... 18.57.41 # gevaerts, why did you shrink the skin buffer in the pebble patch? 18.57.46 # did I? 18.57.55 *** Saving seen data "./dancer.seen" 18.57.57 # -#define SKIN_BUFFER_SIZE (MAIN_BUFFER + REMOTE_BUFFER) + \ 18.57.58 # - (WPS_MAX_TOKENS * sizeof(struct wps_token)) 18.58.00 # +//#define SKIN_BUFFER_SIZE (MAIN_BUFFER + REMOTE_BUFFER) + \ 18.58.01 # +// (WPS_MAX_TOKENS * sizeof(struct wps_token)) 18.58.03 # +#define SKIN_BUFFER_SIZE 0x2000 18.58.06 Quit Strife89|Desktop (Quit: Booting into Windows to do maintenance.) 18.58.07 # oops 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 # 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 # 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 # So it's basically a very primitive relocation format 19.05.48 # ah. how messy is handling the relocs? 19.06.44 # three lines of code 19.07.02 # trivial from the loader side - a huge mess for the compiler (and the code generated by it) 19.07.38 # what about ELF / PE / whatever executables and a proper relocator? 19.08.25 # TheSeven: elf apparently has an appalling number of reloc types for ARM :/ 19.08.35 # The consensus seems to be that ELF is too complex, but that COFF might be doable 19.08.46 # coff is rather trivial 19.08.59 # However, nobody seems to be doing it, so I decided to go ahead to wake things up :) 19.09.01 # i haven't seen anything but reloc type 3 being used there 19.10.10 # 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 # well, the jumps *aren't* relative if you use -fPIC 19.11.03 # they load the destination address from the GOT instead of just using a relative jump -.- 19.12.58 # Maybe -mno-gotplt helps? I'm not sure if I understand what it does 19.13.46 # http://pastie.org/835605 19.14.26 Join mt [0] (~mtee@rockbox/developer/mt) 19.15.12 # 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 # although direct-bl for calls into core might not be a practical relocation scheme anyway... 19.16.54 # 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 # the core calls are still better than the internals calls in the pebble! 19.19.04 # 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 # AlexP: I wouldnt expect it to, whats the issue? 19.19.59 # pixelma: arg, thats damn wierd 19.19.59 # 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 # kugel: why would that make it any harder to size? 19.20.21 # 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 # anyway, I have it almost working 19.21.20 # TheSeven: have you tried without -mlong-calls? 19.22.06 # 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 # Unhelpful: afaict the compiler emits the code in a way that inhibits this (only a single section) 19.23.10 # kugel: ? the end is start+size? whats so hard about that? 19.23.21 # woo, found the stupid bug in this divider. :D 19.23.27 # JdGordon: the size is unknown.. 19.23.34 # ...now to write it in ARM :/ 19.24.11 # then you are creating the buffer too early 19.24.28 # 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 # 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 # sure 19.25.32 # why does one even need a GOT? 19.25.33 # "sure"? 19.25.46 # why can't they just pc-relative values instead? 19.25.56 # 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 # 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 # gevaerts: where in that weird make file do i place that best? 19.26.23 # TheSeven: those are range-limited. reasonably for jumps, but more tightly for loads. 19.26.40 # TheSeven: at the end of PEBBLEFLAGS in apps/pebbles/pebbles.make 19.26.44 # Unhelpful: ldr Rx, =difference, add Rx, Rx, PC 19.26.46 # JdGordon: that's all much harder than just grabbing the entire audio buffer and cap it 19.26.52 # still a lot faster than the GOT crap 19.27.13 # kugel: but then you have to stop playback to reload a theme? 19.27.19 # imo thats the wrong way to do it 19.27.30 # what's the wrong way? 19.27.55 # also, what happened to figuring out the required size during parse time and only continue loading if it fits? 19.28.04 # 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 # that's what I do right now 19.29.13 # 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 # that's what I do right now 19.29.29 # Unhelpful: the constant pools are close enough to be loaded via LDR Rx, [PC,#whatever] 19.29.42 # I'm just saying it's harder than it needs to be 19.30.18 # its exactly as hard as it should be 19.30.18 # image loading is broken I think. it should fail to parse if an image can't be loaded 19.30.34 # using the whole buffer means having to stop playback which is lame 19.30.46 # you don't understand me 19.31.14 # 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 # that would be simple and nice 19.31.25 # btw, why isn't the linker cabable of inserting thunks for out-of-range relative branches? 19.31.36 # then we could disable that long-call mess altogether 19.31.46 # TheSeven: ...eabi is doing that :) 19.31.56 Quit Uretti (Read error: Connection reset by peer) 19.32.10 # i'm using eabi, and it doesn't seem to do it 19.32.22 # have you removed -mlong-calls? 19.33.07 # not manually, but why isn't that done on eabi by default? 19.33.29 # it should. but if it's doing long calls it's buggy :) 19.33.46 # TheSeven: -mlong-calls is enabled by CFLAGS I think 19.34.43 # print GCCOPTS to be sure 19.35.28 # 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 # no, the 940t doesn't have an mmu 19.36.13 # but wasn't there a trick? 19.36.17 # that also wouldn't help for all targets 19.37.02 # 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 # 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 # 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 # multifonts on the remote worked when it was commited! 19.39.03 # configure, line 263+ 19.39.53 # ugh 19.40.40 # JdGordon: image loading is broken, parsing should fail if it can't be loaded 19.41.22 # load_skin_bitmaps always returns true 19.41.35 # New commit by 03theseven (r24811): Fix configure to not use -mlong-calls when configuring for EABI 19.42.01 # kugel: so fix it? 19.42.13 # trying.. 19.42.14 # wow, that has been a stupid bug 19.42.23 # 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 # 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 # JdGordon: %X|-| is valid? 19.50.01 # shouldnt be 19.50.05 # not anymore 19.50.10 # did that get left in somewhere? 19.50.15 Join Blue_Dude [0] (~chatzilla@adsl-235-206-131.mco.bellsouth.net) 19.50.30 # - 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 # I'm a bit confused by "if (backdrop[0] == '-')" in skin_backdrop_load 19.50.57 # ah ok 19.51.43 # kugel: yes, 56K binsize decrease 19.55.21 # kugel: Thanks for the playlist viewer screen fix yesterday. 19.56.42 # TheSeven: funny-i-could-swear-i-did-that-ages-ago. :/ 19.57.01 # 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 # Unhelpful: yes, you did it, but it was broken 19.57.29 # look at the diff i just commited ;-) 19.57.30 # 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 # the nasty thing about that is that it just fails silently 19.59.21 # Blue_Dude: one click delete? 19.59.59 # TheSeven: test pretty much always does ;) 20.00.34 # * gevaerts is confused 20.00.38 # JdGordon: more like one click to confirm-delete. 20.03.52 # perl needs { } for single line ifs? 20.04.21 # Blue_Dude: I wouldn't use it a lot and would rather see insert on the rec button 20.04.46 # Blue_Dude: I thought I was the only one annoyed by that :) 20.04.51 # kugel: perl needs {} for ALL ifs 20.05.45 # 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 # I have put my hands on the patches to linux kernel which add as352x and as353x targets 20.07.41 # woo! 20.07.53 # does this mean I shold go buy another clip+? 20.07.54 # 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 # well the MMC/SD driver for as353x is clearly suited for clip+, but i must check the licence of this file 20.09.26 # 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 # New commit by 03jdgordon (r24812): remote multifont fixes. it shoud be working again (blame AlexP! he made me break it last week!) 20.10.31 # funman: that seems too easy ;) 20.10.45 Quit karashata (Ping timeout: 268 seconds) 20.11.00 # New commit by 03kugel (r24813): Fix wpsbuild to properly generate "-" for theme related settings (to get the default values/no file for filename settings). 20.11.08 # 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 # do we still have the ams contact? 20.11.54 # i have the mail of that marketing person 20.11.56 # JdGordon: unfortunately not 20.12.07 Join saratoga [0] (~463f90ed@gateway/web/freenode/x-hszyhocvfybjjxkx) 20.12.07 # they seem to have abandoned us 20.12.07 # :( 20.12.27 # this guy had sent me the as353x datasheet (after several mails/delay though) 20.12.42 # aha, that's good 20.13.20 # 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 # does anyone know why read_bmp_file multiplies error return values with fd? 20.13.53 # 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 # What does this: "no configurable keys/menus" mean? 20.14.37 # I thought we changed our minds about it? 20.14.51 # What's a quickscreen then? 20.15.08 # note, those files which have the restrictive header also have a "MODULE_LICENSE("GPL"); line at the bottom 20.15.37 # so they cheat? 20.16.03 # I checked the patches sent by Thomas Luo 4 years ago to linux-arm-kernel mailing list for as352x 20.16.16 # some were exactly the files I have, but with a correct GPLv2 header 20.16.36 # I would think it's probably an old habit of using that kind of headers, on the advice of their lawyers 20.16.43 # 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 # We can't use them verbatim 20.17.01 # Unhelpful: do you know? 20.17.05 # 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 # i don't think rockbox builds for the clip+ 20.17.22 # iq: rockbox doesn't build for clip+ yet, since the bootloader isn't finished 20.18.19 # ok - I guess I'll have to wait then. 20.18.26 # so how hard will it be to get an SD driver using these sources? 20.18.44 # i would expect quite easy 20.19.05 # do they cover other parts of the chip like clocks and power management? 20.19.21 # i guess everything is in here 20.19.33 # usb, i2c, sound, clocks ... 20.19.52 # ! 20.20.17 # kugel: do i know? 20.20.23 # "does anyone know why read_bmp_file multiplies error return values with fd?" 20.20.42 # 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 # yes that seems reasonable 20.21.18 # if they didn't put it out in the open we probably shouldn't redistribute it anyway 20.21.24 # well publically redistribute 20.21.33 # kugel: i'm not looking at it right now, but doesn't it do something like -(fd *10 + const)? 20.21.35 # if only so they help us when we ask about the Clip++ 20.21.42 # 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 # 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 # 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 # so I can see it by the constant? 20.24.54 # it=the error 20.25.13 # if (error % 10) ... ? 20.25.23 Join Lear [0] (chatzilla@rockbox/developer/lear) 20.25.32 # 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 # New commit by 03kugel (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 # 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 # ah: there was some errors in reverse engineering :/ 20.33.15 Join stooo [0] (~sto@e181177203.adsl.alicedsl.de) 20.39.29 # 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 # it should be parsed max once 20.41.03 # 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 # does the wps need to be parsed before the rsbs? 20.43.23 # * gevaerts finally finds what he was doing wrong 20.43.30 # or could I swap them (and put the skin loading within FOR_NB_SCREENS()) 20.44.22 # the sbs MUST be parsed first for each screen 20.44.29 # otherwise order doesnt matter 20.44.39 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 20.45.26 # hmm, I meant the screens sbs must be parsed before any other skins on that screen 20.45.31 # so yes, you could but it in a loop 20.46.21 # what does the linux source refer to the as3525v2 as ? 20.47.06 # New commit by 03Buschel (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 # 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 # saratoga: not sure if there is linux code for this one 20.48.47 # so its just the as3525 and the as353x? 20.48.58 # i believe AMS just updated the as3525 with some components present in the as353x (SDMMC, VIC, as3514) 20.49.11 # as352x, there is also as3527 code 20.49.17 # do you want them ? 20.50.10 # gevaerts: on eabi without -mlong-calls the pebble code is sane 20.51.15 # 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 # TheSeven: nice! 20.52.51 # In the meantime, I've (finally!) managed to put the rb pointer back automatically 20.53.22 # funman: sure 20.53.43 # JdGordon kugel: maybe an opportunity to look at disabling the copy of rsbs for tagets that doesn't have one 20.54.08 # ? 20.54.09 Quit darkham (Quit: Sto andando via) 20.55.29 # I meant that .rsb files are still there for tagets that don't have remote, sure that need an easy fix 20.56.03 # if (setting[0] && setting[0] != 0xff && setting[0] != '-') #-> "warning: comparison is always true due to limited range of data type" 20.56.08 # ??? 20.56.28 # wtf is the check for 0xff? 20.56.42 # thats there on a few settings but I dont think is still needed 20.57.16 # no idea, it's there since I looked at it for the first time 20.57.19 Quit iq (Quit: Leaving) 20.57.29 # funman: if you have a link handy, would you gtalk it to me? i have to head out 20.57.43 # i'll probably be useless for this port but i'd still like to look it over 20.57.44 # kugel: nice that you noticed a slowdown on boot, since JdGordon doesn't/don't want :p 20.57.48 # i'll send it by mail 20.57.55 # 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 # funman: no time right now but I see your comments above with great interest ;-) 20.59.09 # thanks 20.59.12 # FlynDice: you're a recipient of the mail as well ;) 20.59.39 # funman: You Da man!! 20.59.47 Quit stooo (Quit: Leaving.) 20.59.53 # I'm not :( 20.59.56 # might as well add kugel, mt 20.59.59 # :) 21.00.06 Quit saratoga (Quit: Page closed) 21.00.08 # kugel: you were already ;) 21.00.54 # 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 # funman: the mail came later. thanks! 21.10.07 Join perfectdrug [0] (~marko@p5B0EED52.dip.t-dialin.net) 21.10.22 # iq: did you run the rockbox bootloader on your clip+ ? 21.12.14 Quit BlakeJohnson86 (Remote host closed the connection) 21.12.47 # pebbles don't work on m68k :\ 21.13.03 # or at least, they need more effort 21.14.36 # funman: were you be able to decode the hex numbers (csd?) now? 21.19.07 # funman, no, I have not. I thought it is incomplete? 21.20.27 # ThomasAH: yes, my app was buggy, they describe a 100% normal SD card 21.20.57 # funman: so SD vs. SDHC? 21.20.58 # 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 # ThomasAH: 2GB is SD and 4/8GB are SDHC 21.21.51 # funman: so as expected, right? 21.21.59 # yep 21.22.01 # 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 # 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 # iq: my clip+ 8gb survived the bootloader ... so I think it is 2 bricked vs. 3 non-bricked now 21.23.57 # i think it's even 4 non-bricked 21.24.05 # ThomasAH, what procedure you followed to load it ? 21.24.28 # iq: i think it's detailed on SansaAMS wiki page (mkamsboot) 21.25.37 # funman, so everyone followed the same procedure and we have a little over 50% success rate. 21.25.38 # 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 # 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 # iq: yes, although the code in mkamsboot changed, and the current code worked 100% of the times it was tried 21.26.09 # 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 # TheSeven: we don't know what happened 21.26.39 Quit karashata (Quit: The fluffy dragon has left completely!) 21.26.39 # and they just don't power on any more, or what do they do? 21.26.46 # for JdGordon's clip, the code might have used r5 or r3 but i don't remember 21.26.46 # no DFU on those things? 21.26.57 # afaik no 21.27.04 # where is the bootloader stored? nor? nand? 21.27.14 # nand 21.27.18 # is there an internal bootrom or is it booting directly from nand? 21.27.27 # (via steppingstone) 21.27.29 # 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 # 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 # so they're using those embedded microsd chips? 21.29.07 Join Farthen [0] (~chatzilla@e179232003.adsl.alicedsl.de) 21.29.17 # there is a nand chip which is read/written by a MMC/SD controller 21.29.40 # probably to avoid wear leveling in software 21.29.54 # and since they are sandisk they don't have to pay royalties for the controller 21.29.59 # I'm happy to post my clip to anyone for an autopsy 21.29.59 # heh, hardware ftl. funny. why don't they integrate that into one chip, like those microsd things do? 21.30.26 # TheSeven: aren't the microsd just a nand chip + a controller? 21.30.35 # yes, but in one package 21.31.13 Join Kitr88 [0] (~Kitr88@BSN-182-25-211.dial-up.dsl.siol.net) 21.31.28 # on e200v2 you can access the OF as a usb mass storage if you connect 2 pads together 21.31.44 # I tried that and didnt have any lucjk 21.31.51 # ThomasAH, where you got clppa-patched.bin ? 21.31.56 # 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 # if i do that on my fuzev1 or clivp1 i have an usb mass storage but with 0 sectors 21.32.19 # iq: this is generated by mkamsboot 21.32.49 # (the third argument is the target file name) 21.33.02 # funman: in theory yes, but the sd controller will probably not like it 21.33.40 # if anything, i would jam the communication between the CPU and the SD controller 21.33.46 # 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 # perhaps the OF is stored on the nand, and also somewhere else 21.34.19 # funman: all of this stuff will only help if the bootrom has a recovery mode 21.34.30 # New commit by 03kugel (r24816): Properly generate (with "Save Theme Settings") and handle filename settings with "-". 21.34.34 # New commit by 03kugel (r24817): Shorten settings_skins_apply() and correct some checks. 21.34.34 # could it be possible to tap all the sd signals? 21.34.36 # New commit by 03kugel (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 # 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 # http://www.austriamicrosystems.com/eng/content/download/16763/295720 21.35.53 # page 22 7.1.6 boot concept 21.37.29 # 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 # e200v2 probably trigger the "USB boot promer" 21.38.37 # "if there is no bootable device" is probably the case when the NAND can't be read 21.39.19 # 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 # funman: are there any pcb scans of clip+? 21.43.36 # there is ABI pictures but i could scan mine if you need bigger resolution 21.44.07 # http://www.anythingbutipod.com/archives/images/sansa-clip-disassembled/sandisk-sansa-clip-disassembled-12.jpg and 13.jpg 21.44.38 # oh, sorry I misread, it's only clipv1 21.44.56 # i haven't seen a clip+ opened 21.45.27 # 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 # heh the patches show CCU_GPIOA through CCU_GPIOP 21.46.39 # i wonder how many are on the clip 21.46.41 # ThomasAH, clppa-original.bin is the clppa.bin from clipplus01.02.09.zip ? 21.46.43 # + 21.46.48 # saratoga: for as353x ? 21.46.54 # 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 # i only saw GPIOA through D 21.47.09 # iq: yes 21.47.46 # BTW, I checked out the code this morning (CST GMT-6) - so hopefully I will have the good bootloader, right :) ? 21.47.58 # http://www.anythingbutipod.com/archives/2009/08/sandisk-sansa-clip-plus-disassembly.php 21.48.19 # iq: yes, manually renamed to avoid mistakes :) 21.48.19 # 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 # Okay, so now I have "clppa-patched.bin" 21.49.44 # iq: be sure you are ready to risk bricking your Clip+ before copying it! 21.50.06 # funman, so you won't send me a new Clip+ :) ? 21.50.52 # it is $40... so if it will help in the testing then i can risk. 21.50.54 # no, only my gratitude :) 21.51.31 # Now i need to figure out how to access the internal memory. 21.52.02 # TheSeven: did you notice the URL? http://www.anythingbutipod.com/archives/2009/08/sandisk-sansa-clip-plus-disassembly.php 21.52.05 # you need to set USB mode to MSC first i think 21.52.18 # in the CGU code: "0 /* removed in V2 */ " 21.52.20 # ThomasAH, Hopefully I won't be needing this - LOL 21.52.25 # 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 # saratoga: they removed a device ? 21.54.12 # they removed some registers apparently 21.54.20 # 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 # iq: then just copy clppa.bin there and unplug 21.55.09 # iq: (next to music, not into :)) 21.55.18 # mv clppa-patched.bin clppa.bin 21.55.27 # iq: noooooooo! :) 21.55.34 # * ThomasAH suggests cp 21.55.41 # ok 21.55.44 # 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 # (for forensic if it fails) 21.56.04 # ThomasAH, start over ? 21.56.06 # I'm not sure I accept responsibility, but ta for fixing :) I'll try it out shortly 21.56.09 # @JdGordon 21.56.17 # :) 21.56.21 # there are registers for setting the SD card communication voltages 21.56.25 # didn't we have an issue with that 21.56.27 # iq: no, just cp back to your PC 21.56.44 # ok 21.57.19 # ThomasAH, it is 15MB 21.57.20 # saratoga: iirc it was the arm core voltage 21.58.10 # ThomasAH, Copied, now unplug from the machine and power cycle ? 21.58.26 # of course unmount first 21.58.28 # iq: no need to power cycle, update will begin immediately 21.58.44 Quit TopyMobile__ (Quit: TopyMobile__) 21.58.48 # here goes my $40 21.58.49 # iq: umount, unplug, wait :) 21.59.05 # Firmware upgrade in progress 21.59.07 Join TopyMobile [0] (~topy@f048243022.adsl.alicedsl.de) 21.59.14 # Update completed 21.59.22 # Black screen :) 21.59.31 # iq: turn it on 21.59.45 # it says RockBox and dmg -> 21.59.59 # dma -> 22.00.05 # iq: dma ... though I saw the same :) 22.00.16 # so now what LOL 22.00.47 # seems like it worked okay, right ? 22.00.58 # 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 # iq: yes 22.01.08 # ok 22.01.11 # home or left button, any of the 2 should work 22.01.21 # so 2 to 4 now :) 22.01.27 # to 5 ! 22.01.33 # funman: 5? 22.01.41 # Now I am back to the sansa firmware :) 22.01.54 # you, iq, FlynDice, me, and someone else who was present on irc 22.02.02 # comments look great, theres all sorts of stuff about power use, recommended clock dividers, etc 22.02.15 # <- was number 4 22.02.22 # funman, ThomasAH, thanks - it was fun ... what next :) 22.02.28 # funman: ah, how could I forget someone else :) 22.02.37 # iq: copy the original clppa.bin to remove the bootloader 22.03.10 # funman, Is it optional ? 22.03.11 # iq: first show it around to impress people :) 22.03.23 # 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 # Now I need to write a Hello World 22.09.39 Join Lear [0] (chatzilla@rockbox/developer/lear) 22.10.17 # iq: adjust http://pastie.org/829514.txt :) 22.11.05 # 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 # Using gcc 4.4.3 btw. 22.11.33 # pamaury? 22.12.01 # 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 # Well, I do have a test folder for a total depth of 12. :) Otherwise not much. 22.13.53 # up to ~20 should be supported with that stack size 22.14.01 # ThomasAH, just apply this patch ? 22.14.29 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100202165920]) 22.14.43 # New commit by 03stripwax (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 # iq: no, look at it to see where printf("Hello World!"); would fit :) 22.15.06 # ThomasAH, oh okay :) 22.16.16 # JdGordon: If you have 2 minutes could you do a quick sync of the fms patch? 22.17.55 # New commit by 03stripwax (r24820): Eep, didn't mean to commit those other files 22.18.07 # New commit by 03Buschel (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 # "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 # 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 # 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 # is the bootloader in DRAM or IRAM? 22.21.47 # Is anything still using use tremor mdct_backward() ? 22.22.19 # saratoga: dram for clipv2 (and fuzev2 i guess), iram for others 22.22.31 # stripwax: no it can go 22.22.46 # funman: ok then it should be possible to increase the clock 22.22.53 Quit knine (Ping timeout: 252 seconds) 22.23.14 # saratoga: before memory_init() would be the right place 22.23.37 # sdram_init()*, memory_init() isn't in the bootloader 22.24.55 # 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 # http://www.datafilehost.com/download-08770d85.html 22.26.27 Join stooo [0] (~sto@e181177203.adsl.alicedsl.de) 22.26.34 # ...apply hold, let it play for 1 min or so, take hold off. Sublines *should* go crazy. 22.26.43 # *unless I've gone insane. 22.30.36 Quit petur (Quit: router reboot) 22.30.45 # 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 # S_a_i_n_t: heh, that's indeed waird 22.35.31 # 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 # weird* 22.36.35 # stripwax: shall I commit the fix? 22.36.52 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 22.37.50 # 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 # 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 # I'm surprised noone's noticed it prior to now... 22.39.24 # i don't quite get what's happening, but something is weird, yes 22.39.40 # New commit by 03Buschel (r24822): Make mdct compilable again for non-ARM targets. 22.39.46 Quit stooo (Ping timeout: 265 seconds) 22.39.49 # scrolling text going mad isn't really something new, saw that in some other places, too 22.40.08 # Buschel - does that fix the ARM targets? sorry, mine is still (re)building 22.40.12 # TheSeven: no, thanks. will have a look 22.40.30 # despite the viewport not being 'displayed'...it's still 'running in the background'? that's my guess... 22.40.40 # allbeit wrong ;p 22.41.00 # stripwax_: it fixes the build for non-ARM (including PC-Sim) 22.41.20 # 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 # 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 # TheSeven: it only happens if the VP is conditional...otherwise, its fine. 22.42.16 # stripwax_: btw, CLIP_TO_15 is not used by any codec anymre 22.42.22 # *anymore 22.43.17 # stripwax: that seems to fit, have you seen it happen? it alternates at pprox 0.1sec intervals. 22.44.19 # 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 # 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 # S_a_i_n_t: it switches after scrolling *twice* for me 22.46.05 # 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 # TheSeven: it's at 10 second intervals...2mins on hold=12 switches. 22.47.09 # 1min=6 22.47.13 # etc. 22.47.32 # well, for me anyway. 22.48.49 # New commit by 03gevaerts (r24823): Disable rombox on ondio SP. It can be reenabled if the binsize goes down again. 22.49.14 # thats a big *if* 22.51.20 # New commit by 03gevaerts (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 # amiconn: I was notified already 22.53.23 # 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 # TheSeven: yes ? 22.53.59 # something's still wrong with the dircache 22.54.09 # 12 levels => stkov 22.54.20 # hum, stkov ? 22.54.25 Join linuxguy3 [0] (~timj@adsl-75-57-163-40.dsl.emhril.sbcglobal.net) 22.54.34 # gevaerts: heh, I think it's incorrect 22.54.34 # see the lines above my ping 22.54.43 # because I had warnings on my machine without this cast 22.55.00 Quit iq (Remote host closed the connection) 22.55.17 # kugel: hm, wait 22.55.53 # 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 # It's a shame that Lear just quit the chan 22.56.22 # it's still an enum if HAVE_REMOTE_LCD 22.56.51 # TheSeven: aparently, mc2739 also reported a problem with a stkov in dircache at boot time, I will investigate this 22.57.35 # TheSeven: funny, hasn't pamaury been optimizing dircache stack/memory usage? 22.57.41 # gevaerts: oh, that's the bug I think 22.57.48 # I'm on it 22.58.01 *** Saving seen data "./dancer.seen" 22.58.23 # 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 # pamaury: Hi, you had questions about FS #11043? 22.58.50 # well, it should be the same everywhere 22.59.04 # gevaerts just negated the yellows... 22.59.19 # on average it's now correct :) 23.00.06 # 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 # charge monitoring in terms of what? 23.00.47 # i only calibrated the battery gauge a bit 23.00.54 # wps %cp etc. tags. 23.01.06 # New commit by 03funman (r24825): as3525v2: full list of registers + description 23.01.10 # New commit by 03funman (r24826): sd-as3525v2: detail MCI_CTRL bits 23.01.16 # New commit by 03funman (r24827): sd-as3525v2: describe CTYPE bit 23.01.19 # New commit by 03funman (r24828): sd-as3525v2: name interrupt bits (no description yet) 23.01.24 # New commit by 03funman (r24829): sd-as3525v2: command register bits 23.01.31 # New commit by 03funman (r24830): sd-as3525v2: MCI_FIFOTH bits 23.01.33 # S_a_i_n_t: don't think i changed something regarding those 23.01.35 # New commit by 03funman (r24831): sd-as3525v2: MCI_HCON bits 23.01.39 # New commit by 03funman (r24832): sd-as3525v2: no limits on the amount of sectors to transfer 23.01.56 # (no functional changes) 23.01.56 # erm, funman, want to hit 24500? :-P 23.02.14 # nah, 123456 ;) 23.02.53 Quit stripwax (Quit: http://miranda-im.org) 23.04.27 # hmmmm, i swear someone did *something*, as %bp & %bc work on my 2g suddenly. weird, but awesome ;D 23.05.34 # New commit by 03gevaerts (r24833): statusbar_position should also return enum statusbar_values if it's a macro 23.05.50 # New commit by 03Buschel (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 # FlynDice: looking at the datasheet it seem to me I can adjust the DRAM clock either by: 23.23.04 # 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 # isn't mem_clk limited to 90MHz ? 23.23.50 # 2) using the built in Clock ratio, CLK register to set the ARM memory controller to double the clock it gets 23.23.55 # yeah it is 23.24.17 # FlynDice: i think you mentioned trying one of these, which was it? 23.24.27 # mc2739: yes 23.24.50 # mc2739: what is the maximum directory depth of your file sysytem tree ? 23.25.14 # pamaury: no more than 6 deep 23.25.53 # 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 # hmm though the patches i have make it sound like only #1 is used 23.27.15 # 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 # on which device ? 23.28.28 # pamaury: e280v1 23.29.13 # 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 # 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 # 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 # Hmmmm, bugger....Plugin/pictureflow gives "*PANIC* Stkov main" on Nano2g 23.34.13 # :( 23.34.16 Quit Strife89|PalmTX (Client Quit) 23.34.25 # 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 # unfortunately that slows down all the peripherals, and i'm not sure if their drivers will be ok with it 23.34.55 # to keep the pclk the same i think we'd need to change the PLL 23.35.09 # gevaerts: thanks for looking into it 23.35.17 # r24803 that is... 23.35.40 # saratoga, it has two PLLs so that provides some extra freedom of choice 23.36.10 # bertrik: i think the pclk and memory clock must use the same PLL 23.36.26 # 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 # 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 # saratoga, which clock is the memory clock, mpmc_clk? 23.39.23 # bertrik: correct 23.39.34 # MultiPortMemoryController iirc 23.40.36 Join Strife89|PalmTX [0] (~upirc@adsl-154-22-249.mcn.bellsouth.net) 23.41.16 # 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 # TheSeven, mc2739: I could have an explaination ! I happily dereferencing a NULL pointer :/ 23.42.24 # that shouldn't cause a stkov though, should it? 23.42.56 # Unhelpful: is it safe to load a bitmap twice using the same bitmap struct? 23.42.58 # save 23.43.04 # whatever :p 23.43.23 # TheSeven: on my device, it runs like a charm ! so I perhaps the result is more or less undefined 23.43.43 # this second pass is still buggy 23.43.46 # kugel: safe was right 23.43.56 # yea, I figured :) 23.45.14 # 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 # New commit by 03pamaury (r24835): Fix a dircache NULL-pointer dereference. 23.49.24 # TheSeven, mc2739: could you try with this new version ? Perhaps it helps things 23.49.57 # New commit by 03funman (r24836): sd-as3525v2: describe interrupt mask bits ... 23.50.01 # New commit by 03funman (r24837): sd-as3525v2: panic in case of error in the isr ... 23.50.02 # pamaury: i didn't get any stkovs... 23.50.20 # 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 # funman: sd transfers don't work yet, do they? 23.52.44 # nope 23.56.41 Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 23.58.27 # there are no errors or data transfer over interrupts, but there are interrupts anyway 23.58.35 # i must check the status of each interrupt