| 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 | TheSeven | YEAH! |
| 00:19:34 | TheSeven | Highspeed UMS working! |
| 00:19:55 | TheSeven | 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 | linuxstb | TheSeven: congratulations! |
| 00:22:51 | TheSeven | but i won't commit it :-P |
| 00:23:07 | Farthen | ;( |
| 00:23:12 | TheSeven | 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 | TheSeven | (which may very well break other targets) |
| 00:24:13 | TheSeven | 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 | linuxstb | TheSeven: Probably best to post a patch and see what others say... |
| 00:29:00 | | Quit robin0800 (Remote closed the connection) |
| 00:29:22 | TheSeven | I |
| 00:29:40 | TheSeven | I'll first commit some other things I need as a base for it, i.e. MMU fixes |
| 00:30:49 | TheSeven | ah, forgot I have that slow internet connection right now |
| 00:31:05 | TheSeven | I would need to update first, which I just can't do right now |
| 00:31:59 | TheSeven | let's see if we can do it by only updating some relevant files |
| 00:32:47 | CIA-85 | New commit by theseven (r23237): Adjust iPod Nano 2G CPU speed to 192MHz, which measurements show it to be. Timers will be more accurate now. |
| 00:33:07 | TheSeven | 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 |
| 01:00:50 | CIA-85 | New commit by theseven (r23238): Implement iPod Nano 2G nand_get_info() |
| 01:06:46 | CIA-85 | New commit by theseven (r23239): Fix S5L870x cache coherency functions. They were split into a different file, as changes were needed all over the place. |
| 01:08:52 | CIA-85 | New commit by theseven (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 | saratoga | are the keys for the virtual keyboard anywhere in the manual? |
| 01:11:22 | saratoga | 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 | pixelma | saratoga: they are |
| 01:22:34 | saratoga | where? |
| 01:23:21 | pixelma | 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 | bertrik | 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 | TheSeven | bertrik: where? |
| 01:29:39 | bertrik | ./firmware/common/timefuncs.c:67: if (current_tick > timeout) |
| 01:29:39 | bertrik | ./apps/tagcache.c:355: if (current_tick >= wakeup_tick) |
| 01:29:39 | bertrik | for example |
| 01:30:23 | saratoga | 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 | pixelma | saratoga: where is it missing? |
| 01:33:49 | saratoga | http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch4.html#x7-420004.1.3 |
| 01:34:02 | TheSeven | gevaerts: what's the intended way to re-setup the default control pipe for receiving the next control packet? |
| 01:34:30 | TheSeven | 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 | TheSeven | is that correct? |
| 01:34:45 | gevaerts | I think so |
| 01:34:56 | TheSeven | ok, then there is a bug in usb_core. |
| 01:35:11 | gevaerts | you mean it was a trick question? ;) |
| 01:35:29 | pixelma | saratoga: aha, I guess the Fuze manual isn't as advanced as others yet |
| 01:35:38 | saratoga | the keymaps are in for it |
| 01:35:41 | saratoga | i wonder why it doesn't show |
| 01:36:13 | TheSeven | 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 | saratoga | i don't have tex installed but perhaps theres a compile error or warning on that section? |
| 01:37:01 | TheSeven | 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 | TheSeven | (instead of the way intended by the USB specs, answering with NAK until the receive request is there) |
| 01:38:40 | TheSeven | 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 | TheSeven | 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 | TheSeven | this fixed it for me, after hunting that weird lockup-when-debugging issue for days |
| 01:40:13 | TheSeven | (this still doesn't explain why it did lock up, but at least it was the root cause of it) |
| 01:40:22 | pixelma | 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 | saratoga | so it just needs to be added? |
| 01:41:17 | TheSeven | so I'm suggesting to move lines 614 and 615 upwards in that code, between lines 602 and 603 |
| 01:41:53 | TheSeven | (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 | pixelma | 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 | saratoga | it looks like it does |
| 01:42:10 | saratoga | the entry is nearly identical to the e200 |
| 01:42:12 | saratoga | but i can't test here |
| 01:42:33 | saratoga | assuming keymap-fuze is all thats needed anyway |
| 01:42:53 | pixelma | yes |
| 01:43:47 | TheSeven | s/there/there may/ |
| 01:44:01 | gevaerts | TheSeven: I'm not entirely convinced it's that simple. Is that allowed for both directions? |
| 01:44:56 | TheSeven | the problem will come up with every non-SETUP packet received by the device |
| 01:45:18 | pixelma | 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 | TheSeven | so this should only happen for control transactions that have a DATA IN stage |
| 01:46:30 | gevaerts | TheSeven: yes. We probably need to split the usb_core_ack_control() function I guess |
| 01:47:35 | TheSeven | 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 | gevaerts | possibly, or make a usb_drv_send_control() that does that |
| 01:48:33 | gevaerts | I'd prefer not to export this complication to non-control |
| 01:48:52 | TheSeven | it will only happen for EP0 anyways |
| 01:49:25 | TheSeven | so you got what the issue is? then I'll go to sleep now |
| 01:49:33 | gevaerts | do we ever want usb_drv_send() on EP0 without the 0-byte DATA OUT? |
| 01:49:58 | mc2739 | saratoga: I can test manual changes if you need |
| 01:50:40 | TheSeven | 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 | TheSeven | 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 | gevaerts | 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 | TheSeven | imposing an unneccessary realtime requirement in the microsecond range isn't good at all. |
| 01:52:12 | TheSeven | yes, mine too |
| 01:52:24 | gevaerts | definitely not. Any timing constraint should go |
| 01:54:00 | gevaerts | I'm not sure if all controllers will like a recv() on EP0 before sending |
| 01:54:20 | TheSeven | yes, that's why i'm asking you what to do about this :-) |
| 01:55:02 | gevaerts | 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 | TheSeven | but we really should look at that tomorrow, I'm almost falling asleep after a long day of hunting this |
| 01:55:13 | gevaerts | good idea |
| 01:57:13 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 02:00 |
| 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 | midgey | http://rockbox.pastebin.ca/1626141 for anyone interested |
| 02:16:27 | | Join AndyIL [0] (n=pasha_in@212.14.205.32) |
| 02:17:05 | n1s | midgey: that's great |
| 02:17:15 | n1s | \o/ |
| 02:17:28 | midgey | slowly but surely i'm merging it in... |
| 02:19:53 | | Quit peter__b (Read error: 145 (Connection timed out)) |
| 02:21:36 | midgey | 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 | metalman1253 | does anybody know how to fix the database on ipod nano 2g |
| 02:54:03 | mc2739 | metalman1253: what is happening? |
| 02:54:50 | metalman1253 | it initilizes fine but then on boot it panics hold on let me recreate it to get the message |
| 02:55:21 | mc2739 | do you have dircache turned on? |
| 02:56:07 | metalman1253 | wait nevermind i guess installing iloader fixed it |
| 02:56:45 | CIA-85 | New commit by midgey34 (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 | mc2739 | ok, if it comes back see: http://www.rockbox.org/tracker/task/10679 |
| 03:00 |
| 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 | metalman1253 | 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 | mc2739 | 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 | sinthetek | i am not sure why but my wps isn't displaying properly anymore |
| 03:39:27 | sinthetek | 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 | mc2739 | 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 | yelped | 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:00 |
| 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 |
| 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 | sinthetek | mc2739 nm, i reinstalled over it and it works fine now |
| 05:22:37 | sinthetek | 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:00 |
| 06:14:18 | CIA-85 | New commit by mc2739 (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:00 |
| 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:00 |
| 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 | sliverchair | 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 | sliverchair | any comment on this? NWZ-E436 vs. iPod Nano 4G? |
| 08:36:41 | robin0800 | sliverchair most of the players rockbox runs on can be found on e-bay or other refurbished/bankrupt stock website |
| 08:37:28 | sliverchair | robin0800, hmm, got no experience with shipping internationally |
| 08:38:12 | sliverchair | robin0800, is there any reason why I shouldn't buy NWZ-E436 over an Nano 4g? |
| 08:39:00 | robin0800 | sliverchair: no idea |
| 08:40:22 | | Join stoffel [0] (n=quassel@p57B4F50D.dip.t-dialin.net) |
| 08:40:43 | mc2739 | sliverchair: that's not really on topic for this channel since Rockbox does not currently run on either of those devices |
| 08:41:47 | sliverchair | 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 | mc2739 | 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:00 |
| 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 | webguest74 | hi. can any 1 help whenever i click on ROMs there are no ROMs? |
| 09:44:48 | mc2739 | webguest74: what ROMs are you looking for? |
| 09:45:00 | | Quit BHSPitLappy ("Ex-Chat") |
| 09:45:09 | webguest74 | i usually play pokemon on the ipod and all of a sudden no games are there |
| 09:46:24 | mc2739 | webguest74: go to your quickscreen and make sure it is set for "supported" or "all" files |
| 09:48:56 | webguest74 | thanks alot |
| 09:49:10 | mc2739 | you're welcome |
| 09:53:10 | | Part OttoScratchansni |
| 10:00 |
| 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:00 |
| 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 | phanboy4 | 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 | TheSeven | gevaerts: ping |
| 11:59:51 | | Join casainho [0] (n=chatzill@bl15-108-152.dsl.telepac.pt) |
| 12:00 |
| 12:03:33 | casainho | 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 | n1s | linuxstb: ping |
| 12:43:41 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 12:45:34 | n1s | 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 | n1s | yeah, that was it /me facepalnms |
| 13:00 |
| 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 | amiconn | TheSeven: Does that wrong order of things potentially affect all transfers, or just enumeration? |
| 13:26:51 | amiconn | 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 | TheSeven | 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 | TheSeven | however, it will only affect control traffic on EP0, not bulk traffic |
| 13:50:54 | amiconn | hmm |
| 13:51:07 | TheSeven | but requests like getmaxlun are also done through that control pipe, so it may as well have an impact after enumeration |
| 14:00 |
| 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 | gevaerts | TheSeven: pong |
| 14:08:21 | TheSeven | gevaerts: ack |
| 14:08:40 | gevaerts | amiconn: the remaining occasional PP resets don't seem at all related to this |
| 14:09:03 | gevaerts | 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 | gevaerts | TheSeven: also FS #10684 apparently |
| 14:10:00 | TheSeven | oh, nice one. I'll look into this |
| 14:10:21 | TheSeven | 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 | gevaerts | no, I managed to keep the issue out of my mind all this time |
| 14:14:14 | gevaerts | 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 | TheSeven | gevaerts: this would increase the amount of work needed to be done to implement new controllers |
| 14:17:08 | TheSeven | 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 | gevaerts | 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 | Utchybann | TheSeven: it seems that your latest commit introduce some sound play back artifact. |
| 14:25:52 | TheSeven | funny. actually it should prevent them. |
| 14:26:11 | Utchybann | TheSeven: I have switched back to r23230 and get a clear sound again. |
| 14:26:31 | TheSeven | what kind of artifact? |
| 14:27:19 | Utchybann | TheSeven: artifact are very similar to those of vinyl records. |
| 14:27:49 | Utchybann | TheSeven: I got them for both mp3 and flac. |
| 14:28:51 | TheSeven | oh yes, there is some light popping action :-/ |
| 14:30:15 | TheSeven | 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 | Utchybann | TheSeven: I follow your USB progress so sorry to disturb you with PCM issues :D |
| 14:33:13 | TheSeven | 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 | CIA-85 | New commit by theseven (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 | gevaerts | 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 | TheSeven | so you would vote for a usb_drv_sendrecv0 function? |
| 14:39:58 | TheSeven | (or whatever you would like to call it) |
| 14:40:16 | gevaerts | 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 | gevaerts | 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 | TheSeven | in theory every hardware should be able to handle that, as they're independant endpoints |
| 14:41:31 | TheSeven | 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 | gevaerts | ah yes, those should be filtered out as well |
| 14:42:03 | gevaerts | so ep==0, direction==IN, length>0 |
| 14:42:26 | TheSeven | direction==IN should be implied by the fact that it's a send() function :-) |
| 14:43:09 | gevaerts | hm, good point :) |
| 14:43:38 | TheSeven | (even though this may look backwards to people who don't know USB :-P ) |
| 14:44:39 | gevaerts | 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 | TheSeven | what's the point in that? |
| 14:45:55 | gevaerts | making drivers two lines shorter |
| 14:46:21 | TheSeven | 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 | funman | TheSeven: do you know you can get details on the caches of s5l8701 by reading cp15 register 0, cache type ? |
| 14:49:30 | TheSeven | funman: It looks like whatever the 940T spec says is correct |
| 14:49:44 | funman | does it say cache line size is 16 bytes ? |
| 14:49:53 | | Part Ubuntuxer |
| 14:49:55 | TheSeven | yep |
| 14:50:15 | funman | perhaps we could define cache line and keep the code in common |
| 14:50:34 | TheSeven | which code? |
| 14:50:35 | | Quit _zic ("Ухожу") |
| 14:50:40 | funman | *cache() |
| 14:51:04 | TheSeven | this would be an ifdef hell |
| 14:51:11 | funman | well not really |
| 14:51:16 | funman | more like add r0, r0, CACHE_LINE |
| 14:51:16 | gevaerts | TheSeven: that would imply doing it explicitely, but maybe that's better |
| 14:51:22 | * | gevaerts prepares a patch |
| 14:52:02 | funman | also invalidating the entire dcache while you could invalidate only a range is quite slow no ? |
| 14:52:42 | TheSeven | funman: can I invalidate a range? |
| 14:53:00 | funman | yes, see invalidate_dcache_range() |
| 14:53:10 | TheSeven | 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 | TheSeven | i can only kick cache lines out, not cache tags |
| 14:54:10 | funman | ah you can't use MVA :/ |
| 14:54:38 | funman | i assumed since 940 > 922 it would be possible like on the arm922tdmi |
| 14:55:20 | funman | then yeah it makes sense to have these functions separated |
| 14:55:51 | funman | ideally they should be separated as mmu-arm940.S mmu-armv6.S .. |
| 14:56:55 | TheSeven | i would rather consider mmu-armv4.S and mmu-armv6.S |
| 14:56:57 | funman | didn't you mention that 940T has no mmu ? |
| 14:57:34 | TheSeven | 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 | funman | rockbox design is flexible ;) |
| 14:58:39 | TheSeven | 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 | amiconn | mmu-armv4.S would be wrong |
| 14:58:58 | amiconn | ARM7TDMI is armv4 as well, but has no mmu |
| 14:59:20 | TheSeven | this thing doesn't have a real MMU either, just cache stuff |
| 14:59:23 | amiconn | It doesn't have CP15 either, which is what this caching stuff is about |
| 14:59:36 | TheSeven | so it doesn't have any caches at all= |
| 14:59:42 | amiconn | It does |
| 15:00 |
| 15:00:01 | amiconn | PP controls its caches by a proprietary method |
| 15:00:15 | TheSeven | bah. |
| 15:02:30 | * | TheSeven just spotted an s5l870x DMA bug |
| 15:05:28 | TheSeven | bertrik: ping |
| 15:05:42 | bertrik | TheSeven, hi |
| 15:06:04 | TheSeven | bertrik: is anything besides PCM actually using the s5l870x DMA right now? |
| 15:06:18 | bertrik | no I don't think so |
| 15:06:50 | TheSeven | 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 | TheSeven | sounds like we need some double buffering there |
| 15:07:16 | CIA-85 | New commit by funman (r23244): Split ARMv6 code from mmu-arm.S |
| 15:07:33 | bertrik | 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 | TheSeven | bertrik: obviously not enough |
| 15:08:09 | bertrik | to allow it continue playing while we set up the next DMA |
| 15:08:20 | TheSeven | 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 | bertrik | TheSeven, what is the maximum gap you can tolerate without playback gaps? |
| 15:09:34 | funman | git-svn doesn't have an equivalent for svn cp :/ |
| 15:10:20 | TheSeven | bertrik: currently around 10 to 20 µS |
| 15:10:22 | bertrik | oh, one sample is obviously not enough ... :) |
| 15:10:27 | TheSeven | which is clearly too small |
| 15:11:57 | funman | TheSeven: what do you think of renaming s5l8700/mmu-* to caching-* ? |
| 15:12:27 | bertrik | I thought the IIS had some buffering |
| 15:12:29 | funman | mmu-target.h is only used inside the target folder (those functions are already defined in another header) |
| 15:12:46 | TheSeven | bertrik: the wmcodec maybe has, but not the I2S controller |
| 15:12:47 | funman | hmm .. mmu-arm.h |
| 15:13:10 | gevaerts | TheSeven: it's the usb_drv_send()+expect ack change that needs to change, right? |
| 15:13:39 | TheSeven | s/ack change/ack case/? |
| 15:13:50 | gevaerts | yes |
| 15:14:55 | TheSeven | 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 | TheSeven | this is the case for setup=>data=>ack-style requests, but maybe also other things... (getmaxlun?) |
| 15:15:20 | amiconn | TheSeven: Weird design. I'd expect a fifo for 8 or 16 samples |
| 15:15:37 | gevaerts | getmaxlun is exactly the same as a get descriptor |
| 15:16:02 | TheSeven | 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 | TheSeven | bertrik: spotted another nice bug in there: for (channel = 0; channel < 4; channel++) { if (DMAALLST & mask) { |
| 15:18:29 | TheSeven | ...without shifting the mask! |
| 15:18:41 | bertrik | mask <<=4 is there somewhere IIRC |
| 15:18:49 | TheSeven | ah, wait, it's shifted below |
| 15:21:46 | bertrik | 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 | gevaerts | 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:00 |
| 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 | gevaerts | 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 | TheSeven | what's that? |
| 16:15:19 | gevaerts | that's from rockbox-info.txt on my mr500. Those blank features shouldn't be there I think |
| 16:15:45 | funman | doesn't it have the feature_hiding feature ? |
| 16:15:49 | gevaerts | TheSeven: can you test if FS #10687 fixes your issues? |
| 16:16:43 | gevaerts | 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 | TheSeven | bertrik: and the s5l8701 DMA doesn't even seem to support auto-reloading! |
| 16:24:27 | CIA-85 | New commit by gevaerts (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 | TheSeven | bertrik: do you have any idea on how to resolve this? |
| 16:30:40 | TheSeven | 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 | bertrik | TheSeven, no sorry, don't know yet |
| 16:54:01 | | Join duffrecords [0] (n=iyoung@dtnoc.alchemy.net) |
| 17:00 |
| 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 | CIA-85 | New commit by bertrik (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 |
| 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 | TheSeven | 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 |
| 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 | yelped | 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 | duffrecords | 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 | kugel | yea, many peoplpe |
| 19:31:57 | kugel | 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 | TheSeven | 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 | duffrecords | kugel: what sort of bad files? incompatible format? something weird in the ID3 tag? |
| 19:43:46 | kugel | duffrecords: corrupted tags |
| 19:45:16 | kugel | does it show a filename in the database debug screen? |
| 19:47:02 | duffrecords | no, Curfile is −−- |
| 19:47:38 | duffrecords | 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 | pixelma | 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 | pixelma | as far as I know the H10 even has a remote but a non-LCD one |
| 19:55:48 | kugel | 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 | duffrecords | 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 | duffrecords | or by moving the folders into new A-M and N-Z folders, and so on, using a half-splitting method |
| 20:00 |
| 20:00:58 | linuxstb | duffrecords: It's also worth checking your filesystem for errors (e.g. chkdsk, fsck.vfat) |
| 20:01:23 | duffrecords | or whatever has the best O(n) time |
| 20:01:40 | duffrecords | yeah, I did a chkdsk and defrag |
| 20:02:03 | duffrecords | errors are fixed, but the database still won't finish building |
| 20:02:17 | kugel | what target? |
| 20:02:33 | duffrecords | 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 | TheSeven | ok, dma refresh latencies are ~2µS now |
| 20:16:15 | | Join togetic [0] (n=togetic@unaffiliated/ibuffy) |
| 20:16:31 | TheSeven | 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 | kkurbjun | 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 | kugel | TheSeven: the code in pcmbuf.c works for every other target, why does it need changing for nano2g? |
| 20:42:02 | TheSeven | kugel: the buffers in the s5l8701's i2s controller seem to be extremely small |
| 20:42:35 | TheSeven | 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 | TheSeven | the only solution to this that i can see is double-buffering audio output, and this needs some small changes |
| 20:43:28 | polobricolo | TheSeven: stupid question, isn't the audio already working |
| 20:43:50 | TheSeven | there is some light clicking/popping action when refreshing the DMA |
| 20:44:36 | TheSeven | 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 | TheSeven | 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 | kkurbjun | 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 | TheSeven | 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 | mc2739 | for any manual developers: Is it a known problem that the iAudio M3 manual does not build? |
| 20:49:13 | kkurbjun | 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 | kkurbjun | 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 | TheSeven | 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 | kugel | TheSeven: it was originally for a v4 arm (922T) |
| 20:51:50 | TheSeven | bah, so this isn't even consistent among ARM4 cores... |
| 20:51:51 | kkurbjun | 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 | kugel | TheSeven: various v4 targets use that file |
| 20:52:31 | TheSeven | kkurbjun: on the 922T you can flush memory regions, on the 940T you can't, for example |
| 20:52:39 | TheSeven | and then there is all this TTB stuff |
| 20:54:08 | TheSeven | gevaerts: your USB patch is working fine for me |
| 20:56:29 | kkurbjun | 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 | kkurbjun | hmm, looking at the 940 assembly though it looks like they may have implemented separate from arch on the 940. |
| 20:59:47 | gevaerts | TheSeven: ok. As soon as mcuelenaere has tested on his targets, it can go in |
| 21:00 |
| 21:00:16 | | Join n1s [0] (n=n1s@cm-84.215.127.139.getinternet.no) |
| 21:00:34 | TheSeven | 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 | mrtok1 | someone here who can explain differences between COP and MAIN_CPU on ipod nano 1g ? |
| 21:07:18 | TheSeven | that pp has 2 cores, right? |
| 21:07:23 | mrtok1 | yep |
| 21:09:25 | | Join yelped [0] (n=ad442244@giant.haxx.se) |
| 21:09:53 | mrtok1 | symptons are: processing dsp function on MAIN_CPU -> sounds good , doing on COP artefacts occur |
| 21:10:26 | linuxstb | mrtok1: The problem is likely to be cache coherency between the two cores. |
| 21:10:38 | linuxstb | (they have independent caches) |
| 21:11:04 | yelped | 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 | kkurbjun | it looks like they do most if by the core version does the samsung yps3 use the sl5L870X |
| 21:11:54 | kkurbjun | looks like it does |
| 21:12:27 | linuxstb | 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 | mrtok1 | 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 | linuxstb | 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 | pixelma | linuxstb: shouldn't the plugin be disabled then? Though I can imagine that the error is in something Fuze specific too... |
| 21:14:51 | yelped | 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 | linuxstb | 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 | yelped | It's also on the e200v1, which is not AMS, which means that it's on all targets. |
| 21:16:04 | mrtok1 | linuxstb: yes - also had a short discussion with saratoga as you suggested |
| 21:16:21 | linuxstb | yelped: What samplerate is the WAV file? |
| 21:16:59 | pixelma | yelped: is it a wav file you recorded with the OF? |
| 21:16:59 | yelped | 24000 Hz. I uploaded a sample file in the comments. |
| 21:17:03 | yelped | Yes. |
| 21:18:26 | mrtok1 | linuxstb: a saw all data in IRAM - but for a dsp function a don´t want to copy all data |
| 21:18:59 | mc2739 | pixelma: did you see my question earlier regarding the iAudio M3 manual? |
| 21:19:18 | pixelma | mc2739: no |
| 21:19:29 | mc2739 | 20:49:04mc2739for any manual developers: Is it a known problem that the iAudio M3 manual does not build? |
| 21:20:46 | pixelma | 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 | polobricolo | i keep having some "panic : scheduling bank 0 block **** for remap ! |
| 21:21:46 | TheSeven | since when? and always bank 0? |
| 21:21:49 | polobricolo | 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 | polobricolo | TheSeven: i don't remember for the bank number but the block is different each time |
| 21:22:56 | pixelma | mc2739: I started to prepare some changes during DevCon but Real Life â„¢ kept me away from it for a while |
| 21:22:57 | TheSeven | when did this start to happen? |
| 21:23:00 | | Join GeekShado_ [0] (n=Antoine@234.232.198-77.rev.gaoland.net) |
| 21:23:07 | polobricolo | and i have them since i have a RW FTL rockbox on my ipod |
| 21:23:15 | | Quit mrtok1 () |
| 21:23:49 | polobricolo | does it meen it plans a remap which is done by norboot ? |
| 21:24:03 | mc2739 | pixelma: OK, I'll try to see if I can do anything with it. |
| 21:24:21 | TheSeven | 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 | bertrik_ | markun, around? I'm looking for some advice on how to write to the m6 sp |
| 21:25:01 | TheSeven | 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 | pixelma | mc2739: you... want to give me some incentive? |
| 21:25:07 | polobricolo | it happens when i shut down rockbox or when i do a lot of writing on the flash (database init) |
| 21:25:09 | TheSeven | and how often does it happen? |
| 21:25:39 | polobricolo | TheSeven: i don't remember is there an svn revision i can test ? |
| 21:26:04 | | Quit GeekShado_ (Client Quit) |
| 21:26:07 | polobricolo | i would say one time out 5 shutdown |
| 21:26:38 | mc2739 | 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 | mc2739 | pixelma: and I promise to not break it too much :) |
| 21:28:14 | polobricolo | when (what svn revision) was the power management introduced in rockbox ? |
| 21:28:24 | polobricolo | (nano2g) |
| 21:28:48 | pixelma | 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 | TheSeven | polobricolo: the revisions i suspect could have introduced the problems are 23099, 23106, 23115, 23126 or 23243 |
| 21:31:13 | mc2739 | pixelma: sure - looking now |
| 21:32:09 | * | polobricolo is testing revision 23098 |
| 21:32:12 | AlexP | pixelma: I agree |
| 21:32:50 | AlexP | I just can't be bothered to make a start :) |
| 21:34:49 | AlexP | 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 | pixelma | the M3 manual builds for me... I just have to dig up my changes :\ |
| 21:35:39 | markun | bertrik_: I'm here, but what kind of advice you need? |
| 21:36:30 | bertrik_ | 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 | markun | yes, hold some key combo for a really long time :) |
| 21:37:05 | markun | don't remember which one, we should put them in the wiki for all 3 players :) |
| 21:37:22 | bertrik_ | 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 | tomers | pixelma: ping |
| 21:40:16 | saratoga | the latest clip patch seems to work fairly well |
| 21:40:23 | saratoga | over an hour without a deadlock for me |
| 21:41:34 | AlexP | 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 | saratoga | AlexP: the debugging builds are quite stable, but its just due to the logging code changing timings a lot |
| 21:42:28 | AlexP | ah right |
| 21:42:32 | pixelma | hmm, I wonder - did I not commit those changes? |
| 21:42:38 | pixelma | tomers: pong |
| 21:42:58 | saratoga | i usually just let the thing go overnight off USB power to get deadlocks when logging |
| 21:42:58 | n1s | pixelma: svn st ? ;) |
| 21:43:07 | pixelma | st? |
| 21:43:19 | saratoga | but logs from old builds aren't interesting now that we have a new fix to look at |
| 21:43:59 | pixelma | 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 | tomers | 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 | saratoga | AlexP: you could try the latest patch in FS #10605 and see if it works for you (without logging) |
| 21:44:53 | CIA-85 | New commit by bertrik (r23247): S5l8700: fix some CLCD controller register names |
| 21:44:56 | AlexP | saratoga: I'll give it a go tomorrow |
| 21:45:52 | saratoga | i'm cautiously optimistic that matsch has found the source of the clip deadlocks |
| 21:46:19 | bertrik_ | \o/ |
| 21:46:21 | saratoga | 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 | pixelma | Matsch? urgh... ;) |
| 21:48:03 | saratoga | Matthias Schneider |
| 21:48:31 | saratoga | has anyone ever benchmarked a FLAKE encoded FLAC file in Rockbox? looking at x86 benchmarks, they seem to decode MUCH slower |
| 21:48:53 | pixelma | just read that, but Matsch is the German word for mud (and that's quite a German sounding name) </off-topic> |
| 21:49:18 | saratoga | ah |
| 21:49:28 | saratoga | i assumed it was just short for Matthias |
| 21:49:38 | mc2739 | 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 | pixelma | 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 | pixelma | it doesn't |
| 21:52:12 | pixelma | but it breaks in the pictureflow plugin, so gets quite far I think |
| 21:53:00 | mc2739 | that is where it stopped for me, too |
| 21:55:12 | linuxstb | saratoga: Do you have a link to those flake benchmarks? |
| 21:55:43 | saratoga | linuxstb: http://flake-enc.sourceforge.net/benchmarks.html |
| 21:55:45 | pixelma | mc2739: that is further than the files my changes affected - and I see the error |
| 21:56:24 | saratoga | 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 | pixelma | now to find the correct "Select" button for pictureflow, due to pluginlib actions that's not easy :\ |
| 21:58:11 | saratoga | linuxstb: I'll try a test file now |
| 21:58:42 | linuxstb | 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 |
| 22:00:44 | TheSeven | linuxstb: did you already do monkey's audio tests? |
| 22:00:55 | TheSeven | how many % realtime are we? |
| 22:01:26 | linuxstb | TheSeven: No |
| 22:01:42 | saratoga | linuxstb: http://duke.edu/~mgg6/rockbox/files1/flake.flac |
| 22:01:57 | saratoga | 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 | saratoga | compression level 12 in flake |
| 22:04:06 | linuxstb | 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 | saratoga | when I did it flake was 43KB smaller |
| 22:04:34 | | Quit ruj1 () |
| 22:04:51 | pixelma | 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 | saratoga | sorry 25KB smaller |
| 22:04:55 | pixelma | currently |
| 22:05:07 | saratoga | so yeah it looks fairly useless but still interesting to know if we can decode efficiently |
| 22:05:09 | linuxstb | saratoga: Which version of flac? And did you decode to wav first? |
| 22:05:31 | linuxstb | (I just did flac -8 -o flac.flac flake.flac) |
| 22:05:33 | saratoga | linuxstb: i just compared to the official flac-8 test file on the wiki |
| 22:05:34 | linuxstb | flac 1.2.1 |
| 22:06:01 | saratoga | tags says reference libFLAC 1.1.2 20050205 |
| 22:06:08 | saratoga | so its an older file |
| 22:07:08 | pixelma | 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 | pixelma | see the wiki page I mentioned earlier |
| 22:08:47 | linuxstb | saratoga: flake - "15.21MHz" (13.94s), flac - "14.71MHz" (13.48s) (on my Nano2G) |
| 22:08:55 | mc2739 | pixelma: thanks, I will look into the remote keymap, but not promising anything quick |
| 22:08:57 | saratoga | ah good |
| 22:09:02 | saratoga | sounds like its a nonissue |
| 22:09:40 | bertrik_ | 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 | bertrik_ | 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 | linuxstb | bertrik_: Not enough RAM on the device? |
| 22:11:56 | bertrik_ | linuxstb, for now I'm running purely from IRAM |
| 22:12:26 | linuxstb | Why is that? Could you put the bss in DRAM? |
| 22:13:05 | bertrik_ | maybe, but I'm not even sure DRAM is set up properly |
| 22:14:26 | linuxstb | The nano2g bootloader does that - see boot.lds (it's a simple change). |
| 22:15:03 | linuxstb | bertrik_: How big is the LCD? Could you just use a smaller than real size framebuffer? |
| 22:15:12 | bertrik_ | I had to revert the latest revision of boot.lds to make the meizu m3 boot properly again |
| 22:15:29 | linuxstb | Oops, sorry... |
| 22:15:32 | * | linuxstb goes to look... |
| 22:16:55 | bertrik_ | I'm not saying it's your fault or anything like that, could be something in the m3 code too |
| 22:17:08 | linuxstb | bertrik_: What revision are you using now? |
| 22:17:50 | CIA-85 | New commit by tomers (r23248): rbutil: Updated Hebrew translation |
| 22:17:54 | bertrik_ | r22879 |
| 22:18:02 | tomers | 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 | CIA-85 | New commit by tomers (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 | linuxstb | TheSeven: Good luck with the ADSL... |
| 22:20:09 | TheSeven | so that i can actually try to update my tree again and commit the usb stuff |
| 22:20:22 | TheSeven | sub-modem speed is really awful |
| 22:20:46 | pixelma | 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 | linuxstb | bertrik_: The only change there I think was to put bss in DRAM... So obviously that isn't working for you. |
| 22:21:41 | pixelma | Unhelpful: is pictureflow really using core actions or only ones that were made "after" the core actions? |
| 22:21:46 | linuxstb | TheSeven: Will the USB stuff be disabled when you commit? |
| 22:22:28 | tomers | 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 | tomers | s/did/made/ |
| 22:23:38 | TheSeven | linuxstb: I don't see a reason to keep it disabled |
| 22:24:13 | linuxstb | TheSeven: Is it reliable? |
| 22:25:03 | | Quit mrtok1 () |
| 22:25:10 | TheSeven | 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 | TheSeven | and i've self-updated rockbox multiple times today without any issue |
| 22:25:37 | TheSeven | (besides rolo still not working) |
| 22:26:27 | TheSeven | was that fixed in the meantime? (I'm still stuck at r23141) |
| 22:27:28 | saratoga | how much memory does the nano2g have? |
| 22:27:40 | TheSeven | 32MB DRAM + 176KB IRAM |
| 22:27:51 | linuxstb | 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 | TheSeven | as long as you won't plug it, there's not much that will change |
| 22:29:20 | saratoga | 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 | saratoga | huh Nano2Gs are cheapish on ebay, i might pick one up |
| 22:32:05 | TheSeven | 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 | linuxstb | 6. clickwheel acceleration |
| 22:32:49 | TheSeven | oh yes, that also needs some calibration, i already noticed that |
| 22:33:05 | TheSeven | which points me to another one: battery lifetime calibration |
| 22:33:23 | linuxstb | 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 | topik | i haven't updated my nano 2g since r23156 which has worked great |
| 22:34:05 | topik | will try recent changes tomorrow |
| 22:34:20 | tomers | 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 | TheSeven | topik: beware that we broke the PCM driver, which will now sound like dirty vinyl :-P |
| 22:34:51 | linuxstb | TheSeven: "we" ? ;) |
| 22:34:58 | topik | only weird thing is the volume |
| 22:34:59 | TheSeven | I'm working on a fix for that :-D |
| 22:35:07 | TheSeven | what's up with the volume? |
| 22:35:16 | topik | on my fuze -15db is the same as -35db on the nano2g |
| 22:35:39 | linuxstb | So the fuze is broken ;) |
| 22:35:42 | TheSeven | oh, interesting |
| 22:35:59 | topik | i have no 3rd device to compare against |
| 22:36:22 | AlexP | The volume control is relative to line level |
| 22:36:51 | TheSeven | AlexP: line level being defined by several manufacturers like they like it to be? |
| 22:36:58 | topik | if that's configurable, i never touched that on either device |
| 22:37:03 | AlexP | TheSeven: So it seems :) |
| 22:37:13 | * | TheSeven will do some measurements about that tomorrow |
| 22:37:44 | AlexP | 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 | topik | fair enough, but shouldn't rockbox try to correct for the difference? |
| 22:38:19 | TheSeven | 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 | topik | so -20db is the same level on all devices? |
| 22:39:01 | AlexP | no |
| 22:39:11 | AlexP | It is relative to line level |
| 22:39:20 | AlexP | So you know when distortion will occur |
| 22:39:30 | saratoga | you can't really correct for different amplifier powers |
| 22:39:59 | linuxstb | TheSeven: Yes, I think it will. |
| 22:40:00 | topik | it's not a problem, just an observation |
| 22:40:18 | topik | i am very excited about rockbox on both my players |
| 22:40:25 | linuxstb | bluebrother: What's the status of beastpatcher? Is it ready for release on Windows? |
| 22:40:29 | TheSeven | 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 | AlexP | 0 dB should be non-clipping with no dsp |
| 22:41:42 | saratoga | no DAP can go that high though |
| 22:41:53 | saratoga | IIRC the AMS sansas max out around 150mV |
| 22:42:16 | topik | shame there seems little chance for my meizu m6 to join my other aging players as rockboxed |
| 22:42:18 | TheSeven | I'll check tomorrow, but I think the ipods can go that high |
| 22:42:23 | | Quit Grahack ("Leaving.") |
| 22:43:02 | bluebrother | 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 | bluebrother | there's still this issue with some beasts rejecting a single bootloader installation |
| 22:43:36 | bluebrother | and installing dual-boot requires using a command line switch. |
| 22:43:39 | linuxstb | That can just be documented as a "known issue" though. |
| 22:44:47 | bluebrother | sure, if we consider that good enough. |
| 22:45:34 | bluebrother | 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 | bluebrother | which shouldn't be an issue for beastpatcher itself, but might cause issues once it's in rbutil |
| 22:46:18 | saratoga | issues are what make a port unstable, I saw write them up in the wiki and let people try it out |
| 22:46:18 | n1s | I'd really like to have the beast as supported :) |
| 22:46:23 | bluebrother | hmm, that's indeed a point :) |
| 22:46:33 | bluebrother | n1s: me too ;-) |
| 22:46:46 | saratoga | maybe it'll encourage more people to work on the beast |
| 22:46:54 | linuxstb | We need to stop talking about it and do it though... |
| 22:47:02 | bluebrother | true. |
| 22:47:16 | bluebrother | do we have an officially released bootloader for the beast? I've always used svn. |
| 22:47:17 | linuxstb | Does beastpatcher compile as a single .exe now on Windows? |
| 22:47:25 | linuxstb | No, there's never been an official bootloader binary |
| 22:47:30 | bluebrother | linuxstb: yes, if you build it with VS2005 |
| 22:48:03 | linuxstb | Does it have the bootloader embedded? |
| 22:48:09 | n1s | 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 | bluebrother | 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 | saratoga | fixing or deleting this page would be nice: http://www.rockbox.org/wiki/GigabeatSInstallation |
| 22:48:52 | AlexP | 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 | bluebrother | linuxstb: you can build it with or without embedded bootloader, like ipodpatcher. |
| 22:49:08 | linuxstb | 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 | bluebrother | do we have a known source for the oOF nk.bin? |
| 22:49:41 | AlexP | there is a link on the wiki somewhere |
| 22:49:45 | saratoga | maybe just delete it since we have directions here: http://www.rockbox.org/wiki/GigabeatSInfo#Loading_code_from_Windows |
| 22:49:53 | linuxstb | saratoga: What's wrong with it? |
| 22:50:01 | AlexP | bluebrother: toshiba released an update |
| 22:50:11 | AlexP | saratoga: I prefer the install page to the info page |
| 22:50:25 | bluebrother | AlexP: update as in something that's in fact an archive one can extract it from? |
| 22:50:25 | saratoga | linuxstb: its got blank steps labeled TODO |
| 22:50:40 | linuxstb | saratoga: That's not a reason to delete it... |
| 22:50:43 | n1s | bluebrother: could rbutil give the user a choice of dual/single? |
| 22:50:46 | saratoga | i think the info page is more up to date |
| 22:51:05 | saratoga | then the info instructions should be removed or depreciated and then copied over |
| 22:51:22 | linuxstb | There's lots of stuff on the info page that shouldn't be there - binary downloads, patched Toshiba software etc etc |
| 22:51:27 | bluebrother | 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 | AlexP | bluebrother: I'll need to check, but I think it can be extracted from the exe |
| 22:51:41 | AlexP | I thought the install page was more up to date |
| 22:51:52 | AlexP | It is just missing e.g. beastpatcher as it wasn't finished |
| 22:51:56 | saratoga | 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 | bluebrother | 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 | AlexP | The install page is virtually there |
| 22:52:34 | topik | 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 | n1s | bluebrother: but if it requires a mountpoint, how can it install the bootloader at all? |
| 22:52:47 | linuxstb | 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 | linuxstb | (but that's up to you of course...) |
| 22:53:32 | bluebrother | 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 | AlexP | bluebrother: http://www.tacp.toshiba.com/tacpassets-images/firmware/MESV12US.zip - It is an exe in an iso in a zip |
| 22:53:51 | AlexP | linuxstb: Sure |
| 22:54:27 | AlexP | linuxstb: I suspect however that test it is implicit in that :) |
| 22:54:27 | linuxstb | 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 | linuxstb | AlexP: Yes... ;) |
| 22:54:37 | n1s | bluebrother: yes, but installing a single or dual bootloader should require the same access |
| 22:54:44 | AlexP | linuxstb: Doing it now |
| 22:55:10 | | Nick YPSY is now known as Ypsy (n=ypsy@87.106.45.183) |
| 22:56:17 | pixelma | 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 | AlexP | pixelma: Single boot sometimes doesn't work on some units |
| 22:56:57 | linuxstb | 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 | bluebrother | ok, got a beast bootloader identifying as 1.0 |
| 23:00 |
| 23:00:08 | AlexP | me too :) |
| 23:00:17 | AlexP | http://aeparker.com/files/nk-v1-r23249.bin |
| 23:00:27 | | Quit fyrestorm (Read error: 131 (Connection reset by peer)) |
| 23:00:28 | AlexP | 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 | linuxstb | bluebrother: What does beastpatcher need? The bootloader.bin? |
| 23:01:06 | bluebrother | works fine for me too, at least when installing as dualboot |
| 23:01:11 | bluebrother | yes |
| 23:01:20 | AlexP | ah right :) |
| 23:01:27 | bluebrother | plus libmtp.a and libusb.a on linux |
| 23:01:29 | AlexP | well, that single boot nk.bin works fine here |
| 23:01:46 | linuxstb | 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 | AlexP | http://aeparker.com/files/bootloader-v1-r23249.bin |
| 23:02:35 | * | bluebrother has build r23249 too :) |
| 23:03:31 | bluebrother | ok, so we're releasing a 1.0 bootloader now? Should I go for building a beastpatcher.exe with that? |
| 23:03:37 | AlexP | bluebrother: copycat! :) |
| 23:03:48 | AlexP | I don't see why not |
| 23:04:01 | * | linuxstb neither |
| 23:04:18 | bluebrother | AlexP: I'm claiming being first −− my network had a short dropout :P |
| 23:04:23 | linuxstb | Step 1 - release bootloader and beastpatcher ; Step 2 - update documentation; Step 3 - promote to unstable and profit. |
| 23:04:23 | AlexP | hehe :) |
| 23:04:30 | * | bluebrother prepares reboot |
| 23:05:16 | bluebrother | anyone willing to build the linux binary? I would need to build libmtp first |
| 23:05:25 | AlexP | sure |
| 23:05:41 | AlexP | Although I think I'll have to build libmtp too :) |
| 23:05:49 | AlexP | I can do 64 bit here |
| 23:06:22 | | Quit bmbl ("Bye!") |
| 23:08:16 | * | bluebrother in wxp now |
| 23:08:21 | AlexP | No, it seems not |
| 23:08:27 | | Quit n1s ("Lämnar") |
| 23:08:31 | AlexP | just make builds it statically right? |
| 23:08:50 | * | linuxstb has built 32-bit linux |
| 23:09:17 | bluebrother | yes. I'm usually changing the LIBS line to get it link with the systems libmtp |
| 23:09:58 | AlexP | 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 | linuxstb | linuxstb.cream.org/rockbox/beastpatcher-linux32.tgz">http://linuxstb.cream.org/rockbox/beastpatcher-linux32.tgz |
| 23:11:07 | AlexP | 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 | bluebrother | 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 | AlexP | bluebrother: I did - the bootloader is fine |
| 23:12:20 | AlexP | bluebrother: I mean I can't test beastpatcher |
| 23:12:41 | linuxstb | It works fine for me "[ERR] No device found" |
| 23:12:42 | bluebrother | AlexP: well, you could put an OF instead and then go through the process of reinstalling ;-) |
| 23:13:11 | linuxstb | bluebrother: And risk things not working? ;) |
| 23:14:06 | AlexP | bluebrother: Yeah, I *could* ... :) |
| 23:14:44 | bluebrother | AlexP: ;-) |
| 23:15:17 | AlexP | http://aeparker.com/files/beastpatcher-linux64.tgz |
| 23:17:03 | linuxstb | 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 | linuxstb | Or /bootloader/toshiba/gigabeat-s/ (and move gigabeat) |
| 23:18:35 | AlexP | Does beastpatcher work on Mac? |
| 23:20:47 | bluebrother | 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 | AlexP | How does tagging work? |
| 23:22:41 | linuxstb | See the UsingSVN wiki page. |
| 23:23:30 | AlexP | Cheers |
| 23:24:09 | AlexP | So we want bootloader_gigabeat-s_v1 I guess? |
| 23:24:34 | CIA-85 | New commit by alex (r23250): Tag release v2 of the Sansa E200 bootloader and sansapatcher |
| 23:24:36 | bluebrother | hmm, something is wrong on windows :( |
| 23:24:50 | AlexP | what the hell |
| 23:24:52 | bluebrother | e200 bootloader? |
| 23:25:02 | linuxstb | v2? |
| 23:25:12 | AlexP | I didn't do that in the checkout |
| 23:25:34 | AlexP | I was in a completely different directory, and I was pasting from the UsingSVN page to edit it for this one |
| 23:25:42 | AlexP | So, next question: |
| 23:25:47 | | Quit pamaury ("exit(*(int *)0 / 0);") |
| 23:25:48 | AlexP | How do I undo that? |
| 23:26:00 | bertrik_ | if I configure the LCD pins on the meizu m6sp (through PCON_ASRAM), it hangs ... |
| 23:26:04 | kugel | svn rm <url> |
| 23:26:10 | AlexP | kugel: Thanks |
| 23:26:12 | bluebrother | AlexP: svn rm svn://..., then svn cp svn://... svn:// |
| 23:26:32 | bluebrother | 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 | AlexP | So svn rm svn://svn.rockbox.org/rockbox/tags/bootloader_e200_v2 ? |
| 23:27:17 | bluebrother | yes |
| 23:27:18 | AlexP | bluebrother: Thanks, wish I had know that before :) |
| 23:27:51 | CIA-85 | New commit by alex (r23251): Revert previous completely accidental commit. |
| 23:28:10 | bluebrother | AlexP: it wouldn't make much sense having to checkout tags/ first, would it? Could become quite large ;-) |
| 23:28:22 | AlexP | true :) |
| 23:29:58 | bluebrother | gnah. beastpatcher works fine when build as debug executable but not when build as release. Seems I've missed that before :( |
| 23:31:52 | AlexP | beastpatcher here is v1 too, so it can be tagged as both right (as in the accidental e200 one above)? |
| 23:32:50 | bluebrother | I'd say so |
| 23:32:58 | AlexP | OK |
| 23:33:22 | pixelma | 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 | AlexP | OK, let's try again :) |
| 23:34:11 | linuxstb | 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 | CIA-85 | New commit by alex (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 | AlexP | linuxstb: The lack on mac wielding people strikes again - I guess we just leave it out for now |
| 23:40:05 | bluebrother | anyone with a windows box around that can check if a debug binary works? |
| 23:40:36 | bluebrother | 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 | mc2739 | bluebrother: do you need any special windows setup for your test? |
| 23:54:34 | linuxstb | AlexP: Yes, we don't have any choice... Yet another thing missing for the beast... |
| 23:55:04 | bluebrother | mc2739: no, but you shouldn't have any visual studio installation (read: windows development tools) installed. |
| 23:55:20 | bluebrother | all you need to check is if the binary runs at all |
| 23:55:38 | bluebrother | http://www.alice-dsl.net/dominik.riebeling/rockbox/beastpatcher.exe |
| 23:55:39 | mc2739 | I don't have visual studio installed |
| 23:55:47 | | Join Thundercloud [0] (i=thunderc@81.187.69.84) |
| 23:55:49 | mc2739 | is win 7 rc ok? |
| 23:56:12 | bluebrother | should be. At least we get to know if it does work on w7 at all :) |
| 23:56:19 | saratoga | [INFO] Found device "SanDisk - SANSA CLIP (D:)" |
| 23:56:21 | saratoga | heh |
| 23:56:47 | saratoga | bootloader installed successfully on my sansa clip |
| 23:56:49 | bluebrother | 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 | linuxstb | bluebrother: What are beastpatcher's requirements? Does it need a certain version of WMP installed? |
| 23:57:41 | bluebrother | 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 | saratoga | clip didn't seem to mind having the beast bootloader installed, I guess since it was in UMS mode |
| 23:58:03 | mc2739 | bluebrother: did you see this? http://forums.rockbox.org/index.php?topic=22961.0 |
| 23:58:14 | mc2739 | rbutil thinks e200v1 is v2 |
| 23:58:40 | mc2739 | I have not confirmed yet |
icon identifies that the person is a core developer (has commit access).