--- Log for 08.09.110 Server: asimov.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 24 days and 1 hour ago 00.01.45 Join clone4crw [0] (~calvin@96-42-90-88.dhcp.roch.mn.charter.com) 00.03.46 Quit ender` (Quit: We must respect the other fellow's religion, but only in the sense and to the extent that we respect his theory that his wife is beautiful and his children smart. -- H.L. Mencken) 00.13.11 Join huffpuff_ [0] (~matthew@h86.28.188.173.dynamic.ip.windstream.net) 00.15.51 Quit huffpuff (Ping timeout: 240 seconds) 00.23.37 Quit rasher (Remote host closed the connection) 00.25.00 Quit bmbl (Quit: Bye!) 00.31.39 Quit jgarvey (Quit: Leaving) 00.33.18 # We could just remove the "custom" channel config setting and allow the stereo width to be configured while in "stereo" channel config 00.34.11 Quit [Saint] (Ping timeout: 255 seconds) 00.34.12 # It's a bit weird to me that the "stereo width" can be controlled but has no effect in "stereo" channel config 00.34.47 Join [Saint] [0] (S_a_i_n_t@203.184.2.222) 00.35.42 # Maybe have a special check for "stereo width" = 100% to avoid wasting processing power 00.36.54 # it's a bit like the equaliser you can have adjust but leave it turned off, it makes it easy to switch. I don't care much but I know people prefer these settings to be independent 00.38.15 # there are virtually no settings that aren't independant currently 00.38.29 # only a few oddities like the "recent only" choices for bookmarking 00.39.11 # * [Saint] reads the logs where he fell off the net and thinks "We could just remove the "custom" channel config setting and allow the stereo width to be configured while in "stereo" channel config" 00.39.14 # <[Saint]> is a good idea. 00.39.25 # <[Saint]> keep the setting, but, remove the ability to set it. 00.39.51 # <[Saint]> ie. remember the last setting, so it can be reapplied 00.40.08 Quit krabador (Ping timeout: 276 seconds) 00.40.09 # tbh i don't see the problem with the current behaviour 00.40.18 # if you don't notice that it didn't do anything then it doesn't matter anyway, no? :) 00.40.28 # and if you do notice then it shouldn't take more than a few seconds to work out why 00.40.32 # Torne, "stereo width" doesn't work in "stereo" mode, is confusing to me 00.40.48 # <[Saint]> it seems weird, I wonder how many people adjust stereo width not knowing its useless without setting channel config to custom 00.40.59 # one setting depending on another setting in a different menu 00.41.11 # * [Saint] nods 00.41.27 # [Saint]: if they adjust it and *don't notice* then they're irrelevant 00.41.42 # if they don't hear that it didn't do anything then it clearly doesn't matter whether it does anything for them ;) 00.42.00 # placebo and all that 00.42.08 # <[Saint]> that's hardly the point being made ;) 00.42.51 # i know, but you keep implying that side :) 00.43.03 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 00.43.41 Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) 00.43.42 Quit rasher (Changing host) 00.43.42 Join rasher [0] (~rasher@rockbox/developer/rasher) 00.43.48 # * Torne shrugs, i just don't see how reducing the flexibility is particularly useful. it's not a feature most people have any reason to use at all, and, yaknow, the manual. 00.44.22 # maybe just rename the setting? 00.44.30 # <[Saint]> I don't see how it reduces flexibility 00.45.10 # if stereo and custom get merged, then you can't turn the custom processing *off* any more without throwing away the value of the setting 00.45.16 # you'd have to set it back to 100% 00.45.36 # seriouusly, i don't see how this is any different to the eq or whatever 00.45.41 # <[Saint]> not if you just have it remember the previous setting like I suggested earlier 00.45.46 # <[Saint]> that wouldn;t be hard. 00.45.48 Join Brownout [0] (~brownout@wikimedia/brownout) 00.45.49 # remember how? 00.45.56 # <[Saint]> from the config 00.46.08 # i don't understand what you mean 00.46.21 # if you eliminate "custom" then how do you tell it to use the remembered setting? 00.46.30 # or how to stop using it, for that matter 00.46.58 # <[Saint]> Hmmm. 00.47.29 # seriously, how is this different from the eq? it's only one number instead of lots, but the same principle applies surely 00.47.51 # there's a switch to turn some kind of processing (which takes cpu power) on and off 00.47.55 # The eq isn't turned on/off in the "channel config" menu 00.48.03 # and there's a configuration for that processing, which happens only to be one value 00.48.19 Part Brownout 00.48.25 # <[Saint]> yeah, I was going to say that...kinda...the EQ stuff is in the same place 00.48.27 # you mean the eq is a submenu and the channel config/width isn't? 00.48.31 # aren't they adjacent? 00.48.47 # <[Saint]> well, yes, but not obviously connected 00.48.52 # "channel config" isn't a menu, it's just a setting 00.49.06 # ok. so make it a submenu :) 00.49.12 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 00.49.15 # <[Saint]> works for me. 00.49.21 # <[Saint]> well..kinda. 00.49.31 # <[Saint]> it's a fair(er) compromise 00.49.46 # i just don't like the implied stuff 00.49.47 # bertrik: but there (in the sense of "somwwhere in the sounds settings" is an "enable graphical eq" setting and then the actual ways to adjust it 00.50.30 # we don't have a sufficiently flexible UI (at the moment) to make it clear when these implicit things happen 00.50.34 # sorry, I can't understand how you think this is perfectly logical 00.50.37 # so, i feel it's better to be explicit 00.51.06 # bertrik: see above, no? one setting enables/disables some piece of DSP logic; the other setting is the parameter for that DSP logic 00.51.12 # how is that not logical? 00.51.18 Quit Luca_S (Quit: CGI:IRC) 00.51.19 # i can see how it's not *obviously connected* when you look at the UI 00.51.26 # because it isn't, you're right 00.51.35 # but once you know that it is, it's perfectly sensible.. 00.51.59 # <[Saint]> well, "sensible", not perfectly sensible. ;) 00.52.07 # like I said, "*stereo* width" having no effect in "*stereo*" mode, allowing one setting to be configureable, but having to enable it in a different menu 00.52.34 # defeats the principle of "least surprise" IMO 00.52.45 Quit liar (Ping timeout: 258 seconds) 00.52.54 # right. 00.52.58 # maybe it's really the naming (and placement) of the "Custom channel config" or however it's called, I'm not a 100% sure of the current structure at the moment 00.53.02 Join krabador [0] (~krabador@host125-179-dynamic.47-79-r.retail.telecomitalia.it) 00.53.02 # so, change the name, or make it a submenu 00.53.19 # pixelma: It's "Channel configuration" and "stereo width", adjacent on the sound settings menu 00.53.25 # Actually I don't enough about it and will probably never use it... :) 00.53.30 # they're right that there's nothing to imply they are connected 00.53.35 # unless you read the manual 00.54.02 # i'm just questioning the need to change the actual logic; i have no proble with changing the UI for it :) 00.54.41 Join Drise [0] (~Drise@user-24-236-91-225.knology.net) 00.54.50 # and no i don't use this setting :) 00.54.58 # I just dislike special cases ;) 00.55.05 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 00.55.08 # ok, me too 00.55.25 # The other way to solve it without any special cases would be to merge the two things 00.55.38 # so mono would just become 0%, stereo 100%, and you'd need special entries for left/right 00.55.46 # (is that all that's on the channel config menu? i think so) 00.56.04 # that does reduce the flexibility but it does so without weird implicit behaviour 00.56.15 # it's at least clear what the effect is in all cases 00.56.30 # dammit 00.56.38 # looks like we have the first nano2g brick 00.57.09 # i'm currently trying to help someone who is experiencing the following problem 00.57.15 Join bluebrother [0] (~dom@f053153215.adsl.alicedsl.de) 00.57.16 Quit bluebrother (Changing host) 00.57.16 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 00.57.20 # Is the fuze v2 usb operational, or do I still need to run the patch 00.57.32 # at least that means there's an opportunity for the first nano2g unbrick 00.57.33 # he tried to rolo into a new build, which locked up 00.57.46 # when he reset the ipod, the FTL was bad 00.58.03 # and since that point, all attempts to erase NAND blocks have failed 00.58.10 Join billybobthornton [0] (S_a_i_n_t@203.184.2.222) 00.58.30 *** Saving seen data "./dancer.seen" 00.58.36 # Kareoki is a bit of a weird one...it doesn't seem to fit. 00.58.46 Nick billybobthornton is now known as S_a_i_n_t (S_a_i_n_t@203.184.2.222) 00.59.26 # Saint: is there a way to type names without having to type them? Such as not having to type S_a_i_n_t? 00.59.37 # you could type saint instead 00.59.37 # Its been a while since I'ved used IRC 00.59.42 Quit bertrik (Quit: goodnight!) 00.59.43 # but yes, tab-complete in just aout every client 00.59.58 Quit [Saint] (Ping timeout: 252 seconds) 01.00.01 # Tab complete!?!?!?! OMFG 01.00.03 # Sorry 01.00.15 # TheSeven: eek 01.00.31 # i have no idea at all how this can happen 01.00.52 # either rolo failed because of that well-known cache issue, and made it execute something weird, which made that flash read-only 01.00.54 Quit bluebroth3r (Ping timeout: 276 seconds) 01.01.09 Quit Llorean (Read error: Connection reset by peer) 01.01.32 # or the flash went bad for a different reason, which made rolo fail to sync the ftl. no idea which one happened 01.01.45 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 01.02.01 # it's really quite depressing how badly the nano handles ftl issues on its own 01.02.06 # the flash *could* have just chosen that moment to die 01.02.09 # the ipod was luckily running iloader, otherwise we wouldn't have had any way of accessing it 01.02.23 # it seems just as feasable as any other explanation. 01.02.45 # S_a_i_n_t: i doubt a flash will fail in a way that makes it to contain mostly valid data, but refuse to erase any block 01.03.01 # Hmmm, good point. 01.03.04 # Lucky me. >_> I have a one-of-a-kind Nano2G brick. 01.03.07 # S_a_i_n_t, Did pamaury finish the usb code? 01.03.14 # yeah it seems more likely that it's managed to protect itself or something 01.03.21 # can he do the open/piss about/solder trick? 01.03.36 # that won't help the flash to get writable :) 01.03.37 # There was a one-byte difference in that one dump thought, TheSeven . . . 01.03.50 # yes, but that just *can't* be the reason 01.03.51 # was it in a bad block? 01.04.06 # *what* was in a bad block? 01.04.14 # mulenmar: was it you? 01.04.20 # Yup. Lucky me. 01.04.28 # oh...bugger :/ 01.04.46 # * mulenmar : born Friday the 13th. X~P 01.05.17 # Torne: any idea what could make that flash be read-only? 01.05.39 # mulenmar: we should probably try if we can write things, if we don't erase it first 01.06.05 Quit Zarggg (Quit: Zarggg) 01.06.11 # TheSeven: i assume you can send it unprotect commands and stuff? 01.06.13 # I thought that flash memory HAD to have the block erased before it could be written to? 01.07.13 Quit JdGordon (Quit: Leaving.) 01.07.24 # to be written to *correctly*, yes 01.07.26 # mulenmar: we still have some erased blocks to play with 01.07.30 # :) 01.07.45 # some flash lets you write the same block more than once, and it just won't program any of the 1's 01.07.48 # and most datasheets claim that a block can be written up to like 4 times before it needs to be erased again 01.08.35 # TheSeven: that won't normally overwrite existing 0's though 01.08.47 # yep 01.08.57 # but it's sufficient to check if anything changes at all 01.09.01 # yeah 01.09.16 # * Drise is running the script, hoping for no errors. 01.09.33 # has the thing been through an actual power cycle, or can't you do that on nano2g either? 01.09.49 # because if the flash chip has decided that ranges are protected, powercycling will generally clear that ;) 01.09.59 # since it doesn't store that anywhere persistent 01.10.11 Quit kart0ffelsack (Ping timeout: 245 seconds) 01.10.39 # Just resets. 01.10.55 # yeah, that may or may not reset protected blocks 01.11.09 # does iloader know how to send the unprotect command for that flash? 01.11.17 # Reset-hold off- let sit was tried once. 01.11.19 # you could just blanket unprotect every sector and see if that makes a difference 01.11.39 # * TheSeven doesn't really have a clue how flash chips work 01.11.48 # heh 01.11.52 # but we can execute arbitrary code, so we can do whatever we need to 01.11.58 # well, what i mean is that most flash chips have a protection feature 01.12.03 # or "lock" they might call it 01.12.10 # so you can write-protect a range of blocks 01.12.20 # it's just a command, and it's not usually stored anywhere persistent 01.12.28 # it's just a protection-from-cockups thing, not a security feature 01.12.45 # normally you use it to, say, protect the bootloader from being overwritten unless something specifically unprotects it forst 01.13.04 # the bootloader would just send the protect command at boot time 01.13.18 # i'm kinda guessing :) 01.17.24 # * kugel agrees with bertrik 01.17.45 # I always wondered if my ears are so bad or why else does stereo width nothing? 01.18.55 # wooo! sorry kugel, just now I KNOW (when a dev messes it up too) that its totally un-obvious that the two are connected (channel config/stereo width) 01.20.00 Join saratoga [0] (9803c22e@gateway/web/freenode/ip.152.3.194.46) 01.20.06 # * Torne isn't disagreeing that it's non-obvios, just objects to the proposed fix 01.20.09 # I didn't even know channel config and stereo width are related to each other 01.20.37 # the eq is a bad example, it would be a better one if channel config was named "enable stereo width" 01.21.01 # so rename the settings to be more logical :) 01.22.19 # I bet nobody actually uses it 01.22.25 # I do 01.22.30 # what about making "Custom" a subdir, and having enable diable stereo width in there, as well as stereo width? 01.22.42 # S_a_i_n_t: that's not possible easily 01.22.42 # our list UI doesn't work that way 01.22.51 # channel config is not a submenu 01.22.54 # it's just a setting 01.23.07 # so, there's no way to give it sub-options without changing the structure of the thing entirely 01.23.08 # way better than crossfeed to my ears - and also available on hwcodec (stereo width) 01.23.38 Quit krabador (Ping timeout: 276 seconds) 01.24.58 # Torne: I think it's doable 01.25.05 # is enabling "custom" als needed for mono etc.? Just thinking that "enable stereo width" could be misleading too if it was 01.25.19 # you can always add custom callbacks to settings and menus so I don't see any blocker right now 01.26.01 # kugel: this seems like a lot of effort/code for a UI issue that's solveable by readnt he manual :) 01.27.02 # pixelma: It is kinda misleading...as I'm fairly sure that "Stereo Width == 0%" is mono, if it isn't, then that's GOT to be a bug 01.27.28 # I think they showed somewhere in the 60s or 70s that UIs need to be easy to use and not missleading regardless of the existence of a manual 01.27.58 # right 01.28.13 # i just really don't think you need to implement some custom thing that's unique to this to solve the problem 01.28.18 # yeah...pretty sure that UIs that don't confuse the fuck out of people are a good thing in general ;) 01.28.21 # move them to a submenu and rename them, or something 01.28.32 # rtfm is nice if there's a lot of effort involved, but I don't think that's the case here 01.28.34 # to make it cear they are connected adn that one thing only affects one mode of the other thing 01.28.48 # we already have all the code for that :) 01.28.55 # no special case required 01.29.05 # S_a_i_n_t: what does that have to do with my question? 01.29.26 # I must have misread it, sorry 01.29.59 # Torne: any idea how to figure out where to get a datasheet for a flash chip with the ID code 0x2585d3ad? 01.30.33 # er, not really 01.30.36 # other than google :) 01.30.41 # the hynix datasheet i had lying around doesn't mention a block protection feature, it seems to have a write protect pin instead 01.31.16 # the first google hit for that ID code ends up in flyspray :/ 01.31.22 # I think keeping the stereo width setting internally (for flexiblity and compatibility), while making stereo width a submenu of custom channel config is doable with little extra code 01.31.41 # and all the other hits in irc logs from rockbox or linux4nano :( 01.31.44 # if you're going to do something like that it makes more sense to just merge the two lists, no? 01.32.04 # have the percentages and also the other options at one end of the list. 01.32.17 # * Torne shrugs 01.32.35 # * Dreamxtreme shrug 01.32.59 # kugel: If you think its doable, persoanlly, I think that's a decent solution for this. 01.33.25 # I think that's more effort in the end (and clutters up the list) 01.33.34 # Torne: ^ 01.34.55 Join krabador [0] (~krabador@host102-56-dynamic.244-95-r.retail.telecomitalia.it) 01.35.26 # TheSeven: is that chip the HY27UT088G2M? 01.35.39 # it's the same that you have at least... 01.36.16 # Hmmm...I have a few, pretty sure they're not *all* the same ;) 01.36.41 # well, at least you mentioned that id once 01.36.49 # did you find a datasheet for the HY27UT088G2M? 01.36.57 # well, that chip id you gave led me to that chip, and, I can find sheets for it. 01.37.04 # yes. 01.37.13 # errr...possibly 01.37.35 # * S_a_i_n_t hands TheSeven http://www.datasheet4u.com/share_search.php?sWord=HY27UT088G2M-TPCB 01.38.28 # now which of those? 01.38.32 # they're all no exact matches 01.39.15 # none? on any of the pages? 01.39.20 # shit. 01.39.28 Join antil33t1 [0] (~Mudkips@124-197-51-80.callplus.net.nz) 01.39.32 Quit antil33t (Disconnected by services) 01.40.22 # theres probably a decoder chart somewhere for the part number 01.40.59 # oh found it 01.42.03 # the datasheet, or the decoder for the partnumber? 01.42.22 # those datasheets all have a decoder in them 01.44.10 # so HY27U = 1.8v NAND, T is the number of levels per cell, 088 is the package type, 01.44.10 # hmm no 01.44.35 # so it's a cached-program 8-level-cell type 01.44.46 # no, 4-level 01.45.06 # * S_a_i_n_t can only find up to HY27US, but, no HY27UT 01.45.17 # +datasheets 01.46.04 # its probably Two levels per cell 01.46.17 # since these are not single level memory chips, it'd have to be either 2 or 3 01.46.24 # * TheSeven has the impression that basically all hynix nand flash chips have device code 0xd3 01.46.30 # err 2 bit or 4 bit 01.46.37 # err 2 bit or 3 bit 01.46.42 # so 4 level or 8 level 01.46.54 # 4 levels according to the decoder in my datasheet 01.47.04 # so T = Two bit probably 01.47.57 # whatever it is, it probably has a hardware WP pin, not a software block protection command 01.48.11 Join bunnyboi [0] (~androgyne@cpe-72-224-17-58.nycap.res.rr.com) 01.49.14 # now what could be driving that pin, and why can it survive a powerdown 01.49.57 # writing also fails, even on an erased page 01.51.22 Quit kugel (Remote host closed the connection) 01.54.13 Quit Drise (Quit: Leaving) 01.59.22 # tried shorting the power and ground pins on the chip? 02.00.54 Quit S_a_i_n_t (Ping timeout: 276 seconds) 02.01.09 Join funman [0] (~fun@rockbox/developer/funman) 02.01.27 Join [Saint] [0] (S_a_i_n_t@203.184.2.254) 02.02.45 Join CaptainKwel [0] (~jason@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 02.03.53 Quit simonrvn (Disconnected by services) 02.03.54 # saratoga: he hasn't opened that thing yet, and they aren't easy to open at all 02.04.27 # and before shorting anything i'd measure the level on the WP pin 02.04.29 Join simonrvn_ [0] (simon@209.191-ppp.3menatwork.com) 02.05.05 Nick simonrvn_ is now known as simonrvn (simon@209.191-ppp.3menatwork.com) 02.05.26 # <[Saint]> "aren't easy" is an understatement. 02.06.02 # <[Saint]> it's very easy to teat the ribbon cable for the hold switch. 02.06.03 # <[Saint]> teat? Ahem...*tear 02.06.56 # <[Saint]> that, and strip the head on the tiny lock-tite'd screws holding the bracket ander the plastic cap on the top. 02.07.09 # <[Saint]> *under...hag. 02.07.24 # <[Saint]> omg, *gah! 02.07.43 Join steve|m1 [0] (~steve@p4FD46502.dip.t-dialin.net) 02.07.43 Quit steve|m (Disconnected by services) 02.07.45 Nick steve|m1 is now known as steve|m (~steve@p4FD46502.dip.t-dialin.net) 02.08.27 # i've also looked at the pmu's gpios, they match 02.08.47 # the only differences i can find are two unknown and apparently read-only bits on the SoC's GPIOs 02.09.10 # and an NVRAM byte in the PMU, along with some interrupt flags 02.10.09 # any ideas left? 02.11.56 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 02.13.30 Join mulenmar_ [0] (~mulenmar@74-132-43-158.dhcp.insightbb.com) 02.13.54 Quit mulenmar (Ping timeout: 264 seconds) 02.16.39 # hmmm now this is weird 02.16.48 # judging from http://www.freemyipod.org/w/images/f/fe/Bot_annote.jpg the WP pin is unconnected! 02.18.41 # <[Saint]> yes...that *is* weird. 02.19.21 # <[Saint]> remind me to *not* do whatever this guy did to his Nano... 02.19.44 # that nano was toast anyway :) 02.19.46 # was that a danger? :) 02.19.51 Quit hebz0rl (Quit: Ex-Chat) 02.20.46 # or wait, there might be a via inside that pad 02.20.56 # [Saint] That would be attempting to upgrade the Rockbox version by deleting .rockbox and transferring over a new version while Rockbox was running, combined with using iLoader instead of Rockbox Loader. 02.21.25 Quit krabador (Ping timeout: 272 seconds) 02.21.31 # After transfering at least 4.5GB total onto and off of the Nano while testing a patch. 02.22.25 # While *preparing* to test a patch, I mean. I was still running vanilla Rockbox. 02.24.52 # now what could apple have connected to that pin? 02.25.12 # the datasheets say that it shouldn't be tied to ground but pulled high during powerup instead 02.26.27 # and how can we permanently affect what this is tied to? 02.26.29 Quit [Saint] (Ping timeout: 272 seconds) 02.28.44 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 02.28.57 Quit efyx (Remote host closed the connection) 02.29.27 # New commit by 03funman (r28031): usb-drv-as3525v2: fixes ... 02.31.09 # r28031 build result: All green 02.32.07 # we have 2 competing drivers for the same hardware 02.32.39 # one is 450 lines, the other is 1302 02.37.25 # * TheSeven wonders if the 450 line one is his one :) 02.37.48 # that's the one yes 02.37.59 # where does the other one come from? 02.38.09 # see last commit 02.38.30 # i'm pretty close to have this one working though 02.41.15 # this doesn't seem to be much more actual code though 02.41.35 # it's commented way better 02.41.57 # and it's using a lot more symbols instead of hardwired numbers 02.42.12 # we must take the best of both 02.43.34 # which one is actually working better? 02.43.53 # could the big one easily be ported to the nano? 02.44.09 # it took me only a few hacks to make the nano2g one work on amsv2 so yeah 02.44.44 # see FS#11607 : usb-target.h 02.44.47 Join ascheel [0] (~ascheel@ampache/staff/ascheel) 02.45.48 # Quick question. http://www.rockbox.org/wiki/SansaAMS says that Sansa v2 is stable, but all other pages like http://www.rockbox.org/wiki/SansaFuze#Fuze_v2 and even http://www.rockbox.org/ itself indicate it is *NOT* currently stable. Can I safely assume that the latter links merely have not yet been updated? 02.46.18 # ascheel: 'Sansa v2' is what exactly? 02.46.22 # Fuzev2? 02.46.24 # Sorry, Fuzev2 02.46.29 # I apologize 02.46.36 # brain is slower than the fingers 02.46.43 # SansaAMS doesn't say it's stable 02.47.09 # ah, I thought the table itself indicated stability 02.47.11 # "Rockbox is considered Stable on Fuze v1/e200v2, Unstable on Clip v1, Clip v2, Clip+, Fuze v2" 02.47.15 # sounds pretty clear to me 02.47.29 # it works pretty fine though 02.47.42 # although i think the clipv1 is stable now 02.47.55 # yeah the front page just need manual update 02.48.25 # Are the 'Specific problems' all that remains before it goes stable? 02.48.35 # no 02.48.56 # i think once we get USB working we'll label them stables 02.49.10 # targets become stable when people feel like it basically 02.49.42 # funman, Fuze v2 I know had the USB listed as the only remaining non working item, but now it says it is functional. Are there portions not yet working not listed? 02.50.04 # or does it require ALL SansaAMS builds to be stable before ANY of them are marked as such? 02.50.07 # USB 02.50.47 # ascheel: take a look at the asterisk 02.51.06 # Yeah, says it's just not in SVN 02.51.14 # "just"? 02.51.16 # So it's working, but not yet being distributed? 02.51.36 # it's really new, not properly tested code, that seems to work well at a first glance 02.51.53 # gotcha. Ah, just now realized the last modified date of that page (yesterday). 02.51.56 # it hasn't even adopted into svn yet, so there's just no way to call that stable :) 02.52.08 # Didn't realize I was that early on the punch with it 02.52.11 # been* 02.53.45 # has anyone noticed problems with the EQ on AMS like that one guy reported in the forums? 02.53.53 # i'm at loss as to how that could be target specific 02.53.58 Quit lestatar (Ping timeout: 240 seconds) 02.58.07 # read: 5.8Mbps on clipv2 (although sometimes it's much much much slower) 02.58.31 *** Saving seen data "./dancer.seen" 03.03.09 # New commit by 03funman (r28032): usb-drv-as3525v2: use dump_dcache_range() ... 03.03.14 # New commit by 03funman (r28033): as3525v2 usb: define USB_HAS_BULK ... 03.05.00 # r28032 build result: All green 03.06.47 # r28033 build result: All green 03.07.13 # still doesn't work correctly all the times 03.07.53 Join leachim6 [0] (~leachim6@rrcs-97-78-139-149.se.biz.rr.com) 03.07.55 # hey 03.08.01 # how do I tell which version of the Sansa Fuze i have? 03.08.12 # whether it's V1 or V2 03.09.33 Quit bunnyboi (Quit: Going!) 03.09.44 # check the manual it explains how to do so 03.09.58 # I looked 03.10.33 # http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch2.html#x4-70002.1 <- you didn't look very close 03.10.47 # thanks 03.10.51 # sorry, I tried to find it on my own before I asked 03.11.35 # so if version says "v0.1.01.07A" 03.11.38 # I have a version 1, right? 03.11.42 # I just want to make completely sure 03.11.45 # right 03.11.53 # sweet :) 03.12.02 # so that means I'm officially supported by the installer at least 03.13.25 Quit Judas_PhD (Quit: This is a quitting message) 03.13.53 Quit TheSeven (Ping timeout: 265 seconds) 03.14.28 Quit funman (Quit: bbl) 03.15.55 # so, If I have an older firmware on my Fuze, do I wanna try to get the old firmware bin and then patch it? or do I want to update to the newsest firmware, then patch that 03.17.43 # which is more ideal? 03.18.43 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 03.19.33 Join funm4n [0] (5648a775@gateway/web/freenode/ip.86.72.167.117) 03.19.57 # AMSv2 USB works (and fails) equally well on windows 03.21.01 # what does that mean? 03.21.12 # I don't know what that means 03.21.18 # he's testing Fuze v2 right now. 03.21.22 # oh right 03.21.25 # I'm lucky I have a v1 03.21.28 # New code. Not anything you'll be experiencing, yet 03.21.51 # you guys are pretty vigilant on new code huh? 03.21.53 # still chugging 03.22.18 # so I should update my v1 to the latest firmware ? 03.23.07 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 03.23.20 # can I just get a yea or nay? 03.26.17 # <--- not rockbox person. Just in here as you are. 03.26.20 # leachim6: installing the rockbox bootloader requires upgrading the OF version 03.26.35 # funm4n, good, because I updated it 03.26.36 # haha 03.26.38 # you can just upgrade to the latest OF while installign rockbox at the same time, no need to upgrade before that 03.26.52 # ok 03.26.59 # "upgrade" means install another version, it doesn't need to be the last one 03.26.59 # so....I'm on the latest version.... 03.27.05 # got rbutil going on 03.27.06 Quit funm4n (Quit: Page closed) 03.27.09 # plugged in my sansa 03.27.16 # now I just run rbutil, and point at my .bin file? 03.27.18 # and that's all? 03.28.59 Join funman [0] (~fun@rockbox/developer/funman) 03.29.24 # that's all. isn't that marvelous? 03.29.27 # wow 03.29.29 # that was esay 03.29.36 # but my sansa's still showing the "connected" animation 03.29.39 # after the whole installation 03.29.44 # shouldn't it like....reboot or something? 03.29.56 # you need to power down and back up, IIRC 03.30.13 # ok 03.30.20 # no 03.30.28 # I fail again 03.30.29 # just eject it 03.30.36 # oh yeah, I got it 03.30.40 # "Firmware update in progress" 03.30.42 # now's crunch time. 03.30.50 # *kneads hands* 03.30.53 # Upgrade complete :D 03.31.01 # w00t! 03.31.02 # rockbox 03.31.21 # funman, powering it up with the USB cable in boots to the OF, correct? 03.31.33 # depends on which player you have 03.31.39 # thanks, saratoga. 03.31.43 # it will on amsv2, won't on amsv1 anymore 03.31.47 # ah 03.31.49 # I think I read that USB is supported on the v1 03.31.49 # yes? 03.31.51 # let me check 03.32.00 # nope, it reboots. 03.32.01 # that just a workaround for nonstable ports, then? 03.32.08 # nope, stable ports reboot too 03.32.20 # I just tested it 03.32.30 # leachim6: read the SansaAMS wiki page (linked from the front page) 03.32.42 # ok, I'll read it 03.32.47 # funman, did you write code for this release? 03.33.27 # me and hundreds of other peoples yes 03.33.33 # well, good on you 03.33.37 # and all the others 03.33.41 # fantastic job 03.33.55 # I've got rockbox on my 5g iPod, and that's kickass too 03.33.59 # but the sansa version is super nice 03.34.17 # does anyone know what the SD card limit is on the v1? 03.34.30 # whatever is the theorical limit, 32GB i guess 03.34.39 # sweet! 03.34.48 # a 32gb card is like.....50 bucks 03.34.52 # :D 03.34.58 # now I can put off that new iPod touch 03.35.52 # iPod touch is worth it ONLY for Sudoku and email, assuming your phone doesn't handle it. 03.35.59 Quit Dreamxtreme (Read error: Connection reset by peer) 03.36.08 # other than that, it sucks for a media player and web browser 03.36.09 # right, I already have a 16gb v2 03.36.14 # which is great for apps and stuff 03.36.21 # guys please stay on topic, move this chat to #rockbox-community 03.36.22 # but the little sansa is really good at playing music 03.36.29 # Sorry, funman 03.36.36 # aw c'kon funman, your name is paradoxical! 03.39.09 Join Dreamxtreme [0] (~Dreamxtre@92.30.156.178) 03.42.17 # I answered my own question anyway lol 03.48.35 # ah i continue to see the weird malformed packet on clip+ 03.50.39 # New commit by 03funman (r28034): USB AMSv2: update endpoint->len on transfer ... 03.50.43 Quit mulenmar_ (Quit: Leaving) 03.52.29 # r28034 build result: All green 03.55.59 Quit anewuser (Ping timeout: 252 seconds) 03.59.45 # New commit by 03funman (r28035): USB AMSv2: cosmetics ... 04.00.01 Quit milz (Remote host closed the connection) 04.01.52 # r28035 build result: All green 04.07.39 Join milz [0] (~kyle@S0106001ff341eb86.cg.shawcable.net) 04.12.32 Quit amiconn (Disconnected by services) 04.12.34 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.12.44 Quit pixelma (Disconnected by services) 04.12.46 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.12.48 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.12.54 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.15.30 Quit TheSeven (Ping timeout: 240 seconds) 04.16.16 # [ 2904.900046] usb 1-3: device firmware changed 04.16.24 # how does it know?? 04.17.25 # magic! 04.21.08 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.30.55 Join Barahir_ [0] (~jonathan@frnk-590f6ae3.pool.mediaWays.net) 04.34.44 Quit Barahir (Ping timeout: 276 seconds) 04.36.33 Quit GodEater (Ping timeout: 260 seconds) 04.37.24 Join GodEater [0] (~bibble@cl-711.lon-02.gb.sixxs.net) 04.37.24 Quit GodEater (Changing host) 04.37.24 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 04.38.46 Quit JdGordon| (Quit: leaving) 04.39.20 # i see weird things in AMSv1 usb driver 04.43.24 Join cjcopi [0] (~craig@adsl-70-239-13-232.dsl.bcvloh.sbcglobal.net) 04.53.31 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 04.58.33 *** Saving seen data "./dancer.seen" 05.02.36 Join kaiscene [0] (~kaiscene@ool-18e45d82.dyn.optonline.net) 05.02.41 # have we got lyrics support in rockbox yet? 05.02.42 # even beta? 05.02.58 # check flyspray i think there's a patch for it 05.03.22 # like a patch that I have to compile in myself? 05.03.26 # or a patch that I stick in the .rockbox folder. 05.03.59 # the first one 05.04.07 # blah 05.04.11 # I'm too lazy to do such a thing haha 05.04.27 # why is that not in core yet? 05.04.46 # it should be explained in the flyspray entry 05.05.06 # which one? 05.05.10 # how to do it, or why it's not in core 05.05.24 # because I know how to do it, I'm just lazy lol 05.05.27 # why it's not in core 05.05.48 # oh, ok, I'll read it 05.06.02 # I think I tried to build rb with that patch for my iPod, I could never get it to work 05.23.23 Join JdGordon [0] (af20d96a@gateway/web/freenode/ip.175.32.217.106) 05.26.14 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 05.31.13 # New commit by 03funman (r28036): usb-s3c6400x.c : don't hardcode USB_NUM_ENDPOINTS but use the define 05.31.21 # New commit by 03funman (r28037): USB AMSv2: use status == -1 to signal errors ... 05.32.46 # r28036 build result: All green 05.33.18 Quit ps-auxw (Ping timeout: 240 seconds) 05.34.17 # r28037 build result: All green 05.41.31 Join kam [0] (~chatzilla@user-0c90t1m.cable.mindspring.com) 05.42.55 Quit JdGordon (Ping timeout: 252 seconds) 05.44.49 Join ps-auxw [0] (~arneb@p4FF7EF16.dip.t-dialin.net) 05.52.11 Quit kam (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100723085406]) 05.59.50 Quit clone4crw (Ping timeout: 240 seconds) 06.01.07 Quit leachim6 (Quit: Leaving) 06.03.47 Quit fyrestorm (Ping timeout: 276 seconds) 06.16.58 Quit Horscht (Quit: Verlassend) 06.20.41 # New commit by 03funman (r28038): USB AMSv2: simplify FOR_EACH* macros ... 06.22.25 # r28038 build result: All green 06.23.10 # TheSeven: I forgot that of course we also have the 22k+ lines Linux driver made by Synopsys 06.27.06 # New commit by 03funman (r28039): USB AMSv2: Reduce the size of (in/out)_ep_list 06.28.34 # r28039 build result: All green 06.35.17 Join anewuser [0] (anewuser@unaffiliated/anewuser) 06.36.43 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 06.36.44 Quit liar (Excess Flood) 06.37.43 # New commit by 03funman (r28040): usb-drv-as3525v2.c: cosmetics (remove trailing spaces) 06.37.47 Quit Judas_PhD (Quit: This is a quitting message) 06.39.09 # r28040 build result: All green 06.47.48 Join shuffle2 [0] (~shuffle2@cpe-74-74-168-216.rochester.res.rr.com) 06.48.51 # hi 06.49.14 # i found this really old log where people discuss the bcm2722 chip used in ipod 5g http://www.rockbox.org/irc/rockbox-20060616.txt 06.49.27 # has anything happened with it since then? :) 06.49.32 # no 06.52.04 Join Zarggg [0] (~zarggg@70.44.12.90.res-cmts.sm.ptd.net) 06.58.38 *** Saving seen data "./dancer.seen" 07.01.04 Join fyrestorm [0] (~nnscript@cpe-68-173-233-99.nyc.res.rr.com) 07.01.34 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 07.03.32 Quit CaptainKwel (Quit: Ex-Chat) 07.04.51 # New commit by 03funman (r28041): USB AMSv2: only read endpoint interrupt status register once 07.05.28 # hum, i was asking about bcm2722 because i saw it has an usb interface 07.05.48 # however the PP5021C-TDF does as well? 07.06.28 # r28041 build result: All green 07.06.41 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 07.06.49 # an usb interface? 07.07.09 # so says http://www.eefocus.com/data/06-12/111_1165987864/File/1166002400.pdf 07.08.54 Quit Judas_PhD (Client Quit) 07.09.03 # "bcm" not found 07.09.19 # ? 07.09.20 Quit BHSPitMonkey (Remote host closed the connection) 07.09.24 # IIUC the bcm2722 is only an audio/video processor (http://www.broadcom.com/products/Cellular/Mobile-Multimedia-Processors/BCM2722) 07.09.30 # I can't find any mention to "bcm" in that pdf 07.09.58 # http://curiouscat.org/Steve/Media/2722-PB01-R.pdf 07.10.03 Join CaptainKwel [0] (~jason@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 07.10.18 # that's because it's a PP part and not made by broadcom?? o_O 07.10.57 # you were asking about bcm2722 because you saw "it has an usb interface" <- "it" is the PP or the bcm2722 ? 07.11.04 # both 07.11.26 # interesting, maybe it's for debug purposes? 07.11.31 # which connects to the external ipod port is what i'm really asking ;p 07.12.06 # i'd guess PP, as it's usb 2.0, opposed to 1.1 07.12.25 # and maybe that makes coding for it easier? do you know of docs for this cpu? 07.12.57 # nope but i don't know PP, wait a bit until the europeans wake up and ask again 07.13.16 # AFAIK most of the work for PP required reverse engineering 07.15.59 Quit soap (Ping timeout: 255 seconds) 07.16.45 # New commit by 03funman (r28042): USB AMSv2: smaller struct usb_endpoint ... 07.17.24 Quit kaiscene (Ping timeout: 276 seconds) 07.17.46 # there are no docs for the bcm or pp chips 07.18.01 # http://www.rockbox.org/wiki/PortalPlayer502x#USB_Controller 07.18.01 # well, it's a start :p 07.18.19 # r28042 build result: All green 07.18.31 # btw what are you using to do build tests? 07.18.52 # self-written perl scripts 07.19.24 # http://www.rockbox.org/wiki/BuildClient 07.19.40 # neat 07.19.40 # (self = written by rockbox hackers, not by me) 07.20.36 # i still don't get what's wrong with USB 07.20.51 Join kaiscene [0] (kaiscene@ool-18e45d82.dyn.optonline.net) 07.21.17 # you mean your current commits? 07.22.50 # the file i'm working on, yes 07.23.38 # it works just like with FS#11607 so i can't compare with usb-s3c6400x.c 07.26.26 Join jfc^3 [0] (~john@dpc6682208002.direcpc.com) 07.29.08 Join soap [0] (~soap@rockbox/staff/soap) 07.29.43 # soo 07.29.59 Quit jfc (Ping timeout: 265 seconds) 07.30.52 # the PP is just arm core(s)? have people dumped apple's code to speak to usb? (or just the entire thing?) 07.31.38 # it can't be that large of a codebase 07.37.01 Quit CaptainKwel (Ping timeout: 252 seconds) 07.41.24 # http://booya.dyndns.ws:666/open/ipod_fw.png :P 07.43.08 # New commit by 03funman (r28043): USB AMSv2: split handle_ep_int() ... 07.44.43 # r28043 build result: All green 07.48.09 Quit Bug2000 (Read error: Connection reset by peer) 07.56.57 Quit anewuser () 08.02.22 Join Bug2000 [0] (~bug@unaffiliated/bug2000) 08.05.07 Join solexx___ [0] (~jrschulz@e176098084.adsl.alicedsl.de) 08.07.50 Quit solexx (Ping timeout: 264 seconds) 08.13.11 # New commit by 03funman (r28044): USB AMSv2: use tables for usb_drv_port_speed() and usb_drv_mps_by_type() 08.14.44 # r28044 build result: All green 08.31.22 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 08.32.01 Quit mc2739 (Ping timeout: 272 seconds) 08.41.08 Join ender` [0] (krneki@foo.eternallybored.org) 08.45.57 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 08.51.45 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.52.19 Quit mc2739 (Ping timeout: 240 seconds) 08.55.31 Join petur [0] (d408b802@rockbox/developer/petur) 08.57.32 Join LinusN [0] (~linus@giant.haxx.se) 08.57.32 Quit LinusN (Changing host) 08.57.32 Join LinusN [0] (~linus@rockbox/developer/LinusN) 08.58.41 *** Saving seen data "./dancer.seen" 08.58.47 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 09.07.15 Quit xnyhps (Quit: leaving) 09.07.46 Join xnyhps [0] (~xnyhps@xnyhps.nl) 09.11.02 Quit bertrik (Quit: :tiuQ) 09.16.35 Join Rob2223 [0] (~Miranda@p4FDCB04E.dip.t-dialin.net) 09.20.15 Quit Rob2222 (Ping timeout: 258 seconds) 09.22.27 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 09.23.40 Quit Luca_S (Client Quit) 09.24.14 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 09.25.27 Quit funman (Quit: free(random());) 09.32.54 # fwiw, the cygwin packages you provide at http://download.rockbox.org/cygwin are named a bit wrongly 09.33.23 # your buildscripts expect "-eabi" in the filename, those packages don't install as such 09.35.51 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 09.40.30 Join Drise [0] (~Drise@user-24-236-91-225.knology.net) 09.41.28 Quit Drise (Client Quit) 09.43.42 Join swilde [0] (~wilde@aktaia.intevation.org) 09.50.32 # shuffle2: they're named correctly 09.51.49 # oh? 09.52.23 # They're not named eabi because, surprise, they're not the eabi compilers 09.53.47 # i'm shocked 10.00.03 Quit sasquatch (Quit: WeeChat 0.3.2) 10.00.28 Join sasquatch [0] (~username@p4FF2DED3.dip.t-dialin.net) 10.07.59 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 10.11.40 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 10.19.17 Quit bmbl (Ping timeout: 258 seconds) 10.26.05 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 10.35.20 Join kyle_ [0] (~kyle@S0106001ff341eb86.cg.shawcable.net) 10.36.09 Quit milz (Ping timeout: 276 seconds) 10.46.11 Part LinusN 10.46.30 Quit Luca_S (Quit: CGI:IRC (Ping timeout)) 10.49.37 Join LinusN [0] (~linus@rockbox/developer/LinusN) 10.54.30 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 10.58.45 *** Saving seen data "./dancer.seen" 11.17.46 Join [Saint] [0] (S_a_i_n_t@203.184.0.26) 11.31.00 Quit [Saint] (Quit: Even if you're lying, please tell me everythings going to be fine.) 11.31.06 Join [Saint] [0] (S_a_i_n_t@203.184.0.26) 11.36.16 # amiconn: the h120 can echo the signal it gets on it's spdif input on its line out, yeah? i've forgotten how it works :> 11.42.12 Quit evilnick (Ping timeout: 240 seconds) 11.56.07 Join funman [0] (~fun@rockbox/developer/funman) 12.21.54 Join Jerom [0] (~jerome@95.171.148.36) 12.38.06 # funman: I see you closed FS11607 with the reason "usb-drv-as3525v2.c now works"; if that's the case, I have to report that enabling USE_ROCKBOX_USB and commenting USB_HANDLED_BY_OF on current SVN leads to PANIC: usb-drv: EP0 data completion while waiting for ACK (FuzeV2) 12.39.11 # try plugging it a dozen of times and see if it gives this message all the times 12.40.22 # the second time has been enough :D :D 12.44.20 # "svn works like fs#11607" -> plug it 10 times, 10 different results 12.44.55 # sometimes it'll mount properly and transfer files with very decent performance, sometimes it'll almost mount but fail, sometimes it fails very early 12.45.06 Join hebz0rl [0] (~hebz0rl@dslb-088-065-062-026.pools.arcor-ip.net) 12.45.49 # do I have to change something in the headers to enable HID? 12.46.42 Quit BlakeJohnson86 (Remote host closed the connection) 12.46.57 # yes but i think you must at least disable usb storage for it to work 12.47.09 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 12.47.39 # grep for HID in firmware/export/config/sansaclip.h and uncomment HAS_USB_INTERRUPT in firmware/export/config.h(? i think it's this file) 12.48.32 # I'll try, thank you 12.58.47 *** Saving seen data "./dancer.seen" 13.04.16 Quit Luca_S (Quit: CGI:IRC) 13.04.16 Quit Jerom (Quit: Leaving.) 13.13.51 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 13.17.16 Join esperegu [0] (~quassel@145.116.15.244) 13.23.25 Join pamaury [0] (~quassel@dhcp-129-136.residence.ens-lyon.fr) 13.23.25 Quit pamaury (Changing host) 13.23.25 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 13.23.39 # funman: ping 13.23.48 # you made lots of changes to my code, some are strange 13.24.08 # i made an effort to separate changes so just ask 13.24.26 # why halving fifo size ? 1024 is a best bound since it also handling isochronous. Also, the fifo is large enough to handle it 13.24.42 # it didn't work with 1024 13.25.00 # i used the fifo size of usb-s3c6400x.c and it magically mounted 13.25.25 # cosmetics: x ? true : false -> x 13.25.31 # NO because the value is not 0 or 1 13.25.42 # it's 0 or 0x80, that's bad practice 13.26.10 # function returns bool so it's casted 13.26.22 # yes but that's bad practice anyway 13.26.47 # why do set endpoints[ep][DIR_IN].status = -1; on reset ? The status is updated each time you trigger a transfer ? 13.27.02 # i don't think so but then you are free to use your style and revert this change 13.27.24 # i initialize to error to be sure success is only reported when transfer is complete 13.27.41 # * amiconn agrees with funman regarding that kind of cosmetics 13.27.55 # before that reset_endpoints() would report success when cancelling transfers 13.27.56 # x ? true : false is just line noise imo 13.28.13 # in the same commit i made sure reset_endpoints set the status to error though 13.28.51 # but why in reset_endpoints AND cancel_transfers ? 13.28.53 # funman, pamaury: regarding the fifo size: the nano2g only seems to have 1K of total fifo size, and that register has only 11 bits each for those fifo addresses 13.29.01 # ok 13.29.04 # pamaury: which revision exactly? 13.29.18 # 28036 13.29.41 # wrong one 13.29.42 # apart from this, you checked on fuzev2 ? Does it work now ? 13.29.48 # 28037 13.29.50 # :) 13.30.38 # cancel_all_transfers() 13.30.57 # the only change in cancel_all_transfers() is 1 -> -1 13.31.22 # yes, but why setting status in reset_endpoints ? if you cancel the transfer, cancel_all_transfers already set it to -1 13.31.49 # it doesn't really matter, I'm just wondering if it changes anything 13.31.50 # reset_endpoints() doesn't call cancel_all_transfers 13.32.08 # no, but in no way you get a bad status after reset_endpoints 13.32.10 # the status need to be an error before wakeup_signal() is called 13.33.01 # hum, right, I forgot reset_endpoints call wakeup_signal() 13.33.04 # i took example on usb-drv-as3525.c (line 181: busy && async -> error) 13.33.18 # * pamaury find it funny that funman know my driver better than me 13.33.21 # and no i didn't check on fuzev2 because i lend it to a friend some days ago 13.33.37 # pamaury: for your defense i spent all the night reading it over and over 13.33.56 # rewriting some parts to make sure i understood it and i committed what i thought would be useful 13.34.25 # the remaining changes are ok, cosmetics are not important to me, if you think it's better this way, I have no objection 13.35.05 # what i didn't understand is the 'next' chaining line 304 13.35.29 # TheSeven has mentioned it in his code also but i dont' know what it means 13.35.31 # that's for dma 13.35.55 # apparently (I have no real doc on this), each IN endpoint need to mention the next endpoint to handle for dma transfers 13.36.29 # you do a cycle so everything works: handle EP0 -> handle EP1 -> handle EP3 -> handle EP0 -> ... 13.36.38 # ah ok 13.36.51 # I did not check without so I can't tell if it's useful or not, the doc says it must be set in dma mode 13.37.05 # btw if you want to look at the remaining problem it seems the same than when using usb-s3c6400x.c on amsv2 13.37.09 # and it definitely must be 13.37.17 # endpoints not in that queue will never be handled 13.37.19 # there is a malformed packet (always the same) visible in wireshark log 13.37.27 # * TheSeven struggled with that crap for quite some time 13.37.32 # it is reproducable ? 13.37.34 # easily ? 13.38.01 # run wireshark and plug/unplug your clip+ until it doesn't mount (it can be on the first time or the 10th time) 13.38.27 # looking at dmesg you will see it can fail at different steps 13.38.55 # ok, I'll have a look but seeing the problem that caused it to fail (the invalidate_dcache()), I fear it can be anything :D 13.39.11 # I need to leave, good news it finally works ! 13.39.21 # yeah thanks to you;) 13.40.18 Join Kitr88 [0] (~Kitarist@BSN-182-63-243.dial-up.dsl.siol.net) 13.41.37 Quit pamaury (Remote host closed the connection) 13.43.05 # i should look in firmware/usbstack/ perhaps the problem is here 13.43.09 Quit Kitar|st (Ping timeout: 265 seconds) 13.43.19 # some buffers use USB_DEVBSS_ATTR, some don't 13.43.52 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.44.20 Quit Kitr88 (Ping timeout: 240 seconds) 13.44.20 # funman: what's the difference between invalidate_dcache and dump_dcache? 13.45.13 # invalidate writes back cache to memory 13.45.53 # I thought flush_ does that 13.45.55 # so if you're going to receive data into this buffer with DMA you should dump it, no need to write back something which will be replaced 13.46.03 # flush_*() doesn't exist 13.46.13 # * kugel always thought invalidate_ doesn't do writeback 13.46.23 # cpucache_flush() does 13.46.29 # invalidate_() writes back and throw away the cache 13.46.38 # clean_() writes back and keeps the cache 13.46.51 # * [Saint] finds that the link: http://home.earthlink.net/~davidegentile/rockbox/codec_pack.zip (which contains CLI encoders, a debug menu patch and a batch file for converting the sample song into various (supported) formats.) on the CodecPerformanceComparison wiki page is dead... 13.46.56 # <[Saint]> Is it available elsewhere? 13.48.04 # cpucache_flush() is alias for clean_dcache(), it makes sure everything is in main memory (originally it was to make sure both cores see the same memory on PP i guess) 13.48.28 # not sure what's invalidate_dcache() useful for though .. 13.48.51 # funman: thanks for the info 13.49.13 # you need that for in-place dma things 13.49.19 # then that's probably why the invalidate call pamaury removed fixed problems 13.49.22 # kugel: i was reading mmu-arm.S this night (because i asked myself the same questions) and i thought i should write something about it 13.49.24 # like encrypting/decrypting/compressing/whatever stuff 13.49.38 # TheSeven: do we do that in rockbox? 13.49.49 # in the nano2g bootloader at least 13.50.00 Join Kitar|st [0] (Kitarist@89.142.55.137) 13.50.06 # and we usually don't want to dump the *full* data cache 13.50.15 # IMO it should be clean_dcache() -> do DMA -> dump_dcache() 13.50.22 # and for example on 940t you can't do it selectively 13.50.48 # if you dump the cache, that will affect things that have been calculated while dma was active 13.50.57 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.51.02 # ah right 13.51.15 # on 940t you'll need clean => dma => invalidate 13.51.30 # the clean will make sure that the invalidate won't overwrite dma data 13.52.18 # are you dumping the full cache anywhere? 13.52.29 # if yes, I'm sure that this will cause trouble somewhere 13.52.42 # everytime you see cpucache_flush() (but that's in common code) 13.52.57 # err it's not dumping 13.53.10 # flush should be mapped to invalidate 13.53.11 # then no 13.53.18 # mmu-arm.S only has a dump_dcache_range() anyway 13.53.33 # yes, because everything else doesn't make sense for that one 13.54.05 # see you later 13.54.09 Quit funman (Quit: free(random());) 13.56.52 # * kugel thinks dump_dcache() is a bit missleading 13.58.35 # * kugel thinks commit (for clean), flush (for invalidate) and trash (for dump) would be better names 13.59.13 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 13.59.49 # make: *** No rule to make target `/data/rockbox-trunk/build/nano2-app/make.dep', needed by `all'. Stop. 13.59.56 # hmm, what the hell... 14.00.44 # * [Saint] scratches his head...I haven't built in ~1.5 days...haven't seen that. 14.01.43 # * TheSeven is updating a working copy that had been abandoned for months 14.02.15 # kugel: normally "invalidate" just means throwing them away 14.02.25 # "flush" == "clean and invalidate" 14.02.57 # but throwing away doesn't imply write-back for me 14.03.05 # That's what I mean 14.03.09 # invalidate *doesn't* write back 14.03.15 # it does 14.03.19 # no it doesn't 14.03.20 # not on ARM 14.03.29 # it does on 940t at least 14.03.31 # No, it doesn't 14.03.35 # our invalidate_dcache does write-back 14.03.36 # i assure you 14.03.42 # then that's not doing an invalidate 14.03.45 # that's doing a clean+invalidate 14.03.53 # ARM's terminology is clean, invalidate, or clean+invalidate 14.03.59 # arm is calling that "clean and flush" usually 14.04.04 Nick solexx___ is now known as solexx (~jrschulz@e176098084.adsl.alicedsl.de) 14.04.12 # Torne: hence our confusion 14.04.21 # no, ARM don't use flush with regards to dcache 14.04.37 # they talk about flushing prefetch buffers, or branch target caches 14.04.44 # I also thought it doesn't write back 14.04.45 # but they only use clean, invalidate and clean and invalidate for caches 14.04.54 # right 14.04.56 # so our names are wrong 14.05.00 # * TheSeven thinks they should be called "writeback" and "discard" 14.05.09 # but the names you are suggesting, i don't think are very good either :) 14.05.32 # * TheSeven still isn't sure how to call the current invalidate function, which is doing both 14.05.43 # i assume it does c14, 0 ? 14.05.52 # ARm call that "Clean and invalidate entire data cache" 14.05.58 # in ARMARM 14.06.50 # what about writeback, discard and flush as the new names? 14.06.53 # i don't like the name flush for *anything* 14.06.53 # I think we should have names which work for all archs (and make sense for the reader), if if that aren't the ones used by the vendor 14.07.01 # because different OSes/vendors use that to mean different things 14.07.09 # even if* 14.07.13 # writeback/discard should be clear at least 14.07.13 # some OSes/chips think flush implies writeback and some think it implies invalidation without writeback 14.07.23 # so I vote to not use the term flush at all 14.07.32 # any ideas for the third name then? 14.07.47 # writeback and discard make sense, yes 14.08.19 # * kugel votes for trash over discard because it rhymes with cache :) 14.08.40 # <[Saint]> err...kinda ;) 14.08.59 # <[Saint]> if you saw "trashe" :P 14.09.06 # <[Saint]> argh! *say 14.09.17 # [Saint]: cache is pronounced cash in british english 14.09.24 # not caysh 14.09.26 # :) 14.09.39 # <[Saint]> here...it is "cash-aye" 14.10.24 # that's dumb 14.10.27 # that sounds weird to me (unless you also pronounce "aye" differently) 14.10.28 # aanyway 14.11.38 # * kugel also prefers commit over writeback 14.12.26 # * Torne doesn't think clean is controversial, but commit and writeback are also perfectly clear so whichever. 14.12.46 # i don't think you can come up with a single-word name for clean+invalidate which is unambiguous, anyway 14.13.13 # <[Saint]> clelidate? ;p 14.13.22 # * Torne beats [Saint] with a stick 14.13.34 # Torne: clean (for me) implies the cache is dirty, but normally you use clean when the ram is dirty (dirty in the sense of old with incorrect content) 14.13.52 # but that's what the cache being dirty means 14.13.58 # the cache being dirty *means* it has newer content 14.14.24 # ram being dirty would mean that it's newer than, say, a copy on disk 14.14.59 # and what's it called if the ram has newer content than cache? 14.15.11 # also dirty ram? 14.15.14 # That's called "your system is already broken" 14.15.23 # That's not a situatoin which is allowed to arise, ever, in a functoining system 14.15.34 # that's called "we use dma" 14.15.43 # no, it's not 14.15.57 # if you are going to use DMA it is your responsibility to eliminate all the cachelines that are relevant *fist* 14.16.08 # such that the newer content in ram has no corresponding cacheline 14.16.19 # otherwise the system is broken, because the cache can choose to do writebacks at any time without your knowledge. 14.16.43 # so no, that situation can never legitimately arise 14.16.59 # no matter what the context (DMA, SMP, etc) 14.17.04 # I see, why does invalidate (without writeback) even exist then= 14.17.05 # ? 14.17.25 # because sometimes you know it's irrelevant whether that data was written or not 14.17.37 # e.g. when you are about to free that bit of memory and reuse it for a different purpose 14.17.46 # and thus you want the performance benefit of not forcing a writeback 14.17.57 # it is very infrequently used, yes 14.18.07 Join Strife89DS [0] (~nds@207.144.201.128) 14.18.14 # * TheSeven realizes that loads of cache coherecy calls are broken, when thinking things through 14.18.26 # TheSeven: this is not surprising, cache coherency is hard :) 14.18.30 # basically every dcache_invalidate call 14.18.44 # Torne: it's even harder when the functions have misleading names 14.18.58 # btw, this is why Symbian has, instead of exposing cache clean/invalidate operations to drivers, just got functions called "SyncMemoryBeforeDmaRead" and "SyncMemoryAfterDmaRead" and the equivalents for write 14.19.01 # IIUC that would only be needed for dma that changes things in-place 14.19.16 # ah, wait 14.19.25 # we need to kill the cachelines even if they're clean 14.19.41 # TheSeven: if you're about to do a DMA read, you can just invalidate the lines in questoin 14.19.50 # you don't care about cleaning them because the DMA will overwrite the data anyway 14.19.59 # * TheSeven works on platforms that can't deal with individual cache lines 14.20.04 # well yes 14.20.13 # you can always implement "invalidate line X" in terms of "invalidate entire cache" 14.20.16 # it's just slower 14.20.20 # it's equivalent from a safety/correctness pov 14.20.28 # it isn't for discarding 14.20.37 # only for commit+discard 14.20.44 # Oh, er, yes 14.20.56 # But that just means you implement "discard line x" as "commit+discard entire cache" 14.21.00 # this is always safe 14.21.03 # so what names should we use now? 14.21.04 # * TheSeven thinks "commit", "discard" and "commit_discard" are probably the best names 14.21.09 # because the writebacks could've always happened at any time anyway 14.21.16 # so forcing them to happen cannot make the system wrong 14.21.19 # unless it was wrong already 14.21.20 Quit esperegu (Remote host closed the connection) 14.21.20 # yep 14.21.25 # TheSeven: yes, probably 14.21.32 # TheSeven: that seems pretty unambiguous to me 14.21.34 # TheSeven: but trash and cache rhyme! 14.21.48 # trayshe? :D 14.22.18 # other than that, I'm fine with those 14.23.03 # maybe we could do with a careful review of all our cache stuff at some point :) 14.23.18 # since if we're wrong in one or two places that could cause just about anything to go wrong on those platforms 14.25.59 # we could alias discard and trash :) 14.26.11 # anyway, who's going to do it? 14.27.58 # we could add the new names as aliases for now, and then check every call of them one by one (old name indicates that it needs checking) 14.30.50 # * kugel we could also make use of __attribute__((deprecated)) but that would add noise to the build system 14.31.21 Join MethoS- [0] (~clemens@134.102.106.250) 14.32.57 # that sounds like a good approach 14.33.12 # are there other functions with the same problem, as well? 14.33.31 # different arches/mmu styles alrady have slightly different names for some of this stuff, don't they? 14.33.38 # the cpucache_* stuff and so on 14.35.43 Quit MethoS- (Remote host closed the connection) 14.36.08 Quit petur (Quit: reboot) 14.36.09 Join MethoS- [0] (~clemens@134.102.106.250) 14.36.17 # aliases don't need the ".type , %function" stuff? 14.41.33 Join CaptainKwel [0] (~jason@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 14.52.15 Quit dfkt (Read error: Connection reset by peer) 14.52.16 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 14.52.58 Join petur [0] (d408b802@rockbox/developer/petur) 14.54.45 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 14.58.49 *** Saving seen data "./dancer.seen" 14.58.51 Quit dfkt_ (Ping timeout: 272 seconds) 14.59.06 Quit Dreamxtreme (Quit: Don't follow me) 15.04.25 Join Dreamxtreme [0] (~Dreamxtre@92.30.156.178) 15.05.09 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 15.08.04 Quit dfkt (Ping timeout: 255 seconds) 15.08.24 Join normalll [0] (~chatzilla@111.118.45.125) 15.08.33 # #iphone 15.08.37 # join #iphone 15.08.46 Mode "#rockbox +o TheSeven" by ChanServ (ChanServ@services.) 15.10.49 # * TheSeven wonders if the hid works with windows 7 at all 15.11.02 Quit kyle_ (Quit: Konversation terminated!) 15.11.02 # it isn't detected properly over here 15.11.09 Join kyle_ [0] (~kyle@S0106001ff341eb86.cg.shawcable.net) 15.11.18 Quit kyle_ (Client Quit) 15.11.31 Mode "#rockbox -o TheSeven" by TheSeven (~TheSeven@rockbox/developer/TheSeven) 15.14.27 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 15.16.02 Join milz [0] (~kyle@S0106001ff341eb86.cg.shawcable.net) 15.18.30 Quit normalll (Quit: ChatZilla 0.9.84 [Firefox 3.0.11/2009060215]) 15.22.40 # TheSeven, Torne: http://pastie.org/1145761 15.25.12 Quit CaptainKwel (Ping timeout: 258 seconds) 15.25.33 # kugel: maybe dcache_* might be a better name, as it doesn't deal with icache 15.25.51 # which one? 15.25.56 # at the top 15.26.15 # IIUC we should basically have the following functions, regardless of the target we're running on: 15.26.23 # cpucache_commit_discard deals with icache (on the platforms that have it) 15.27.11 # I think it's cpucache to hide i/dcache separation from non-target tree code 15.27.21 # or any cache details in fact 15.27.26 # do we really want to hide that? 15.27.46 # I don't know, I just renamed :) 15.28.31 # dcache_commit_range, dcache_discard_range, dcache_commit_discard_range and icache_discard_range should basically catch everything 15.28.56 # indeed, cpucache_* is basically only used where *only* the icache needs to be discarded (loading code), but on CF and PP it only deals with dcache 15.28.56 # they can be handled efficiently on targets that support it, or just flush the whole cache on targets that don't 15.29.08 # IIUC 15.29.17 # hi. i came here yesterday looking for info about ipodlinux usb support. since then i've realized that rockbox is much more advanced in this regard (not to mention ipodlinux has been inactive for years...) 15.29.21 Quit user890104 () 15.29.26 Join user890104 [0] (~Venci@212.233.135.74) 15.29.59 Quit user890104 (Client Quit) 15.30.02 # anyways, is the best place for info the code itself? I've noticed the wiki claims the usb on this particular PP is undocumented...while rockbox appears to use usb just fine on my ipod ;p 15.30.03 Join user890104 [0] (~Venci@212.233.135.74) 15.30.27 # undocumented doesn't mean that nobody reverse-engineered it :) 15.31.37 # I'm not sure if *_range is enough on targets that have MMU 15.31.47 Quit milz (Ping timeout: 260 seconds) 15.32.53 # err, I mean where different ram regions are used (i.e. iram and ram), and where there are not adjacent 15.44.10 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 15.45.07 Quit dfkt (Read error: Connection reset by peer) 15.45.08 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 15.56.50 Quit komputes (Remote host closed the connection) 16.00.01 Join Jaykay [0] (~chatzilla@p5DC577DA.dip.t-dialin.net) 16.04.33 Join anewuser [0] (anewuser@unaffiliated/anewuser) 16.05.59 Quit kkurbjun (Ping timeout: 240 seconds) 16.08.30 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 16.28.27 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 16.33.47 # * pamaury read the discussion on invalidate vs flush vs ... and think invalidate is a confusing name for write-back 16.33.55 # it explain all my problems ! 16.35.00 Join r0b- [0] (~nnscript@adsl-76-235-191-177.dsl.klmzmi.sbcglobal.net) 16.36.20 Join toffe82 [0] (~chatzilla@12.169.218.14) 16.37.55 Quit krazykit (Quit: ok, moving to chicago) 16.42.13 Quit parafin (Quit: So long and thanks for all the fish) 16.45.23 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 16.46.44 Quit robin0800 (Client Quit) 16.47.04 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 16.47.17 Quit robin0800 (Remote host closed the connection) 16.47.40 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 16.55.04 Quit Strife89DS (Ping timeout: 276 seconds) 16.55.23 Join Strife89DS [0] (~nds@207.144.201.128) 16.56.16 Quit Gatz85 (Quit: Gatz85) 16.56.44 Part LinusN 16.58.53 *** Saving seen data "./dancer.seen" 16.59.07 Join Gatz85 [0] (~gatz@173.217.238.185) 17.12.34 Part Zagor 17.14.56 Join _s1gma [0] (~d.d.derp@77.107.164.131) 17.15.21 Quit _s1gma (Max SendQ exceeded) 17.15.22 Join esperegu [0] (~quassel@145.116.15.244) 17.15.51 Join evilnick [0] (~evilnick@cpe-68-174-75-165.nyc.res.rr.com) 17.15.52 Join _s1gma [0] (~d.d.derp@77.107.164.131) 17.18.42 Join Misanthropos_ [0] (~Misanthro@dsl-38-204.telebyte.com) 17.20.43 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.22.54 # kugel: I object to changing the comments on the individual mcr instructions 17.23.17 # "Clean and invalidate line by MVA" is the ARM ARM definition of what cp15 c7 c14 does. 17.24.11 # using different terminology to explain what a specific instruction for a specific processor does, compared to that processor's manual, doesn't seem useful 17.24.30 Quit robin0800 (Remote host closed the connection) 17.24.56 # and i'm still not sure what the cpucache_* ones refer to 17.25.13 # if they mean both caches we should be more explicit about that 17.25.19 # if it just means one or the other then call it one or the other 17.25.32 # and arches where the caches are not separate will just have two names for the same actual functionality 17.31.19 Quit petur (Quit: Page closed) 17.31.50 Quit Xerion (Quit: ) 17.33.48 Quit steve|m (Remote host closed the connection) 17.35.20 Join steve|m [0] (~steve@p4FD46502.dip.t-dialin.net) 17.37.45 Quit Strife89DS (Read error: Connection reset by peer) 17.37.58 Join Strife89DS [0] (~nds@207.144.201.128) 17.39.01 # Torne: ok, restoring 17.39.38 # kugel: if you wanted to be clear you could have a comment at the top explaining that the generic name "discard" is referred to by ARM as invalidate, in the ARM-specific code, even 17.42.11 # * TheSeven wonders what those cpucache_* functions are good for any if we should just get rid of them 17.43.09 # * Torne has no idea, has not really paid attention to the cache stuff before now. 17.46.59 # those seem to have been an attempt at a unified cross-architecture cache api providing the functions needed outside of the target tree (to execute dynamically loaded code) 17.47.33 # right.. but it sounds from the discussoin earlier like they only take care of the icache (except on arches where the cache is unified) 17.47.44 # and the names don't imply that at all 17.47.58 # they take care of both 17.48.51 # having one set called cpucache_* and the othe rset called *_dcache is weird in any case 17.48.55 # well, cpucache_invalidate does for both, cpucache_flush only for dcache 17.48.59 Join [sko] [0] (~sko]@p57A9BC43.dip0.t-ipconnect.de) 17.49.22 # I think the _dcache ones are only for within the target tree 17.49.36 # hm 17.49.45 # hi there. the usb status of the sansa clip+ changed from no* to a yellow yes*. does it mean you can use usb now with the sansa in rockbox? 17.49.56 # if the point of cpucache_whatever is to be used in generic code I'd suggest making the operations even *more* generic 17.50.10 # like the examples i mentioned above: SyncCache{Before,After}DMA{Read,Write} 17.50.17 # the generic code (high level firmware/, apps/) should only call cpucache_* 17.50.22 # such that the semantic is to specify *why* you need a cache operation done 17.50.25 # not what cache operation to do 17.50.36 # Torne: they don't only care about the icache, they need to commit the dcache and drain the write buffer before they discard the icache to make sure the loaded code is actually in ram 17.50.39 # that seems to be the convention from looking at it, I don't know if that's official or anything 17.50.55 # kugel: right, bt i don't think it's apps/ business to know about cleaning and invalidating at all 17.51.20 # if the purpose is "i'm about to load some code to here" and "i'm done loading some code to here" then it seems nicer to say so :) 17.51.45 # i mean, we're a long way from it for now but SMP systems have multiple levels of cleanliness of caches, which are needed for different purposes 17.51.51 Join vaguerant [0] (3aaf4cc7@wikipedia/vague-rant) 17.52.06 # well, apps/ doesn't even use those anymore (since my load_code.c work) but some plugins and codecs use it 17.52.22 # right, but same principle, no? 17.52.36 # it makes more sense to specify the operatoins, where possible, in terms of actual functional semantics 17.52.39 # I think plugins don't load code (except overlay?), so they must have another reason 17.52.48 # and let the target-specific code decide entirely for itself what that has to mean 17.52.49 # maybe dual-core stuff 17.52.59 # Misanthropos_: yes but there are still a few glitches 17.53.46 # Torne: yes, I think so 17.53.56 # Folks, I run a Clip+, and browsing the SVN it looks like funman recently pushed USB support for AMS Sansas, but despite updating both bootloader and Rockbox on my end, I'm still not seeing USB support. Have I misinterpreted something? 17.54.13 # kugel: so "before and after dma read/write" is one set of operations, the implementation of which depends on architecture 17.54.23 # it happens that the implementations are fairly similar on RISC but x86 is not :) 17.54.35 # because x86 is fucking crazy and has full coherency 17.55.11 # vaguerant: I'm not sure if that is enabled by default yet 17.55.15 # pamaury, rhx 17.55.31 # TheSeven: Ahh, that makes sense. 17.55.37 # vaguerant: I fixed the code and funman made some cosmetic changes. Normally it should work but we reached this point this yersterday and night, so as I said, there might be problems left 17.56.19 # pamaury: is it enabled in current builds? 17.56.31 # funman told me it might work on fuzev2 (I can't check), it works for me on clip+ but I need to investigate a random problem. I'm not sure it's enabled by default however 17.57.09 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 17.57.20 # hum no, looking at the code it's disable by default for now 17.57.26 # Is that a runtime or compile-time thing? I do have an environment set up if necessary. 17.57.30 # Ahh, fair enough. 17.57.31 # compile-time 17.57.41 # the wiki says USB isn't in SVN yet 17.57.59 # uncomment //#define USE_ROCKBOX_USB in firmware/export/config/{target}.h 17.58.01 # pamaury: I can confirm that it works (randomly) on FuzeV2. vaguerant: It's disabled by default, but can be enabled easily. 17.58.25 # saratoga: the usb code for amsv2 has always been in SVN, it's just that it wasn't working :D 17.59.05 Quit Judas_PhD (Quit: This is a quitting message) 17.59.16 # I guess the not in SVN could be made more clear 17.59.22 # something like "NOT ENABLED" 17.59.47 # Right, I did see that but it was in reference to an already-closed issue on the tracker. 18.00.05 # Closed with the reasoning that the implementation was now working. 18.00.13 # I just figured the wiki was out of date. 18.00.24 # yes funman tried to make nano2g code work and at the same time I fixed the svn code. It might be that one day the two drivers get merge 18.00.25 Quit Strife89DS (Quit: ClIRC - IRC client for Nintendo DS) 18.03.20 Quit evilnick (Quit: evilnick) 18.04.58 Quit fyrestorm (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) 18.13.03 # Torne: commit? 18.14.19 # kugel: it seem slike the right way to go 18.14.35 # kugel: i can put "review cache stuff" on my ever growing todo list but who knows if i'll get there ;) 18.15.44 # saratoga: do you know why the mad_synth_thread does cpucache_invalidate() on thread exit? 18.16.09 # kugel: probably to clean up the incoherrent cache on PP 18.16.12 # let me double check that 18.16.31 # I guessed so, but I don't see why it would be incoherrent there 18.17.05 # * kugel also wonders what spc does with the caches 18.18.02 # kugel: presumably because while the thread is running on the other core it knows that it's the only one touching those parts of memory 18.18.14 # but after it exits then the memory may be reused on a different core 18.18.21 # so delayed writebacks would trash stuff 18.18.22 # does cpucache_invalidate flush or just dump the cache? 18.18.47 # we try to not use terms like flush and dump anymore :P 18.18.59 # does it write back or just erase 18.19.04 Join domonoky [0] (~Domonoky@agsb-4d0483ac.pool.mediaWays.net) 18.19.10 Quit domonoky (Changing host) 18.19.10 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.19.12 # both 18.19.12 # i guess it doesn't matter since the COP thread shouldn't have any state at that point anyway 18.20.27 # * pamaury has no luck at making usb code fail, even after 20 attempts ! Why can't it fail the first time :) 18.21.14 Quit vaguerant (Ping timeout: 252 seconds) 18.21.22 # saratoga: it doesn't matter by definition 18.21.37 # discarding cachelines without writing back is only ever a performance optimistaion 18.21.49 # it's never any more correct/safe. 18.21.52 Join milz [0] (~kyle@S0106001ff341eb86.cg.shawcable.net) 18.21.54 # well i mean if I was accidentally deleting them without write back :) 18.21.57 # Torne: once more, the current invalidate does write-back :) 18.22.05 # that applies for cpucache_invalidate as well 18.22.30 # oh, yeah, it matters the other way raround :) 18.22.38 # nevermind 18.22.43 # just ignor eme ;) 18.23.13 # fft seems to use commit&discard but it looks like it should only commit 18.23.51 Quit Dreamxtreme (Quit: Ex-Chat) 18.23.55 # considering it also clears the icache, changing it to cpucache_commit should give a performance boost 18.24.13 # (or a more obvious dual_core_sync_shared_mem()) 18.28.53 # * Torne is trying to think of th ebest name for the abstract ops :) 18.29.10 # * Torne re-reads the definitions of point of coherency and point of unification in the ARM ARM. 18.29.25 Quit milz (Quit: Konversation terminated!) 18.29.39 Join milz [0] (~kyle@S0106001ff341eb86.cg.shawcable.net) 18.29.55 # Apparently, I have a usb failure because of a CRC failure 18.30.08 # I think overlay&spc load code, fft does calculations on both cores (in an alternating fashion), the cache op in mad can probably be just removed 18.30.17 # it seems that after that, the device resend the data but the wrong one :o 18.32.13 Quit rasher (Quit: Lost terminal) 18.32.29 Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) 18.32.29 Quit rasher (Changing host) 18.32.29 Join rasher [0] (~rasher@rockbox/developer/rasher) 18.32.46 Join parafin [0] (parafin@paraf.in) 18.32.48 # kugel: so yeah, dma, code loading, and multicore threading on PP are the three cases we have 18.33.13 # there's a fourth case as well but we don't use it at present: needing to write out changes to pagetables so that the MMU walk sees them 18.33.25 # multicore is only a problem because PP's cache is retarded 18.33.30 # code loading is abstracted, except for the case where icode is copied from the binary to the location in iram 18.33.32 # real SMP systems all have MESI cache coherency between cores 18.33.41 # PP doesn't because it's thick as a plank 18.34.24 # right, so all you need for that is a call "code_memory_modified()" or similar 18.34.38 # to note that you have changed data in a region and need the caches twiddling before you execute from it 18.34.42 # which ARM call "point of unification" 18.34.50 # hm no, load_code_from_mem() does what we need 18.35.02 # Ah good 18.35.06 # and presumably nothing in apps is doing DMA either 18.35.15 # it was originally thought to be used for blobs which have a header but that's not a necessary requirement I guess 18.35.29 # so app code should only need to care about this stuff at all if it's doing multicore 18.35.31 # hum, no something is strange, the device sends wrong data but with wrong crc and then good data, ...wtf ! 18.35.44 # which is only a couple of plugins and codecs.. 18.37.24 # and then the controller sends more data than requested by the driver :| 18.39.08 Quit Luca_S (Quit: CGI:IRC) 18.47.20 Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) 18.56.05 Quit parafin (Quit: So long and thanks for all the fish) 18.57.20 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.58.57 *** Saving seen data "./dancer.seen" 19.05.53 # New commit by 03kugel (r28045): Rename cache coherency functions. ... 19.07.55 # I think sd_as3525*.c does it wrong 19.08.04 # r28045 build result: All green 19.08.20 Join parafin [0] (parafin@paraf.in) 19.10.30 # kugel: it what way ? 19.12.29 # hm no, it should be alright 19.13.53 # but I'm thinking maybe the transfer buffer for unaligned transfers should also be cached? 19.14.14 # wouldn't that speedup the following memcpy()? 19.14.38 # which buffers ? 19.14.58 # all transfers buffer should be aligned 19.15.15 # * pamaury thinks he understands one the random problem of the amsv2 usb code 19.15.20 Join evilnick [0] (44ae4ba5@rockbox/staff/evilnick) 19.15.45 # pamaury: no, not all are aligned 19.16.47 # like ? 19.16.55 # New commit by 03kugel (r28046): Change sd-as3525*.c to the new cache coherency function names. 19.17.03 # buffers on stack 19.17.42 # there should *never* be usb buffers on the stack 19.17.58 # I'm not talking about usb 19.18.42 Quit hebz0rl (Remote host closed the connection) 19.18.47 # ah 19.18.51 # r28046 build result: All green 19.20.43 # gevaerts: did you commit your fat buffer patch? 19.21.06 # kugel: If you want non-misleading function names you need to rename the cf one 19.21.33 # didn't I do that? 19.21.34 # i'm still getting main thread stackoverflows at 8K main thread stack size when trying to add a track to a newly created playlist 19.21.36 # Coldfire only has an instruction cache which is hence never written back 19.21.53 # TheSeven: I committed the FAT stack thing, yes 19.22.52 # amiconn: I see, but it's named after the cpucache_* scheme which doesn't care about i/d cache separation 19.23.00 # TheSeven: maybe check if the on-stack buffer in fat_rename() isn't allocated for the entire function? 19.23.01 # kugel: cpucache_commit_discard -> cpucache_discard 19.23.20 # There is nothing that could be committed. 19.23.53 # commit_discard shluld be an alias then 19.23.54 # I know (and I didn't know it only has icache), but the cpucache_* ones are abstrated from the underlying cache 19.24.07 # Torne wants to work on cleaning those up 19.24.16 # Then I don't get the purpose of that commit 19.24.50 # * pamaury is confused by the usb problem, there seem to be an unusual amount of crc failures 19.26.13 # there's no cpucache_discard yet, and all code that needs to discard icache calls the one that also (potentially) touches the dcache 19.26.48 Join Strife89DS [0] (~nds@207.144.201.128) 19.26.56 # I just renamed to the new scheme, analyzing what the functions do exactly is over my head 19.27.24 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.27.43 # maybe you shouldn't rename them then? :P 19.28.19 # but I think there ought to be something like cache_sync_after_code_load() for all platforms (modifying only icache) 19.29.08 # That is what I'm thinking, actually. If the new scheme isn't implemented correctly, it's as misleading as the old one 19.31.16 # cache_sync_after_codec_load() is something that needs very different handling depending on whether the platform has icache only, dcache only, both, or a unified cache, and on the number of cores 19.32.30 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19.32.38 # icache only -> needs invalidating, before or after load doesn't matter 19.32.50 # dcache only -> needs flushing after load 19.33.01 # no 19.33.05 # dcache + icache -> flush dcache, invalidate icache 19.33.08 # dcache only needs no action 19.33.27 # kugel: it does 19.33.29 # unified cache -> no action, unless more than one core 19.34.11 # TheSeven: why? 19.34.40 # because you have to make sure that the loaded data gets actually written to RAM before trying to execute it (or fetch it into the icache) 19.34.43 # gevaerts: indeed, renaming a file from the file browser crashes. now why does that fill up an 8K-sized stack? 19.35.02 # kugel: dcache only means instructions are fetched from main memory. Loading a codec goes through data cache. This data needs to be written to main mem for the instruction queue to load from 19.35.32 # ah yes, I see 19.35.35 # TheSeven: Depending on compiler behaviour that one *might* still have two sectors on stack 19.35.54 # yeah, but not four 19.36.11 # Good point 19.36.53 # unless it's somewhere else, outside fat.c 19.37.03 # main thread stack peak is at 51% (so slightly above 4K) if I navigate directly to the debug menu upon boot 19.37.27 # that's a lot... 19.37.58 # well, it's the peak value 19.38.36 # it surely has read/written some files at that point, so 2K of it are probably already coming from the FAT code 19.38.51 # amiconn: it would be nice if the existing cpucache_* were also split up into the _commit, _discard, _commit_discard, but I don't have enoug knowledge 19.38.56 # btw. should we make that menu also show the current stack usage? 19.39.38 # seems easy on cf and standard arm and pp502x, but the asm in pp5002 scares me 19.40.55 # TheSeven: Same on Clip+. On Recorder (hwcodec) it's 48% without voice, 59% with voice enabled 19.41.09 # So those 51% certainly don't come from sector buffers 19.41.59 # 49% on gigabeat f with default settings 19.43.51 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]) 19.43.54 # kugel: PP5002 is very easy too, even though we don't know the details of that cache controller 19.44.22 # amiconn: how would you handle cf with that? do you want to call _commit and _discard separately? I assume you don't want _commit_discard do what it does now going by your statement 19.44.58 # Iiuc *you* are suggesting this 19.45.14 # if you want to maintain the single call, then _commit_discard also needs to discard the icache; in that case it's correct now (and I see nothing wrong with that) 19.45.18 # (judging from r28045) 19.45.54 # * amiconn would just have left those functions as they were 19.48.56 Quit Misanthropos_ (Quit: Ex-Chat) 19.52.01 Quit Strife89DS (Read error: Connection reset by peer) 19.52.47 # TheSeven: if I read this correctly, fat_rename still uses 4716 bytes of stack :\ 19.53.04 Quit evilnick (Quit: Page closed) 19.55.20 Join Jaykay [0] (~chatzilla@p5DC577DA.dip.t-dialin.net) 19.55.55 # * gevaerts doesn't understand where 19.56.35 Quit Jaykay (Remote host closed the connection) 19.57.34 # That's assuming I read "sub sp, sp, #4672" at the start of the function correctly 19.58.13 Join Jaykay [0] (~chatzilla@p5DC577DA.dip.t-dialin.net) 19.58.15 Quit antil33t1 (Read error: Connection reset by peer) 19.58.22 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 19.58.49 Join Dreamxtreme [0] (~Dreamxtre@92.30.189.198) 20.05.20 Join Strife89DS [0] (~nds@207.144.201.128) 20.05.34 Join karlis [0] (adb74099@gateway/web/freenode/ip.173.183.64.153) 20.06.02 Nick karlis is now known as Guest27285 (adb74099@gateway/web/freenode/ip.173.183.64.153) 20.06.03 # anyone familiar with the channel setup in wavplay.c? 20.07.14 # * gevaerts finds another sector buffer :\ 20.10.46 # Guest27285: nope, but if you ask your question maybe someone can answer or someone sees it in the logs and answers 20.14.16 # amiconn: i might see about changing all the cache stuff to just ask for semantics; see my discussion with kugel earlier 20.14.27 # amiconn: but th eold names for the dcache stuff suck :) 20.14.38 # why? 20.14.48 # because they're inconsistent with what most of the world uses those terms to mean 20.15.01 # invalidate doesn't actually write any data back to memory anywhere else that i'm aware of 20.15.07 # certainly ARM's docs don't use it that way 20.16.26 # I don't quite understand how the val_rr (rl,ll,lr) are used to create the karaoke and custom channel setups, but I'm wondering if it's possible to create a mono crossover channel setup, so channel 1 (R) is a mono with a highpass filter, and channel 2 is a mono signal with a lowpass filter. Probably need a few more functions but it would be a useful feature for testing speaker setups and for mobile sound rigs 20.16.34 # TheSeven: the remaining problem is the "struct fat_dir olddir" in fat_rename(), and possibly the 'struct fat_dir newdir' in mkdir_uncached() (in dir_uncached.c) 20.16.45 # * amiconn thinks the new names are just different, but in no way less confusing than the old one (also not more confusing either) 20.17.51 # gevaerts: urgh... i didn't expect those structs to turn up on the stack 20.18.02 # i can't see how the new ones can be ambiguous 20.18.09 # they don't really belong there either, do they? 20.18.14 # but anyway, i would like semantic names 20.18.20 # I think they don't, but... 20.18.24 # Guest27285: wait wavplay.c, are you using an old archos? 20.18.34 # why doesn't it just open those dirs in the pool? 20.18.44 # pre/post dma, post code modify, and sync to point of coherency between cores on PP 20.18.45 Quit Strife89DS (Quit: Going to Walgreens to ask about whether I've been hired (last day). Wish me luck?) 20.18.49 # Even on a 512-byte stack system that uses more than 1KB... 20.18.53 # *sector 20.20.53 # Torne: I pointed out the very first ambiguity. Furthermore a proper rename involves changing all calls imo, not just providing aliases 20.21.14 # amiconn: the point was to change them as they were verified to be correct.. 20.21.20 # If the only problem was that invalidate actually did flush+invalidate, I would have renamed that single function 20.21.27 # since it's likely that they are not all now 20.21.42 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 20.21.45 # (flush is also a terrible word because that means different things on different systems also) 20.22.10 # Really syncing between cores on PP involves core hopping - a quite expensive operation 20.22.19 Quit milz (Remote host closed the connection) 20.22.27 # OK, I think it's wavplay.c, I was browsing it late last night. I'm using an old olympus modrobe 20.23.35 # amiconn: well, there is that. PP sucks, though ;) 20.23.45 # its specialness is not a good reason for anything much. 20.24.10 # and i'm not sure what inconsistency you mean, i haven't ooekd at the commit 20.24.28 # * Torne has a look 20.25.34 # The cf case I mentioned 20.26.03 # i don't see what's inconsistent about that 20.26.15 # just because it doesn't have a dcache doesn't mean anything calling it should care 20.26.27 # TheSeven: maybe have a set of functions to get and release a DIR_UNCACHED in dir_uncached.c? Are we sure that that won't cause problems with e.g. people suddenly not being able to rename files if they're deep in the filebrowser or anything like that? 20.27.14 # amiconn: the combinations should, ideally, *all exist* on all platforms 20.27.19 # and then code can just call them without caring 20.27.32 # and the ones that are copies of each other or noops can just be copies or noops 20.28.00 # * TheSeven has a look at why we need those dir handles in the first place 20.28.59 # so yes, the maximum that cpucache_invalidate will do is clean and invalidate all caches, that's what it's used for in various places 20.29.06 # the fact that it doesn't actually need to do that much on CF is irrelevant 20.29.22 # and yes, it would be nicer to reduce the calls to it to ask for weaker semantics if tha's what they really wanted 20.29.37 # that's why it's not renamed, so the old calls can be updated based on individual requirements 20.29.48 # hm, the first one doesn't seem to be used at all, the second one doesn't seem to use its buffer 20.30.10 # amiconn: cpucache_invalidate did write-back on other archs, which isnt what people expect 20.30.28 # [20:21:16] If the only problem was that invalidate actually did flush+invalidate, I would have renamed that single function 20.30.59 # except you can't rename it to flush because that doesn't mean anything specific either 20.31.03 # * gevaerts blames LinusN 20.31.14 # and that doesn't solve the problem that some things might be calling that when they actually want just weaker semantics 20.31.20 # i.e. a potential performance improvement 20.31.27 # gevaerts: any idea what that first fat_opendir is good for? (the /* create a temporary file handle */ one) 20.31.30 # we wanted new names which are clear and not influenced by vendor manuals which use them differently 20.31.48 # but yes, the nicer way to do it would be to have sync_{before,after}_dma_{read,write} and similar meaningful high level ops 20.32.05 # and substitute those everywhere, leavin the actual clean/invalidate/etc as internals of the target specific code 20.32.14 # imo :) 20.32.57 # but that's a lot more work, someone'd have to figure out what the right hting is everywhere. and as you point out the PP core coherency is actually very complicated 20.33.01 # because PP is stupid 20.33.02 # :) 20.33.58 # TheSeven: no idea 20.34.38 # if cpucache_commit_discard only discards the icache (because there's no icache), then it does the right thing. it's neither misleading or wrong. but if cpucache_invalidate does write-back then it's misleading 20.34.56 # because there's no dcache* 20.35.04 # gevaerts: and the second one should probably be a fat_file 20.38.58 # TheSeven: yes, looks like it 20.41.39 Join Strife89TX [0] (~cstrife89@207.144.201.128) 20.42.31 Quit Strife89TX (Client Quit) 20.49.57 # * TheSeven glares at /* The root cluster is cluster 0 in the ".." entry */ 20.52.25 # * TheSeven also thinks that "dummyfile" isn't a very good variable name, for something that isn't really da dummy 20.52.29 # a* 20.58.59 *** Saving seen data "./dancer.seen" 21.03.40 # TheSeven: http://pastebin.com/AVrLJHWu is my totally untested attempt 21.04.26 # * TheSeven thinks we can get completely rid of those 21.05.53 # can we remove the newdir arg from fat_create_dir? 21.06.30 Quit Guest27285 (Quit: Page closed) 21.07.19 # hm, the memset in mkdir_uncached is unneeded at least :) 21.09.26 # is fat_create_dir used from anywhere else? 21.09.35 Join Jerom [0] (~jerome@95.171.148.36) 21.14.16 # apparently not 21.16.42 # pamaury and funman, thanks for the usb driver :) 21.25.48 # gevaerts: your patch seems to work fine and get rid of the stkovs 21.25.55 # at least the file browser ones 21.25.59 # let's try some plugins 21.26.44 # hm, goban locks up with only a backdrop on the screen 21.27.05 Join panni_ [0] (hannes@ip-178-203-81-220.unitymediagroup.de) 21.27.25 # blackjack runs into an undefined instruction 21.28.12 # hm, all the plugins seem to be broken 21.28.21 # * TheSeven re-extracts the zip 21.29.15 # r28045 only renames things, right? It shouldn't actually change anything? 21.29.31 # yea 21.30.05 # haha 21.30.25 # re-extracting the zip fixed it, so there was probably file system or ftl screwup 21.30.38 # now i entered blackjack, the menu came up, and when i hit "quit" it locked up 21.31.05 # TheSeven: filesystem screwup after an untested fat.c patch? Unlikely! ;) 21.31.19 # really unlikely in that case 21.32.00 # that "quit blackjack" lockup is reproducible 21.33.05 # ew... 21.33.43 # funman (logs): can you have a quick look at this one http://pastie.org/1146562 ? it changes pcm-as3525.c to use the new cache names but also reorders a bit and makes mono2stereo not use uncached adresses 21.34.29 # and *loads* of plugins are still stuck with a backdrop-only screen 21.34.40 # i just read back and compared the .rockbox folder, it's fine 21.35.07 # Did you try plugins recently without this patch? 21.35.26 # that patch can't affect reading, so i'm deducing that either current svn is broken or they're stkov'ing 21.37.05 # increasing the stack size didn't affect the bavior 21.37.08 # behavior* 21.38.42 # * gevaerts tends to be suspicious of rename-only changes that affect binsize 21.39.06 # the fun part: blackjack works perfectly, apart from locking up when trying to quit 21.41.52 # hm, the build system build works fine 21.50.04 # * TheSeven just had a lockup with the build server build, after unplugging and re-plugging the usb cable rather fast 21.50.18 # the backlight thread still works, but the main thread is dead 21.50.32 Quit Jaykay (Read error: Connection reset by peer) 21.50.53 Quit [sko] (Read error: Connection reset by peer) 21.53.55 # New commit by 03nls (r28047): keybox: do not leak filehandle when the wrong password is entered. 21.54.15 # Are multiple simultaneous operations from different threads using the same dirent pointer allowed? 21.55.59 # r28047 build result: All green 22.00.31 Join Xerion [0] (~xerion@84.25.7.202) 22.04.08 # gevaerts: I doubt it 22.05.17 # gevaerts: the sim uses a single dirent for all dir operations, so there should only be one thread ever using dirents :) 22.05.29 # Unfortunately it doesn't help me anyway. I was thinking of being able to steal the dirent sector buffer for fat operations (and marking it as dirty), which would work well, except that most on-stack sector buffers are in functions that don't get a fat_dir pointer at all 22.05.48 # kugel: really? That sounds broken... 22.07.10 # exactly my thought 22.07.25 # it seems to work though, but I avoided that in the android port 22.07.38 # (where the host's dirent is used anyway) 22.08.03 # Maybe nothing in core keeps a dirent open for a longer time 22.09.39 # most parts that use dirent recursive over directories (so a single static dirent is broken there too) but they do so without breaking it :) 22.09.48 # recurse* 22.17.14 Join vaguerant [0] (3aaf4cc7@wikipedia/vague-rant) 22.18.37 # No luck for me with USB on Clip+, the USB icon displays but doesn't mount in either Windows or Linux. 22.20.53 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 22.21.57 Join efyx__ [0] (~efyx@82.225.185.146) 22.22.14 Part Gatz85 22.22.44 Quit efyx_ (Client Quit) 22.22.46 Quit efyx (Quit: Quitte) 22.22.56 Quit efyx__ (Client Quit) 22.23.40 # vaguerant: it's not enabled in the the builds yet 22.25.15 # n1s, right, I edited /firmware/export/config/sansaclipplus.h as suggested here though with no results. 22.25.35 # Well. Some results, but not the kind which include USB access. 22.25.56 # ah 22.26.17 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 22.26.25 Quit efyx (Remote host closed the connection) 22.26.36 # i'd suggest waiting until it is enabled in the svn source then unless you want to hack on t 22.26.40 # *it 22.30.02 # vaguerant, seems to work for me for reading (just tried), I'm not really comfortable using it for writing though 22.35.51 # btw, i can reproduce that usb unplug-replug main thread lockup 22.36.37 Join krazykit [0] (~kkit@24-148-94-173.frg-bsr1.chi-frg.il.cable.rcn.com) 22.40.00 # New commit by 03kugel (r28048): Cleanup io.c a bit. 22.41.04 Quit liar (Ping timeout: 258 seconds) 22.41.44 # r28048 build result: 156 errors, 0 warnings (kugel committed) 22.42.41 # New commit by 03kugel (r28049): fix red. 22.42.51 Quit anewuser (Ping timeout: 276 seconds) 22.43.07 Join anewuser [0] (anewuser@unaffiliated/anewuser) 22.44.14 # * kugel can suddenly repro FS#11610 on mingw/wine now 22.44.45 # r28049 build result: All green 22.47.49 Quit krazykit (Quit: bbl) 22.59.00 *** Saving seen data "./dancer.seen" 23.00.59 Join jgarvey_ [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 23.01.47 Join m|c [0] (~mtq@h1439481.stratoserver.net) 23.01.51 Quit steve|m (Ping timeout: 276 seconds) 23.01.57 Quit jgarvey (Ping timeout: 276 seconds) 23.01.57 Quit FOAD (Ping timeout: 276 seconds) 23.01.58 Quit miceh (Read error: Connection reset by peer) 23.03.08 Join olejorge1b [0] (bronner@caracal.stud.ntnu.no) 23.03.15 Quit olejorgenb (Remote host closed the connection) 23.03.15 Join maraz [0] (maraz@kapsi.fi) 23.03.17 Quit maraz_ (Ping timeout: 276 seconds) 23.03.19 Quit threeothree (Ping timeout: 240 seconds) 23.03.45 Join steve|m [0] (~steve@p4FD46502.dip.t-dialin.net) 23.04.49 Quit n1s (Quit: Lämnar) 23.05.02 Join FOAD_ [0] (~dok@83.160.60.104) 23.05.02 Nick FOAD_ is now known as FOAD (~dok@83.160.60.104) 23.07.27 # *oops* 23.08.17 Quit anewuser (Ping timeout: 258 seconds) 23.08.37 Join anewuser [0] (anewuser@unaffiliated/anewuser) 23.09.16 # Quick question. Using unstable for Fuze v2, after following http://www.rockbox.org/wiki/SansaAMS and loading the firmware on, it reboots to the rockbox loading page, then says "Loading firmware" "File not found" 23.09.24 # But not sure what I screwed up on. Any ideas? 23.09.27 Join kkurbjun [0] (~kkurbjun@c-24-9-122-9.hsd1.co.comcast.net) 23.13.06 # sounds like you only installed the bootloader and not the build 23.13.37 # I threw my fuze back to MSC mode and noticed fuzpa.bin is no longer present. Awesome. Tossed it back on, now booting again 23.14.21 Quit simonrvn (Ping timeout: 245 seconds) 23.14.44 # well of course. The original firmware sees that there's a file called fuzpa.bin, which it then uses for a firmware upgrade, and it then deletes the file. That's normal 23.16.12 # followed the directions, pixelma. mkamsboot [OF] [bootloader] [outputfile.bin] 23.16.28 # I don't mean that, I meant the build that is linked from the page - behind the "normal Rockbox build" link. You need to unzip this to the root of your player 23.16.31 # then move outputfile.bin to device root and rename to fuzpa.bin (OF name) 23.16.47 # pixelma, understood 23.17.38 # *sigh* yeah I missed that somehow. 23.21.10 # And that has it rolling. Thanks again! 23.22.23 Join threeothree [0] (generic@server1.unitedservers.de) 23.26.39 # New commit by 03kugel (r28050): Revert r27972 to fix FS#11610 (but in a way android builds still work). 23.27.13 # kugel: DEBUGF("aaa\n"); ? 23.27.16 # New commit by 03kugel (r28051): Oops, remove left-over DEBUGFs. 23.27.26 # :) 23.27.26 # gevaerts: :) 23.28.08 # I wonder if anyone's working on porting gnugo to rockbox... 23.28.26 # it has a nice go plugin but it's useless when I'm all alone :( 23.28.29 # r28050 build result: All green 23.29.23 Join simonrvn [0] (simon@209.191-ppp.3menatwork.com) 23.30.44 # r28051 build result: All green 23.31.00 Quit domonoky (Read error: Connection reset by peer) 23.38.17 Quit parafin (Ping timeout: 246 seconds) 23.41.28 Join clone4crw [0] (~calvin@96-42-90-88.dhcp.roch.mn.charter.com) 23.42.38 # What wiki software do you guys use on rockbox.org? 23.43.14 # Sorry, that's more appropriate for #rockbox-community 23.43.22 # http://www.rockbox.org/wiki/WebHome 23.43.25 # says foswiki 23.43.45 # saratoga: thanks again. :) 23.47.14 Quit pamaury (Read error: Connection reset by peer) 23.49.27 Quit solexx (Quit: leaving) 23.50.44 Join Drise [0] (Drise@146.229.119.1) 23.51.38 # Hey guys. Do we know if the new Fuze v2's like the old Fuze v2's? 23.51.50 # *work like 23.52.07 Join mulenmar [0] (~mulenmar_@74-132-43-158.dhcp.insightbb.com) 23.54.44 Part Drise 23.54.44 Join Drise [0] (Drise@146.229.119.1) 23.54.44 Part Drise 23.54.44 Join Drise [0] (Drise@146.229.119.1)