--- Log for 19.05.110 Server: jordan.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 12 days and 12 hours ago 00.00.18 # Just to rule out any compiling problems from your machine/setup 00.00.19 # I know where the table with the OF values is (which we can't use, at least not for all targets, as we do set up some other values in a better way), but not where the code is that uses the table 00.01.08 # there is already one: FS#11267, pretty much describing what i have, but i think it's title should be rephrased 00.01.13 # Unfortunately I forgot to document that when finding it a long time ago :( 00.01.53 # max242: is this with an official build? 00.03.19 Quit Boldfilter (Quit: Boldfilter) 00.03.59 # gevaerts: issue got started since r25299, and is pretty persistant ... 00.04.16 # That's not what I asked :) 00.04.24 # But is that from an official build? 00.04.32 # Or from your own compiled version? 00.06.25 # evilnick_B: from the 'current-builds' part of the rockbox website 00.07.14 # i'm running r26133 right now 00.07.17 # THAT's what we needed, thanks 00.07.31 # you're welcome 00.08.53 Quit Battousai (Read error: Operation timed out) 00.09.02 Quit jgarvey (Quit: Leaving) 00.09.19 # i also posted a message on this in the forum: http://forums.rockbox.org/index.php?topic=14064.msg167033#msg167033 00.10.08 # is bor_ka sometimes on irc, he seems to have also lockup issues which got started since r25299 00.10.35 Join Battousai [0] (~bryan@gentoo/developer/battousai) 00.11.14 # as he originated the flyspray ticket FS#11267 00.12.39 Quit phi1ippe (Quit: leaving) 00.13.04 Quit stripwax (Read error: Connection reset by peer) 00.13.17 # i'm off to bed now, i will pester you guys later ;-) 00.13.59 Quit max242 (Quit: CGI:IRC (EOF)) 00.17.52 Quit efyx (Remote host closed the connection) 00.21.24 Quit lpereira (Quit: Leaving.) 00.25.40 Quit notlistening (Ping timeout: 248 seconds) 00.38.28 Quit merbanan (Ping timeout: 260 seconds) 00.39.28 Quit DerPapst (Quit: Leaving.) 00.44.47 Quit ender` (Quit: Anyone who thinks people lack originality should watch them folding roadmaps.) 00.47.17 Part domonoky 01.07.41 Quit pamaury (Quit: Page closed) 01.08.25 Quit solexx_ (Read error: Connection reset by peer) 01.08.27 Join solexx [0] (~jrschulz@e176105210.adsl.alicedsl.de) 01.21.38 Part toffe82 01.24.45 Join n1s [0] (~n1s@rockbox/developer/n1s) 01.30.39 # FS#11293 - Catalan language update 01.34.44 # mm, I'm unable to apply the diff from FS#11293, all 16 hunks fail to apply 01.35.31 # why is it? 01.35.50 # if every chunk of a diff fails it usually means you have the wrong value for -p 01.38.04 # d'oh 01.38.09 # Torne: true 01.38.35 # Torne: I suppose it's already time to go to bed 01.44.35 Quit linuxstb (Ping timeout: 276 seconds) 01.44.52 Join Pikidalto [0] (~Piki@unaffiliated/piki) 01.45.24 # hi, i was just wandering if there were any plans to port to the Philips GoGear SA32XX series 01.45.53 # Pikidalto: we don't make plans for ports 01.46.29 # and i have not heard that target mentioned as one someone is investigating or working on a port for 01.46.35 # n1s: so basically you just go ahead do the ports if it's possible? 01.47.28 # n1s: yes, i was afraid of that, i had not seen any mention of it on the site 01.47.54 # well, usually an interested owner of a player starts a port, after the groundwork is done (a way to execute custom code) it's not uncommon that others join in 01.50.02 # New commit by 03jethead71 (r26154): Gigabeat S: Implement LCD contrast, invert and flip modes. Enhance LCD power management. Include init data but it's not needed yet (identical to ... 01.50.22 # i'm no programmer, so i wouldn't know where to start, other than posting information on the player and pics of the inside (my mother is interested in rockbox just for the cool Plugins, but i doubt she'd like having a disassembled GoGear lol) :-( 01.51.50 # Pikidalto: the most important information about the hardware is what kind of processor or System on Chip is in the player, if it is one we already have working drivers for a port is usually substantially easier 01.52.32 *** Saving seen data "./dancer.seen" 01.52.43 # n1s: i no longer have the packaging or manual, but i could try to find it on google 01.53.07 # the packaging or manual are extremely unlikely to say what the processor/soc are 01.53.19 # that's not usualy mentioned in the manual, but if you can find pictures of the inside they can be useful 01.53.27 # and a lot of the google results for that kind of thing for various players point at us.. ;) 01.54.45 # any ideas how to get the CPU/System information without popping open the case? 01.55.24 # well, it can sometimes be found out from a firmware update 01.57.53 Quit evilnick_B (Quit: Page closed) 01.59.20 # hmm, i'd guess it's a STMP3500 02.00.11 # for my GoGear? currently trying to do a firmware update 02.00.39 # *doing* a firmware update won't tell you anything, probably.. 02.00.43 # looking at it might :) 02.01.11 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 02.01.23 # true, i guess, only probelm is *getting* the firmware file 02.02.00 Quit bieber (Ping timeout: 260 seconds) 02.02.15 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 02.02.38 # Pikidalto: the product brief for the gogear sa3285 shows that it supports "SMV" video which seems to be Sigmatel Motion Video which they have in their stmp35xx sdk 02.03.01 # also it lists support for mp3 and wma only, which is ey common for players based on this SoC too 02.03.24 # this one specifically is a 3245/37, but it shouldn't be much different 02.03.29 # SoC? 02.03.40 # guess i should read the lingo page :-) 02.04.15 # System on Chip 02.05.30 # well, the stmp35xx SoC's have a dsp core (no cpu) which AFAIK ther's no free compiler for so a port of rockbox for this is *very* difficult (read not going to happen) 02.08.04 # jhMikeS: any measurable battery time improvement from that lcd power management improvement? 02.08.15 # eh s/life/time/ 02.09.49 # n1s: haven't had a chace to really test but it's the same thing as the F, so I imagine given that it's not insignifant, it won't hurt anything. 02.10.41 # jhMikeS: ok, btw, do you know if the pmic can tell the current battery current? 02.10.47 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 02.10.59 # noone else seems to actually producing benches lately and I've done my share already. :) 02.11.11 # how much current is sucked from the battery that is 02.11.27 # jhMikeS: heh, i'll do one tomorrow then! 02.11.37 # n1s: it *can* if it's wired for it, but that sense is shorted. only the charging sense works. 02.11.46 # aha 02.15.08 Join Rob2222 [0] (~Miranda@p4FDCA421.dip.t-dialin.net) 02.17.48 # * jhMikeS better redump the IPU since he thinks he just add a bit set that need not be there. 02.18.48 Quit Rob2223 (Ping timeout: 265 seconds) 02.24.48 # oh wow, i'm in Live Support for philips, they don't have the specs on their own MP3 Player 02.25.13 # more like, it's a closely guarded secret 02.28.31 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 02.32.21 Quit MagusG (Read error: Connection reset by peer) 02.33.16 Join MagusG [0] (magusg@c-76-97-148-35.hsd1.ga.comcast.net) 02.33.16 # well i'm out, thanks for the time guys, i'll be back if i find more info on this player 02.33.18 # bye 02.33.20 Part Pikidalto ("Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is") 02.33.22 Join Xqtftqx [0] (~Xqtftqx@cpe-184-59-157-220.neo.res.rr.com) 02.33.25 # YO WASSUP 02.34.03 Join n00b81 [0] (~185b52cd@gateway/web/freenode/x-zztpchmvaxlwmibh) 02.34.22 # logbot, this message will go down in history 02.34.34 # What i am typing now, will always remain in the rockbox logs 02.35.34 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 02.36.15 # Welcome to #rockbox kramer3d! I am the automated welcome bot! Please read the rules before chatting! 02.36.31 # no youre not 02.36.32 # i know you 02.36.49 # Oh really 02.36.56 # yeah 02.37.02 # i also know your step brother Mark 02.37.02 # How so? 02.37.09 # I dont have a step brother. 02.39.55 Quit DataGhost (Ping timeout: 240 seconds) 02.41.47 Quit n1s (Quit: Lämnar) 02.42.56 # New commit by 03jethead71 (r26155): Gigabeat S: Wrong thing messing with IPU_CONF. No fiddling is needed just yet. 02.47.44 Quit cdb (Ping timeout: 260 seconds) 02.51.00 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 02.59.05 # oh ... an overlooked detail on the main page of rockbox.org 02.59.51 # sansa clip and fuzev2 is double listed ... they need to be removed from unusable ports 03.00.30 Quit kramer3d (Quit: Leaving) 03.02.29 Part n00b81 03.10.35 # New commit by 03mc2739 (r26156): Remove clip and fuzev2 from unusable ports 03.10.56 # thanks 03.15.03 Join ischeria1 [0] (~ischeriad@p5B0A08F8.dip0.t-ipconnect.de) 03.18.30 Quit ischeriad (Ping timeout: 264 seconds) 03.33.28 # B4gder or Zagor: Could you update the web server for a main page change? Thanks 03.52.34 *** Saving seen data "./dancer.seen" 04.07.25 Quit TheSeven (Ping timeout: 240 seconds) 04.11.40 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.15.48 Quit pixelma (Disconnected by services) 04.15.48 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.15.52 Quit amiconn (Disconnected by services) 04.15.54 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.16.08 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.16.13 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.22.03 Join CGL [0] (~CGL@190.207.171.217) 04.24.21 Quit Xqtftqx (Ping timeout: 264 seconds) 04.50.34 Join cdb [0] (~cdb@206-248-134-203.dsl.teksavvy.com) 04.54.50 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 05.04.52 Quit BlakeJohnson86 (Quit: Leaving.) 05.09.32 Join BlakeJohnson86 [0] (~bjohnson@2002:1876:a27b:0:227:13ff:fe65:1262) 05.10.45 Quit wincent_balin (Ping timeout: 240 seconds) 05.17.27 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 05.28.12 Quit Horscht (Quit: Verlassend) 05.50.00 Quit Unhelpful (Ping timeout: 240 seconds) 05.52.35 *** Saving seen data "./dancer.seen" 06.04.33 Quit LambdaCalculus37 (Quit: Fwump) 06.10.11 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 06.11.58 # * S_a_i_n_t is plagued by "need to hard-reset to turn the DAP (2 different iPod Nano1Gs) on" today... 06.12.57 # Between the two of them, it's happened ~10 times today, and I find it a little too much of a coincidence that they both ended up with "white screen of death" trying to recover from it. 06.14.33 # Restored, re-installed RB...haven't seen the problem again yet...*yet*. 06.28.54 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 06.36.39 Join webguest32 [0] (~43bc5e1f@giant.haxx.se) 06.37.22 Quit webguest32 (Client Quit) 06.37.31 Join webguest94 [0] (~43bc5e1f@giant.haxx.se) 06.40.13 Join pupuserb7dc64 [0] (~pupuserb7@ool-45735857.dyn.optonline.net) 06.42.10 # . 06.42.53 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-zzmofwwvlikygwyn) 06.43.03 Quit webguest94 (Quit: CGI:IRC (Ping timeout)) 06.44.23 Part pupuserb7dc64 06.51.24 Quit mikroflops (Ping timeout: 240 seconds) 06.53.33 Join mikroflops [0] (~yogurt@90-224-31-157-no112.tbcn.telia.com) 07.07.27 Join stoffel [0] (~quassel@p57B4CFF4.dip.t-dialin.net) 07.19.18 Join puetzk [0] (~private@173-31-158-106.client.mchsi.com) 07.19.47 Quit S_a_i_n_t () 07.20.06 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.4.149) 07.23.13 # Is there a known issue with the recording gain on AMSv2 Sansas (specifically a Clip+). The microphone is extremely quiet, and if I turn up the gain it starts clipping long before reaching a reasonable volume. I didn't find anything obvious in Flyspray or the wiki (which said recording worked). 07.23.45 Join gurenko [0] (~538aeb9b@giant.haxx.se) 07.23.58 # hi! 07.25.59 # anyone knows if there are any news about rockbox for sansa fuze v02? 07.26.29 # Besides what's in the wiki at SansaAMS? 07.26.40 # anyone knows if there are any news about rockbox for sansa fuze v02? 07.26.47 Quit gurenko (Client Quit) 07.26.55 Join gurenko [0] (~538aeb9b@giant.haxx.se) 07.27.30 # hi! anyone knows if there are any news about rockbox for sansa fuze v02? 07.27.41 # you've asked that three times 07.27.57 # sorry 07.28.05 # but computer freeze 07.28.54 # http://www.rockbox.org/wiki/SansaAMS got updated today, so that's probably pretty good status 07.28.54 # I just put it on a Clip+, which is more or less the same hardware 07.29.54 # ok, thank you 07.30.12 # i'm going to see it 07.31.38 # I'm having a little trouble with the recorder (it's very quiet), but so far rockbox is faring better than the OF, which wants to reread tags every time it boots (and seems to hang while doing so). YMMV 07.34.16 Join katsuru [0] (~katsuru@static-87-245-59-45.teleos-web.de) 07.37.16 # Hello every1 i am trying to install rockbox on my Clip+, i am on ubuntux64 and i cannot execute mkamsboot from the terminal... 07.37.27 Join notlistening [0] (~tom@94-195-105-95.zone9.bethere.co.uk) 07.37.47 # katsuru@katsuru-desktop:~/Desktop/rbinstall$ sudo ./mkamsboot clppa.bin bootloader-clipplus.sansa pfile.bin 07.37.47 # sudo: ./mkamsboot: command not found 07.37.53 # any help please 07.38.13 # katsuru: did you make mkamsboot yet? 07.38.13 # are you in the directory where you downloaded it? 07.38.21 # yeah i am 07.38.26 # rbinstall in desktop 07.38.39 # is the file marked executable? (chmod a+x mkamsboot if not) 07.39.07 # puetzk, worked 07.39.09 # thank you ;) 07.40.19 # puetzk, on the website they say i gotta paste the output file on the root of my device... by that they mean on the SDcard right? 07.40.40 # No, the device itself should go to mass storage mode and mount as a filesystem 07.40.54 # the expansion card is separate, and I don't think it will firmware update from that 07.41.16 # mine called itself "SANSA CLIPP" as the volume label 07.41.25 # so is mine 07.41.46 # but that's the internal flash, not the uSD card 07.41.53 # (if you have one in) 07.42.17 # ohhh damn right... mine doesn't even have a card.... i am sorry man 07.42.27 # i am just used to have my 2Gb one connected to the PC 07.42.35 Quit gurenko (Quit: CGI:IRC) 07.46.32 Quit notlistening (Ping timeout: 264 seconds) 07.48.00 # I just tried in the OF, and recordings have a normal volume there 07.52.37 *** Saving seen data "./dancer.seen" 07.53.16 Join puetzk_ [0] (~private@173-31-158-106.client.mchsi.com) 07.54.30 # so the quiet recordings to appear to be something rockbox is setting up differently 07.54.44 Quit puetzk (Disconnected by services) 07.54.44 Nick puetzk_ is now known as puetzk (~private@173-31-158-106.client.mchsi.com) 08.02.02 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 08.03.05 Quit stoffel (Remote host closed the connection) 08.06.01 Quit puetzk (Remote host closed the connection) 08.06.08 Join puetzk [0] (~private@173-31-158-106.client.mchsi.com) 08.06.48 Quit puetzk (Client Quit) 08.19.53 Quit kramer3d (Read error: Connection reset by peer) 08.21.30 Join Szpila [0] (~sszpila@212.244.249.187) 08.21.30 Join ender` [0] (krneki@foo.eternallybored.org) 08.29.55 Join LinusN [0] (~linus@rockbox/developer/LinusN) 08.33.07 Join mitk [0] (~mitk@195.117.162.130) 08.38.34 Join simon [0] (~simon@vishnu.gjk.dk) 08.39.17 # hiya. I've got an iPod Nano that won't be patched with rockbox because its filesystem partition is apparently empty. 08.40.38 # simon: A first generation Nano? 08.41.28 # oh darn, it turns out this iPod is called an iPod shuffle and rockbox doesn't even seem to support it. :-) 08.42.04 # No, it doesn't. It's completely different hardware to the ipods Rockbox does run on. 08.48.52 Join flydutch [0] (~flydutch@host138-162-dynamic.14-87-r.retail.telecomitalia.it) 08.59.17 Join gurenko [0] (~538aeb9b@giant.haxx.se) 09.10.28 Quit gurenko (Quit: CGI:IRC) 09.12.48 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 09.14.16 Join watto [0] (~watto@193.203.81.165) 09.15.48 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 09.18.32 Join DerPapst [0] (~Alexander@dslb-088-069-139-013.pools.arcor-ip.net) 09.26.48 Quit markun (Ping timeout: 276 seconds) 09.27.18 # Torne: I doubt my iPod would be a good testing candidate. Afaik there are 2 different display types. The motherboard of my original 3G iPod broke and i replaced it with a mobo from a defunct iPod i bought of ebay. However, the replaced mobo is for the other display type and now the contrast is always way to high. If i boot the original firmware the display is barely readable because it's too dark. 09.27.20 # So i probably would have to change the default contrast settings anyway before compiling to make sure any bootloader messages are readable. And my lowest contrast value would be way below those 3G iPods with a matching display + controller. 09.35.20 # Torne: but i can test the behaviour of the bootloader though. I assume the code is already in svn? 09.35.45 Join petur [0] (~petur@rockbox/developer/petur) 09.38.48 # hmm... i'll think i even install rb + bootloader in OSOS ;) 09.40.17 # whee... my build is way outdated... 100130 :D 09.43.08 Join funman [0] (~fun@rockbox/developer/funman) 09.45.22 # anyone here that worked on the iriver h300 port? 09.46.58 # kenguest: it works better if you ask your question instead... 09.47.03 Join markun [0] (~markun@rockbox/developer/markun) 09.52.39 *** Saving seen data "./dancer.seen" 09.52.54 # B4gder: it was going to be more of a statement than a question ;-) I owe at least one person a drink for making using my h340 bearable! 09.53.08 # hehe 09.53.34 # lots of Rockbox devs hang out here, and a bunch of them/us are involved in the h3xx series too 09.53.49 # beer for everyone! 09.55.17 # i've got some nice tree conflicts.. where is uisimulator/sdl/button.c now? 09.55.48 # nvm. found it ;) 09.58.35 Join swilde [0] (~wilde@aktaia.intevation.org) 10.03.01 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.03.40 Quit polobricolo (Ping timeout: 260 seconds) 10.11.04 Quit n17ikh (Ping timeout: 265 seconds) 10.14.45 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 10.15.07 Join kugel [0] (~kugel@rockbox/developer/kugel) 10.17.38 Join hebz0rl [0] (~hebz0rl@dslb-088-065-209-066.pools.arcor-ip.net) 10.21.41 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 10.21.45 # the as3531 datasheet mentions a vectored interrupt controller with 32 vectored interrupts, so i thought it might be a PL192, but the OF uses a register not present in the pl192 10.22.07 # not that we'll need more than 16 interrupts anyway 10.27.52 # funman: saw my scrollwheel patch? 10.28.05 # yes but didn't test yet 10.28.11 # funman: is rebooting to the OF on the clip+ supposed to work ? 10.28.32 # pamaury: yes if you have patched with a recent mkamsboot 10.28.33 # from what I can tell it works really well now, played a bit around (in bubbles) on my trip to the uni 10.29.15 # kugel: there is another patch on FS, did you see it ? 10.31.13 # no, but now. that one should work better but I think it doesn't necessarily detect overflows 10.31.34 # v doesn't have a reliable value if the overflow occured 10.32.01 # if(time < last_wheel_post) should be enough to detect it ? 10.33.03 # it could be > as well, the top bits are cut off but that doesn't always mean that time smaller than last_wheel_post, no? 10.33.40 # but maybe it's good enough 10.33.42 # it works fine (didn't test 23 minutes ;) ) 10.33.53 # New commit by 03pamaury (r26157): as3525v2: add partial usb init code 10.34.07 # hm test_disk stops when writing the last bits to storage 10.35.22 Quit TheSeven (Ping timeout: 264 seconds) 10.35.39 # last commits in it are related to open/creat 10.36.39 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.37.56 # how could my commit add errors on a completely unrelated target ? 10.38.19 # /bin/sh: /home/robert/rb/builds/build-samsungyh920/apps/core_asmdefs.h: No such file or directory 10.38.27 # I didn't modify anything ! 10.38.29 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 10.38.47 # perhaps a missing make dependency 10.39.27 # but that would have break at the last build 10.40.23 # kugel: there should be no need to cast open_wrapper in plugin.c no ? 10.40.40 # pamaury: a lot of for() loops just for logf? 10.41.02 # that is called debugging :) 10.41.21 # will those be optimized away in a non-logf build? 10.41.25 # I hope so 10.41.27 # I think so 10.41.41 # Anyway, the driver is non functional and there will be removed at the end 10.43.02 # I suspect my init code about fifo is wrong (a night revelation) but as there are no explaination in the linux code, that will be hard to notice at this stage 10.44.37 Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) 10.44.40 # I will move more things to compile time constants at the next commit, I don't want to pollute the code by reading to registers to handle every hardware configuration whereras it will not change for a specific target 10.49.09 # test_disk freezes on close() 10.52.47 Quit Strife89 (Ping timeout: 258 seconds) 10.54.50 Join Strife89 [0] (~Strife89@adsl-80-129-208.mcn.bellsouth.net) 10.55.17 # (fuzev1, write & verify, closing after writing succeeded) 11.01.00 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 11.02.19 # kugel: shouldn't HAVE_PLUGIN_CHECK_OPEN_CLOSE be defined only for sim ? 11.03.14 # dunno, gevaerts ? 11.03.20 # or pamaury ? 11.03.25 Part blairb 11.03.48 # anyway the close wrapper looks ok 11.03.50 # why ? 11.04.14 # it freezes even with it undefined 11.04.19 # ah no it worked! 11.04.22 # funman: why? we could disable it for the release, but what's the advantage of sim-only? 11.04.44 # dunno, just thinking logf isn't enabled on non-sim builds 11.05.44 # hmm I probably know what the problem with keyreading on HD200 is - lm339 has response time at best 300ns which coresponds to 3.33 MHz sampling rate. This means that I have to set adc divider to 6.75 or more (8 is the closest possible) for 45 MHz cpu clock and 18.61 (32 is the closest possible) for 124 MHz. I was too optimistic when selecting divider 11.05.53 # funman: it doesn't only logf 11.07.24 # hm with a reduced test size test_disk works fine 11.07.34 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 11.11.51 Part blairb 11.12.22 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 11.12.28 Part blairb 11.14.38 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 11.15.34 Quit blairb (Client Quit) 11.16.54 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 11.18.57 Quit blairb (Client Quit) 11.19.18 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 11.19.31 # http://pastie.org/967313 <- a setting on as3543, what is this threshold, how much the current drawn by the battery is reduced when reaching end of charge ? 11.21.35 Quit phanboy_iv (Ping timeout: 240 seconds) 11.22.09 # I suppose so, if your charging current is set to 200mA and the threshold to 10%, then you will get the interrupt when the current has dropped to 20mA mode. 11.22.18 # -mode 11.22.20 # * n1s batterybenches beast with rev 26153 11.22.34 # to, or by ? 11.23.17 # hm test_disk works fine on fuzev2 :'( 11.23.22 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.23.51 # DerPapst: ah, right, i guess that does make your contrast probably irrelevant to everyone else ;) 11.27.29 # clip+ seems to charge at 3.9V/50mA 11.27.59 # with 4.2V charging voltage i don't have end of charge itnerrupt 11.29.24 # New commit by 03wodz (r26158): HD200 - lm339 response time is at best 300 ns so adcclk can not be too high 11.29.55 Quit linuxstb (Ping timeout: 252 seconds) 11.30.27 # Torne: guess so :P 11.31.51 # I'm not sure actually 11.32.04 # Doesn't the OF just guess the wrong one of the same two choices? 11.32.13 # ah no, with this low voltage i get continuous end of charge 11.36.13 Join Evilnick_ [0] (~Evilnick@ool-457bccf5.dyn.optonline.net) 11.37.26 Quit blairb (Quit: Ex-Chat) 11.38.47 Quit evilnick (Ping timeout: 240 seconds) 11.39.27 # 3.9V/50mA this is rather unusual - You mean 50mA at CC phase and 3.9V at CV phase? 11.39.38 # 4.15V/100mA seems to work 11.39.43 # i don't know what i mean 11.40.03 # funman: lol 11.40.13 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 11.41.49 Quit jfc (Read error: Connection reset by peer) 11.42.10 # just trying different settings for the clips to both charge, and detect end of charge correctly 11.42.24 # afaiu, the current drawn can be arbitrary 11.42.32 # just not too high to not melt the wires 11.42.43 # funman: didn't you have some problems with charging in the OF? I have them as well now. 11.42.58 # markun: yes on clipv1, but i left it plugged and it eventually took off 11.43.08 # currently discharging it completely to try again 11.43.11 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 11.43.18 Join jfc [0] (~john@dpc6682208002.direcpc.com) 11.43.37 # wodz: the charger voltage should not be too much higher than the battery voltage ? 11.43.52 # funman: generally no 11.44.05 # I men for li-ion and lipo batteries 11.44.14 # s/men/mean/ 11.44.40 # funman: mine issue is probably unrelated then. Plugging in USB while holding 'select' crashed rockbox, so I rebooted into the OF and left it connected at night. The next morning I assumed it would be full, but still showed it was charging and rockbox told me it was at 30%.. 11.45.17 # funman: typical limit is about 4.3V and because of this most charger circuits sets upper limit to 4.2 to be on the safe side 11.46.39 # if i set it to 4.15V and not 4.2V then end of charge is detected immediately on clip+ (battery 100%) 11.47.34 # funman: when speaking about current drawn You are not quite right - You cannot set it too high because battery will heat up and eventually protection circuit (integrated with every li-ion/lipo) will cut off 11.47.58 # ah thanks 11.48.50 # and if You set current way too high - smoke and fire may come into action :-) 11.48.56 # :p 11.49.18 # i can understand current but voltage is still mysterious to me 11.49.59 Join mikroflops_ [0] (~yogurt@90-224-31-157-no112.tbcn.telia.com) 11.50.17 # standard setting for charging li batteries is C/10 which means take capacity in mAh/10 = charge current in mA 11.50.51 # we use higher values on sansas (don't know where these charging current come from btw) 11.51.19 # but from the other hand good lipo can withstand 3-5C charging 11.52.25 # if i set charger voltage to 4.15V, is it normal if the battery has a higher voltage? 11.52.40 *** Saving seen data "./dancer.seen" 11.52.46 # can You elaborate? 11.53.21 Quit blairb (Remote host closed the connection) 11.53.23 # i set 'maximum charger voltage' to 4.15V in as3543 registers, and reading battery voltage when charging shows 4.16 11.54.05 # that is ok - it comes probably from scalling adc readout 11.54.11 Quit mikroflops (Ping timeout: 276 seconds) 11.54.49 # hm indeed now the battery voltage is flat, but still charging 11.55.10 # funman, thats ok also - You reached CV phase 11.56.18 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 12.00.03 Quit mikroflops_ (Ping timeout: 240 seconds) 12.00.29 # can I lock a semaphore in thread A and and release it in thread B (with the intention that thread A waits if it tries to lock the semaphore again before B released it)? 12.03.26 # what is default procedure to calibrate percent_to_volt_charge[] ? 12.03.53 Join blairb_ [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 12.04.00 Quit blairb_ (Remote host closed the connection) 12.04.14 # btw it only makes sense in CC phase of charging 12.04.18 Join Forsaken_Boy [0] (~chatzilla@24.138.199.192) 12.04.32 Quit blairb (Quit: Ex-Chat) 12.04.32 # wodz: battery bench 12.04.53 # battery bench during charging and no playback? 12.05.03 # yea, why not? 12.05.10 # just asking 12.05.11 # wodz: that's what i did 12.05.39 # i don't get what's so special with this close(bigfile) on fuze, writing the 300MB prior to closing succeeded 12.06.44 # maybe it's related to the lot freezes I see on it recently 12.06.51 Quit bieber (Ping timeout: 260 seconds) 12.06.57 # indeed but i have a potential fix which i'm testing 12.06.57 # where recently == since 2 month or so 12.07.06 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 12.07.36 # give a lower priority to audio interrupts -> move down the list of vectored interrupts 12.07.46 # pictureflow/database work fine but i wanted to confirm with test_disk 12.10.28 Join tchan1 [0] (~tchan@c-69-243-144-70.hsd1.il.comcast.net) 12.11.51 # this guy on the forum found the problems appeared when audio interrupts were added 12.12.08 Quit tchan (Ping timeout: 245 seconds) 12.12.52 Quit powell14ski__ (Ping timeout: 265 seconds) 12.13.19 Quit BlakeJohnson86 (Read error: Operation timed out) 12.15.15 # is there reliable way to determine mean frequency (% boosted) during playback? 12.15.42 # nope, test_codec is the only precise bench 12.15.51 Join powell14ski__ [0] (~powell14s@c-24-9-7-198.hsd1.co.comcast.net) 12.16.47 Join BlakeJohnson86 [0] (~bjohnson@2002:1876:a27b:0:227:13ff:fe65:1262) 12.17.02 # I was thinking about setting second timer with fixed div and read this timer value in system tick interrupt 12.17.52 # does it make sense? 12.18.25 # tick already read boosting and show it in buffering thread 12.18.32 Quit GeekShadow (Ping timeout: 260 seconds) 12.18.45 # but I heard several times it is unreliable 12.19.27 # i say that because it just see if it's boosted each tick, if we are boosting between 2 ticks it's not shown 12.20.25 # so it counts boost when it is in boosted state entering system tick interrupt? 12.23.57 # yep 12.24.02 Join mt_ [0] (~mtee@41.233.154.36) 12.24.09 # but if boosting times are typically longer than 1 tick it could work 12.24.51 # I think I try with timer approach and compare results 12.25.48 # I've updated catalan translation and i've posted the diff at FS#11293 12.26.18 Quit mt (Ping timeout: 258 seconds) 12.26.26 # I've had to manuallt edit catalan.lang, as translate.rockbox.org wouldn't save new translated strings 12.26.27 Nick mt_ is now known as mt (~mtee@41.233.154.36) 12.26.33 # wodz: i think the boostin percent works pretty well in the buffering screen, but it's too coarse to measure codec speeds 12.27.31 Join blairb [0] (~blair@121-73-216-35.broadband.telstraclear.net) 12.28.09 # Is it the right procedure? 12.28.14 Quit blairb (Client Quit) 12.28.55 # n1s: OK so if test_codec returns comparable resutls to other CFs, test_mem also and buffering screen shows way higher boost % how to narrow it down? 12.28.59 # ssorgatem_, yes 12.29.53 # wodz: that is weird indeed... 12.30.02 # ssorgatem_: also tell bluebroth3r if you have problems with the translate website 12.30.16 # funman: ok 12.30.38 # bluebroth3r: ping? 12.30.57 # n1s: lcd performance is superb with about 1000fps fullscreen updates 12.31.18 Join blairb [0] (~blair@121-73-216-35.broadband.telstraclear.net) 12.31.40 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 12.32.20 # wodz: did you measure time needed to run set_cpu_frequency ? 12.32.22 # wodz: if test_codec is as fast i'd guess something that isn't running while running test_codec but is running during normal playback sucks the rest of the cpu... 12.33.39 # funman: 1) I don't see the way to measure this 2) I can do nothing about this time it is hardware constrain and should be common to all CFs 12.34.27 # 1) boost/unboost 1000 times, measure number of ticks 12.34.31 # are you using the dma for audio? 12.34.44 # n1s: yes as all other CSs 12.34.52 # s/CSs/CFs/ 12.35.36 # funman: I don't think this will be reliable 12.36.14 Quit yawny (Ping timeout: 246 seconds) 12.37.21 Join max242 [0] (~c3cf0579@giant.haxx.se) 12.38.26 # is there an easy way to lower the priority of the audio interrupts? 12.38.43 # i'm interested and willing to test things out tonight 12.39.10 # i wonder if it will solve the pictureflow issues i see since r25299 12.41.13 # markun: http://pastie.org/967386 12.41.15 # max242: ^ 12.41.22 # i saw ranma is the author of the changes in r25299 12.41.40 # can he give us a clue what's wrong and what we can change in the code 12.41.59 # yes, i'm here for a short while during my lunch break 12.42.40 # i don't think r25299 is wrong in any way 12.43.18 # ok, no problem. Is there any place described how to work with patches? I never did that myself up to now 12.43.59 # this evening, on my personal laptop where i have the rockbox dev. environment installed, i'll give it a try 12.44.18 # http://www.rockbox.org/wiki/WorkingWithPatches 12.44.29 Join elcan [0] (user36@pr0.us) 12.44.29 # thanks! I have to go back to work now, cheers ;-) 12.45.41 Quit max242 (Quit: CGI:IRC (EOF)) 12.56.02 # jhMikeS: ping 12.57.52 # gevaerts: I got an answer on the mini2440 ml re x-server start problem 12.58.40 # What is default policy in rockbox about datasheets? Should we keep local copy or relay on some external internet source? 12.59.50 # it usually depends on whether it publicly available or not 13.00.14 Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) 13.00.16 # read: if you signed an NDA or something like that to get it 13.00.31 Quit GeekShadow (Ping timeout: 260 seconds) 13.02.19 # I have couple of public pdfs 13.05.40 Quit blairb (Quit: Leaving) 13.08.08 # ranma: does test_disk work on c200v2 ? 13.08.14 # (write & verify) 13.13.28 Join evilnick|ipad [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 13.14.15 Quit n1s (Ping timeout: 248 seconds) 13.14.57 Quit kugel (Ping timeout: 264 seconds) 13.19.04 # hm it locks on reading a sector, not on writing 13.19.08 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 13.20.09 # with a 30MB test file 13.20.23 Quit Farthen (Remote host closed the connection) 13.21.05 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 13.22.24 # 2nd try on a 30MB file: closing succeeds -> test finish and pass 13.23.01 # funman: what is your problem ? close hangs on a very big file ? 13.23.04 Quit Farthen (Remote host closed the connection) 13.23.07 # yeah 13.23.29 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 13.25.00 # do you have a clue ? Is it writing/reading something ? 13.25.11 # reading 1 sector i think 13.25.24 # not sure if the freeze is in fat/file code or in as3525 sd driver 13.26.14 Join wincent_balin [0] (~wincent@f055087255.adsl.alicedsl.de) 13.26.30 # does it happen on other devices ? 13.26.38 # not on fuzev 13.26.39 # 2 13.27.07 # then perhaps it's the sd driver but why would it happen with a big file only ? 13.28.17 Part LinusN 13.29.31 Nick Evilnick_ is now known as evilnick (~Evilnick@ool-457bccf5.dyn.optonline.net) 13.29.40 Quit evilnick (Changing host) 13.29.40 Join evilnick [0] (~Evilnick@rockbox/staff/evilnick) 13.29.40 Quit Farthen (Remote host closed the connection) 13.31.36 # it's writing in sectors 0xCxxxx, and after write finished the last SD op i see is a read of 1 sector at 0x5xxxx 13.32.14 # it hangs completely the device ? Can't you debug it to see which part hang ? 13.32.28 # well no it still works 13.32.54 # i don't know FAT at all so i don't want to look here 13.33.30 # I know fat so I can have a look if you are sure there is a problem witht he fat code :) Perhaps the sd read fails and the fat keeps trying or locks 13.34.00 # yes that's what i think 13.34.04 # or rather the read is incorrect 13.36.00 # incorrect in which sense ? 13.36.09 # perhaps the data is corrupted 13.36.20 # well now it works 13.36.25 Quit bieber (Ping timeout: 246 seconds) 13.36.38 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 13.36.47 # heisenbug? 13.37.03 # the controller should check data crc 13.39.55 # So far I got Create 23 files/s Open 50 files/s Dirscan 6225 files/s Delete 52 files/s Create(512, A): 296 KB/s 13.40.06 # Write seems to hang... 13.40.13 # ranma: not the speed, the write & verify 13.41.22 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.41.36 Quit kugel (Remote host closed the connection) 13.42.31 Quit GeekShadow (Ping timeout: 248 seconds) 13.43.13 # i'm building with http://pastie.org/967386 applied 13.44.00 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.44.34 # goddamn it works 13.45.50 # Charge monitoring is *SO* overcomplicated on MPIO. I think I fuck this at all and relay only on AC plug detection 13.46.04 Join LinusN [0] (~linus@rockbox/developer/LinusN) 13.46.09 # * funman is ok with the fucking part 13.48.45 # MPIO uses two pins OUT and IN to detect charging state. First it sets OUT high and reads IN. If IN=low device is charging in CC regime, else device reached C/10 condition. Than it sets OUT to HiZ and reads IN. If IN=low device is charging in CV regime, else timeout has occured 13.49.48 Join Jaykay [0] (~chatzilla@p5DC574A6.dip.t-dialin.net) 13.50.28 # funman: Test passed. 13.50.46 # ranma: thanks 13.50.53 # can you test database rebuild & picture flow cache? 13.51.38 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 13.51.52 # these locked with svn (i had ~2GB of mp3 split in albums, all with tags) 13.52.10 # * petur looks slightly past LinusN at his h120 13.52.41 *** Saving seen data "./dancer.seen" 13.53.43 Join esperegu [0] (~quassel@145.116.15.244) 13.53.53 # petur: the parallel port card is in the mail... 13.54.34 # :) 13.56.26 # same test without my lcd debug code at entry & exit of sd_transfer_sectors() -> lock (file system formatted prior to installing rockbox) 13.59.19 Quit B4gder (Quit: It is time to say moo) 14.00.21 Join n1s [0] (~n1s@rockbox/developer/n1s) 14.02.02 # Zagor: Could you update the web server for a main page change? Thanks 14.03.26 # mc2739: done 14.04.13 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 14.09.58 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 14.10.16 # funman: I ran "update now" from the menu, but since that runs in the background, how do I know if it's working? 14.10.22 # * ranma hasn't really used the Database... 14.10.57 # if you delete .rockbox/database_* it will be renew totally 14.11.10 # (and block until it's done) 14.11.23 # ranma: you have database status in debug menu 14.11.45 # ranma: I always wondered that myself, I'm not sure there is a cue for when "update now" completes :/ 14.11.52 # New commit by 03funman (r26159): sd-as3525: give timeout in HZ units, not in ticks ... 14.11.57 # New commit by 03funman (r26160): as3525: reorder vectored interrupts ... 14.12.02 # New commit by 03funman (r26161): sd-as3525: avoid division when calculating current bank, we only deal with 1 or 2 banks 14.14.44 Quit TheSeven (Ping timeout: 276 seconds) 14.16.09 # still locks on fuze :o 14.19.07 # Ok, it says 'Initialized: Yes' and 'Progress: -1% (398 entries)', so I guess that worked too. 14.19.18 # ranma, S_a_i_n_t: I always look at the disk indicator of the statusbar 14.20.38 Join katsuru_ [0] (~katsuru@static-87-245-30-229.teleos-web.de) 14.24.22 Quit katsuru (Ping timeout: 258 seconds) 14.28.10 Join Schmogel [0] (~Miranda@p3EE22B08.dip0.t-ipconnect.de) 14.31.35 Join merbzt [0] (~benlar@193.13.246.198) 14.42.24 # kugel: sir? 14.42.44 # jhMikeS: saw my question about semaphores earlier today? 14.43.05 # kugel: nope, haven't been paying attention here 14.43.29 # jhMikeS: can I lock a semaphore in thread A and and release it in thread B (with the intention that thread A waits if it tries to lock the semaphore again before B released it)? 14.43.50 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 14.43.56 # that's fine. sems aren't owned like mutexes. really, they're just counted. 14.44.21 # ok, there goes my suspicion why my code doesn't work :\ 14.44.25 # if it didn't work, dual core mp3 and spc wouldn't work very well 14.45.14 # are you talking about rockbox object? can't necessarily speak for other implementation, though they wouldn't be semantically correct i suppose 14.45.25 # yea I do 14.46.30 # http://pastie.org/967500 is my code, I would like to make lcd updates asynchronous (because they're slow) on as3525(v2) 14.46.43 # oops 14.47.30 # here it is: http://pastie.org/967506 14.48.33 # kugel: asynchronous lcd might be useful on RaaA too I think. I still suspect SDL screen updates for the stuttering on my n900 14.50.37 # gevaerts: I think it could easily done for all lcd drivers too, but most are fast enough so that it doesn't matter 14.51.01 # kugel: wouldn't that cause artifacts if something starts drawing while the update is happening? 14.51.23 # jhMikeS: that's what the semaphore is supposed to prevent 14.51.49 # so then you slow it down elsewhere while it waits anyway? :) 14.52.29 # * jhMikeS 'll look at the pastie before saying more 14.53.41 # That's when you add double buffering I guess 14.54.07 # jhMikeS: no, the main benefit would be letting the other threads run while the lcd thread waits for the fifo to empty before it feeds new data 14.54.37 # I think it wouldn't slow down anything, the worst that can happen is nothing is improved 14.55.00 # kugel: yea, that's why I'm looking. I'm not too familiar with that hardware. 14.57.02 # the patch looks like it's off from the source tree I have. was there a commit that changed dbop? 14.57.17 # it's against current svn 14.57.28 # r26138 14.58.46 # * jhMikeS is a few revisions behind 14.59.51 # firmware/target/arm/as3525/dbop-as3525.c exists for a long time now :) 15.00.28 # yeah, bit I see no queues, sems, mutexes or any such thing while they're clearly already there in the patch 15.00.48 # the patch adds them 15.02.42 Quit antil33t (Read error: Connection reset by peer) 15.02.48 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 15.03.59 # hm i think i detect end of charge OK on clip+ now 15.04.06 # * jhMikeS notices not all have a "+" next to them. 15.04.40 # jhMikeS: are you looking at the first or second paste? 15.04.57 # ignore the first one 15.05.23 # ah...hahaha...I got on the first one, not the second. :P 15.10.43 # on as3543 no need to clear the interrupt on plugging, perhaps they have a better detection 15.11.39 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 15.11.50 Quit liar (Remote host closed the connection) 15.12.28 # now I'm getting failed hunks :\ 15.12.41 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 15.13.18 # jhMikeS: you need -p1 15.13.36 Part Zagor 15.13.46 # oh uh, the SOURCES and system-as3525.c might fail 15.14.40 # remove it? 15.14.50 # it is system 15.15.14 # hmmm...looks important 15.15.20 # I think you can ignore the hunk if you don't want to run the code 15.15.44 # that should be fine 15.23.23 *** Started Dancer V4.16 15.23.23 *** Connected to irc.freenode.net on port 6667 15.23.23 *** Logfile for #rockbox started 15.23.24 Mode "logbot :+i" by logbot 15.23.25 Ctcp Version from frigg!~frigg@freenode/utility-bot/frigg 15.23.25 *** Server message 501: 'logbot :Unknown MODE flag' 15.23.25 Join logbot [0] (~rockbox@giant.haxx.se) 15.23.25 Join komputes [0] (~komputes@ubuntu/member/komputes) 15.23.25 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 15.23.25 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 15.23.25 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 15.23.25 Join merbzt [0] (~benlar@193.13.246.198) 15.23.25 Join Schmogel [0] (~Miranda@p3EE22B08.dip0.t-ipconnect.de) 15.23.25 Join katsuru_ [0] (~katsuru@static-87-245-30-229.teleos-web.de) 15.23.25 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 15.23.25 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 15.23.25 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.23.25 Join esperegu [0] (~quassel@145.116.15.244) 15.23.25 Join Jaykay [0] (~chatzilla@p5DC574A6.dip.t-dialin.net) 15.23.25 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.23.25 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 15.23.25 Join wincent_balin [0] (~wincent@f055087255.adsl.alicedsl.de) 15.23.25 Join evilnick|ipad [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 15.23.25 Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) 15.23.25 Join elcan [0] (user36@pr0.us) 15.23.25 Join mt [0] (~mtee@41.233.154.36) 15.23.25 Join BlakeJohnson86 [0] (~bjohnson@2002:1876:a27b:0:227:13ff:fe65:1262) 15.23.25 Join powell14ski__ [0] (~powell14s@c-24-9-7-198.hsd1.co.comcast.net) 15.23.25 Join tchan1 [0] (~tchan@c-69-243-144-70.hsd1.il.comcast.net) 15.23.25 Join Forsaken_Boy [0] (~chatzilla@24.138.199.192) 15.23.25 Join jfc [0] (~john@dpc6682208002.direcpc.com) 15.23.25 Join evilnick [0] (~Evilnick@rockbox/staff/evilnick) 15.23.25 Join dfkt [0] (dfkt@unaffiliated/dfkt) 15.23.25 Join Strife89 [0] (~Strife89@adsl-80-129-208.mcn.bellsouth.net) 15.23.25 Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) 15.23.25 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 15.23.25 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 15.23.25 Join hebz0rl [0] (~hebz0rl@dslb-088-065-209-066.pools.arcor-ip.net) 15.23.25 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 15.23.25 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 15.23.25 Join swilde [0] (~wilde@aktaia.intevation.org) 15.23.25 Join markun [0] (~markun@rockbox/developer/markun) 15.23.25 Join funman [0] (~fun@rockbox/developer/funman) 15.23.25 Join petur [0] (~petur@rockbox/developer/petur) 15.23.25 Join DerPapst [0] (~Alexander@dslb-088-069-139-013.pools.arcor-ip.net) 15.23.25 Join watto [0] (~watto@193.203.81.165) 15.23.25 Join flydutch [0] (~flydutch@host138-162-dynamic.14-87-r.retail.telecomitalia.it) 15.23.25 Join simon [0] (~simon@vishnu.gjk.dk) 15.23.25 Join mitk [0] (~mitk@195.117.162.130) 15.23.25 Join ender` [0] (krneki@foo.eternallybored.org) 15.23.25 Join Szpila [0] (~sszpila@212.244.249.187) 15.23.25 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.4.149) 15.23.25 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-zzmofwwvlikygwyn) 15.23.25 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 15.23.25 Join cdb [0] (~cdb@206-248-134-203.dsl.teksavvy.com) 15.23.25 Join CGL [0] (~CGL@190.207.171.217) 15.23.25 Join amiconn [0] (quassel@rockbox/developer/amiconn) 15.23.25 Join pixelma [0] (quassel@rockbox/staff/pixelma) 15.23.25 Join ischeria1 [0] (~ischeriad@p5B0A08F8.dip0.t-ipconnect.de) 15.23.25 Join MagusG [0] (magusg@c-76-97-148-35.hsd1.ga.comcast.net) 15.23.25 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 15.23.25 Join Rob2222 [0] (~Miranda@p4FDCA421.dip.t-dialin.net) 15.23.25 Join solexx [0] (~jrschulz@e176105210.adsl.alicedsl.de) 15.23.25 Join Battousai [0] (~bryan@gentoo/developer/battousai) 15.23.25 Join nimak [0] (~nima@adsl-75-45-243-71.dsl.sfldmi.sbcglobal.net) 15.23.25 Join AlexP [0] (~ap@rockbox/staff/AlexP) 15.23.25 Join Kitar|st [0] (Kitar_st@89.143.110.127) 15.23.25 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 15.23.25 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 15.23.25 Join ved [0] (ved@ddsbox.co.cc) 15.23.25 Join togetic [0] (~togetic@unaffiliated/ibuffy) 15.23.25 Join YPSY [0] (~ypsy@geekpadawan.de) 15.23.25 Join Kohlrabi [0] (~Kohlrabi@frustum.nosebud.de) 15.23.25 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 15.23.25 Join Tuplis [0] (~jani@adsl-77-109-221-158.kymp.net) 15.23.25 Join kenguest [0] (~radagast@78.153.202.217) 15.23.25 Join rvvs89 [0] (ivo@bright-snat.ucc.asn.au) 15.23.25 Join krazykit [0] (~kkit@70.236.74.71) 15.23.25 Join linuxguy3 [0] (~timj@adsl-75-57-191-181.dsl.emhril.sbcglobal.net) 15.23.25 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 15.23.25 Join Guest55923 [0] (jljhook@irkki.fi) 15.23.25 Join MuscleNerd [0] (eric@adsl-75-16-51-17.dsl.irvnca.sbcglobal.net) 15.23.25 Join scorche [0] (~scorche@rockbox/administrator/scorche) 15.23.25 Join Zambezi [0] (Zulu@unaffiliated/zambezi) 15.23.25 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe10fb00-173.dhcp.inet.fi) 15.23.25 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 15.23.25 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 15.23.25 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 15.23.25 Join Barahir_ [0] (~jonathan@frnk-590ff441.pool.mediaWays.net) 15.23.25 Join ssorgatem_ [0] (~ssorgatem@229.Red-88-15-212.dynamicIP.rima-tde.net) 15.23.25 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 15.23.25 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 15.23.25 Join Curtman [0] (~curt@S010600248c269238.wp.shawcable.net) 15.23.25 Join slck [0] (Venci@Slackware.SlackPix.Com) 15.23.25 Join topik [0] (awesome@wtf.grmpf.org) 15.23.25 Join @ChanServ [0] (ChanServ@services.) 15.23.25 Join ThomasAH [0] (~thomas@aktaia.intevation.org) 15.23.25 Join fxb [0] (~felixbrun@h1252615.stratoserver.net) 15.23.25 Join dionoea [0] (~dionoea@videolan/developer/dionoea) 15.23.25 Join Hadaka [0] (~naked@naked.iki.fi) 15.23.25 Join Kamyk_ [0] (kamyk@szluug.org) 15.23.25 Join Utchybann [0] (~Utchy@rps6752.ovh.net) 15.23.25 Join daurnimator [0] (daurnimato@freenode/staff/daurnimator) 15.23.25 Join stavrob [0] (~sam@78-105-125-218.zone3.bethere.co.uk) 15.23.25 Join sharp [0] (~sharp@sauropod.org) 15.23.25 Join blithe [0] (~blithe@72.14.176.144) 15.23.25 Join CIA-5 [0] (cia@208.69.182.149) 15.23.25 Join maraz [0] (maraz@kapsi.fi) 15.23.25 Join aevin [0] (eivindsy@unaffiliated/aevin) 15.23.25 Join tmzt [0] (~ircuser@99-157-224-139.lightspeed.bcvloh.sbcglobal.net) 15.23.25 Join simabeis [0] (~simabeis@lobmenschen.de) 15.23.25 Join avacore [0] (nobody@1008ds1-rdo.0.fullrate.dk) 15.23.25 Join kadoban [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 15.23.25 Join bug2000 [0] (~bug@unaffiliated/bug2000) 15.23.25 Join FOAD [0] (~dok@83.160.60.104) 15.23.25 Join Guest951 [0] (~mapi@KHP222006067242.ppp-bb.dion.ne.jp) 15.23.25 Join pjm0616 [0] (~user@61.250.113.98) 15.23.25 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 15.23.25 Join cYmen [0] (~cymen@squint.a-oben.org) 15.23.25 Join wombat23 [0] (~beuteltie@adsl-99-39-2-249.dsl.pltn13.sbcglobal.net) 15.23.25 Join bzed [0] (~bzed@devel.recluse.de) 15.23.25 Join jae [0] (~jae@jaerhard.com) 15.23.25 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 15.23.25 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 15.23.25 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 15.23.25 Join Torne [0] (torne@rockbox/developer/Torne) 15.23.25 Join soap [0] (~soap@rockbox/staff/soap) 15.23.25 Join Topy44 [0] (~topy@my.fastsh.it) 15.23.25 Join whydoubt [0] (~whydoubt@ip68-12-76-9.ok.ok.cox.net) 15.23.25 Join lostlogic [0] (~lostlogic@rockbox/developer/lostlogic) 15.23.25 Join parafin [0] (parafin@paraf.in) 15.23.25 Join xavieran [0] (~xavieran@ppp118-209-181-25.lns20.mel6.internode.on.net) 15.23.25 Join rhodan [0] (~Quassel@2001:1608:12:2::38) 15.23.25 Join sevard [0] (sev@216.164.6.24) 15.23.25 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 15.23.25 Join kisak [0] (~kisak@c-98-235-209-218.hsd1.pa.comcast.net) 15.23.25 Join rasher [0] (~rasher@rockbox/developer/rasher) 15.23.25 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 15.23.25 Join Bagder [0] (~daniel@rockbox/developer/bagder) 15.23.25 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 15.23.26 Join Beta2K [0] (~Beta2K@d24-36-126-101.home1.cgocable.net) 15.23.26 Join bluefoxx [0] (~FuzzyLomb@S0106000347a5e69e.vs.shawcable.net) 15.23.26 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 15.23.26 Join ranma [0] (ranma@mx.tdiedrich.de) 15.23.26 Join detaos [0] (~quassel@ip72-218-104-242.hr.hr.cox.net) 15.23.26 Join BeFalou [0] (~mamutoi@unaffiliated/befalou) 15.23.26 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 15.23.26 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) 15.23.30 # Connection refused: Can't connect to host 'svn.rockbox.org' 15.23.41 # kugel: wouldn't one thread lock the sem, leave it locked and then the thread would lock the sem again? 15.23.53 Join teru [0] (~teru@ZF151152.ppp.dion.ne.jp) 15.24.02 # test_disk works fine if i disable sd_enable() 15.24.17 # jhMikeS: it should wait when it tries to lock it a second time 15.24.20 # nvm, thought I saw another lock in there :( 15.24.20 # New commit by 03wodz (r26162): Add charging/discharging indication to battery debug menu if CONFIG_CHARGING >= CHARGING_MONITOR 15.24.22 # or add a delay before disabling it at exit of transfer 15.22.46 # aa ok, temporary problem 15.23.17 # kugel: oh, no I did spot something :) dbop_write_data. what is supposed to happen? 15.24.20 # in svn it does the transfer, after the patch it should poke the lcd thread to start the transfer 15.25.47 Join Locke_Fireclaw [0] (~Locke_Fir@host81-155-174-43.range81-155.btcentralplus.com) 15.26.00 Part Locke_Fireclaw 15.26.10 # dbop_write_data_ex (called by thread) calls dbop_write_data which calls semaphore_wait. what if another thread locked it already? dbop_write_data gets called externally? 15.26.30 # ah yes, I fixed that one already without success 15.27.52 # so, you get an int for the TXFIFO empty? 15.28.05 # almost empty, yes 15.28.28 # I'd fill the data in the INT handler, not on-thread to be honest. 15.29.47 # when starting, prefill and then keep filling from the ISR 15.29.48 # that could work but it's not the cause of the problem is it? 15.30.02 # not sure, and it would sure be easier to see 15.30.20 # you said you fixed the deadlock possibility? 15.30.25 # yep 15.30.43 # when I boot rockbox I get a white screen (and apparently a panic because a button press reboots immediately) 15.31.23 # wodz: svn is slow here too 15.31.58 # what is the frequency of battery graph update in debug->battery? 15.32.15 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 15.32.16 # kugel: perhaps the correct int enables aren't being observed? 15.32.39 # it looks like it could be 100% interrupt based to keep the fifos going, no thread, no anything else really. 15.33.05 # from 3rd screen I judge it should be 1 per minute but in reality it is more like 1/few minutes 15.33.11 Join LinusN [0] (~linus@rockbox/developer/LinusN) 15.35.57 # jhMikeS: I still need the semaphore to prevent artifacts. I guess I can also release it from the isr? 15.36.47 # kugel: why? 15.36.48 # hm, it might be tricky if thread_switch() is called from an isr 15.36.57 # kugel: you can't do taht 15.37.13 # that would effectively cause preemption 15.37.39 # I would like the thread which wants the update to continue before the update finishes (hence asynchronous) 15.38.33 # the ISR would be the worker, not a thread 15.39.23 # but I cannot block out the calling thread from re-entering this way, can I? 15.39.40 # well, busy polling some variable would work but that's not really nice 15.41.16 Quit wodz (Quit: Leaving) 15.43.53 # kugel: yes, use the wakeup. wake it from the ISR when finished. wait on it at the beginnine. first thread in does the wait and it will block other threads. next wakeup lets the next thread go in. 15.44.13 # s/beginnine/beginning 15.44.37 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 15.45.00 # but what if there's no update running? there'd be no isr to signal it 15.46.33 # hmm what is the purpose of storage_enable() in firmware/usb.c::usb_slave_mode() ? 15.47.22 Quit panni_ (Ping timeout: 246 seconds) 15.49.25 # funman: I think it's because in slave mode the storage is hardware controlled (ie us-ata bridge) 15.49.40 # kugel: I don't understand? when the ISR exhausts the data, it signals it. it becomes a "not busy" signal. if you run out of data in a prefill, signal it from the thread instead. 15.49.46 # ok 15.49.48 # so usb.c disable software control and then enable it on unplug 15.49.58 # but that's juste a guess 15.50.08 # that makes sense 15.50.17 # it's the only place where it's used 15.50.31 # on as3525 we have it but it's internal to this file 15.50.35 Quit mitk (Quit: Leaving) 15.50.36 # jhMikeS: you said in wait for the signal in the beginning. if there's no update currently and no isr running then it would cause a deadlock wouldn't it? 15.51.01 # kugel: no, because it would remain signaled after the last transfer 15.51.31 # ah so you can signal first, then wait and the wait would be a no-op? 15.51.31 # funman: that's true, all other places use the more specialized {ata,mmc,}_enable() 15.51.39 # kugel: set it signaled right after creation too 15.51.56 # but how can it be internal ? When there are multi drive enable, it is define in storage.c 15.52.46 # kugel: you wait upon entering the update function, if TBOP is busy, it blocks out the thread until TBOP is done with whatever it was doing 15.53.14 # if no thread was there, it just stay signaled until something comes along and starts a new update 15.53.16 # ok, I didn't know you can signal before the wait 15.54.11 # yes, it's basically a single-count semaphore. if I just added some irq disabling in the sem code, sems could be wakeups, even multicount ones. 15.59.37 # too much differences between as3514/3515 and as3543 :/ 16.00.05 # some registers were added, some removed, some moved, some modified 16.00.24 # sometimes the bits are the same but not at the same place (they are shifted) 16.01.14 # the adc channel we read for battery is charger out, but on as3514 this one is charger in 16.01.43 Quit rvvs89 (Changing host) 16.01.43 Join rvvs89 [0] (ivo@pdpc/supporter/base/rvvs89) 16.03.40 # someone with a 100% charged fuzev2 want to test a patch? mine just takes ages to charge (the OF still shows the battery icon moving) 16.04.38 # * jhMikeS was told input fifo int weren't available and that's why the scrollwheel needs polling but the DS says otherwise 16.05.24 # * kugel doesn't see the correlation 16.05.41 # * jhMikeS was just commenting on something from long ago 16.05.55 # nevermind it just finished 16.06.10 # New commit by 03funman (r26163): as3525v2: fix end of charge detection 16.06.15 # New commit by 03funman (r26164): sd-as3525: wait 100µs before disabling SD clocks ... 16.06.21 # you cannot interrupt on bits on DBOP_DIN, which is unrelated from DBOP_DOUT 16.07.03 # kugel: ah, I guess just on pop error then 16.09.06 # anyway, looks like you should mask 'almost empty' when out of data and enable 'empty' which does signal, then remask it 16.11.46 # it looks like "almost empty" is bit 9, not bit 7 (which is 'almost full') ?? 16.12.14 # oops 16.12.23 # but well, it still worked 16.12.33 # Unhelpful: any idea with the asmdefs.h failure on roolku builds ? 16.12.45 # I enable that when it's completely full so almost full works too 16.13.07 Quit pamaury (Quit: Quitte) 16.13.16 # kugel: Two datasheets show different bits 16.13.23 # as I said the wakeup/WFI part works 16.13.55 # 1.1 shows one thing, 1.12 shows another 16.14.30 # jhMikeS: eh. the irq enable bit is bit 7, the status bit is bit 9 16.15.13 # oh, crap, I think had 3524 open, not 3524...what's going on? I read it like five time. :\ 16.15.15 # (DS version 1.13) 16.17.22 # * jhMikeS wonder just what the hell he was looking at 16.17.57 # * funman dunno about 3524 16.17.57 # funman: the preprocessor condition for INT_GPIOA in the ivt looks wrong to me 16.18.08 # jhMikeS: you need 3525 16.18.19 # frack, was looking at status reg by mistake (doing too much here) 16.18.24 # kugel: why? 16.18.47 # look at the conditions in INT_GPIOA() 16.19.12 # true 16.19.19 # the 1st one should be HOTSWAP i think 16.19.30 # also HOTSWAP makes more sense than MULTIDRIVE 16.19.34 # although* 16.19.38 # yeah 16.19.42 Part Szpila 16.19.46 # MULTIDRIVE also works with ramdisks 16.20.22 # kugel: this looks like a really easy thing that needs only a wakeup and the proper ISR. basically it's like handling audio or the serial ports. 16.20.31 Quit GeekShadow (Read error: Connection reset by peer) 16.20.39 # yes, you convinced me long ago :P 16.21.01 # kugel: http://pastie.org/967641 ? 16.21.02 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 16.21.12 # hmm no 16.21.26 # i guess it should just be ifdef SANSA_FUZEV2, not SCROLLWHEEL + AS3525v2 16.22.14 # maybe even s/CONFIG_CPU == AS3525v2/defined(INCREASED_SCROLLWHEEL_POLLING)/ 16.22.22 # err, !defined() 16.22.31 # kugel: only problem is other processor modes that might touch the display and need to write something (I suppose a mode check and simply busy write in that case) 16.22.41 # kugel: well it's not related 16.22.48 # it is 16.23.14 # how we read the wheel on fuzev2 isn't configurable 16.23.16 # INCREASED_SCROLLWHEEL_POLLING and scrollwheel interrupt are the exact opposite (and mutually exclusive) 16.24.45 # it's actually "#define INCREASED_SCROLLWHEEL_POLLING (defined(HAVE_SCROLLWHEEL) && (CONFIG_CPU == AS3525))" 16.24.47 # http://pastie.org/967641 16.25.26 Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) 16.25.34 # button_gpioa_isr() won't work on fuzev1/e200v2, and INCREASED_SCROLLWHEEL_POLLING won't work on fuzev2 16.26.13 Nick CGL is now known as [CGL] (~CGL@190.207.171.217) 16.26.22 # that's not right 16.26.34 # we did INCREASED_SCROLLWHEEL_POLLING earlier on the fuzev2 16.26.49 # ok but now it won't work 16.27.10 # you cannot activate it by simply defining it, but that's the reason it's not in config.h, it still describes the wheel mechanismk 16.27.21 Part LinusN 16.27.48 # what is read strobe? 16.29.14 # jhMikeS: bertrik may be able to explain 16.29.22 # he figured out the dbop din reading 16.30.26 # kugel: can the pop fifo be read by DMA? 16.30.43 # New commit by 03funman (r26165): better preprocessor conditions for enabling GPIOA interrupt ... 16.31.13 # kugel: i did (defined(SANSA_FUZEV2) && !defined(INCREASED_SCROLLWHEEL_POLLING)) 16.31.19 # why that? 16.31.22 Join panni_ [0] (~hannes@ip-95-222-52-93.unitymediagroup.de) 16.31.34 # I don't think defined(SANSA_FUZEV2) is needed 16.31.57 # yes 16.32.17 # it is needed: if you build for fuzev1 you don't need the gpioa interrupt regardless how scrollwheel code works 16.33.14 # it should be "#if defined(HAVE_HOTSWAP) || INCREASED_SCROLLWHEEL_POLLING 16.33.29 # INCREASED_SCROLLWHEEL_POLLING is always defined, but only true for fuzev2 16.34.00 # aah it's not a HAVE_* 16.34.19 # and defined(SANSA_FUZEV2) is still unneeded 16.34.38 # nope i don't agree: 16.34.50 # * jhMikeS wonders about using increased polling rates *only* if the wheel is turning, otherwise, cut back and the user won't notice 16.35.00 # funman: why? 16.35.07 # if you build for fuzev1 you don't need the gpioa interrupt regardless how scrollwheel code works 16.35.26 # you need it for hotswap 16.35.32 # and INCREASED_SCROLLWHEEL_POLLING is 0 for fuzev1 16.35.36 # that's why we have the HOTSWAP condition 16.35.46 # button_gpioa_isr() only exist on fuzev2 16.35.53 # you don't get it if you don't define HOTSWAP 16.36.14 # yes i will, because INCREASED_SCROLLWHEEL_POLLING will be true 16.36.39 # ah, I mean !INCREASED_SCROLLWHEEL_POLLING of course 16.37.13 # #if defined(HAVE_HOTSWAP) || \ (defined(SANSA_FUZEV2) && !INCREASED_SCROLLWHEEL_POLLING) 16.37.21 # this one is good ? 16.37.37 # (i checked that it builds this time :s ) 16.37.47 # it will work for sure, but I'm thinking the defined(SANSA_FUZEV2) is redundant 16.38.21 # redundant with !INCREASED_SCROLLWHEEL_POLLING ? 16.38.27 # yes 16.38.45 # ah wait, it's 0 for non-scrollwheel targets as well 16.38.48 # one is configurable not the other 16.39.18 # * jhMikeS wonders at what these companies will come up with just to look clever and innovative, then totally screw up the implementation 16.39.21 Quit n1s (Ping timeout: 264 seconds) 16.40.03 # build fuzev1 with HOTSWAP disabled and INCREASED_SCROLLWHEEL_POLLING disabled -> build breaks 16.40.20 # so, #if defined(HAVE_HOTSWAP) || \ defined(HAVE_SCROLLWHEEL) && !INCREASED_SCROLLWHEEL_POLLING) should be most correct 16.40.39 # it sure does 16.40.46 # then the condition is incorrect 16.40.47 # "you cannot activate it by simply defining it, but that's the reason it's not in config.h, it still describes the wheel mechanism" 16.41.02 # configurability doesn't really matter here 16.41.06 # ok then 16.41.30 # i'll keep FUZEV2 because it's more explicit 16.41.54 # it really doesn't matter because we probably won't get more targets anytime soon 16.41.58 # New commit by 03funman (r26166): fix previous commit 16.42.04 # for as3525* 16.42.06 # sansafuzev3 !! 16.42.49 # with dual HD screen & 3d wheel 16.43.45 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 16.43.56 # lol 16.45.56 # funman: 3d wheel? is that a sphere? 16.46.30 # yeah i guess 16.46.34 # * funman greps for HAVE_SCROLLSPHERE 16.46.52 # HAVE_BALLS, rather 16.46.55 # :D 16.47.23 # ah damned i have waited for the clipv1 to charge but i forgot to run battery bench 16.48.02 Quit bieber (Ping timeout: 276 seconds) 16.48.16 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 16.49.23 # i'm discharging clipv1/v2/+/fuzev2 to make charging graphs 16.49.50 # after that i think there are issues with recording, perhaps they aer fixed with interrupt priority reordering 16.50.24 # also with FM, i have different tuning in station mode if i go to a certain station from the previous one or the next one 16.51.19 # perhaps the rare µSD problems are fixed too 16.52.03 # * funman is not sure if the amsv2 will be stable for 3.6 16.52.09 # funman: did your cpu_set_frequency patch work out well? 16.52.17 # i was expecting you to test it ;) 16.52.48 # I can make me a build I guess 16.52.54 # i leave that for the end, when all the other features work ok (not sure if i will look at usb code though, i think pamaury & ranma are way more experts than me) 16.53.09 # i am not sure how multiple stores are scheduled 16.55.29 # i forgot also: there are hiss on clip+/v2 (very big on v2) 16.55.35 # very loud* 16.56.07 # jhMikeS: the isr needs to be interruptable 16.56.15 Quit funman (Quit: free(random());) 16.57.07 # I don't know if that works automagically (due to the VIC) or if I need to enable interrupts in the isr explicitely 16.58.46 # funman: looks like a deps issue? asmdefs is generated, and the deps script is *supposed* to fix up deps on core_asmdefs.h to give a full path. 16.58.47 # kugel: you need to program special prologue/epilogue for that that drops to SVN mode and enables interrupts. what about aborts and such? 16.58.59 # s/SVN/SVC 17.00.35 # * Unhelpful wonders if there's a way to look at the generated deps file for the failed build 17.00.44 Join Szpila [0] (~1@chello089074134159.chello.pl) 17.02.32 # just enabling IRQ in the ISR will corrupt SPSR if not stacked and not dropping back to SVC will corrupt LR in any nested calls because it won't be banked and the ISR doesn't necessarily restore that 17.05.05 Quit Farthen (Remote host closed the connection) 17.05.28 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 17.08.58 # jhMikeS: meh :( 17.09.27 # the lcd updates are so slow they would lock out the tick for too long I fear 17.10.56 # kugel: I was referring to other exceptions that display data like prefetch abort and such. I think filling a FIFO will be done quickly enough. 17.13.28 # hm, maybe 17.14.09 # it ~5MB/s, the fifo is 512kB big 17.15.46 # but: the button driver (from tick task) waits for the fifo to empty before reading the actual buttons so in irq would be triggered in there. will the re-fill isr executed directly after the tick tasks or or will it be dropped? 17.16.01 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 17.17.00 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.23.16 # kugel: the pending interrupt should stick until serviced and cleared 17.23.27 *** Saving seen data "./dancer.seen" 17.24.04 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 17.24.24 # * jhMikeS did a mini battery bench on the S and it seems to pull ahead a little of where the 8.5 hr bench was going 17.24.53 # at least it show it's not worse off by now :D 17.27.30 Quit lpereira (Quit: Leaving.) 17.27.49 # jhMikeS: ah, i'm running one now with r 26153 (just before your lcd power commit) to get a baseline, it's just gone on 6h10m now 17.29.09 # n1s: I hope I've not set the shutoff too high. I don't have alot of data on more recent revisions where to set it exactly. 17.29.34 # i'll post my logs when i finnish if you are interested 17.30.02 # n1s: great! I look forward. 17.30.18 # aaand, just there it died 17.30.32 # 6h12m 17.30.37 # died or shut off? 17.31.10 # dunno, i heard a HD click and the music stopped, the display wasn't on at the time 17.31.31 # I suppose the bench log will tell 17.31.43 # this was with ~200kbps vorbis 17.31.56 Join MethoS- [0] (~clemens@134.102.106.250) 17.32.56 # bootloader reported 3.648V but as soon as it started RB it shut down (this time properly at least) 17.33.32 # maybe the bootloader should refuse to start RB if it will just shut down 17.33.41 # probably 17.34.37 # if it could mange to start RB, I'm guessing it's a bit on the high side, maybe 17.35.22 # on mine, 3.6-ish meant it had about 15min left on the 8.5hr test 17.36.14 # the log says it did a proper poweroff, at 3.722V 17.36.28 Quit linuxstb (Ping timeout: 258 seconds) 17.37.57 # http://pastie.org/967791 17.39.00 # 3.772 ?? that's way too soon. it's not supposed to unless some HD activity faked it. 17.39.13 # I'll charge it up and run it with latest svn unless it gets too late 17.39.40 # that's between the 4th and 5th points on the discharge curve : 17.40.02 # it's quite possible this battery is dying 17.40.23 # not 3.772, 3.722 17.40.25 # I think I'm gonna have to compensate the voltage reading when the disk is spinning, it makes battery reading difficult 17.40.36 # gtg now 17.40.39 # later 17.43.07 Part watto 17.43.54 # New commit by 03ranma (r26167): Handshake still grinds to a halt at some point, but it works better now. 17.44.52 Join toffe82 [0] (~chatzilla@12.169.218.14) 17.47.58 # New commit by 03teru (r26168): skin_parser.c: fix possibile overflow in parse_setting_and_lang(). simplify comparison of string in parameter in parse_touchregion(). 17.56.28 # New commit by 03teru (r26169): sudoku: remove commented out code. 17.58.01 Join webguest86 [0] (~4362c802@giant.haxx.se) 18.01.11 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 18.01.43 # New commit by 03alle (r26170): Fix another not nice apostrophe (FS#11296) 18.02.59 Quit petur (Quit: collecting toys at the postoffice :)) 18.03.33 Quit webguest86 (Quit: CGI:IRC (EOF)) 18.04.02 Quit teru (Quit: Quit) 18.05.57 Join webguest57 [0] (~4362c802@giant.haxx.se) 18.06.44 # New commit by 03alle (r26171): Use nice 'times' glyphs for describing dimensions (FS#11295) 18.07.28 Quit GeekShadow (Ping timeout: 276 seconds) 18.08.37 Quit webguest57 (Client Quit) 18.12.06 Quit linuxstb (Ping timeout: 258 seconds) 18.12.44 Quit antil33t (Read error: Connection reset by peer) 18.12.50 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 18.14.55 Quit kugel (Read error: Connection reset by peer) 18.16.48 Quit n1s (Ping timeout: 246 seconds) 18.32.47 Join phanboy_iv [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 18.34.21 # New commit by 03alle (r26172): Show another way to learn about convbdf 18.39.23 Join Boldfilter [0] (~Boldfilte@adsl-71-215-115.jax.bellsouth.net) 18.51.02 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.52.45 Join Peter93 [0] (~IRC-Clien@port-92-202-124-39.dynamic.qsc.de) 18.54.08 Quit hebz0rl (Read error: Connection reset by peer) 18.58.15 Join polobricolo [0] (~polobrico@AGrenoble-257-1-21-176.w86-194.abo.wanadoo.fr) 18.59.51 Join fml [0] (~chatzilla@pD9E3C464.dip.t-dialin.net) 19.00.01 # Hi, i'm porting rockbox to a stm32 (arm cortex) device. To what should i set ARM_ARCH ? CORTEX ? C ? 19.00.20 # Hrm... How can I revert a commit? svn up -r , and then commit? 19.00.42 # also would rockbox work even though its a thumb2 only arm ? 19.00.53 # fml: no 19.01.12 # gevaerts: how then? r26171 should be reverted 19.01.22 # fml: i think you use merge (not sure) 19.01.33 Quit esperegu (Remote host closed the connection) 19.02.06 # fml: in this case I'd probably do "svn diff -c 26171 | patch -p0 -R", but svn merge would be cleaner 19.03.17 # I *think* svn merge -r 26171:26170 should do it 19.03.54 # Or svn merge -c -26171 19.04.35 # polobricolo: Currently if we build Rockbox for thumb it doens't work 19.04.47 # polobricolo: so I would guess that building for a Cortex-M is also going to have problems 19.04.51 # but who knows. 19.05.11 # Oh my arm is a Cortex-M3 19.05.15 Join DerPapst1 [0] (~Alexander@p5099d40e.dip0.t-ipconnect.de) 19.05.17 # Dont' make it CORTEX, though, that covers Cortex-A as well :) 19.05.42 # I'll define it CM3 19.05.46 # Cortex-M3 architecture is ARMv7-M 19.05.54 # what's the problem with thumb ? threads ? 19.05.55 # (Cortex-A series is ARMv7-A) 19.06.03 # gevaerts: all those commands do not work (for me) 19.06.21 # M3 is a kind of processor, not an arch, so I wouldn't suggest that.. 19.06.27 # it's a v7-M, srsly. 19.06.42 # fml: try "svn merge -c -26171 ." 19.07.07 Quit DerPapst (Ping timeout: 276 seconds) 19.07.19 # those arm version numbers are really strange.. 19.07.25 # oh i just realised that the family s different from archtecture version (eg ARM8 is an ARMv4) 19.07.35 # (http://en.wikipedia.org/wiki/ARM_architecture#ARM_cores) 19.07.41 Quit flydutch (Quit: /* empty */) 19.08.02 # gevaerts: that seemed to work. Thanks! 19.09.58 # polobricolo: ARM_ARCH is used like: "ARM_ARCH >= 5" so using CM3 would probably not work :-) 19.10.18 # New commit by 03alle (r26173): Revert r26171. Special macro for the image base name is needed. Will be committed soon. 19.10.59 # * domonoky thinks ARM_ARCH should be 7 for a Cortex cpu 19.12.02 # i've just put it to 7 19.14.18 # what is ATTRIBUTE_PRINTF ? 19.14.18 Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19.14.34 Quit DerPapst1 (Quit: Leaving.) 19.14.44 Quit fml (Ping timeout: 240 seconds) 19.16.22 # * domonoky thinks that is the special attribute from gcc for variable parameters.. 19.17.47 Join wincent [0] (~wincent@f055227177.adsl.alicedsl.de) 19.19.00 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 19.19.03 Quit wincent_balin (Ping timeout: 268 seconds) 19.20.44 Quit evilnick (Ping timeout: 240 seconds) 19.22.05 Join DataGhost [0] (~dataghost@17-18-ftth.onsnetstudenten.nl) 19.22.05 Quit DataGhost (Changing host) 19.22.05 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 19.23.31 *** Saving seen data "./dancer.seen" 19.23.36 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 19.24.40 Join GeekShado_ [0] (~Antoine@63.140.195-77.rev.gaoland.net) 19.25.00 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 19.25.16 Quit stripwax (Client Quit) 19.28.34 Quit GeekShadow (Ping timeout: 276 seconds) 19.28.46 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 19.29.20 Join notlistening [0] (~tom@94-195-105-95.zone9.bethere.co.uk) 19.29.45 Quit Peter93 (Ping timeout: 260 seconds) 19.30.41 # New commit by 03funman (r26174): as3514.c: clean up ... 19.33.31 Join esperegu [0] (~quassel@145.116.15.244) 19.33.36 Join arbingordon [0] (~w@unaffiliated/arbingordon) 19.33.39 Join _arbingordon [0] (~w@c-68-44-148-113.hsd1.pa.comcast.net) 19.34.14 # New commit by 03kugel (r26175): Revert r26060. A better fix was found. The acceleration should be fixed once for all now. 19.35.26 Quit arbingordon (Client Quit) 19.35.26 Quit _arbingordon (Client Quit) 19.37.06 Join arbingordon [0] (~w@unaffiliated/arbingordon) 19.37.09 Join _arbingordon [0] (~w@c-68-44-148-113.hsd1.pa.comcast.net) 19.38.41 Quit _arbingordon (Client Quit) 19.38.41 Quit arbingordon (Client Quit) 19.40.15 Quit evilnick|ipad (Remote host closed the connection) 19.41.21 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 19.43.10 # domonoky: 7 for cortex-m is maybe not okay though 19.43.37 # domonoky: there are instructions that don't exist in v7-m 19.44.03 # it's not really part of the same architecture series at all, just related 19.50.14 Quit linuxstb (Ping timeout: 258 seconds) 19.51.26 Join baptiste [0] (~chatzilla@vir91-12-78-231-137-156.fbx.proxad.net) 19.52.30 Join DerPapst [0] (~Alexander@p4FE8F8CE.dip.t-dialin.net) 19.56.49 # New commit by 03funman (r26176): as3525: don't use IRAM for usb, and avoid usb storage using uncached addresses behind our back ... 19.58.16 Join arbingordon [0] (~q@unaffiliated/arbingordon) 19.58.16 Join arbingordon_ [0] (~q@c-68-44-148-113.hsd1.pa.comcast.net) 19.58.58 Quit arbingordon_ (Client Quit) 19.58.59 Quit arbingordon (Client Quit) 19.59.03 Quit Kitar|st (Ping timeout: 258 seconds) 20.03.33 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 20.03.51 Join Kitar|st [0] (Kitar_st@89.143.110.127) 20.04.34 Join funman [0] (~fun@rockbox/developer/funman) 20.04.55 # sorry i hadn't seen the size of ALLOCATE_BUFFER_SIZE :/ 20.05.31 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 20.08.22 Join petur [0] (~petur@rockbox/developer/petur) 20.08.36 # New commit by 03funman (r26177): revert part of r26176 to avoid large static allocation ... 20.09.03 Join panni__ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 20.11.45 Quit panni_ (Ping timeout: 260 seconds) 20.12.45 Join perfectdrug [0] (~marko@p5B0ECE09.dip.t-dialin.net) 20.12.45 Quit perfectdrug (Client Quit) 20.13.08 # New commit by 03funman (r26178): as3525: hide our UNCACHED_ADDR from usb_storage.c 20.13.14 Quit Forsaken_Boy (Ping timeout: 258 seconds) 20.15.40 # pixelma: on c200/e200, FM has the same volume when recording or not? 20.15.48 Join krabador [0] (~ubuntu@host158-217-dynamic.117-80-r.retail.telecomitalia.it) 20.16.02 # on clip the volume is louder when not recording 20.19.56 # hm not only, when using passthrough the sound is different 20.21.15 # I never recorded from radio on any swcodec target, would need to check 20.25.03 # no need to record, just entering the record menu from FM playback should activate passthrough 20.27.02 Quit baptiste (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20100106054534]) 20.28.33 # it's quieter on the c200 too 20.30.07 # and also seems to sound differently (less heights I think) not entirely sure if this is only in my mind though because it's quieter 20.31.48 Join ssorgatem__ [0] (~ssorgatem@83.43.130.93) 20.33.10 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 20.33.32 Join ssorgatem [0] (~ssorgatem@229.Red-88-15-212.dynamicIP.rima-tde.net) 20.34.14 Quit ssorgatem_ (Read error: Connection reset by peer) 20.35.54 # * polobricolo just discovered ARMv7 is completely different from other arms and hates it. 20.36.11 # ARMv7-M is completely different, yes 20.36.24 # ARMv7-A is not 20.37.32 Quit ssorgatem__ (Ping timeout: 264 seconds) 20.39.16 # CPSR doesn't even exist. APSR replaces it but it has a different format :( 20.41.15 # This is going to be REALLY hard to port to rockbox (if i ever manage to port it) 20.42.00 # yeah, for the most part i would say you probably *don't* want to treat it as being an ARM device 20.42.17 # ARM_ARCH == 7 will cause major problems because lots of ARMv7-A instructions don't exist on M3 20.42.24 # ssorgatem: pong 20.42.51 # ssorgatem: for problems with the translation page ping rasher. He created that page, I just pointed to it :) 20.42.53 # Probably. I think i'm going to create a new ARMv7-M cpu .... 20.42.58 # I imagine it is excruciating to adapt hardware to fit the software 20.43.03 # or add lots of defines 20.43.50 # gevaerts: any idea why you made TCC targets use a static buffer for USB ? r18703 commit log just mentions reorganisation 20.44.18 # did I? 20.44.26 # you did! 20.45.25 # pixelma, funman: No surprise that fm recording sounds different on e200/c200 - it can't record at 44.1kHz sample rate, only at 22.05kHz 20.45.46 # amiconn: just speaking of passthrough, not the actual recording 20.46.08 # Yes - digital passthrough *is* using the adc 20.46.32 # adc -> dac ? 20.46.40 # i thought the analog signal was sent to the headphones 20.46.50 # hm, strange 20.46.55 # The analog signal is sent to the headphone when not recording 20.47.08 # ah true 20.47.16 # but at same time ARMv7-M supports hardware multithreading (which might be better than soft) 20.47.34 # gevaerts: i am still trying to understand what this UNCACHED_ADDR does here 20.48.01 # funman: ah, there I disclaim all knowledge. It's magic 20.48.13 # * amiconn still doesn't understand why AMS built a shitty audio codec like this 20.48.46 # funman: if I understand it correctly, UNCACHED_ADDR aliases the address to a range where the CPU doesn't use the cache at all 20.48.56 # that's right 20.49.13 # but there's also a side effect on non-as3525 targets i think: it returns a physical address 20.49.59 # yes, possibly. You obviously need an address that the controller driver can handle 20.50.27 # but other usb code doesn't give uncached (or physical) addresses to usb_drv_ functions 20.50.37 # and that's something that should go into the controller code 20.50.48 Quit ssorgatem (Read error: Connection reset by peer) 20.51.11 Join ssorgatem [0] (~ssorgatem@229.Red-88-15-212.dynamicIP.rima-tde.net) 20.51.49 # which code doesn't? 20.51.59 # * gevaerts points to USB_DEVBSS_ATTR 20.52.03 # amiconn: ok for fs#11189 ? 20.52.22 # gevaerts: usb_hid or usb_serial 20.52.30 # or usb_core even 20.52.41 # they do 20.53.29 # ok, that's why it sounds worse... sure 20.53.42 # they use USB_DEVBSS_ATTR, but not UNCACHED_ADDR macro 20.53.58 # UNCACHED_ADDR returning a physical address sounds kinda weird 20.54.21 # i'd expect it to return an uncached virtual alias if you have an MMU... 20.54.33 # yes, that's what I understand it to do 20.55.01 # if you need a physical address "uncached" doesn't make any sense 20.55.01 # well, it's physical too on PP, but we don't use an MMU there 20.55.19 # well, not on arches with an MMU 20.55.21 # on PP it's different ;) 20.56.28 # funman: USB_DEVBSS_ATTR is uncached by careful choice of other properties I think 20.57.37 # why is that needed? 20.58.32 # it allows not having to flush things 20.59.31 # If you define USB_DEVBSS_ATTR as something cached, and your controller driver handles that, fine. I predict slower MSC then though 20.59.53 # Why is it a problem? 21.00.29 # i expected the controller code to handle that - but i admit i don't know much about usb 21.06.49 Join bluebrother [0] (~dom@f053153203.adsl.alicedsl.de) 21.06.50 Quit bluebrother (Changing host) 21.06.50 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 21.07.28 # USB_DEVBSS_ATTR is only uncached for gigabeats 21.08.02 # for other targets it's either in iram, either aligend on cacheline size 21.08.56 Join Kitr88 [0] (~Kitar_st@89.142.68.201) 21.09.04 Quit Kitar|st (Read error: Connection reset by peer) 21.09.57 # does it use DMA ? 21.10.09 # "it"? 21.10.18 Join kaniini [0] (~quassel@dyn75-70.yok.fi) 21.10.22 Quit kaniini (Read error: Connection reset by peer) 21.10.31 Quit bluebroth3r (Ping timeout: 264 seconds) 21.10.34 # oops i had typed something about usb-drv-arc.c but i deleted it :P 21.10.38 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 21.10.48 # it = ARC driver 21.11.03 # it does, yes 21.12.01 Join Luca_S [0] (~5711fe55@giant.haxx.se) 21.12.17 Join Kitar|st [0] (Kitar_st@89.142.60.107) 21.12.39 # usb_drv_recv() is given both iram addresses and uncached addresses, perhaps both correspond to physical addresses 21.13.23 # they need to be physical addresses, yes 21.13.31 Quit Kitr88 (Ping timeout: 264 seconds) 21.13.33 # PP caches work for iram too ? 21.13.43 Join hp_sebastian [0] (~jan@188-193-210-48-dynip.superkabel.de) 21.16.51 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 21.16.55 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 21.17.14 # kugel: my patch for set_cpu_frequency() didn't crash so far, we'll see in the long run 21.17.38 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 21.17.41 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 21.17.57 Join Peter93 [0] (~IRC-Clien@port-92-202-124-39.dynamic.qsc.de) 21.18.00 Quit sharp (Remote host closed the connection) 21.18.06 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 21.18.10 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 21.22.20 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 21.22.23 Quit DataGhost (Ping timeout: 240 seconds) 21.22.30 Part Szpila 21.22.51 Join Szpila [0] (~1@chello089074134159.chello.pl) 21.23.33 *** Saving seen data "./dancer.seen" 21.25.08 # funman: why not just change the memory mapping so that the uncached address is the physical one? Is there some hardware reason? 21.25.13 # hm i don't see manuals for fuzev2 and the samsungs, i swear they would be here 21.25.23 # jhMikeS: no specific reason, it was just done that way 21.25.53 # well it was easier to have rockbox built with physical address because the MMU is not setup in the bootloader 21.27.11 Quit GeekShado_ (Ping timeout: 240 seconds) 21.27.48 # i think crt0.S has position dependant code 21.27.53 # any reason? imx sets it up in the bl, and the bl executes at 32MB *after* remap, but starts at a different location. firmware is copied down at 0 then. 21.28.15 # reason was that mmu/caching code didn't work back then ;) 21.30.33 # ah, that's a poor reason now....erm, right? :) 21.30.33 # yep 21.30.33 # but if UNCACHED_ADDR means UNCACHED_PHYSICAL_ADDR it should be renamed 21.30.33 Quit wincent (Ping timeout: 264 seconds) 21.30.33 # so far it's used in greylib and mpegplayer for PP, in usb_storage.c, and in target code 21.30.33 DBUG Enqueued KICK funman 21.30.33 # i think greylib & mpegplayer really means 'uncached', to protect from the other core 21.30.33 # the problems might go further than that since if uncached=physical, cache handling doesn't have to be done when working with device addreses 21.31.03 # you mean hardware registers? 21.31.50 # no, I mean things such as using memcpy and then sending that buffer to a device. if uncached=physical, it's coherent already 21.32.20 # pp and imx avoid alot of flush_cache stuff that way 21.32.51 Quit Guest55923 (Ping timeout: 240 seconds) 21.33.10 Join feisar_ [0] (jljhook@irkki.fi) 21.33.32 # well you can write to the uncached address & give the physical address to the hardware 21.33.42 # the other way has hazards, like the processor could write back from the cached address even after copy to the uncached but virtual one 21.33.49 Quit bluefoxx (Ping timeout: 252 seconds) 21.35.26 # in sd-as3525.c there is 2 buffers: one is sent to the DMA controller, the other one is the uncached alias and is the one used for memcpy 21.35.39 # UNCACHED_ADDR in greylib is for running the isr on the cop 21.35.56 # amiconn: ping for fs#11189 21.37.32 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 21.37.32 # * funman likes http://forums.rockbox.org/index.php?topic=23525.msg167065#msg167065 21.40.03 # * jhMikeS thinks it should be changed to uncached=physical, then all targets can share the same code without condition 21.40.17 Quit [CGL] (Remote host closed the connection) 21.41.30 Quit Strife89 (Quit: Reboot.) 21.48.19 Join Strife89 [0] (~Strife89@adsl-80-129-208.mcn.bellsouth.net) 21.48.19 Part Szpila 21.50.27 # there's only this line in usb_storage.c 21.51.53 # i think it would be doable, but we would need to change both bootloader & build at the same time? 21.51.53 # unless we make crt0 PIC 21.51.53 # at least until it sets up MMU 21.57.52 # replacing ldr in the vectors by b, and bl by mov lr/bx would work 21.58.18 # for old bootloader+new rockbox.sansa 22.04.21 Join yawny [0] (user36@pr0.us) 22.06.12 Quit elcan (Ping timeout: 240 seconds) 22.10.04 Join n1s [0] (~n1s@rockbox/developer/n1s) 22.11.12 Quit bieber (Ping timeout: 260 seconds) 22.13.03 Quit bmbl (Quit: Bye!) 22.17.28 # funman: Fuze manual build gets this error: ! LaTeX Error: File `platform/sansafuzev2.tex' not found. 22.17.50 # funman: same for the Samsungs also 22.18.31 Join Schmogel [0] (~Miranda@p3EE22B08.dip0.t-ipconnect.de) 22.18.44 Quit notlistening (Read error: Connection reset by peer) 22.19.30 # funman: you should look at the imx code. it does some footwork to start at 8a0000000, setup the MMU and run at 82000000 and use ints in the bl and fw. perhaps you'll improve upon the scheme and I'll steal that back. :) 22.19.49 # jhMikeS: i'm ok with current situation 22.22.15 # * jhMikeS dislikes it wouldn't want to work around it (and a clip is arriving in the mail) 22.22.53 # cool! which one you you get? 22.24.04 # excuse me, not clip, fuse. type? cheap! woot sucker special, some 4gb thing with an SD slot. (thx saratoga iirc) 22.28.14 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 22.30.27 # ah i just see that raw m2v streams don't seek in mpegplayer 22.30.50 # (and they don't have sound, but it's normal, right? ;) 22.31.44 # yeah, they dont' *have* sound :) 22.31.46 # m2v is just video 22.33.03 # there's no times in a raw stream either. either you have to parse the whole stream, adding frame durations or perhaps it could seek by percent. 22.37.41 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 22.41.52 # New commit by 03funman (r26179): sd-as3525v2: masked interrupts and block size won't change, and DMA won't be disabled, so we can just set these in the controller init once for all 22.42.24 # funman: i looked at that firmware file from abi that broke that guys clipv2, and its identical to the one i just made using our tools and the current bootloader 22.43.07 # i expected no problem with the file 22.43.33 # FlynDice clip+ broke while doign nothing too 22.43.46 # so a bug in the OF's update code maybe? 22.45.02 # yep or battery problem when updating 22.45.35 # grr i have no idea why we have noise when doing SD ops 22.45.42 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 22.46.19 # make sure it's charged before updating huh? I've been reluctant because iiuc there's no recovery. what does that mean exactly for making bootloaders? 22.46.49 # jhMikeS: nothing special, all the dangerous code is in mkamsboot 22.47.07 # the bootloader actually runs after the code that does the bootloading :) 22.47.24 # yeah, rockbox bootloader is stage2 ;) 22.47.29 Quit krabador (Quit: Sto andando via) 22.47.32 # hmmm....prebootloader 22.47.51 # bootloaderloader 22.49.13 # it's actually flashing it? 22.49.22 # no just written to SD 22.49.42 # the only memory on the device is a couple KB of actual ROM masked into the chip and the NAND 22.49.54 # so everything you can write has to go into the nand 22.52.12 # yep or battery problem when updating <-- i tried updating a clipv1 with low battery once - the stock firmware complained about that and didn't want to flash 22.52.59 # could just be a bad sector on his NAND that happened to get written to 22.53.15 # shouldn't SD stuff handle that? 22.53.23 # he didn't say if he saw 'firmware upgrading' 22.53.37 # well it should, but theres no way to predict if a sector is going to fail until you try 22.53.58 # though you'd think the OF would read back what it wrote to see if it succeeded 22.56.23 # who takes care of language updates? 22.57.19 # saratoga: so the OF is completely responsible for the upgrading and the 2KB ROM has no code to get at the NAND? 22.57.39 # jhMikeS: AFAIK yes 22.58.04 # i think on the e200v2 which had a recovery mode of sorts that gave direct flash access, you could fix it just by dd'ing a bin file to the flash 23.01.29 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 23.01.32 Join Forsaken_Boy [0] (~chatzilla@24.138.199.192) 23.04.08 Quit Schmogel (Ping timeout: 248 seconds) 23.05.02 # there's also the "water damage" mode - somewhere in the forums it was reported that after water damage (probably shorting something) a clip device showed a small (4Mb) usb mass storage device 23.05.33 # but it has been already dismissed as not useful as it seems read only 23.06.15 # STORAGE_WANTS_ALIGN work for all storage transfers now ? 23.10.29 # nope, codecs crash :/ 23.13.49 Quit Xerion (Quit: ) 23.20.56 Part domonoky 23.21.29 Quit Peter93 (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 23.21.55 Join GeekShado_ [0] (~Antoine@63.140.195-77.rev.gaoland.net) 23.22.33 Quit stripwax (Quit: http://miranda-im.org) 23.23.35 *** Saving seen data "./dancer.seen" 23.28.27 # hmm it seems the OF too makes that noise 23.28.46 Join wodz [0] (~wodz@chello087206240004.chello.pl) 23.31.01 # Am I correct that battery graph in debug->battery should "move" once per minute? 23.31.44 # yes, I think it's once a minute 23.32.29 Quit efyx (Remote host closed the connection) 23.32.36 # Hmm that is strange. On MPIO it inserts new value once per several minutes 23.34.28 # I'd check the source code to be sure of the interval. jhMikeS is the one who did the latest rework of the power management stuff AFAIK 23.36.31 Join CGL [0] (~CGL@190.207.171.217) 23.36.39 # It's a 60 second interval indeed. Maybe your HZ timer is running slow? 23.38.55 Quit GeekShado_ (Quit: The cake is a lie !) 23.42.26 Quit esperegu (Remote host closed the connection) 23.43.51 Quit n1s (Quit: Lämnar) 23.45.46 Quit bertrik (Remote host closed the connection) 23.50.14 Join max242 [0] (~5741a24e@giant.haxx.se) 23.50.45 Quit max242 (Client Quit) 23.51.18 Join max242 [0] (~5741a24e@giant.haxx.se) 23.52.43 # do all you fuze v1 owners wait till 'refreshing your media' message disappears after changing the content on the uSD? 23.53.29 # i typically abort the whole OF update process by pressing the 'power on' button for more then 10 seconds. 23.53.42 # but could that corrupt the filesystem? 23.53.58 # if you umount/eject it should be ok i guess 23.54.51 Quit petur (Quit: Zzzzz) 23.54.58 # hmm, 'cause i want to check if the picture flow freeze issue is gone now, but have troubles running the latest build 23.55.21 # i guess the filesystem on my fuze got corrupted 23.55.53 # the fuze simply refuses to boot with r26179 23.58.03 # hmm, i think i really have to format my 8G fuze, but i first want to move all of my music to a safe place ... that's gonna take a while 23.58.28 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.58.31 # works fine here 23.58.39 # so testing out pictureflow will not be for tonight anymore 23.58.51 # perhaps simpler to just repair the filesystem ?