--- Log for 18.10.109 Server: kubrick.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 1 hour ago 00.02.48 Quit DerPapst ("Leaving.") 00.04.28 Quit midgey (Read error: 104 (Connection reset by peer)) 00.05.19 Quit pamaury ("exit(*(int *)0 / 0);") 00.07.54 Quit Jaykay (Read error: 110 (Connection timed out)) 00.10.53 Join barrywardell [0] (n=barrywar@rockbox/developer/barrywardell) 00.13.47 # * TheSeven needs gevaerts' vote on what to do about this, as he's the USB guru. 00.16.35 Join midgey [0] (n=tjross@rockbox/developer/midgey) 00.18.26 Join ShapeShifter499 [0] (n=chatzill@adsl-68-126-134-159.dsl.scrm01.pacbell.net) 00.19.27 # YEAH! 00.19.34 # Highspeed UMS working! 00.19.55 # it's still pretty slow because of the inefficient FTL implementation, but at least it works! 00.20.23 Quit esperegu_ (Read error: 113 (No route to host)) 00.22.29 # TheSeven: congratulations! 00.22.51 # but i won't commit it :-P 00.23.07 # ;( 00.23.12 # at least not until gevaerts has told me what to do about it, as it needs a pretty questionable change in the USB core 00.23.26 # (which may very well break other targets) 00.24.13 # not sure what the "right way" there is. I consider the way it's currently done a bug, but there are reasons why one could want it to be like this. 00.28.52 # TheSeven: Probably best to post a patch and see what others say... 00.29.00 Quit robin0800 (Remote closed the connection) 00.29.22 # I 00.29.40 # I'll first commit some other things I need as a base for it, i.e. MMU fixes 00.30.49 # ah, forgot I have that slow internet connection right now 00.31.05 # I would need to update first, which I just can't do right now 00.31.59 # let's see if we can do it by only updating some relevant files 00.32.47 # New commit by 03theseven (r23237): Adjust iPod Nano 2G CPU speed to 192MHz, which measurements show it to be. Timers will be more accurate now. 00.33.07 # wow. that 2kiB commit needed 11 seconds to upload! 00.35.46 Join stoffel [0] (n=quassel@p57B4D723.dip.t-dialin.net) 00.38.59 Quit DarkDefender (Remote closed the connection) 00.43.26 Quit stoffel (Remote closed the connection) 00.48.17 *** Saving seen data "./dancer.seen" 01.00.50 # New commit by 03theseven (r23238): Implement iPod Nano 2G nand_get_info() 01.06.46 # New commit by 03theseven (r23239): Fix S5L870x cache coherency functions. They were split into a different file, as changes were needed all over the place. 01.08.52 # New commit by 03theseven (r23240): Add dcache cleaning to the S5L870x PCM driver. 01.09.57 Join saratoga [0] (i=98039f25@gateway/web/freenode/x-qarbxfufdnrfoise) 01.10.11 # are the keys for the virtual keyboard anywhere in the manual? 01.11.22 # it would appear that they are not 01.14.25 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 01.15.27 # * TheSeven will now have a look at how to improve the NAND caching things 01.20.29 Quit ender` (" Smoking is one of the leading causes of statistics.") 01.22.25 # saratoga: they are 01.22.34 # where? 01.23.21 # in the browsing and playing chapter 01.24.57 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 01.25.21 # I see several places where current_tick is compared directly to some deadline value, I plan to make those wrap-safe by using the TIME_BEFORE and TIME_AFTER macros 01.25.22 # * TheSeven should read that manual some day, too 01.28.54 # bertrik: where? 01.29.39 # ./firmware/common/timefuncs.c:67: if (current_tick > timeout) 01.29.39 # ./apps/tagcache.c:355: if (current_tick >= wakeup_tick) 01.29.39 # for example 01.30.23 # pixelma: ah its only in there for some targets 01.32.24 Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 01.32.44 # * gevaerts tries to understand exactly what the he problem is TheSeven is complaining about 01.33.32 # saratoga: where is it missing? 01.33.49 # http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch4.html#x7-420004.1.3 01.34.02 # gevaerts: what's the intended way to re-setup the default control pipe for receiving the next control packet? 01.34.30 # as i don't see an api for this, i'm assuming it should automatically be done when a packet is being received 01.34.37 # is that correct? 01.34.45 # I think so 01.34.56 # ok, then there is a bug in usb_core. 01.35.11 # you mean it was a trick question? ;) 01.35.29 # saratoga: aha, I guess the Fuze manual isn't as advanced as others yet 01.35.38 # the keymaps are in for it 01.35.41 # i wonder why it doesn't show 01.36.13 # the problem is that the control pipe will be set up for a SETUP receive. then a descriptor will be sent, and then recv() will be called, to receive a DATA1 packet. 01.36.52 # i don't have tex installed but perhaps theres a compile error or warning on that section? 01.37.01 # if this recv() manages to reach the usb controller in time, everything is fine. but if the USB controller still thinks it's supposed to receive a SETUP packet when the ACK comes in, it will respond with STALL 01.37.35 # (instead of the way intended by the USB specs, answering with NAK until the receive request is there) 01.38.40 # however, this means that the recv() must be set up within a few microseconds, and some debugging code (logf-based) was slowing it down enough to make it exceed that 01.39.25 # so the easiest solution probably is to move the request for the ACK from the host above the transmission of the actual descriptor (or whatever is being sent). 01.39.28 # * gevaerts tries to follow the code 01.39.47 # this fixed it for me, after hunting that weird lockup-when-debugging issue for days 01.40.13 # (this still doesn't explain why it did lock up, but at least it was the root cause of it) 01.40.22 # saratoga: no - there are two tables - one for targets which only moving on the input line if you "step" on it (called "picker area") and others that also have keys for that. That's why they are \opts around either of the two tables and the fuze isn't in any of the two opts 01.40.54 # so it just needs to be added? 01.41.17 # so I'm suggesting to move lines 614 and 615 upwards in that code, between lines 602 and 603 01.41.53 # (I'm talking about usb_core.c... there also be some more locations that have the same bug, but this one was most critical) 01.41.53 # saratoga: yes to one of the two, provided that the keymap file (the tex one) has all the \ActionBlah that are needed 01.42.03 # it looks like it does 01.42.10 # the entry is nearly identical to the e200 01.42.12 # but i can't test here 01.42.33 # assuming keymap-fuze is all thats needed anyway 01.42.53 # yes 01.43.47 # s/there/there may/ 01.44.01 # TheSeven: I'm not entirely convinced it's that simple. Is that allowed for both directions? 01.44.56 # the problem will come up with every non-SETUP packet received by the device 01.45.18 # saratoga: if you don't find another person, I can try tomorrow but am about to go to sleep. Feel free to remind me, not as late as now though 01.45.24 # so this should only happen for control transactions that have a DATA IN stage 01.46.30 # TheSeven: yes. We probably need to split the usb_core_ack_control() function I guess 01.47.35 # or just add a parameter to the usb_drv_send function that indicates that a 0-byte DATA OUT is to follow 01.47.40 Quit n17ikh (Read error: 104 (Connection reset by peer)) 01.48.17 # possibly, or make a usb_drv_send_control() that does that 01.48.33 # I'd prefer not to export this complication to non-control 01.48.52 # it will only happen for EP0 anyways 01.49.25 # so you got what the issue is? then I'll go to sleep now 01.49.33 # do we ever want usb_drv_send() on EP0 without the 0-byte DATA OUT? 01.49.58 # saratoga: I can test manual changes if you need 01.50.40 # can you check how the other drivers handle that? I'm somehow thinking they are probably just fast enough for this to stay hidden 01.50.55 Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 01.51.20 # this seems to have disappeared for me, too, now that I have disabled debugging again, but this definitely needs to be fixed 01.51.55 # I'll try to look at this tomorrow. My brain is just awake enough to see that there is a problem, but not to exactly understand all nuances 01.52.03 # imposing an unneccessary realtime requirement in the microsecond range isn't good at all. 01.52.12 # yes, mine too 01.52.24 # definitely not. Any timing constraint should go 01.54.00 # I'm not sure if all controllers will like a recv() on EP0 before sending 01.54.20 # yes, that's why i'm asking you what to do about this :-) 01.55.02 # the answer is: I don't know... I've only ever really looked at the ARC. I can test ARC and tcc here 01.55.04 # but we really should look at that tomorrow, I'm almost falling asleep after a long day of hunting this 01.55.13 # good idea 01.57.13 Join FOAD_ [0] (n=dok@dinah.blub.net) 02.04.14 Join explore [0] (n=msparker@pool-173-57-92-51.dllstx.fios.verizon.net) 02.04.59 # * midgey is planning to commit his changes to lang format for translatable plugins 02.08.56 Quit explore (Client Quit) 02.09.24 Quit FOAD (Read error: 110 (Connection timed out)) 02.09.24 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 02.10.54 Join peter-b [0] (n=peter_b@93.135.43.96) 02.13.45 # http://rockbox.pastebin.ca/1626141 for anyone interested 02.16.27 Join AndyIL [0] (n=pasha_in@212.14.205.32) 02.17.05 # midgey: that's great 02.17.15 # \o/ 02.17.28 # slowly but surely i'm merging it in... 02.19.53 Quit peter__b (Read error: 145 (Connection timed out)) 02.21.36 # after committing that, the only changes to the core will should be adding functions to the plugin api and some makefile stuff 02.21.52 Quit ShapeShifter499 ("ChatZilla 0.9.85 [Firefox 3.0.14/2009090216]") 02.24.08 Quit TheSeven (Read error: 110 (Connection timed out)) 02.24.20 Quit n1s ("Lämnar") 02.28.51 Quit AndyI (Read error: 110 (Connection timed out)) 02.31.14 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 02.32.39 Quit BHSPitLappy (Remote closed the connection) 02.34.38 Quit volkmar (Remote closed the connection) 02.34.49 Join volkmar [0] (n=volkmar@91.121.198.82) 02.40.58 Join casainho [0] (n=chatzill@bl15-108-152.dsl.telepac.pt) 02.41.23 Quit casainho (Client Quit) 02.48.18 *** Saving seen data "./dancer.seen" 02.49.01 Join newnick [0] (n=182dc0d1@giant.haxx.se) 02.49.25 Nick newnick is now known as metalman1253 (n=182dc0d1@giant.haxx.se) 02.52.11 Quit efyx_ (Remote closed the connection) 02.53.13 # does anybody know how to fix the database on ipod nano 2g 02.54.03 # metalman1253: what is happening? 02.54.50 # it initilizes fine but then on boot it panics hold on let me recreate it to get the message 02.55.21 # do you have dircache turned on? 02.56.07 # wait nevermind i guess installing iloader fixed it 02.56.45 # New commit by 03midgey34 (r23241): Change the .lng files to contain strings from multiple users. Still hard-coded to only output the core strings for now. Should be the majority of the ... 02.57.04 # ok, if it comes back see: http://www.rockbox.org/tracker/task/10679 03.01.08 Quit amiconn (Nick collision from services.) 03.01.10 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 03.01.30 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 03.03.47 Quit pixelma (Nick collision from services.) 03.03.49 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 03.04.09 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 03.05.59 # ok i tried it on my other nano 2g but its not working it has something to do with having disktidy set to clean all items and then that panics then when i booted up again it just worked 03.07.58 # metalman1253: if you can reproduce the problem, please post a bug report on flyspray with all details. 03.12.13 Quit Thundercloud (Remote closed the connection) 03.38.30 Join sinthetek [0] (n=sinthete@cpe-071-076-249-163.triad.res.rr.com) 03.38.51 # i am not sure why but my wps isn't displaying properly anymore 03.39.27 # for some reason everything but the track progress-bar is scrambled-looking 03.40.30 Quit Farthen (Read error: 113 (No route to host)) 03.46.56 Join barrywardell_ [0] (n=barrywar@91.37.163.171) 03.48.28 Join midgey_ [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) 03.50.21 Quit volkmar (Remote closed the connection) 03.52.40 # sinthetek: what revision of Rockbox are you using? 03.56.23 Quit midgey (Read error: 110 (Connection timed out)) 03.56.23 Nick midgey_ is now known as midgey (n=tjross@rockbox/developer/midgey) 03.57.10 Join yelped [0] (n=ad442244@giant.haxx.se) 03.58.49 Join volkmar [0] (n=volkmar@91.121.198.82) 03.59.24 # Can someone please check out this bug and see if it happens on all targets? Mp3encoder encodes squirell-voice-files. http://www.rockbox.org/tracker/task/10678 03.59.25 Quit metalman1253 ("CGI:IRC (EOF)") 03.59.51 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 04.03.38 Quit barrywardell (Read error: 110 (Connection timed out)) 04.03.39 Nick barrywardell_ is now known as barrywardell (n=barrywar@rockbox/developer/barrywardell) 04.08.12 Join Hillshum [0] (n=hillshum@75-165-235-2.slkc.qwest.net) 04.14.40 Join FOAD_ [0] (n=dok@dinah.blub.net) 04.15.24 Quit yelped ("CGI:IRC") 04.16.01 Quit FOAD (Read error: 60 (Operation timed out)) 04.16.02 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 04.17.13 Part froggyman 04.17.51 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 04.23.41 Quit n17ikh () 04.24.09 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 04.25.10 Join mikroflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) 04.32.13 Quit uflops (Read error: 145 (Connection timed out)) 04.38.15 Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 04.38.19 Quit Rondom (Nick collision from services.) 04.38.29 Join Rondom [0] (n=Rondom@dslb-084-057-157-055.pools.arcor-ip.net) 04.44.45 Quit midgey () 04.48.20 *** Saving seen data "./dancer.seen" 04.56.45 Quit JdGordon ("Leaving.") 04.59.55 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 05.00.42 Quit n17ikh () 05.10.00 Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 05.10.53 Quit StealthyXIIGer (Read error: 110 (Connection timed out)) 05.22.21 # mc2739 nm, i reinstalled over it and it works fine now 05.22.37 # it was just something corrupted with that specific theme i believe 05.26.30 Nick fxb is now known as fxb__ (n=felixbru@85.214.97.64) 05.49.55 Quit Hillshum (Remote closed the connection) 06.14.18 # New commit by 03mc2739 (r23242): Add Fuze virtual keyboard keymap chart to manual 06.17.46 Join Minthe [0] (n=Minthe@KD124214153219.ppp-bb.dion.ne.jp) 06.19.31 Join gtkspert_ [0] (n=gtkspert@203-59-109-220.dyn.iinet.net.au) 06.31.54 Quit gtkspert (Read error: 101 (Network is unreachable)) 06.33.19 Join dmb [0] (n=Dmb@unaffiliated/dmb) 06.37.41 Join Strife1989 [0] (n=michael@adsl-146-206-157.mcn.bellsouth.net) 06.38.30 Quit Strife1989 (Read error: 104 (Connection reset by peer)) 06.47.11 Part toffe82 06.48.21 *** Saving seen data "./dancer.seen" 06.51.09 Quit dmb (Read error: 131 (Connection reset by peer)) 06.53.38 Quit Strife89 (Read error: 110 (Connection timed out)) 07.22.23 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 07.40.39 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 07.46.01 Nick markatto_ is now known as markatto (n=markatto@76.226.220.203) 07.46.49 Quit Horscht (Read error: 60 (Operation timed out)) 07.55.45 Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) 08.02.44 Join arohtar [0] (n=faemir@78.33.109.163) 08.17.32 Quit faemir (Read error: 110 (Connection timed out)) 08.25.15 Join Rob2223 [0] (n=Miranda@p4FDCF92A.dip.t-dialin.net) 08.27.42 Join sliverchair [0] (n=thirdy@112.202.169.209) 08.28.33 # hi, I'm gonna buy a Sony E-series walkman today since there's no available Sansa or iRiver here just iPods 08.30.50 # any comment on this? NWZ-E436 vs. iPod Nano 4G? 08.36.41 # sliverchair most of the players rockbox runs on can be found on e-bay or other refurbished/bankrupt stock website 08.37.28 # robin0800, hmm, got no experience with shipping internationally 08.38.12 # robin0800, is there any reason why I shouldn't buy NWZ-E436 over an Nano 4g? 08.39.00 # sliverchair: no idea 08.40.22 Join stoffel [0] (n=quassel@p57B4F50D.dip.t-dialin.net) 08.40.43 # sliverchair: that's not really on topic for this channel since Rockbox does not currently run on either of those devices 08.41.47 # mc2739, any plans on porting rockbox for Walkman e-series? if not, it's still technically possible right, so there's still hope 08.43.05 Quit Rob2222 (Read error: 110 (Connection timed out)) 08.43.28 # There are no "plans" to port to any device. It is possible that a port could happen, but only if users with that device are interested in doing the work. 08.48.23 *** Saving seen data "./dancer.seen" 08.49.24 Join esperegu [0] (n=quassel@145.116.15.244) 08.53.26 Quit sliverchair (Read error: 54 (Connection reset by peer)) 08.59.01 Quit panni_ (Read error: 104 (Connection reset by peer)) 09.03.08 Part mc2739 09.03.10 Join mc2739 [0] (n=mc2739@rockbox/developer/mc2739) 09.08.36 Quit FlynDice (Remote closed the connection) 09.11.34 Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 09.23.23 Join DerPapst [0] (n=DerPapst@p4FE8F6CD.dip.t-dialin.net) 09.41.35 Join webguest74 [0] (n=52176701@giant.haxx.se) 09.42.05 Quit daurnimator (Remote closed the connection) 09.43.04 Join daurnimator [0] (i=daurnima@freenode/staff/daurnimator) 09.44.04 # hi. can any 1 help whenever i click on ROMs there are no ROMs? 09.44.48 # webguest74: what ROMs are you looking for? 09.45.00 Quit BHSPitLappy ("Ex-Chat") 09.45.09 # i usually play pokemon on the ipod and all of a sudden no games are there 09.46.24 # webguest74: go to your quickscreen and make sure it is set for "supported" or "all" files 09.48.56 # thanks alot 09.49.10 # you're welcome 09.53.10 Part OttoScratchansni 10.00.32 Quit niekie (Remote closed the connection) 10.00.45 Join ender` [0] (i=krneki@foo.eternallybored.org) 10.05.41 Quit n17ikh () 10.06.16 Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 10.07.02 Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht) 10.10.42 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 10.24.49 Quit webguest74 ("CGI:IRC") 10.32.10 Quit DerPapst ("Leaving.") 10.37.28 Quit n17ikh (Read error: 60 (Operation timed out)) 10.42.10 Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 10.45.01 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 10.48.25 *** Saving seen data "./dancer.seen" 10.50.08 Join niekie [0] (i=quasselc@78.129.140.218) 11.05.18 Join TheSeven [0] (n=theseven@rockbox/developer/TheSeven) 11.05.44 Join n1s [0] (n=n1s@rockbox/developer/n1s) 11.32.28 # http://www.blackdynamitemovie.com/store-main 11.39.11 Quit stoffel (Remote closed the connection) 11.42.47 Join Highlander [0] (i=Highland@82.236.45.205) 11.50.18 # gevaerts: ping 11.59.51 Join casainho [0] (n=chatzill@bl15-108-152.dsl.telepac.pt) 12.03.33 # JdGordon: hello :-) -- could you flash the Rockbox bootloader already? And do you have a JTAG cable working? 12.03.54 Join AndyI [0] (n=pasha_in@212.14.208.235) 12.05.04 # * TheSeven is envious 12.06.31 Join kyle6513 [0] (n=kyle@58.174.128.189) 12.10.09 Join pamaury [0] (n=pamaury@91-168-94-4.rev.libertysurf.net) 12.15.01 Quit phanboy4 (Read error: 110 (Connection timed out)) 12.16.41 Join |DaMaGeD| [0] (n=|DaMaGeD@83.149.19.92) 12.22.58 Quit AndyIL (Read error: 110 (Connection timed out)) 12.29.03 Quit |DaMaGeD| ("Back in reality.") 12.33.09 Quit GodEater (Remote closed the connection) 12.33.19 Join GodEater [0] (n=bibble@bb-87-80-121-64.ukonline.co.uk) 12.33.31 Quit barrywardell () 12.39.17 Join _zic [0] (n=user@91-165-239-167.rev.libertysurf.net) 12.39.46 # linuxstb: ping 12.43.41 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 12.45.34 # TheSeven: it just hit me that i probably botched my change to the note generator and that's why it didn't work 12.45.34 Quit Juozapas (Read error: 104 (Connection reset by peer)) 12.45.49 Join Juozapas [0] (n=qzaz@78-60-24-63.static.zebra.lt) 12.48.26 *** Saving seen data "./dancer.seen" 12.50.04 Quit Thundercloud (Remote closed the connection) 12.57.34 # yeah, that was it /me facepalnms 13.00.15 Quit AndyI () 13.02.45 Quit scorche (" rawr...that is all...rawr") 13.03.42 Quit Minthe ("Leaving...") 13.19.40 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 13.24.59 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 13.26.11 # TheSeven: Does that wrong order of things potentially affect all transfers, or just enumeration? 13.26.51 # I'm asking because the rockbox usb stack has problems with occasional resets on PP as well 13.31.09 Join Ubuntuxer [0] (n=johannes@dslb-094-220-239-068.pools.arcor-ip.net) 13.36.01 Nick fxb__ is now known as fxb (n=felixbru@85.214.97.64) 13.41.18 Join MethoS- [0] (n=clemens@134.102.106.250) 13.45.25 Quit GodEater (Read error: 113 (No route to host)) 13.50.13 # amiconn: fixing it for "get descriptor" requests alone seemed stable for me, but i can't guarantee that there aren't other places where this is done wrong as well 13.50.33 # however, it will only affect control traffic on EP0, not bulk traffic 13.50.54 # hmm 13.51.07 # but requests like getmaxlun are also done through that control pipe, so it may as well have an impact after enumeration 14.01.21 Quit antil33t (Read error: 104 (Connection reset by peer)) 14.01.26 Join antil33t [0] (n=Mudkips@119.224.12.185) 14.06.47 Quit J-23 (Read error: 104 (Connection reset by peer)) 14.08.07 # TheSeven: pong 14.08.21 # gevaerts: ack 14.08.40 # amiconn: the remaining occasional PP resets don't seem at all related to this 14.09.03 # TheSeven: have you seen http://forums.rockbox.org/index.php?topic=22964.0 ? 14.09.12 Join stoffel [0] (n=quassel@p57B4F50D.dip.t-dialin.net) 14.09.26 # * TheSeven starts loading that page over his slow line 14.09.54 # TheSeven: also FS#10684 apparently 14.10.00 # oh, nice one. I'll look into this 14.10.21 # did you have any further thoughts on how to solve that usb issue? 14.10.41 Join J-23 [0] (n=zelazko@unix.net.pl) 14.12.12 # no, I managed to keep the issue out of my mind all this time 14.14.14 # maybe the proper solution is to move most of the control handling out of usb_core.c and into the drivers 14.14.35 # * gevaerts just thinks out loud at the moment 14.16.30 # gevaerts: this would increase the amount of work needed to be done to implement new controllers 14.17.08 # on the other hand, i already have another quirk where I need to bypass usb_core's handling of the SET_ADDRESS command, and I remember seeing something similar in the tcc driver 14.17.09 # true, but this seems to be an area where controllers have different expectations from software 14.23.01 Join Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) 14.25.12 # TheSeven: it seems that your latest commit introduce some sound play back artifact. 14.25.52 # funny. actually it should prevent them. 14.26.11 # TheSeven: I have switched back to r23230 and get a clear sound again. 14.26.31 # what kind of artifact? 14.27.19 # TheSeven: artifact are very similar to those of vinyl records. 14.27.49 # TheSeven: I got them for both mp3 and flac. 14.28.51 # oh yes, there is some light popping action :-/ 14.30.15 # I'll now commit my latest nand changes, and then I'll have a look at those PCM issues 14.30.45 # * gevaerts likes those issues. They give him time to think about the USB thing :) 14.32.39 # TheSeven: I follow your USB progress so sorry to disturb you with PCM issues :D 14.33.13 # My USB progress is currently blocking on gevaerts anyways :-D 14.33.46 # * TheSeven wonders if this popping is related to FS#10684 14.36.19 # New commit by 03theseven (r23243): iPod Nano 2G storage performance improved by not copying around buffers unneccessarily if they are aligned anyways and using cache coherency functions ... 14.37.40 # * TheSeven hopes no further NAND trouble will arise from this 14.38.32 Quit n1s ("Lämnar") 14.38.50 Part Grahack 14.38.51 # TheSeven: if we move the recv(EP0,0) to the driver, to be done together with the send(EP0,whatever), drivers can do it before or after the transmit depending on what the hardware can handle 14.39.44 # so you would vote for a usb_drv_sendrecv0 function? 14.39.58 # (or whatever you would like to call it) 14.40.16 # if we do that, at least for arc doing the recv() after the send() will be less easy than doing it before, so I hope the hardware can handle before 14.40.56 # I would actually do it in usb_drv_send(). I don't think any EP0 transmit will ever not want the 0-byte receive 14.41.03 # in theory every hardware should be able to handle that, as they're independant endpoints 14.41.31 # gevaerts: what about EP0 transmits that are 0-byte ACKs themselves? 14.41.48 Join einhirn [0] (n=Miranda@93.204.9.28) 14.41.50 # ah yes, those should be filtered out as well 14.42.03 # so ep==0, direction==IN, length>0 14.42.26 # direction==IN should be implied by the fact that it's a send() function :-) 14.43.09 # hm, good point :) 14.43.38 # (even though this may look backwards to people who don't know USB :-P ) 14.44.39 # if we assume that all controllers can handle this, maybe we should provide wrappers for send and receive in usb_core.c that do all this? 14.45.27 # what's the point in that? 14.45.55 # making drivers two lines shorter 14.46.21 # couldn't we just reverse the order we're doing things in the core then? 14.47.59 Quit casainho ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824085743]") 14.48.19 Join funman [0] (n=fun@rockbox/developer/funman) 14.48.28 *** Saving seen data "./dancer.seen" 14.48.56 # TheSeven: do you know you can get details on the caches of s5l8701 by reading cp15 register 0, cache type ? 14.49.30 # funman: It looks like whatever the 940T spec says is correct 14.49.44 # does it say cache line size is 16 bytes ? 14.49.53 Part Ubuntuxer 14.49.55 # yep 14.50.15 # perhaps we could define cache line and keep the code in common 14.50.34 # which code? 14.50.35 Quit _zic ("Ухожу") 14.50.40 # *cache() 14.51.04 # this would be an ifdef hell 14.51.11 # well not really 14.51.16 # more like add r0, r0, CACHE_LINE 14.51.16 # TheSeven: that would imply doing it explicitely, but maybe that's better 14.51.22 # * gevaerts prepares a patch 14.52.02 # also invalidating the entire dcache while you could invalidate only a range is quite slow no ? 14.52.42 # funman: can I invalidate a range? 14.53.00 # yes, see invalidate_dcache_range() 14.53.10 # as far as i can tell, that's one of the things needing to be ifdef'ed out because this core doesn't support it 14.53.59 # i can only kick cache lines out, not cache tags 14.54.10 # ah you can't use MVA :/ 14.54.38 # i assumed since 940 > 922 it would be possible like on the arm922tdmi 14.55.20 # then yeah it makes sense to have these functions separated 14.55.51 # ideally they should be separated as mmu-arm940.S mmu-armv6.S .. 14.56.55 # i would rather consider mmu-armv4.S and mmu-armv6.S 14.56.57 # didn't you mention that 940T has no mmu ? 14.57.34 # funman: no real MMU in terms of remapping, but of course it has cache coherency stuff, which is in a "mmu-xyz" file by rockbox design 14.57.46 # rockbox design is flexible ;) 14.58.39 # in fact, calling it "cp15-armv4.S" would make more sense, and adding things to define memory regions and protection stuff, that's currently done in crt0.S 14.58.42 # mmu-armv4.S would be wrong 14.58.58 # ARM7TDMI is armv4 as well, but has no mmu 14.59.20 # this thing doesn't have a real MMU either, just cache stuff 14.59.23 # It doesn't have CP15 either, which is what this caching stuff is about 14.59.36 # so it doesn't have any caches at all= 14.59.42 # It does 15.00.01 # PP controls its caches by a proprietary method 15.00.15 # bah. 15.02.30 # * TheSeven just spotted an s5l870x DMA bug 15.05.28 # bertrik: ping 15.05.42 # TheSeven, hi 15.06.04 # bertrik: is anything besides PCM actually using the s5l870x DMA right now? 15.06.18 # no I don't think so 15.06.50 # the problem is that this is only restarted on whole completion currently, which is resulting in some popping action as it isn't fast enough 15.07.06 # sounds like we need some double buffering there 15.07.16 # New commit by 03funman (r23244): Split ARMv6 code from mmu-arm.S 15.07.33 # I thought the I2S has some buffering 15.07.34 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 15.07.46 # bertrik: obviously not enough 15.08.09 # to allow it continue playing while we set up the next DMA 15.08.20 # it's only buffering a single sample of one channel 15.08.41 # * gevaerts grumbles about things being complicated 15.09.13 Join DerPapst [0] (n=DerPapst@p4FE8F6CD.dip.t-dialin.net) 15.09.32 # TheSeven, what is the maximum gap you can tolerate without playback gaps? 15.09.34 # git-svn doesn't have an equivalent for svn cp :/ 15.10.20 # bertrik: currently around 10 to 20 µS 15.10.22 # oh, one sample is obviously not enough ... :) 15.10.27 # which is clearly too small 15.11.57 # TheSeven: what do you think of renaming s5l8700/mmu-* to caching-* ? 15.12.27 # I thought the IIS had some buffering 15.12.29 # mmu-target.h is only used inside the target folder (those functions are already defined in another header) 15.12.46 # bertrik: the wmcodec maybe has, but not the I2S controller 15.12.47 # hmm .. mmu-arm.h 15.13.10 # TheSeven: it's the usb_drv_send()+expect ack change that needs to change, right? 15.13.39 # s/ack change/ack case/? 15.13.50 # yes 15.14.55 # generally, everything that needs to be received on EP0 which isn't a setup packet will need to call recv() before it can be sent from the host side, so before triggering it by sending something to the host 15.15.16 # this is the case for setup=>data=>ack-style requests, but maybe also other things... (getmaxlun?) 15.15.20 # TheSeven: Weird design. I'd expect a fifo for 8 or 16 samples 15.15.37 # getmaxlun is exactly the same as a get descriptor 15.16.02 # amiconn: I can't say for sure that there is no such fifo, but the DS at least doesn't mention one 15.18.24 # bertrik: spotted another nice bug in there: for (channel = 0; channel < 4; channel++) { if (DMAALLST & mask) { 15.18.29 # ...without shifting the mask! 15.18.41 # mask <<=4 is there somewhere IIRC 15.18.49 # ah, wait, it's shifted below 15.21.46 # not having any buffering in IIS is going to make things slightly more complicated ... 15.21.55 Join daurn [0] (i=daurnima@freenode/staff/daurnimator) 15.23.43 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 15.29.15 Join T44 [0] (n=Topy44@f049157041.adsl.alicedsl.de) 15.30.31 Quit domonoky (Read error: 104 (Connection reset by peer)) 15.31.37 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 15.34.53 # TheSeven: FS#10687 15.39.42 # * gevaerts decides to also actually test that patch 15.41.12 Quit daurnimator (Read error: 110 (Connection timed out)) 15.46.59 Quit Topy44 (Read error: 110 (Connection timed out)) 15.49.47 Quit stoffel (Remote closed the connection) 16.05.03 Join efyx_ [0] (n=efyx@82.225.185.146) 16.07.59 Quit daurn (Read error: 110 (Connection timed out)) 16.10.15 Join daurn [0] (i=daurnima@freenode/staff/daurnimator) 16.12.23 # hm "Features: : : : : : : : : : :albumart:backlight_brightness:backlight_fade_bool:dircache:disk_storage:hold_button:lcd_bitmap:lcd_non-mono:lcd_color:lcd_sleep:pitchscreen:quickscreen:remote:remote_lcd_invert:rtc:swcodec:tagcache:tc_ramcache:charging:usbstack:usb_hid:touchscreen:large_plugin_buffer" 16.12.56 # what's that? 16.15.19 # that's from rockbox-info.txt on my mr500. Those blank features shouldn't be there I think 16.15.45 # doesn't it have the feature_hiding feature ? 16.15.49 # TheSeven: can you test if FS#10687 fixes your issues? 16.16.43 # then we only need to find mcuelenaere to test his drivers 16.17.39 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 16.21.31 # bertrik: and the s5l8701 DMA doesn't even seem to support auto-reloading! 16.24.27 # New commit by 03gevaerts (r23245): Also filter lines with only spaces in apps/features. At least mr500 had those after the preprocessing step. 16.29.29 Quit FlynDice (Remote closed the connection) 16.30.16 # bertrik: do you have any idea on how to resolve this? 16.30.40 # can a FIQ interrupt an IRQ? 16.32.14 Quit kyle6513 ("Leaving") 16.32.37 Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 16.32.48 Join stoffel [0] (n=quassel@p57B4F50D.dip.t-dialin.net) 16.39.20 Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) 16.43.21 # * TheSeven would like to drop that DMA thing altogether 16.47.40 Nick fxb is now known as fxb__ (n=felixbru@85.214.97.64) 16.47.43 Nick fxb__ is now known as fxb (n=felixbru@85.214.97.64) 16.48.32 *** Saving seen data "./dancer.seen" 16.49.27 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 16.51.04 Quit robin0800 (Read error: 104 (Connection reset by peer)) 16.51.06 Join robin0800_ [0] (n=robin080@general-ld-216.t-mobile.co.uk) 16.52.59 # TheSeven, no sorry, don't know yet 16.54.01 Join duffrecords [0] (n=iyoung@dtnoc.alchemy.net) 17.07.24 Quit panni_ (Read error: 113 (No route to host)) 17.10.28 Join z35 [0] (n=z35@ool-45714f83.dyn.optonline.net) 17.11.36 Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) 17.15.16 Join petur [0] (n=peter@d54C6F49C.access.telenet.be) 17.21.50 Nick YPSY is now known as Ypsy (n=ypsy@87.106.45.183) 17.22.12 Join webguest50 [0] (n=d9e494f9@giant.haxx.se) 17.24.14 Quit webguest50 (Client Quit) 17.29.34 Join polobricolo [0] (n=polobric@86.206.12.22) 17.33.07 Quit funman ("free(random());") 17.37.51 Quit DataGhost (Read error: 60 (Operation timed out)) 17.39.58 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 17.40.15 Quit robin0800_ (Remote closed the connection) 17.40.28 Quit stripwax (Client Quit) 17.44.18 Join flydutch [0] (n=flydutch@87.15.167.77) 17.50.32 # New commit by 03bertrik (r23246): Use wrap-safe TIME_BEFORE/TIME_AFTER macros to compare times with current_time, instead of comparing them directly. 17.59.41 Quit arohtar (Client Quit) 18.00.40 Quit polobricolo (Remote closed the connection) 18.10.55 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) 18.15.43 # * TheSeven now has very weird audio output 18.16.51 Join ruj1 [0] (n=ruj1@88.147.206.60) 18.17.17 # baaah, how do i stop the codecs from overwriting too much of the pcm buffer that hasn't been played yet!? 18.20.33 Join polobricolo [0] (n=polobric@AGrenoble-257-1-37-22.w86-206.abo.wanadoo.fr) 18.24.41 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 18.25.30 Quit polobricolo (Client Quit) 18.26.00 Join polobricolo [0] (n=polobric@AGrenoble-257-1-37-22.w86-206.abo.wanadoo.fr) 18.37.22 Join esperegu_ [0] (n=quassel@145.116.15.244) 18.38.04 Quit esperegu (Read error: 113 (No route to host)) 18.48.34 *** Saving seen data "./dancer.seen" 18.55.59 Join kugel [0] (n=kugel@rockbox/developer/kugel) 19.00.44 # * TheSeven tries to understand how pcmbuf.c works 19.00.49 Join GodEater [0] (n=bibble@bb-87-80-121-64.ukonline.co.uk) 19.01.36 Quit Utchybann (Read error: 113 (No route to host)) 19.11.41 Quit togetic ("WeeChat 0.3.0") 19.11.46 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 19.17.06 Quit phanboy4 ("Leaving") 19.18.40 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) 19.25.35 Join yelped [0] (n=ad442244@83.168.254.42) 19.26.18 # Can someone please check out this bug and see if it happens on all targets? Mp3encoder encodes squirell-voice-files. http://www.rockbox.org/tracker/task/10678 19.27.22 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 19.31.07 # I'm having trouble with my database. it starts building, then gets to a particular number of songs and stops there. has anyone else experienced this? 19.31.48 # yea, many peoplpe 19.31.57 # usually it comes across bad files 19.32.06 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 19.35.47 Quit StealthyXIIGer (Read error: 104 (Connection reset by peer)) 19.36.08 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 19.36.37 # anybody with a basic understanding of the pcmbuf here? 19.36.52 Join Sajber^ [0] (n=Sajber@h-143-146.A213.priv.bahnhof.se) 19.39.24 Nick Ypsy is now known as YPSY (n=ypsy@87.106.45.183) 19.43.22 # kugel: what sort of bad files? incompatible format? something weird in the ID3 tag? 19.43.46 # duffrecords: corrupted tags 19.45.16 # does it show a filename in the database debug screen? 19.47.02 # no, Curfile is --- 19.47.38 # because the only way out of the stuck screen is to press PREV, which I suppose cancels the rebuilding 19.51.02 Join NoGare [0] (i=chatzill@216.8.164.46) 19.52.00 # * TheSeven finally has stable playback again, after an ugly hack 19.53.10 # hmm... on the themes site - I thought themes with RWPSs won't show up on subpages of targets with the same main screen resolution but without remote, am I wrong? The reason I ask is that there is an X5 theme with remote WPS that is listed on the big H10 theme page too 19.53.54 # as far as I know the H10 even has a remote but a non-LCD one 19.55.48 # duffrecords: you can find the file by putting a database.ignore in some folders that will skip adding the folder to the db 19.57.56 # kugel: ok. I think I'll try that one at a time, going backwards by file modification date until I find it 19.59.49 # or by moving the folders into new A-M and N-Z folders, and so on, using a half-splitting method 20.00.58 # duffrecords: It's also worth checking your filesystem for errors (e.g. chkdsk, fsck.vfat) 20.01.23 # or whatever has the best O(n) time 20.01.40 # yeah, I did a chkdsk and defrag 20.02.03 # errors are fixed, but the database still won't finish building 20.02.17 # what target? 20.02.33 # iPod Video 30 GB 20.07.05 Join skyhunter [0] (n=quassel@e177246142.adsl.alicedsl.de) 20.07.59 Join faemir [0] (n=faemir@78.33.109.163) 20.09.34 Quit Highlander ("Quitte") 20.12.37 Join togetic [0] (n=togetic@unaffiliated/ibuffy) 20.14.57 Quit togetic (Client Quit) 20.15.15 Quit phanboy4 ("Leaving") 20.15.51 # ok, dma refresh latencies are ~2µS now 20.16.15 Join togetic [0] (n=togetic@unaffiliated/ibuffy) 20.16.31 # but this needs some changes to pcmbuf.c 20.17.44 Quit esperegu_ (Read error: 104 (Connection reset by peer)) 20.22.04 Quit yelped ("CGI:IRC") 20.26.12 Quit skyhunter (Remote closed the connection) 20.26.20 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 20.26.21 Join midgey [0] (n=tjross@rockbox/developer/midgey) 20.26.37 # TheSeven: why does the S5L870X need separate cache coherency functions? 20.28.07 Quit StealthyXIIGer (Read error: 104 (Connection reset by peer)) 20.31.58 Quit NoGare ("ChatZilla 0.9.85 [Firefox 3.5.4/20091007001339]") 20.32.16 # TheSeven: the code in pcmbuf.c works for every other target, why does it need changing for nano2g? 20.42.02 # kugel: the buffers in the s5l8701's i2s controller seem to be extremely small 20.42.35 # this means that the DMA refreshing is extremely latency-critical 20.42.51 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) 20.43.05 # the only solution to this that i can see is double-buffering audio output, and this needs some small changes 20.43.28 # TheSeven: stupid question, isn't the audio already working 20.43.50 # there is some light clicking/popping action when refreshing the DMA 20.44.36 # the latest cache coherency changes (which increased refreshing latencies a little) made them clearly audible, so we need to do something about it 20.45.43 Join mrtok1 [0] (n=dummy@p5B39E9E6.dip.t-dialin.net) 20.45.46 # and the whole lot of pcmbuf code seems to be too slow to pass me a new buffer in time (according to the datasheet, there is only a single sample of buffer in the I2S!) 20.46.42 # TheSeven: I was looking at the logs it is right that the cache coherency changes were split because of the cache line size, or are there other changes? 20.47.32 # most of the functions in the mmu-arm.S aren't applicable to that core at all 20.48.35 *** Saving seen data "./dancer.seen" 20.49.04 # for any manual developers: Is it a known problem that the iAudio M3 manual does not build? 20.49.13 # understood, but what are the functional differences for those particular instructions - I am curious because I thought I read somewhere that the cache line size is selectable when they are synthesizing the ARM core 20.50.01 Quit mrtok1 (Client Quit) 20.50.04 # in your particular case it will always be the same but, I was wondering if it would make more sense to split out the coherency functions and define the cache size in the soc include 20.50.24 # mmu-arm.S seems to be written for an ARM6 core. the s5l870x is an ARM4 core (iiuc), but not all ARM4 cores have a cp15 at all, so a separate file for arm4 doesn't make too much sense either 20.51.27 # TheSeven: it was originally for a v4 arm (922T) 20.51.50 # bah, so this isn't even consistent among ARM4 cores... 20.51.51 # but if you have a cp15 the cache coherency functions should be the same besides the variability in the cache line size for all v4's and v5's I believe 20.51.52 Join mrtok1 [0] (n=dummy@p5B39E9E6.dip.t-dialin.net) 20.52.16 # TheSeven: various v4 targets use that file 20.52.31 # kkurbjun: on the 922T you can flush memory regions, on the 940T you can't, for example 20.52.39 # and then there is all this TTB stuff 20.54.08 # gevaerts: your USB patch is working fine for me 20.56.29 # TheSeven: linux is able to maintain the cache coherency functions by architecture - it looks like there are three variants for arm v4: http://lxr.linux.no/#linux+v2.6.29/arch/arm/mm/ 20.58.21 Quit midgey () 20.58.33 # hmm, looking at the 940 assembly though it looks like they may have implemented separate from arch on the 940. 20.59.47 # TheSeven: ok. As soon as mcuelenaere has tested on his targets, it can go in 21.00.16 Join n1s [0] (n=n1s@cm-84.215.127.139.getinternet.no) 21.00.34 # kkurbjun: cache-v4.S looks like a bunch of stubs, and the other ones are for write-back/write-through configuration of the cache 21.02.00 Join fyrestorm [0] (n=nnscript@cpe-69-203-148-25.si.res.rr.com) 21.04.48 Quit fyrestorm (Client Quit) 21.05.43 Join fyrestorm [0] (n=nnscript@69.203.148.25) 21.06.59 # someone here who can explain differences between COP and MAIN_CPU on ipod nano 1g ? 21.07.18 # that pp has 2 cores, right? 21.07.23 # yep 21.09.25 Join yelped [0] (n=ad442244@giant.haxx.se) 21.09.53 # symptons are: processing dsp function on MAIN_CPU -> sounds good , doing on COP artefacts occur 21.10.26 # mrtok1: The problem is likely to be cache coherency between the two cores. 21.10.38 # (they have independent caches) 21.11.04 # Can someone please check out why Mp3encoder doesn't work properly with 24000Hz files? Mp3encoder encodes squirell-voice-files. http://www.rockbox.org/tracker/task/10678 21.11.06 # it looks like they do most if by the core version does the samsung yps3 use the sl5L870X 21.11.54 # looks like it does 21.12.27 # yelped: I think we've all see that now.... But that plugin is more or less abandoned - it was implemented as a first test before mp3 encoding was integrated into recording. It's poor quality at best. 21.12.57 # linuxstb: okay - the idea is starting a thread on the cop, passing pointer to second channel to process, waiting for thread_exit - how to deal with 2 caches - do i have to update the COP cache manually? 21.14.23 # mrtok1: I've never programmed it, but I believe you'll need to flush the cache on the main CPU and invalidate it for the COP (for memory shared between the two processors). Have you looked at other code using the COP - e.g. the mp3 decoder? 21.14.45 # linuxstb: shouldn't the plugin be disabled then? Though I can imagine that the error is in something Fuze specific too... 21.14.51 # Oh, because Recording is not enabled yet on the AMS Sansas, so meanwhile I was using the OF to record and when I wanted to save some space, I used the Mp3encoder. Thanks for the info! 21.15.32 # pixelma: I don't know the state of it - Toni wrote it, and he's one of those committers who still commits occasionally, but is never around IRC. 21.15.43 # It's also on the e200v1, which is not AMS, which means that it's on all targets. 21.16.04 # linuxstb: yes - also had a short discussion with saratoga as you suggested 21.16.21 # yelped: What samplerate is the WAV file? 21.16.59 # yelped: is it a wav file you recorded with the OF? 21.16.59 # 24000 Hz. I uploaded a sample file in the comments. 21.17.03 # Yes. 21.18.26 # linuxstb: a saw all data in IRAM - but for a dsp function a don´t want to copy all data 21.18.59 # pixelma: did you see my question earlier regarding the iAudio M3 manual? 21.19.18 # mc2739: no 21.19.29 # 20:49:04 mc2739 for any manual developers: Is it a known problem that the iAudio M3 manual does not build? 21.20.46 # mc2739: yes because the Iaudio M3 is a special case - it has controls but no display on the main unit - and there is an LCD remote 21.21.23 # i keep having some "panic : scheduling bank 0 block **** for remap ! 21.21.46 # since when? and always bank 0? 21.21.49 # any idea what is the problem (on a nano2g) 21.22.04 Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 21.22.28 # TheSeven: i don't remember for the bank number but the block is different each time 21.22.56 # mc2739: I started to prepare some changes during DevCon but Real Life â„¢ kept me away from it for a while 21.22.57 # when did this start to happen? 21.23.00 Join GeekShado_ [0] (n=Antoine@234.232.198-77.rev.gaoland.net) 21.23.07 # and i have them since i have a RW FTL rockbox on my ipod 21.23.15 Quit mrtok1 () 21.23.49 # does it meen it plans a remap which is done by norboot ? 21.24.03 # pixelma: OK, I'll try to see if I can do anything with it. 21.24.21 # no, it's having trouble reading a sector and wants to schedule that for remap, but as i don't trust this yet, it's ending up in a panic 21.24.27 # markun, around? I'm looking for some advice on how to write to the m6 sp 21.25.01 # and i bet this is not a bad block but rather a bug somewhere. did you even have that with stoneage NAND driver versions before power management was introduced? 21.25.06 # mc2739: you... want to give me some incentive? 21.25.07 # it happens when i shut down rockbox or when i do a lot of writing on the flash (database init) 21.25.09 # and how often does it happen? 21.25.39 # TheSeven: i don't remember is there an svn revision i can test ? 21.26.04 Quit GeekShado_ (Client Quit) 21.26.07 # i would say one time out 5 shutdown 21.26.38 # pixelma: no, I'm just trying to get a better feel for the manuals and I thought the best way would be to dig into a real problem. 21.27.33 # pixelma: and I promise to not break it too much :) 21.28.14 # when (what svn revision) was the power management introduced in rockbox ? 21.28.24 # (nano2g) 21.28.48 # mc2739: if you are interested in the manuals - could you also take a look at LatexGuidelinesTalk and give an opinion about my suggestion/question (last item)? 21.29.09 # polobricolo: the revisions i suspect could have introduced the problems are 23099, 23106, 23115, 23126 or 23243 21.31.13 # pixelma: sure - looking now 21.32.09 # * polobricolo is testing revision 23098 21.32.12 # pixelma: I agree 21.32.50 # I just can't be bothered to make a start :) 21.34.49 # mc2739: The M3 manual is easy to make build (if somewhat time consuming) - the main problem is where buttons are referred to in the block text and not in button tables 21.35.29 # the M3 manual builds for me... I just have to dig up my changes :\ 21.35.39 # bertrik_: I'm here, but what kind of advice you need? 21.36.30 # markun, I think I got it now, the M6 wouldn't power-on anymore and also not be reprogrammed but I managed to make it boot again 21.36.50 # yes, hold some key combo for a really long time :) 21.37.05 # don't remember which one, we should put them in the wiki for all 3 players :) 21.37.22 # I tried power/play and BACK for about 30 seconds 21.39.28 Quit GeekShadow (Read error: 110 (Connection timed out)) 21.39.36 Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) 21.40.02 # pixelma: ping 21.40.16 # the latest clip patch seems to work fairly well 21.40.23 # over an hour without a deadlock for me 21.41.34 # saratoga: I tried with your debugging build and couldn't get it to crash at all 21.41.36 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 21.41.52 Quit yelped ("CGI:IRC (EOF)") 21.42.16 # AlexP: the debugging builds are quite stable, but its just due to the logging code changing timings a lot 21.42.28 # ah right 21.42.32 # hmm, I wonder - did I not commit those changes? 21.42.38 # tomers: pong 21.42.58 # i usually just let the thing go overnight off USB power to get deadlocks when logging 21.42.58 # pixelma: svn st ? ;) 21.43.07 # st? 21.43.19 # but logs from old builds aren't interesting now that we have a new fix to look at 21.43.59 # n1s: I'm not sure what I'm actually looking for (which changes were needed and what files (except the svg) 21.44.06 Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) 21.44.08 # pixelma: Regarding the USB HID feature in the manual, should I define an action for each USB HID action, and put all actions in each platform's file, or keep it the way I did, all platform's button definition in system_options.tex? 21.44.31 # AlexP: you could try the latest patch in FS#10605 and see if it works for you (without logging) 21.44.53 # New commit by 03bertrik (r23247): S5l8700: fix some CLCD controller register names 21.44.56 # saratoga: I'll give it a go tomorrow 21.45.52 # i'm cautiously optimistic that matsch has found the source of the clip deadlocks 21.46.19 # \o/ 21.46.21 # hes got quite a good eye to have found it in our buffering code 21.46.48 Join mrtok1 [0] (n=dummy@p5B39E9E6.dip.t-dialin.net) 21.47.31 # Matsch? urgh... ;) 21.48.03 # Matthias Schneider 21.48.31 # has anyone ever benchmarked a FLAKE encoded FLAC file in Rockbox? looking at x86 benchmarks, they seem to decode MUCH slower 21.48.53 # just read that, but Matsch is the German word for mud (and that's quite a German sounding name) 21.49.18 # ah 21.49.28 # i assumed it was just short for Matthias 21.49.38 # pixelma: You may not have committed your changes, or something else broke the M3 manuals since there are no daily manual builds for the M3 21.50.56 # I think I committed them and do a test build currently, there can be other reasons that it's not available as a daily. And even if it builds, I think it's fairly incomplete 21.51.24 # it doesn't 21.52.12 # but it breaks in the pictureflow plugin, so gets quite far I think 21.53.00 # that is where it stopped for me, too 21.55.12 # saratoga: Do you have a link to those flake benchmarks? 21.55.43 # linuxstb: http://flake-enc.sourceforge.net/benchmarks.html 21.55.45 # mc2739: that is further than the files my changes affected - and I see the error 21.56.24 # although from what I understand the CUDA enabled FLAKE can use even more aggressive encoding (since the GPU can do more extensive brute force searching of optimal codes or something) 21.57.10 # now to find the correct "Select" button for pictureflow, due to pluginlib actions that's not easy :\ 21.58.11 # linuxstb: I'll try a test file now 21.58.42 # saratoga: Yes, looks like flake is generating files with higher LPC orders, and that's giving a minimal compression advantage, with the disadvantage that it's much harder to decode. 22.00.44 # linuxstb: did you already do monkey's audio tests? 22.00.55 # how many % realtime are we? 22.01.26 # TheSeven: No 22.01.42 # linuxstb: http://duke.edu/~mgg6/rockbox/files1/flake.flac 22.01.57 # unfortunately I have only AMS devices in front of me and cannot test the file 22.03.07 Quit stoffel (Remote closed the connection) 22.03.22 # compression level 12 in flake 22.04.06 # I've just re-encoded with "flac -8", and it came out very slightly smaller (20581181 bytes vs 20599959 bytes) - maybe that's just metadata differences... 22.04.25 # when I did it flake was 43KB smaller 22.04.34 Quit ruj1 () 22.04.51 # mc2739: committing a fix in a bit. The pictureflow error was the only thing to make it build again. The next step would be to add HAVEREMOTEKEYMAP (or the like) to the options and fill out the button tables with the Iaudio remote mappings, you would have to read the code for it because the remote buttons are not simulated 22.04.55 # sorry 25KB smaller 22.04.55 # currently 22.05.07 # so yeah it looks fairly useless but still interesting to know if we can decode efficiently 22.05.09 # saratoga: Which version of flac? And did you decode to wav first? 22.05.31 # (I just did flac -8 -o flac.flac flake.flac) 22.05.33 # linuxstb: i just compared to the official flac-8 test file on the wiki 22.05.34 # flac 1.2.1 22.06.01 # tags says reference libFLAC 1.1.2 20050205 22.06.08 # so its an older file 22.07.08 # mc2739: or find a way to try remotes in the sim too (if you want something challenging ;) For the button tables: I'd really like if the mess was cleaned up too while at it or in an extra commit first but it's a lot of work 22.07.14 Quit midgey () 22.07.25 # see the wiki page I mentioned earlier 22.08.47 # saratoga: flake - "15.21MHz" (13.94s), flac - "14.71MHz" (13.48s) (on my Nano2G) 22.08.55 # pixelma: thanks, I will look into the remote keymap, but not promising anything quick 22.08.57 # ah good 22.09.02 # sounds like its a nonissue 22.09.40 # markun, I forgot something about the lcd: the lcd controller used by the m6sp wants 32-bit pixel (at least as far as I understand it) and rockbox does not support that 22.10.58 # I tried to come up with a quick hack where the 16-bit framebuffer data is converted to 32-bit framebuffer data in lcd_update_rect but I don't have enough RAM to even compile it ... 22.11.21 # bertrik_: Not enough RAM on the device? 22.11.56 # linuxstb, for now I'm running purely from IRAM 22.12.26 # Why is that? Could you put the bss in DRAM? 22.13.05 # maybe, but I'm not even sure DRAM is set up properly 22.14.26 # The nano2g bootloader does that - see boot.lds (it's a simple change). 22.15.03 # bertrik_: How big is the LCD? Could you just use a smaller than real size framebuffer? 22.15.12 # I had to revert the latest revision of boot.lds to make the meizu m3 boot properly again 22.15.29 # Oops, sorry... 22.15.32 # * linuxstb goes to look... 22.16.55 # I'm not saying it's your fault or anything like that, could be something in the m3 code too 22.17.08 # bertrik_: What revision are you using now? 22.17.50 # New commit by 03tomers (r23248): rbutil: Updated Hebrew translation 22.17.54 # r22879 22.18.02 # pixelma: ping 22.18.15 Quit gevaerts (Read error: 60 (Operation timed out)) 22.18.38 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 22.19.22 # New commit by 03tomers (r23249): Use pointer instead of multiple access to array 22.19.45 # * TheSeven will leave now and hopes he has a better connection again tomorrow. 22.20.02 # TheSeven: Good luck with the ADSL... 22.20.09 # so that i can actually try to update my tree again and commit the usb stuff 22.20.22 # sub-modem speed is really awful 22.20.46 # tomers: saw your question but got occupied with something else. I don't think it matters much but if you think those actions could appear somewhere else too it is nicer to have them in the platform files for easier reuse and for more consistency (as the other core actions got their part in the manual too there) 22.20.59 # bertrik_: The only change there I think was to put bss in DRAM... So obviously that isn't working for you. 22.21.41 # Unhelpful: is pictureflow really using core actions or only ones that were made "after" the core actions? 22.21.46 # TheSeven: Will the USB stuff be disabled when you commit? 22.22.28 # pixelma: I chose this method since indeed this was the only place where I thought they could use, and I didn't want to trash these platform files with so many actions. I guess I did the right decision... 22.22.44 # s/did/made/ 22.23.38 # linuxstb: I don't see a reason to keep it disabled 22.24.13 # TheSeven: Is it reliable? 22.25.03 Quit mrtok1 () 22.25.10 # still some minor glitches (especially the "hold the menu key for charging" thing only working around 90% of the times), but no hangs or such 22.25.25 # and i've self-updated rockbox multiple times today without any issue 22.25.37 # (besides rolo still not working) 22.26.27 # was that fixed in the meantime? (I'm still stuck at r23141) 22.27.28 # how much memory does the nano2g have? 22.27.40 # 32MB DRAM + 176KB IRAM 22.27.51 # I still think it would be sensible to not enable it by default, but give people chance to test, just in case of unexpected problems (like the NAND power-management caused) 22.28.31 # as long as you won't plug it, there's not much that will change 22.29.20 # post a test build in the forums, wait a week or two, then enable it would be my preference 22.29.40 # * TheSeven still wonders why 3 people are having trouble with the nand stuff, one of them having the same chip that i have, but not others 22.30.49 # huh Nano2Gs are cheapish on ebay, i might pick one up 22.32.05 # issues left: 1. nand powermanagement, 2. that pcm quirk for people who don't like their ipod sounding like a dirty vinyl record, 3. usb testing, 4. performance testing and improvements, 5. power management improvements 22.32.24 # 6. clickwheel acceleration 22.32.49 # oh yes, that also needs some calibration, i already noticed that 22.33.05 # which points me to another one: battery lifetime calibration 22.33.23 # saratoga: I don't think a test build is needed - the active nano2g users (i.e. people likely to test) seem to be compiling themselves. 22.33.57 # i haven't updated my nano 2g since r23156 which has worked great 22.34.05 # will try recent changes tomorrow 22.34.20 # I see all over the code that an instance of 'struct screen' is sometimes called 'display' and sometimes 'screen'. Don't you think this is a bit confusing? Should we have some sort of convention for this? 22.34.35 # topik: beware that we broke the PCM driver, which will now sound like dirty vinyl :-P 22.34.51 # TheSeven: "we" ? ;) 22.34.58 # only weird thing is the volume 22.34.59 # I'm working on a fix for that :-D 22.35.07 # what's up with the volume? 22.35.16 # on my fuze -15db is the same as -35db on the nano2g 22.35.39 # So the fuze is broken ;) 22.35.42 # oh, interesting 22.35.59 # i have no 3rd device to compare against 22.36.22 # The volume control is relative to line level 22.36.51 # AlexP: line level being defined by several manufacturers like they like it to be? 22.36.58 # if that's configurable, i never touched that on either device 22.37.03 # TheSeven: So it seems :) 22.37.13 # * TheSeven will do some measurements about that tomorrow 22.37.44 # topik: My point is, that AIUI (and I could be wrong) the volume is relative to the line out level of the hardware - this can be different between hardware 22.38.16 # fair enough, but shouldn't rockbox try to correct for the difference? 22.38.19 # linuxstb: do you know how the wmcodec works, if levels above 0dB can clip? 22.38.26 Nick bluebroth3r is now known as bluebrother (n=dom@rockbox/developer/bluebrother) 22.38.27 # so -20db is the same level on all devices? 22.39.01 # no 22.39.11 # It is relative to line level 22.39.20 # So you know when distortion will occur 22.39.30 # you can't really correct for different amplifier powers 22.39.59 # TheSeven: Yes, I think it will. 22.40.00 # it's not a problem, just an observation 22.40.18 # i am very excited about rockbox on both my players 22.40.25 # bluebrother: What's the status of beastpatcher? Is it ready for release on Windows? 22.40.29 # I would nevertheless suggest to at least keep the 0dB setting around 1V, so that externally connected stuff also won't clip. 22.41.32 # 0 dB should be non-clipping with no dsp 22.41.42 # no DAP can go that high though 22.41.53 # IIRC the AMS sansas max out around 150mV 22.42.16 # shame there seems little chance for my meizu m6 to join my other aging players as rockboxed 22.42.18 # I'll check tomorrow, but I think the ipods can go that high 22.42.23 Quit Grahack ("Leaving.") 22.43.02 # linuxstb: well, I haven't thought about what's needed to qualify as end-user ready. It can install the beasts bootloader and install a nk.bin with our bootloader. 22.43.21 # there's still this issue with some beasts rejecting a single bootloader installation 22.43.36 # and installing dual-boot requires using a command line switch. 22.43.39 # That can just be documented as a "known issue" though. 22.44.47 # sure, if we consider that good enough. 22.45.34 # oh, there is one issue I haven't figured: on linux the beast reboots once you installed the bootloader. On Windows it doesn't -- it reboots once you disconnect USB. 22.45.49 # * linuxstb can remember the initial "ipod_fw" way to install on an ipod - if we supported that, we can support the beast... 22.46.07 # which shouldn't be an issue for beastpatcher itself, but might cause issues once it's in rbutil 22.46.18 # issues are what make a port unstable, I saw write them up in the wiki and let people try it out 22.46.18 # I'd really like to have the beast as supported :) 22.46.23 # hmm, that's indeed a point :) 22.46.33 # n1s: me too ;-) 22.46.46 # maybe it'll encourage more people to work on the beast 22.46.54 # We need to stop talking about it and do it though... 22.47.02 # true. 22.47.16 # do we have an officially released bootloader for the beast? I've always used svn. 22.47.17 # Does beastpatcher compile as a single .exe now on Windows? 22.47.25 # No, there's never been an official bootloader binary 22.47.30 # linuxstb: yes, if you build it with VS2005 22.48.03 # Does it have the bootloader embedded? 22.48.09 # so we just need to release the bootloader, beastpatcher and rbutil, anything else? 22.48.13 # * linuxstb forgets what it does, even though he wrote it.... 22.48.23 # btw, I was thinking about an embedded dll approach. Just don't link against it but load it later using LoadLibrary. That way we could also build it with MinGW / cygwin. 22.48.39 *** Saving seen data "./dancer.seen" 22.48.49 # fixing or deleting this page would be nice: http://www.rockbox.org/wiki/GigabeatSInstallation 22.48.52 # manual is there, it just needs the links (and probably an explanation of single vs dual) - although we could go for dual by defualt and then let people who want single do it manually 22.48.52 # linuxstb: you can build it with or without embedded bootloader, like ipodpatcher. 22.49.08 # Step 1 would seem to be to release a bootloader - can someone with a beast build current svn, and call it "1.0" ? I think that's just done with "make VERSION=1.0" 22.49.09 Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) 22.49.25 # do we have a known source for the oOF nk.bin? 22.49.41 # there is a link on the wiki somewhere 22.49.45 # maybe just delete it since we have directions here: http://www.rockbox.org/wiki/GigabeatSInfo#Loading_code_from_Windows 22.49.53 # saratoga: What's wrong with it? 22.50.01 # bluebrother: toshiba released an update 22.50.11 # saratoga: I prefer the install page to the info page 22.50.25 # AlexP: update as in something that's in fact an archive one can extract it from? 22.50.25 # linuxstb: its got blank steps labeled TODO 22.50.40 # saratoga: That's not a reason to delete it... 22.50.43 # bluebrother: could rbutil give the user a choice of dual/single? 22.50.46 # i think the info page is more up to date 22.51.05 # then the info instructions should be removed or depreciated and then copied over 22.51.22 # There's lots of stuff on the info page that shouldn't be there - binary downloads, patched Toshiba software etc etc 22.51.27 # n1s: sure. There's a different issue though: rbutil requires a mount point, but until the bootloader is installed and the beast rebooted there is none. 22.51.41 # bluebrother: I'll need to check, but I think it can be extracted from the exe 22.51.41 # I thought the install page was more up to date 22.51.52 # It is just missing e.g. beastpatcher as it wasn't finished 22.51.56 # IMO thats biggest thing to do, even unofficial (i.e. linked in the test forum) binaries are fine as long as there are clear directions saying how to use them 22.52.10 # which means, especially for automated install, we need some means of rescanning the system for devices. Which in turn means we need better autodetection (which we need anyway) 22.52.19 # The install page is virtually there 22.52.34 # the test forum is a great tool imo. it made me test a lot on my fuze 22.52.43 Join einhirn [0] (n=Miranda@p5DCC091C.dip0.t-ipconnect.de) 22.52.43 # bluebrother: but if it requires a mountpoint, how can it install the bootloader at all? 22.52.47 # bluebrother: I don't think we should worry about rbutil - beastpatcher will be easy enough, and it will never be one of the most popular targets. 22.52.57 # (but that's up to you of course...) 22.53.32 # n1s: well, the bootloader is installed in MTP mode (we can't access the beast in UMS mode when the OF is run), and after a reboot the bootloader usb mode gives us MTP 22.53.43 # * linuxstb wonders if any beast owners are volunteering to build a 1.0 bootloader.... 22.53.48 # bluebrother: http://www.tacp.toshiba.com/tacpassets-images/firmware/MESV12US.zip - It is an exe in an iso in a zip 22.53.51 # linuxstb: Sure 22.54.27 # linuxstb: I suspect however that test it is implicit in that :) 22.54.27 # AlexP: As I said, just "make VERSION=1.0" should do it. And make a note of which SVN revision you've used, so we can tag it. 22.54.33 # AlexP: Yes... ;) 22.54.37 # bluebrother: yes, but installing a single or dual bootloader should require the same access 22.54.44 # linuxstb: Doing it now 22.55.10 Nick YPSY is now known as Ypsy (n=ypsy@87.106.45.183) 22.56.17 # I thought the issue with the Gigabeat S was that the bootloader installation didn't work the same on some units (or some working with the dual boot bootloader and some don't or so) - or has this been resolved? 22.56.22 Join evilnick [0] (n=evilnick@rockbox/staff/evilnick) 22.56.33 # pixelma: Single boot sometimes doesn't work on some units 22.56.57 # pixelma: Yes, that's still a problem. But I don't think it's enough to keep it out of "Unstable" (as long as we document it as a known issue) 22.59.04 Quit bluebrother (Nick collision from services.) 22.59.07 Join bluebroth3r [0] (n=dom@rockbox/developer/bluebrother) 22.59.24 Nick bluebroth3r is now known as bluebrother (n=dom@rockbox/developer/bluebrother) 22.59.37 # ok, got a beast bootloader identifying as 1.0 23.00.08 # me too :) 23.00.17 # http://aeparker.com/files/nk-v1-r23249.bin 23.00.27 Quit fyrestorm (Read error: 131 (Connection reset by peer)) 23.00.28 # And it works fine on my beast 23.00.50 Join fyrestorm [0] (n=nnscript@cpe-69-203-148-25.si.res.rr.com) 23.00.59 # bluebrother: What does beastpatcher need? The bootloader.bin? 23.01.06 # works fine for me too, at least when installing as dualboot 23.01.11 # yes 23.01.20 # ah right :) 23.01.27 # plus libmtp.a and libusb.a on linux 23.01.29 # well, that single boot nk.bin works fine here 23.01.46 # bluebrother: Then it's probably worth putting both on the download server... (the single-boot nk.bin and bootloader.bin) 23.01.57 # * linuxstb pings Bagder 23.02.09 # http://aeparker.com/files/bootloader-v1-r23249.bin 23.02.35 # * bluebrother has build r23249 too :) 23.03.31 # ok, so we're releasing a 1.0 bootloader now? Should I go for building a beastpatcher.exe with that? 23.03.37 # bluebrother: copycat! :) 23.03.48 # I don't see why not 23.04.01 # * linuxstb neither 23.04.18 # AlexP: I'm claiming being first -- my network had a short dropout :P 23.04.23 # Step 1 - release bootloader and beastpatcher ; Step 2 - update documentation; Step 3 - promote to unstable and profit. 23.04.23 # hehe :) 23.04.30 # * bluebrother prepares reboot 23.05.16 # anyone willing to build the linux binary? I would need to build libmtp first 23.05.25 # sure 23.05.41 # Although I think I'll have to build libmtp too :) 23.05.49 # I can do 64 bit here 23.06.22 Quit bmbl ("Bye!") 23.08.16 # * bluebrother in wxp now 23.08.21 # No, it seems not 23.08.27 Quit n1s ("Lämnar") 23.08.31 # just make builds it statically right? 23.08.50 # * linuxstb has built 32-bit linux 23.09.17 # yes. I'm usually changing the LIBS line to get it link with the systems libmtp 23.09.58 # http://aeparker.com/files/beastpatcher-linux64 23.09.59 Quit TheSeven (Read error: 110 (Connection timed out)) 23.10.31 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 23.10.33 # http://linuxstb.cream.org/rockbox/beastpatcher-linux32.tgz 23.11.07 # I can't test it as I no longer have the OF 23.11.21 # * AlexP goes to do a bit of compressing too 23.11.57 # AlexP: you can simply replace the nk.bin file on the other partition. At least it seemed to work when I played around with that a while back. 23.12.09 # bluebrother: I did - the bootloader is fine 23.12.20 # bluebrother: I mean I can't test beastpatcher 23.12.41 # It works fine for me "[ERR] No device found" 23.12.42 # AlexP: well, you could put an OF instead and then go through the process of reinstalling ;-) 23.13.11 # bluebrother: And risk things not working? ;) 23.14.06 # bluebrother: Yeah, I *could* ... :) 23.14.44 # AlexP: ;-) 23.15.17 # http://aeparker.com/files/beastpatcher-linux64.tgz 23.17.03 # Could someone put these in a nice directory hierarchy for Bagder/Zagor to put on the download server? I'm guessing we want them in /bootloader/gigabeat-s/ ? 23.17.42 # Or /bootloader/toshiba/gigabeat-s/ (and move gigabeat) 23.18.35 # Does beastpatcher work on Mac? 23.20.47 # hmm, I haven't added the creation of bootimg.c to the VS project. Ok, that can wait until after the release 23.21.25 # How does tagging work? 23.22.41 # See the UsingSVN wiki page. 23.23.30 # Cheers 23.24.09 # So we want bootloader_gigabeat-s_v1 I guess? 23.24.34 # New commit by 03alex (r23250): Tag release v2 of the Sansa E200 bootloader and sansapatcher 23.24.36 # hmm, something is wrong on windows :( 23.24.50 # what the hell 23.24.52 # e200 bootloader? 23.25.02 # v2? 23.25.12 # I didn't do that in the checkout 23.25.34 # I was in a completely different directory, and I was pasting from the UsingSVN page to edit it for this one 23.25.42 # So, next question: 23.25.47 Quit pamaury ("exit(*(int *)0 / 0);") 23.25.48 # How do I undo that? 23.26.00 # if I configure the LCD pins on the meizu m6sp (through PCON_ASRAM), it hangs ... 23.26.04 # svn rm 23.26.10 # kugel: Thanks 23.26.12 # AlexP: svn rm svn://..., then svn cp svn://... svn:// 23.26.32 # if you invoke svn with full urls you don't need to do this in a checkout 23.26.55 Quit einhirn (Read error: 104 (Connection reset by peer)) 23.27.07 # So svn rm svn://svn.rockbox.org/rockbox/tags/bootloader_e200_v2 ? 23.27.17 # yes 23.27.18 # bluebrother: Thanks, wish I had know that before :) 23.27.51 # New commit by 03alex (r23251): Revert previous completely accidental commit. 23.28.10 # AlexP: it wouldn't make much sense having to checkout tags/ first, would it? Could become quite large ;-) 23.28.22 # true :) 23.29.58 # gnah. beastpatcher works fine when build as debug executable but not when build as release. Seems I've missed that before :( 23.31.52 # beastpatcher here is v1 too, so it can be tagged as both right (as in the accidental e200 one above)? 23.32.50 # I'd say so 23.32.58 # OK 23.33.22 # AlexP: for plugins the 3 column button tables is a bit weird on the M3 as usually only remote buttons are mapped (maybe a quit here and there)... maybe not much of a difference to remote buttons on the H100 - just the other way around 23.33.49 # OK, let's try again :) 23.34.11 # AlexP: To answer your earlier question, beastpatcher _should_ work on Mac (libusb works there, so libMTP _should), but no-one has managed to get it to compile. 23.34.57 # New commit by 03alex (r23252): Tag release v1 of the Toshiba Gigabeat S bootloader and beastpatcher 23.35.06 Join GeekShadow [0] (n=Antoine@92.136.173.52) 23.39.08 # linuxstb: The lack on mac wielding people strikes again - I guess we just leave it out for now 23.40.05 # anyone with a windows box around that can check if a debug binary works? 23.40.36 # somethings broken with the release build in VS -- it works partly 23.49.09 Join webguest08 [0] (n=63425d10@giant.haxx.se) 23.49.14 Quit webguest08 (Client Quit) 23.52.42 # * bertrik_ is trying to run something on the meizu m6 directly from ram 23.54.27 # bluebrother: do you need any special windows setup for your test? 23.54.34 # AlexP: Yes, we don't have any choice... Yet another thing missing for the beast... 23.55.04 # mc2739: no, but you shouldn't have any visual studio installation (read: windows development tools) installed. 23.55.20 # all you need to check is if the binary runs at all 23.55.38 # http://www.alice-dsl.net/dominik.riebeling/rockbox/beastpatcher.exe 23.55.39 # I don't have visual studio installed 23.55.47 Join Thundercloud [0] (i=thunderc@81.187.69.84) 23.55.49 # is win 7 rc ok? 23.56.12 # should be. At least we get to know if it does work on w7 at all :) 23.56.19 # [INFO] Found device "SanDisk - SANSA CLIP (D:)" 23.56.21 # heh 23.56.47 # bootloader installed successfully on my sansa clip 23.56.49 # oh. We might need to be more careful here to make sure we're not sending a beast firmware to a different player. 23.57.06 Quit liar ("Verlassend") 23.57.27 # bluebrother: What are beastpatcher's requirements? Does it need a certain version of WMP installed? 23.57.41 # which of course raises the question if it's possible to install the bootloader on other player that way. Like the H10MTP 23.57.45 # clip didn't seem to mind having the beast bootloader installed, I guess since it was in UMS mode 23.58.03 # bluebrother: did you see this? http://forums.rockbox.org/index.php?topic=22961.0 23.58.14 # rbutil thinks e200v1 is v2 23.58.40 # I have not confirmed yet