| 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 | bertrik | 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 | bertrik | 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 | bertrik | Maybe have a special check for "stereo width" = 100% to avoid wasting processing power |
| 00:36:54 | pixelma | 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 | Torne | there are virtually no settings that aren't independant currently |
| 00:38:29 | Torne | 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 | Torne | tbh i don't see the problem with the current behaviour |
| 00:40:18 | Torne | if you don't notice that it didn't do anything then it doesn't matter anyway, no? :) |
| 00:40:28 | Torne | and if you do notice then it shouldn't take more than a few seconds to work out why |
| 00:40:32 | bertrik | 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 | bertrik | one setting depending on another setting in a different menu |
| 00:41:11 | * | [Saint] nods |
| 00:41:27 | Torne | [Saint]: if they adjust it and *don't notice* then they're irrelevant |
| 00:41:42 | Torne | 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 | Torne | placebo and all that |
| 00:42:08 | [Saint] | that's hardly the point being made ;) |
| 00:42:51 | Torne | 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 | Torne | maybe just rename the setting? |
| 00:44:30 | [Saint] | I don't see how it reduces flexibility |
| 00:45:10 | Torne | 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 | Torne | you'd have to set it back to 100% |
| 00:45:36 | Torne | 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 | Torne | remember how? |
| 00:45:56 | [Saint] | from the config |
| 00:46:08 | Torne | i don't understand what you mean |
| 00:46:21 | Torne | if you eliminate "custom" then how do you tell it to use the remembered setting? |
| 00:46:30 | Torne | or how to stop using it, for that matter |
| 00:46:58 | [Saint] | Hmmm. |
| 00:47:29 | Torne | 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 | Torne | there's a switch to turn some kind of processing (which takes cpu power) on and off |
| 00:47:55 | bertrik | The eq isn't turned on/off in the "channel config" menu |
| 00:48:03 | Torne | 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 | Torne | you mean the eq is a submenu and the channel config/width isn't? |
| 00:48:31 | Torne | aren't they adjacent? |
| 00:48:47 | [Saint] | well, yes, but not obviously connected |
| 00:48:52 | Torne | "channel config" isn't a menu, it's just a setting |
| 00:49:06 | Torne | 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 | Torne | i just don't like the implied stuff |
| 00:49:47 | pixelma | 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 | Torne | we don't have a sufficiently flexible UI (at the moment) to make it clear when these implicit things happen |
| 00:50:34 | bertrik | sorry, I can't understand how you think this is perfectly logical |
| 00:50:37 | Torne | so, i feel it's better to be explicit |
| 00:51:06 | Torne | 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 | Torne | how is that not logical? |
| 00:51:18 | | Quit Luca_S (Quit: CGI:IRC) |
| 00:51:19 | Torne | i can see how it's not *obviously connected* when you look at the UI |
| 00:51:26 | Torne | because it isn't, you're right |
| 00:51:35 | Torne | but once you know that it is, it's perfectly sensible.. |
| 00:51:59 | [Saint] | well, "sensible", not perfectly sensible. ;) |
| 00:52:07 | bertrik | 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 | bertrik | defeats the principle of "least surprise" IMO |
| 00:52:45 | | Quit liar (Ping timeout: 258 seconds) |
| 00:52:54 | Torne | right. |
| 00:52:58 | pixelma | 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 | Torne | so, change the name, or make it a submenu |
| 00:53:19 | Torne | pixelma: It's "Channel configuration" and "stereo width", adjacent on the sound settings menu |
| 00:53:25 | bertrik | Actually I don't enough about it and will probably never use it... :) |
| 00:53:30 | Torne | they're right that there's nothing to imply they are connected |
| 00:53:35 | Torne | unless you read the manual |
| 00:54:02 | Torne | 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 | Torne | and no i don't use this setting :) |
| 00:54:58 | Torne | I just dislike special cases ;) |
| 00:55:05 | | Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 00:55:08 | bertrik | ok, me too |
| 00:55:25 | Torne | The other way to solve it without any special cases would be to merge the two things |
| 00:55:38 | Torne | so mono would just become 0%, stereo 100%, and you'd need special entries for left/right |
| 00:55:46 | Torne | (is that all that's on the channel config menu? i think so) |
| 00:56:04 | Torne | that does reduce the flexibility but it does so without weird implicit behaviour |
| 00:56:15 | Torne | it's at least clear what the effect is in all cases |
| 00:56:30 | TheSeven | dammit |
| 00:56:38 | TheSeven | looks like we have the first nano2g brick |
| 00:57:09 | TheSeven | 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 | Drise | Is the fuze v2 usb operational, or do I still need to run the patch |
| 00:57:32 | Battousai | at least that means there's an opportunity for the first nano2g unbrick |
| 00:57:33 | TheSeven | he tried to rolo into a new build, which locked up |
| 00:57:46 | TheSeven | when he reset the ipod, the FTL was bad |
| 00:58:03 | TheSeven | 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 | billybobthornton | 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 | Drise | 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 | Torne | you could type saint instead |
| 00:59:37 | Drise | Its been a while since I'ved used IRC |
| 00:59:42 | | Quit bertrik (Quit: goodnight!) |
| 00:59:43 | Torne | but yes, tab-complete in just aout every client |
| 00:59:58 | | Quit [Saint] (Ping timeout: 252 seconds) |
| 01:00 |
| 01:00:01 | Drise | Tab complete!?!?!?! OMFG |
| 01:00:03 | Drise | Sorry |
| 01:00:15 | Torne | TheSeven: eek |
| 01:00:31 | TheSeven | i have no idea at all how this can happen |
| 01:00:52 | TheSeven | 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 | TheSeven | 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 | Torne | it's really quite depressing how badly the nano handles ftl issues on its own |
| 01:02:06 | S_a_i_n_t | the flash *could* have just chosen that moment to die |
| 01:02:09 | TheSeven | the ipod was luckily running iloader, otherwise we wouldn't have had any way of accessing it |
| 01:02:23 | S_a_i_n_t | it seems just as feasable as any other explanation. |
| 01:02:45 | TheSeven | 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 | S_a_i_n_t | Hmmm, good point. |
| 01:03:04 | mulenmar | Lucky me. >_> I have a one-of-a-kind Nano2G brick. |
| 01:03:07 | Drise | S_a_i_n_t, Did pamaury finish the usb code? |
| 01:03:14 | Torne | yeah it seems more likely that it's managed to protect itself or something |
| 01:03:21 | S_a_i_n_t | can he do the open/piss about/solder trick? |
| 01:03:36 | TheSeven | that won't help the flash to get writable :) |
| 01:03:37 | mulenmar | There was a one-byte difference in that one dump thought, TheSeven . . . |
| 01:03:50 | TheSeven | yes, but that just *can't* be the reason |
| 01:03:51 | Torne | was it in a bad block? |
| 01:04:06 | TheSeven | *what* was in a bad block? |
| 01:04:14 | S_a_i_n_t | mulenmar: was it you? |
| 01:04:20 | mulenmar | Yup. Lucky me. |
| 01:04:28 | S_a_i_n_t | oh...bugger :/ |
| 01:04:46 | * | mulenmar : born Friday the 13th. X~P |
| 01:05:17 | TheSeven | Torne: any idea what could make that flash be read-only? |
| 01:05:39 | TheSeven | 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 | Torne | TheSeven: i assume you can send it unprotect commands and stuff? |
| 01:06:13 | mulenmar | 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 | Torne | to be written to *correctly*, yes |
| 01:07:26 | TheSeven | mulenmar: we still have some erased blocks to play with |
| 01:07:30 | Torne | :) |
| 01:07:45 | Torne | 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 | TheSeven | 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 | Torne | TheSeven: that won't normally overwrite existing 0's though |
| 01:08:47 | TheSeven | yep |
| 01:08:57 | TheSeven | but it's sufficient to check if anything changes at all |
| 01:09:01 | Torne | yeah |
| 01:09:16 | * | Drise is running the script, hoping for no errors. |
| 01:09:33 | Torne | has the thing been through an actual power cycle, or can't you do that on nano2g either? |
| 01:09:49 | Torne | because if the flash chip has decided that ranges are protected, powercycling will generally clear that ;) |
| 01:09:59 | Torne | since it doesn't store that anywhere persistent |
| 01:10:11 | | Quit kart0ffelsack (Ping timeout: 245 seconds) |
| 01:10:39 | mulenmar | Just resets. |
| 01:10:55 | Torne | yeah, that may or may not reset protected blocks |
| 01:11:09 | Torne | does iloader know how to send the unprotect command for that flash? |
| 01:11:17 | mulenmar | Reset-hold off- let sit was tried once. |
| 01:11:19 | Torne | 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 | Torne | heh |
| 01:11:52 | TheSeven | but we can execute arbitrary code, so we can do whatever we need to |
| 01:11:58 | Torne | well, what i mean is that most flash chips have a protection feature |
| 01:12:03 | Torne | or "lock" they might call it |
| 01:12:10 | Torne | so you can write-protect a range of blocks |
| 01:12:20 | Torne | it's just a command, and it's not usually stored anywhere persistent |
| 01:12:28 | Torne | it's just a protection-from-cockups thing, not a security feature |
| 01:12:45 | Torne | normally you use it to, say, protect the bootloader from being overwritten unless something specifically unprotects it forst |
| 01:13:04 | Torne | the bootloader would just send the protect command at boot time |
| 01:13:18 | Torne | i'm kinda guessing :) |
| 01:17:24 | * | kugel agrees with bertrik |
| 01:17:45 | kugel | I always wondered if my ears are so bad or why else does stereo width nothing? |
| 01:18:55 | S_a_i_n_t | 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 | kugel | I didn't even know channel config and stereo width are related to each other |
| 01:20:37 | kugel | the eq is a bad example, it would be a better one if channel config was named "enable stereo width" |
| 01:21:01 | Torne | so rename the settings to be more logical :) |
| 01:22:19 | kugel | I bet nobody actually uses it |
| 01:22:25 | pixelma | I do |
| 01:22:30 | S_a_i_n_t | what about making "Custom" a subdir, and having enable diable stereo width in there, as well as stereo width? |
| 01:22:42 | Torne | S_a_i_n_t: that's not possible easily |
| 01:22:42 | Torne | our list UI doesn't work that way |
| 01:22:51 | Torne | channel config is not a submenu |
| 01:22:54 | Torne | it's just a setting |
| 01:23:07 | Torne | so, there's no way to give it sub-options without changing the structure of the thing entirely |
| 01:23:08 | pixelma | 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 | kugel | Torne: I think it's doable |
| 01:25:05 | pixelma | is enabling "custom" als needed for mono etc.? Just thinking that "enable stereo width" could be misleading too if it was |
| 01:25:19 | kugel | you can always add custom callbacks to settings and menus so I don't see any blocker right now |
| 01:26:01 | Torne | kugel: this seems like a lot of effort/code for a UI issue that's solveable by readnt he manual :) |
| 01:27:02 | S_a_i_n_t | 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 | kugel | 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 | Torne | right |
| 01:28:13 | Torne | 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 | S_a_i_n_t | yeah...pretty sure that UIs that don't confuse the fuck out of people are a good thing in general ;) |
| 01:28:21 | Torne | move them to a submenu and rename them, or something |
| 01:28:32 | kugel | rtfm is nice if there's a lot of effort involved, but I don't think that's the case here |
| 01:28:34 | Torne | to make it cear they are connected adn that one thing only affects one mode of the other thing |
| 01:28:48 | Torne | we already have all the code for that :) |
| 01:28:55 | Torne | no special case required |
| 01:29:05 | pixelma | S_a_i_n_t: what does that have to do with my question? |
| 01:29:26 | S_a_i_n_t | I must have misread it, sorry |
| 01:29:59 | TheSeven | Torne: any idea how to figure out where to get a datasheet for a flash chip with the ID code 0x2585d3ad? |
| 01:30:33 | Torne | er, not really |
| 01:30:36 | Torne | other than google :) |
| 01:30:41 | TheSeven | 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 | TheSeven | the first google hit for that ID code ends up in flyspray :/ |
| 01:31:22 | kugel | 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 | TheSeven | and all the other hits in irc logs from rockbox or linux4nano :( |
| 01:31:44 | Torne | if you're going to do something like that it makes more sense to just merge the two lists, no? |
| 01:32:04 | Torne | 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 | S_a_i_n_t | kugel: If you think its doable, persoanlly, I think that's a decent solution for this. |
| 01:33:25 | kugel | I think that's more effort in the end (and clutters up the list) |
| 01:33:34 | kugel | Torne: ^ |
| 01:34:55 | | Join krabador [0] (~krabador@host102-56-dynamic.244-95-r.retail.telecomitalia.it) |
| 01:35:26 | S_a_i_n_t | TheSeven: is that chip the HY27UT088G2M? |
| 01:35:39 | TheSeven | it's the same that you have at least... |
| 01:36:16 | S_a_i_n_t | Hmmm...I have a few, pretty sure they're not *all* the same ;) |
| 01:36:41 | TheSeven | well, at least you mentioned that id once |
| 01:36:49 | TheSeven | did you find a datasheet for the HY27UT088G2M? |
| 01:36:57 | S_a_i_n_t | well, that chip id you gave led me to that chip, and, I can find sheets for it. |
| 01:37:04 | S_a_i_n_t | yes. |
| 01:37:13 | S_a_i_n_t | 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 | TheSeven | now which of those? |
| 01:38:32 | TheSeven | they're all no exact matches |
| 01:39:15 | S_a_i_n_t | none? on any of the pages? |
| 01:39:20 | S_a_i_n_t | 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 | saratoga | theres probably a decoder chart somewhere for the part number |
| 01:40:59 | saratoga | oh found it |
| 01:42:03 | S_a_i_n_t | the datasheet, or the decoder for the partnumber? |
| 01:42:22 | saratoga | those datasheets all have a decoder in them |
| 01:44:10 | saratoga | so HY27U = 1.8v NAND, T is the number of levels per cell, 088 is the package type, |
| 01:44:10 | saratoga | hmm no |
| 01:44:35 | TheSeven | so it's a cached-program 8-level-cell type |
| 01:44:46 | TheSeven | no, 4-level |
| 01:45:06 | * | S_a_i_n_t can only find up to HY27US, but, no HY27UT |
| 01:45:17 | S_a_i_n_t | +datasheets |
| 01:46:04 | saratoga | its probably Two levels per cell |
| 01:46:17 | saratoga | 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 | saratoga | err 2 bit or 4 bit |
| 01:46:37 | saratoga | err 2 bit or 3 bit |
| 01:46:42 | saratoga | so 4 level or 8 level |
| 01:46:54 | TheSeven | 4 levels according to the decoder in my datasheet |
| 01:47:04 | saratoga | so T = Two bit probably |
| 01:47:57 | TheSeven | 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 | TheSeven | now what could be driving that pin, and why can it survive a powerdown |
| 01:49:57 | TheSeven | 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 | saratoga | tried shorting the power and ground pins on the chip? |
| 02:00 |
| 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 | TheSeven | saratoga: he hasn't opened that thing yet, and they aren't easy to open at all |
| 02:04:27 | TheSeven | 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 | TheSeven | i've also looked at the pmu's gpios, they match |
| 02:08:47 | TheSeven | the only differences i can find are two unknown and apparently read-only bits on the SoC's GPIOs |
| 02:09:10 | TheSeven | and an NVRAM byte in the PMU, along with some interrupt flags |
| 02:10:09 | TheSeven | 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 | TheSeven | hmmm now this is weird |
| 02:16:48 | TheSeven | 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 | TheSeven | that nano was toast anyway :) |
| 02:19:46 | JdGordon| | was that a danger? :) |
| 02:19:51 | | Quit hebz0rl (Quit: Ex-Chat) |
| 02:20:46 | TheSeven | or wait, there might be a via inside that pad |
| 02:20:56 | mulenmar_ | [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 | mulenmar_ | After transfering at least 4.5GB total onto and off of the Nano while testing a patch. |
| 02:22:25 | mulenmar_ | While *preparing* to test a patch, I mean. I was still running vanilla Rockbox. |
| 02:24:52 | TheSeven | now what could apple have connected to that pin? |
| 02:25:12 | TheSeven | the datasheets say that it shouldn't be tied to ground but pulled high during powerup instead |
| 02:26:27 | TheSeven | 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 | CIA-81 | New commit by funman (r28031): usb-drv-as3525v2: fixes ... |
| 02:31:09 | CIA-81 | r28031 build result: All green |
| 02:32:07 | funman | we have 2 competing drivers for the same hardware |
| 02:32:39 | funman | one is 450 lines, the other is 1302 |
| 02:37:25 | * | TheSeven wonders if the 450 line one is his one :) |
| 02:37:48 | funman | that's the one yes |
| 02:37:59 | TheSeven | where does the other one come from? |
| 02:38:09 | funman | see last commit |
| 02:38:30 | funman | i'm pretty close to have this one working though |
| 02:41:15 | TheSeven | this doesn't seem to be much more actual code though |
| 02:41:35 | TheSeven | it's commented way better |
| 02:41:57 | TheSeven | and it's using a lot more symbols instead of hardwired numbers |
| 02:42:12 | funman | we must take the best of both |
| 02:43:34 | TheSeven | which one is actually working better? |
| 02:43:53 | TheSeven | could the big one easily be ported to the nano? |
| 02:44:09 | funman | it took me only a few hacks to make the nano2g one work on amsv2 so yeah |
| 02:44:44 | funman | see FS #11607 : usb-target.h |
| 02:44:47 | | Join ascheel [0] (~ascheel@ampache/staff/ascheel) |
| 02:45:48 | ascheel | 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 | funman | ascheel: 'Sansa v2' is what exactly? |
| 02:46:22 | funman | Fuzev2? |
| 02:46:24 | ascheel | Sorry, Fuzev2 |
| 02:46:29 | ascheel | I apologize |
| 02:46:36 | ascheel | brain is slower than the fingers |
| 02:46:43 | funman | SansaAMS doesn't say it's stable |
| 02:47:09 | ascheel | ah, I thought the table itself indicated stability |
| 02:47:11 | saratoga | "Rockbox is considered Stable on Fuze v1/e200v2, Unstable on Clip v1, Clip v2, Clip+, Fuze v2" |
| 02:47:15 | saratoga | sounds pretty clear to me |
| 02:47:29 | funman | it works pretty fine though |
| 02:47:42 | saratoga | although i think the clipv1 is stable now |
| 02:47:55 | funman | yeah the front page just need manual update |
| 02:48:25 | ascheel | Are the 'Specific problems' all that remains before it goes stable? |
| 02:48:35 | funman | no |
| 02:48:56 | funman | i think once we get USB working we'll label them stables |
| 02:49:10 | saratoga | targets become stable when people feel like it basically |
| 02:49:42 | ascheel | 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 | ascheel | or does it require ALL SansaAMS builds to be stable before ANY of them are marked as such? |
| 02:50:07 | funman | USB |
| 02:50:47 | saratoga | ascheel: take a look at the asterisk |
| 02:51:06 | ascheel | Yeah, says it's just not in SVN |
| 02:51:14 | TheSeven | "just"? |
| 02:51:16 | ascheel | So it's working, but not yet being distributed? |
| 02:51:36 | TheSeven | it's really new, not properly tested code, that seems to work well at a first glance |
| 02:51:53 | ascheel | gotcha. Ah, just now realized the last modified date of that page (yesterday). |
| 02:51:56 | TheSeven | it hasn't even adopted into svn yet, so there's just no way to call that stable :) |
| 02:52:08 | ascheel | Didn't realize I was that early on the punch with it |
| 02:52:11 | TheSeven | been* |
| 02:53:45 | saratoga | has anyone noticed problems with the EQ on AMS like that one guy reported in the forums? |
| 02:53:53 | saratoga | i'm at loss as to how that could be target specific |
| 02:53:58 | | Quit lestatar (Ping timeout: 240 seconds) |
| 02:58:07 | funman | read: 5.8Mbps on clipv2 (although sometimes it's much much much slower) |
| 02:58:31 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:03:09 | CIA-81 | New commit by funman (r28032): usb-drv-as3525v2: use dump_dcache_range() ... |
| 03:03:14 | CIA-81 | New commit by funman (r28033): as3525v2 usb: define USB_HAS_BULK ... |
| 03:05:00 | CIA-81 | r28032 build result: All green |
| 03:06:47 | CIA-81 | r28033 build result: All green |
| 03:07:13 | funman | 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 | leachim6 | hey |
| 03:08:01 | leachim6 | how do I tell which version of the Sansa Fuze i have? |
| 03:08:12 | leachim6 | whether it's V1 or V2 |
| 03:09:33 | | Quit bunnyboi (Quit: Going!) |
| 03:09:44 | funman | check the manual it explains how to do so |
| 03:09:58 | leachim6 | I looked |
| 03:10:33 | funman | http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch2.html#x4-70002.1 <- you didn't look very close |
| 03:10:47 | leachim6 | thanks |
| 03:10:51 | leachim6 | sorry, I tried to find it on my own before I asked |
| 03:11:35 | leachim6 | so if version says "v0.1.01.07A" |
| 03:11:38 | leachim6 | I have a version 1, right? |
| 03:11:42 | leachim6 | I just want to make completely sure |
| 03:11:45 | funman | right |
| 03:11:53 | leachim6 | sweet :) |
| 03:12:02 | leachim6 | 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 | leachim6 | 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 | leachim6 | 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 | funm4n | AMSv2 USB works (and fails) equally well on windows |
| 03:21:01 | leachim6 | what does that mean? |
| 03:21:12 | leachim6 | I don't know what that means |
| 03:21:18 | ascheel | he's testing Fuze v2 right now. |
| 03:21:22 | leachim6 | oh right |
| 03:21:25 | leachim6 | I'm lucky I have a v1 |
| 03:21:28 | ascheel | New code. Not anything you'll be experiencing, yet |
| 03:21:51 | leachim6 | you guys are pretty vigilant on new code huh? |
| 03:21:53 | leachim6 | still chugging |
| 03:22:18 | leachim6 | 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 | leachim6 | can I just get a yea or nay? |
| 03:26:17 | ascheel | <−−- not rockbox person. Just in here as you are. |
| 03:26:20 | funm4n | leachim6: installing the rockbox bootloader requires upgrading the OF version |
| 03:26:35 | leachim6 | funm4n, good, because I updated it |
| 03:26:36 | leachim6 | haha |
| 03:26:38 | funm4n | you can just upgrade to the latest OF while installign rockbox at the same time, no need to upgrade before that |
| 03:26:52 | leachim6 | ok |
| 03:26:59 | funm4n | "upgrade" means install another version, it doesn't need to be the last one |
| 03:26:59 | leachim6 | so....I'm on the latest version.... |
| 03:27:05 | leachim6 | got rbutil going on |
| 03:27:06 | | Quit funm4n (Quit: Page closed) |
| 03:27:09 | leachim6 | plugged in my sansa |
| 03:27:16 | leachim6 | now I just run rbutil, and point at my .bin file? |
| 03:27:18 | leachim6 | and that's all? |
| 03:28:59 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 03:29:24 | funman | that's all. isn't that marvelous? |
| 03:29:27 | leachim6 | wow |
| 03:29:29 | leachim6 | that was esay |
| 03:29:36 | leachim6 | but my sansa's still showing the "connected" animation |
| 03:29:39 | leachim6 | after the whole installation |
| 03:29:44 | leachim6 | shouldn't it like....reboot or something? |
| 03:29:56 | ascheel | you need to power down and back up, IIRC |
| 03:30:13 | leachim6 | ok |
| 03:30:20 | funman | no |
| 03:30:28 | ascheel | I fail again |
| 03:30:29 | funman | just eject it |
| 03:30:36 | leachim6 | oh yeah, I got it |
| 03:30:40 | leachim6 | "Firmware update in progress" |
| 03:30:42 | leachim6 | now's crunch time. |
| 03:30:50 | leachim6 | *kneads hands* |
| 03:30:53 | leachim6 | Upgrade complete :D |
| 03:31:01 | leachim6 | w00t! |
| 03:31:02 | leachim6 | rockbox |
| 03:31:21 | ascheel | funman, powering it up with the USB cable in boots to the OF, correct? |
| 03:31:33 | saratoga | depends on which player you have |
| 03:31:39 | ascheel | thanks, saratoga. |
| 03:31:43 | saratoga | it will on amsv2, won't on amsv1 anymore |
| 03:31:47 | ascheel | ah |
| 03:31:49 | leachim6 | I think I read that USB is supported on the v1 |
| 03:31:49 | leachim6 | yes? |
| 03:31:51 | leachim6 | let me check |
| 03:32:00 | leachim6 | nope, it reboots. |
| 03:32:01 | ascheel | that just a workaround for nonstable ports, then? |
| 03:32:08 | leachim6 | nope, stable ports reboot too |
| 03:32:20 | leachim6 | I just tested it |
| 03:32:30 | funman | leachim6: read the SansaAMS wiki page (linked from the front page) |
| 03:32:42 | leachim6 | ok, I'll read it |
| 03:32:47 | leachim6 | funman, did you write code for this release? |
| 03:33:27 | funman | me and hundreds of other peoples yes |
| 03:33:33 | leachim6 | well, good on you |
| 03:33:37 | leachim6 | and all the others |
| 03:33:41 | leachim6 | fantastic job |
| 03:33:55 | leachim6 | I've got rockbox on my 5g iPod, and that's kickass too |
| 03:33:59 | leachim6 | but the sansa version is super nice |
| 03:34:17 | leachim6 | does anyone know what the SD card limit is on the v1? |
| 03:34:30 | funman | whatever is the theorical limit, 32GB i guess |
| 03:34:39 | leachim6 | sweet! |
| 03:34:48 | leachim6 | a 32gb card is like.....50 bucks |
| 03:34:52 | leachim6 | :D |
| 03:34:58 | leachim6 | now I can put off that new iPod touch |
| 03:35:52 | ascheel | 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 | ascheel | other than that, it sucks for a media player and web browser |
| 03:36:09 | leachim6 | right, I already have a 16gb v2 |
| 03:36:14 | leachim6 | which is great for apps and stuff |
| 03:36:21 | funman | guys please stay on topic, move this chat to #rockbox-community |
| 03:36:22 | leachim6 | but the little sansa is really good at playing music |
| 03:36:29 | ascheel | Sorry, funman |
| 03:36:36 | leachim6 | aw c'kon funman, your name is paradoxical! |
| 03:39:09 | | Join Dreamxtreme [0] (~Dreamxtre@92.30.156.178) |
| 03:42:17 | leachim6 | I answered my own question anyway lol |
| 03:48:35 | funman | ah i continue to see the weird malformed packet on clip+ |
| 03:50:39 | CIA-81 | New commit by funman (r28034): USB AMSv2: update endpoint->len on transfer ... |
| 03:50:43 | | Quit mulenmar_ (Quit: Leaving) |
| 03:52:29 | CIA-81 | r28034 build result: All green |
| 03:55:59 | | Quit anewuser (Ping timeout: 252 seconds) |
| 03:59:45 | CIA-81 | New commit by funman (r28035): USB AMSv2: cosmetics ... |
| 04:00 |
| 04:00:01 | | Quit milz (Remote host closed the connection) |
| 04:01:52 | CIA-81 | 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 | funman | [ 2904.900046] usb 1-3: device firmware changed |
| 04:16:24 | funman | how does it know?? |
| 04:17:25 | JdGordon| | 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 | funman | 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:00 |
| 05:02:36 | | Join kaiscene [0] (~kaiscene@ool-18e45d82.dyn.optonline.net) |
| 05:02:41 | leachim6 | have we got lyrics support in rockbox yet? |
| 05:02:42 | leachim6 | even beta? |
| 05:02:58 | funman | check flyspray i think there's a patch for it |
| 05:03:22 | leachim6 | like a patch that I have to compile in myself? |
| 05:03:26 | leachim6 | or a patch that I stick in the .rockbox folder. |
| 05:03:59 | funman | the first one |
| 05:04:07 | leachim6 | blah |
| 05:04:11 | leachim6 | I'm too lazy to do such a thing haha |
| 05:04:27 | leachim6 | why is that not in core yet? |
| 05:04:46 | funman | it should be explained in the flyspray entry |
| 05:05:06 | leachim6 | which one? |
| 05:05:10 | leachim6 | how to do it, or why it's not in core |
| 05:05:24 | leachim6 | because I know how to do it, I'm just lazy lol |
| 05:05:27 | funman | why it's not in core |
| 05:05:48 | leachim6 | oh, ok, I'll read it |
| 05:06:02 | leachim6 | 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 | CIA-81 | New commit by funman (r28036): usb-s3c6400x.c : don't hardcode USB_NUM_ENDPOINTS but use the define |
| 05:31:21 | CIA-81 | New commit by funman (r28037): USB AMSv2: use status == -1 to signal errors ... |
| 05:32:46 | CIA-81 | r28036 build result: All green |
| 05:33:18 | | Quit ps-auxw (Ping timeout: 240 seconds) |
| 05:34:17 | CIA-81 | 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:00 |
| 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 | CIA-81 | New commit by funman (r28038): USB AMSv2: simplify FOR_EACH* macros ... |
| 06:22:25 | CIA-81 | r28038 build result: All green |
| 06:23:10 | funman | TheSeven: I forgot that of course we also have the 22k+ lines Linux driver made by Synopsys |
| 06:27:06 | CIA-81 | New commit by funman (r28039): USB AMSv2: Reduce the size of (in/out)_ep_list |
| 06:28:34 | CIA-81 | 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 | CIA-81 | New commit by funman (r28040): usb-drv-as3525v2.c: cosmetics (remove trailing spaces) |
| 06:37:47 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 06:39:09 | CIA-81 | r28040 build result: All green |
| 06:47:48 | | Join shuffle2 [0] (~shuffle2@cpe-74-74-168-216.rochester.res.rr.com) |
| 06:48:51 | shuffle2 | hi |
| 06:49:14 | shuffle2 | 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 | shuffle2 | has anything happened with it since then? :) |
| 06:49:32 | funman | 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:00 |
| 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 | CIA-81 | New commit by funman (r28041): USB AMSv2: only read endpoint interrupt status register once |
| 07:05:28 | shuffle2 | hum, i was asking about bcm2722 because i saw it has an usb interface |
| 07:05:48 | shuffle2 | however the PP5021C-TDF does as well? |
| 07:06:28 | CIA-81 | r28041 build result: All green |
| 07:06:41 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 07:06:49 | funman | an usb interface? |
| 07:07:09 | shuffle2 | 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 | funman | "bcm" not found |
| 07:09:19 | shuffle2 | ? |
| 07:09:20 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 07:09:24 | funman | IIUC the bcm2722 is only an audio/video processor (http://www.broadcom.com/products/Cellular/Mobile-Multimedia-Processors/BCM2722) |
| 07:09:30 | funman | I can't find any mention to "bcm" in that pdf |
| 07:09:58 | shuffle2 | 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 | shuffle2 | that's because it's a PP part and not made by broadcom?? o_O |
| 07:10:57 | funman | you were asking about bcm2722 because you saw "it has an usb interface" <- "it" is the PP or the bcm2722 ? |
| 07:11:04 | shuffle2 | both |
| 07:11:26 | funman | interesting, maybe it's for debug purposes? |
| 07:11:31 | shuffle2 | which connects to the external ipod port is what i'm really asking ;p |
| 07:12:06 | shuffle2 | i'd guess PP, as it's usb 2.0, opposed to 1.1 |
| 07:12:25 | shuffle2 | and maybe that makes coding for it easier? do you know of docs for this cpu? |
| 07:12:57 | funman | nope but i don't know PP, wait a bit until the europeans wake up and ask again |
| 07:13:16 | funman | AFAIK most of the work for PP required reverse engineering |
| 07:15:59 | | Quit soap (Ping timeout: 255 seconds) |
| 07:16:45 | CIA-81 | New commit by funman (r28042): USB AMSv2: smaller struct usb_endpoint ... |
| 07:17:24 | | Quit kaiscene (Ping timeout: 276 seconds) |
| 07:17:46 | saratoga | there are no docs for the bcm or pp chips |
| 07:18:01 | shuffle2 | http://www.rockbox.org/wiki/PortalPlayer502x#USB_Controller |
| 07:18:01 | shuffle2 | well, it's a start :p |
| 07:18:19 | CIA-81 | r28042 build result: All green |
| 07:18:31 | shuffle2 | btw what are you using to do build tests? |
| 07:18:52 | funman | self-written perl scripts |
| 07:19:24 | funman | http://www.rockbox.org/wiki/BuildClient |
| 07:19:40 | shuffle2 | neat |
| 07:19:40 | funman | (self = written by rockbox hackers, not by me) |
| 07:20:36 | funman | 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 | shuffle2 | you mean your current commits? |
| 07:22:50 | funman | the file i'm working on, yes |
| 07:23:38 | funman | 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 | shuffle2 | soo |
| 07:29:59 | | Quit jfc (Ping timeout: 265 seconds) |
| 07:30:52 | shuffle2 | 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 | shuffle2 | it can't be that large of a codebase |
| 07:37:01 | | Quit CaptainKwel (Ping timeout: 252 seconds) |
| 07:41:24 | shuffle2 | http://booya.dyndns.ws:666/open/ipod_fw.png :P |
| 07:43:08 | CIA-81 | New commit by funman (r28043): USB AMSv2: split handle_ep_int() ... |
| 07:44:43 | CIA-81 | r28043 build result: All green |
| 07:48:09 | | Quit Bug2000 (Read error: Connection reset by peer) |
| 07:56:57 | | Quit anewuser () |
| 08:00 |
| 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 | CIA-81 | New commit by funman (r28044): USB AMSv2: use tables for usb_drv_port_speed() and usb_drv_mps_by_type() |
| 08:14:44 | CIA-81 | 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:00 |
| 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 | shuffle2 | fwiw, the cygwin packages you provide at http://download.rockbox.org/cygwin are named a bit wrongly |
| 09:33:23 | shuffle2 | 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 | gevaerts | shuffle2: they're named correctly |
| 09:51:49 | shuffle2 | oh? |
| 09:52:23 | gevaerts | They're not named eabi because, surprise, they're not the eabi compilers |
| 09:53:47 | shuffle2 | i'm shocked |
| 10:00 |
| 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:00 |
| 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 | preglow | 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:00 |
| 12:21:54 | | Join Jerom [0] (~jerome@95.171.148.36) |
| 12:38:06 | Luca_S | 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 | funman | try plugging it a dozen of times and see if it gives this message all the times |
| 12:40:22 | Luca_S | the second time has been enough :D :D |
| 12:44:20 | funman | "svn works like fs#11607" -> plug it 10 times, 10 different results |
| 12:44:55 | funman | 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 | Luca_S | 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 | funman | 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 | funman | 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 | Luca_S | I'll try, thank you |
| 12:58:47 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 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 | pamaury | funman: ping |
| 13:23:48 | pamaury | you made lots of changes to my code, some are strange |
| 13:24:08 | funman | i made an effort to separate changes so just ask |
| 13:24:26 | pamaury | 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 | funman | it didn't work with 1024 |
| 13:25:00 | funman | i used the fifo size of usb-s3c6400x.c and it magically mounted |
| 13:25:25 | pamaury | cosmetics: x ? true : false -> x |
| 13:25:31 | pamaury | NO because the value is not 0 or 1 |
| 13:25:42 | pamaury | it's 0 or 0x80, that's bad practice |
| 13:26:10 | funman | function returns bool so it's casted |
| 13:26:22 | pamaury | yes but that's bad practice anyway |
| 13:26:47 | pamaury | why do set endpoints[ep][DIR_IN].status = -1; on reset ? The status is updated each time you trigger a transfer ? |
| 13:27:02 | funman | i don't think so but then you are free to use your style and revert this change |
| 13:27:24 | funman | 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 | funman | before that reset_endpoints() would report success when cancelling transfers |
| 13:27:56 | amiconn | x ? true : false is just line noise imo |
| 13:28:13 | funman | in the same commit i made sure reset_endpoints set the status to error though |
| 13:28:51 | pamaury | but why in reset_endpoints AND cancel_transfers ? |
| 13:28:53 | TheSeven | 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 | pamaury | ok |
| 13:29:04 | funman | pamaury: which revision exactly? |
| 13:29:18 | pamaury | 28036 |
| 13:29:41 | funman | wrong one |
| 13:29:42 | pamaury | apart from this, you checked on fuzev2 ? Does it work now ? |
| 13:29:48 | pamaury | 28037 |
| 13:29:50 | pamaury | :) |
| 13:30:38 | funman | cancel_all_transfers() |
| 13:30:57 | funman | the only change in cancel_all_transfers() is 1 -> -1 |
| 13:31:22 | pamaury | yes, but why setting status in reset_endpoints ? if you cancel the transfer, cancel_all_transfers already set it to -1 |
| 13:31:49 | pamaury | it doesn't really matter, I'm just wondering if it changes anything |
| 13:31:50 | funman | reset_endpoints() doesn't call cancel_all_transfers |
| 13:32:08 | pamaury | no, but in no way you get a bad status after reset_endpoints |
| 13:32:10 | funman | the status need to be an error before wakeup_signal() is called |
| 13:33:01 | pamaury | hum, right, I forgot reset_endpoints call wakeup_signal() |
| 13:33:04 | funman | 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 | funman | and no i didn't check on fuzev2 because i lend it to a friend some days ago |
| 13:33:37 | funman | pamaury: for your defense i spent all the night reading it over and over |
| 13:33:56 | funman | rewriting some parts to make sure i understood it and i committed what i thought would be useful |
| 13:34:25 | pamaury | 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 | funman | what i didn't understand is the 'next' chaining line 304 |
| 13:35:29 | funman | TheSeven has mentioned it in his code also but i dont' know what it means |
| 13:35:31 | pamaury | that's for dma |
| 13:35:55 | pamaury | 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 | pamaury | you do a cycle so everything works: handle EP0 -> handle EP1 -> handle EP3 -> handle EP0 -> ... |
| 13:36:38 | funman | ah ok |
| 13:36:51 | pamaury | 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 | funman | 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 | TheSeven | and it definitely must be |
| 13:37:17 | TheSeven | endpoints not in that queue will never be handled |
| 13:37:19 | funman | 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 | pamaury | it is reproducable ? |
| 13:37:34 | pamaury | easily ? |
| 13:38:01 | funman | 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 | funman | looking at dmesg you will see it can fail at different steps |
| 13:38:55 | pamaury | 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 | pamaury | I need to leave, good news it finally works ! |
| 13:39:21 | funman | 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 | funman | i should look in firmware/usbstack/ perhaps the problem is here |
| 13:43:09 | | Quit Kitar|st (Ping timeout: 265 seconds) |
| 13:43:19 | funman | 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 | kugel | funman: what's the difference between invalidate_dcache and dump_dcache? |
| 13:45:13 | funman | invalidate writes back cache to memory |
| 13:45:53 | kugel | I thought flush_ does that |
| 13:45:55 | funman | 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 | funman | flush_*() doesn't exist |
| 13:46:13 | * | kugel always thought invalidate_ doesn't do writeback |
| 13:46:23 | kugel | cpucache_flush() does |
| 13:46:29 | funman | invalidate_() writes back and throw away the cache |
| 13:46:38 | funman | 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 | funman | 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 | funman | not sure what's invalidate_dcache() useful for though .. |
| 13:48:51 | kugel | funman: thanks for the info |
| 13:49:13 | TheSeven | you need that for in-place dma things |
| 13:49:19 | kugel | then that's probably why the invalidate call pamaury removed fixed problems |
| 13:49:22 | funman | 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 | TheSeven | like encrypting/decrypting/compressing/whatever stuff |
| 13:49:38 | funman | TheSeven: do we do that in rockbox? |
| 13:49:49 | TheSeven | in the nano2g bootloader at least |
| 13:50:00 | | Join Kitar|st [0] (Kitarist@89.142.55.137) |
| 13:50:06 | TheSeven | and we usually don't want to dump the *full* data cache |
| 13:50:15 | funman | IMO it should be clean_dcache() -> do DMA -> dump_dcache() |
| 13:50:22 | TheSeven | and for example on 940t you can't do it selectively |
| 13:50:48 | TheSeven | 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 | funman | ah right |
| 13:51:15 | TheSeven | on 940t you'll need clean => dma => invalidate |
| 13:51:30 | TheSeven | the clean will make sure that the invalidate won't overwrite dma data |
| 13:52:18 | TheSeven | are you dumping the full cache anywhere? |
| 13:52:29 | TheSeven | if yes, I'm sure that this will cause trouble somewhere |
| 13:52:42 | funman | everytime you see cpucache_flush() (but that's in common code) |
| 13:52:57 | funman | err it's not dumping |
| 13:53:10 | TheSeven | flush should be mapped to invalidate |
| 13:53:11 | funman | then no |
| 13:53:18 | funman | mmu-arm.S only has a dump_dcache_range() anyway |
| 13:53:33 | TheSeven | yes, because everything else doesn't make sense for that one |
| 13:54:05 | funman | 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 | TheSeven | make: *** No rule to make target `/data/rockbox-trunk/build/nano2-app/make.dep', needed by `all'. Stop. |
| 13:59:56 | TheSeven | hmm, what the hell... |
| 14:00 |
| 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 | Torne | kugel: normally "invalidate" just means throwing them away |
| 14:02:25 | Torne | "flush" == "clean and invalidate" |
| 14:02:57 | kugel | but throwing away doesn't imply write-back for me |
| 14:03:05 | Torne | That's what I mean |
| 14:03:09 | Torne | invalidate *doesn't* write back |
| 14:03:15 | kugel | it does |
| 14:03:19 | Torne | no it doesn't |
| 14:03:20 | Torne | not on ARM |
| 14:03:29 | TheSeven | it does on 940t at least |
| 14:03:31 | Torne | No, it doesn't |
| 14:03:35 | kugel | our invalidate_dcache does write-back |
| 14:03:36 | Torne | i assure you |
| 14:03:42 | Torne | then that's not doing an invalidate |
| 14:03:45 | Torne | that's doing a clean+invalidate |
| 14:03:53 | Torne | ARM's terminology is clean, invalidate, or clean+invalidate |
| 14:03:59 | TheSeven | 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 | kugel | Torne: hence our confusion |
| 14:04:21 | Torne | no, ARM don't use flush with regards to dcache |
| 14:04:37 | Torne | they talk about flushing prefetch buffers, or branch target caches |
| 14:04:44 | kugel | I also thought it doesn't write back |
| 14:04:45 | Torne | but they only use clean, invalidate and clean and invalidate for caches |
| 14:04:54 | Torne | right |
| 14:04:56 | Torne | so our names are wrong |
| 14:05:00 | * | TheSeven thinks they should be called "writeback" and "discard" |
| 14:05:09 | Torne | 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 | Torne | i assume it does c14, 0 ? |
| 14:05:52 | Torne | ARm call that "Clean and invalidate entire data cache" |
| 14:05:58 | Torne | in ARMARM |
| 14:06:50 | TheSeven | what about writeback, discard and flush as the new names? |
| 14:06:53 | Torne | i don't like the name flush for *anything* |
| 14:06:53 | kugel | 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 | Torne | because different OSes/vendors use that to mean different things |
| 14:07:09 | kugel | even if* |
| 14:07:13 | TheSeven | writeback/discard should be clear at least |
| 14:07:13 | Torne | some OSes/chips think flush implies writeback and some think it implies invalidation without writeback |
| 14:07:23 | Torne | so I vote to not use the term flush at all |
| 14:07:32 | TheSeven | any ideas for the third name then? |
| 14:07:47 | Torne | 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 | Torne | [Saint]: cache is pronounced cash in british english |
| 14:09:24 | Torne | not caysh |
| 14:09:26 | Torne | :) |
| 14:09:39 | [Saint] | here...it is "cash-aye" |
| 14:10:24 | Torne | that's dumb |
| 14:10:27 | kugel | that sounds weird to me (unless you also pronounce "aye" differently) |
| 14:10:28 | Torne | 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 | Torne | 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 | kugel | 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 | Torne | but that's what the cache being dirty means |
| 14:13:58 | Torne | the cache being dirty *means* it has newer content |
| 14:14:24 | Torne | ram being dirty would mean that it's newer than, say, a copy on disk |
| 14:14:59 | kugel | and what's it called if the ram has newer content than cache? |
| 14:15:11 | kugel | also dirty ram? |
| 14:15:14 | Torne | That's called "your system is already broken" |
| 14:15:23 | Torne | That's not a situatoin which is allowed to arise, ever, in a functoining system |
| 14:15:34 | kugel | that's called "we use dma" |
| 14:15:43 | Torne | no, it's not |
| 14:15:57 | Torne | if you are going to use DMA it is your responsibility to eliminate all the cachelines that are relevant *fist* |
| 14:16:08 | Torne | such that the newer content in ram has no corresponding cacheline |
| 14:16:19 | Torne | otherwise the system is broken, because the cache can choose to do writebacks at any time without your knowledge. |
| 14:16:43 | Torne | so no, that situation can never legitimately arise |
| 14:16:59 | Torne | no matter what the context (DMA, SMP, etc) |
| 14:17:04 | kugel | I see, why does invalidate (without writeback) even exist then= |
| 14:17:05 | kugel | ? |
| 14:17:25 | Torne | because sometimes you know it's irrelevant whether that data was written or not |
| 14:17:37 | Torne | e.g. when you are about to free that bit of memory and reuse it for a different purpose |
| 14:17:46 | Torne | and thus you want the performance benefit of not forcing a writeback |
| 14:17:57 | Torne | 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 | Torne | TheSeven: this is not surprising, cache coherency is hard :) |
| 14:18:30 | TheSeven | basically every dcache_invalidate call |
| 14:18:44 | kugel | Torne: it's even harder when the functions have misleading names |
| 14:18:58 | Torne | 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 | TheSeven | IIUC that would only be needed for dma that changes things in-place |
| 14:19:16 | TheSeven | ah, wait |
| 14:19:25 | TheSeven | we need to kill the cachelines even if they're clean |
| 14:19:41 | Torne | TheSeven: if you're about to do a DMA read, you can just invalidate the lines in questoin |
| 14:19:50 | Torne | 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 | Torne | well yes |
| 14:20:13 | Torne | you can always implement "invalidate line X" in terms of "invalidate entire cache" |
| 14:20:16 | Torne | it's just slower |
| 14:20:20 | Torne | it's equivalent from a safety/correctness pov |
| 14:20:28 | TheSeven | it isn't for discarding |
| 14:20:37 | TheSeven | only for commit+discard |
| 14:20:44 | Torne | Oh, er, yes |
| 14:20:56 | Torne | But that just means you implement "discard line x" as "commit+discard entire cache" |
| 14:21:00 | Torne | this is always safe |
| 14:21:03 | kugel | 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 | Torne | because the writebacks could've always happened at any time anyway |
| 14:21:16 | Torne | so forcing them to happen cannot make the system wrong |
| 14:21:19 | Torne | unless it was wrong already |
| 14:21:20 | | Quit esperegu (Remote host closed the connection) |
| 14:21:20 | TheSeven | yep |
| 14:21:25 | Torne | TheSeven: yes, probably |
| 14:21:32 | Torne | TheSeven: that seems pretty unambiguous to me |
| 14:21:34 | kugel | TheSeven: but trash and cache rhyme! |
| 14:21:48 | TheSeven | trayshe? :D |
| 14:22:18 | kugel | other than that, I'm fine with those |
| 14:23:03 | Torne | maybe we could do with a careful review of all our cache stuff at some point :) |
| 14:23:18 | Torne | 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 | kugel | we could alias discard and trash :) |
| 14:26:11 | kugel | anyway, who's going to do it? |
| 14:27:58 | kugel | 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 | Torne | that sounds like a good approach |
| 14:33:12 | Torne | are there other functions with the same problem, as well? |
| 14:33:31 | Torne | different arches/mmu styles alrady have slightly different names for some of this stuff, don't they? |
| 14:33:38 | Torne | 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 | kugel | aliases don't need the ".type <func_name>, %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:00 |
| 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 | normalll | #iphone |
| 15:08:37 | normalll | 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 | TheSeven | 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 | kugel | TheSeven, Torne: http://pastie.org/1145761 |
| 15:25:12 | | Quit CaptainKwel (Ping timeout: 258 seconds) |
| 15:25:33 | TheSeven | kugel: maybe dcache_* might be a better name, as it doesn't deal with icache |
| 15:25:51 | kugel | which one? |
| 15:25:56 | TheSeven | at the top |
| 15:26:15 | TheSeven | IIUC we should basically have the following functions, regardless of the target we're running on: |
| 15:26:23 | kugel | cpucache_commit_discard deals with icache (on the platforms that have it) |
| 15:27:11 | kugel | I think it's cpucache to hide i/dcache separation from non-target tree code |
| 15:27:21 | kugel | or any cache details in fact |
| 15:27:26 | TheSeven | do we really want to hide that? |
| 15:27:46 | kugel | I don't know, I just renamed :) |
| 15:28:31 | TheSeven | dcache_commit_range, dcache_discard_range, dcache_commit_discard_range and icache_discard_range should basically catch everything |
| 15:28:56 | kugel | 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 | TheSeven | they can be handled efficiently on targets that support it, or just flush the whole cache on targets that don't |
| 15:29:08 | kugel | IIUC |
| 15:29:17 | shuffle2 | 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 | shuffle2 | 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 | TheSeven | undocumented doesn't mean that nobody reverse-engineered it :) |
| 15:31:37 | kugel | 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 | kugel | 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 |
| 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 | pamaury | 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:00 |
| 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 | Torne | kugel: I object to changing the comments on the individual mcr instructions |
| 17:23:17 | Torne | "Clean and invalidate line by MVA" is the ARM ARM definition of what cp15 c7 c14 does. |
| 17:24:11 | Torne | 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 | Torne | and i'm still not sure what the cpucache_* ones refer to |
| 17:25:13 | Torne | if they mean both caches we should be more explicit about that |
| 17:25:19 | Torne | if it just means one or the other then call it one or the other |
| 17:25:32 | Torne | 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 | kugel | Torne: ok, restoring |
| 17:39:38 | Torne | 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 | TheSeven | 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 | Torne | 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 | Torne | and the names don't imply that at all |
| 17:47:58 | kugel | they take care of both |
| 17:48:51 | Torne | having one set called cpucache_* and the othe rset called *_dcache is weird in any case |
| 17:48:55 | kugel | 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 | kugel | I think the _dcache ones are only for within the target tree |
| 17:49:36 | Torne | hm |
| 17:49:45 | Misanthropos_ | 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 | Torne | 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 | Torne | like the examples i mentioned above: SyncCache{Before,After}DMA{Read,Write} |
| 17:50:17 | kugel | the generic code (high level firmware/, apps/) should only call cpucache_* |
| 17:50:22 | Torne | such that the semantic is to specify *why* you need a cache operation done |
| 17:50:25 | Torne | not what cache operation to do |
| 17:50:36 | TheSeven | 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 | kugel | that seems to be the convention from looking at it, I don't know if that's official or anything |
| 17:50:55 | Torne | kugel: right, bt i don't think it's apps/ business to know about cleaning and invalidating at all |
| 17:51:20 | Torne | 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 | Torne | 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 | kugel | well, apps/ doesn't even use those anymore (since my load_code.c work) but some plugins and codecs use it |
| 17:52:22 | Torne | right, but same principle, no? |
| 17:52:36 | Torne | it makes more sense to specify the operatoins, where possible, in terms of actual functional semantics |
| 17:52:39 | kugel | I think plugins don't load code (except overlay?), so they must have another reason |
| 17:52:48 | Torne | and let the target-specific code decide entirely for itself what that has to mean |
| 17:52:49 | kugel | maybe dual-core stuff |
| 17:52:59 | pamaury | Misanthropos_: yes but there are still a few glitches |
| 17:53:46 | kugel | Torne: yes, I think so |
| 17:53:56 | vaguerant | 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 | Torne | kugel: so "before and after dma read/write" is one set of operations, the implementation of which depends on architecture |
| 17:54:23 | Torne | it happens that the implementations are fairly similar on RISC but x86 is not :) |
| 17:54:35 | Torne | because x86 is fucking crazy and has full coherency |
| 17:55:11 | TheSeven | vaguerant: I'm not sure if that is enabled by default yet |
| 17:55:15 | Misanthropos_ | pamaury, rhx |
| 17:55:31 | vaguerant | TheSeven: Ahh, that makes sense. |
| 17:55:37 | pamaury | 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 | n1s | pamaury: is it enabled in current builds? |
| 17:56:31 | pamaury | 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 | pamaury | hum no, looking at the code it's disable by default for now |
| 17:57:26 | vaguerant | Is that a runtime or compile-time thing? I do have an environment set up if necessary. |
| 17:57:30 | vaguerant | Ahh, fair enough. |
| 17:57:31 | pamaury | compile-time |
| 17:57:41 | saratoga | the wiki says USB isn't in SVN yet |
| 17:57:59 | pamaury | uncomment //#define USE_ROCKBOX_USB in firmware/export/config/{target}.h |
| 17:58:01 | Luca_S | pamaury: I can confirm that it works (randomly) on FuzeV2. vaguerant: It's disabled by default, but can be enabled easily. |
| 17:58:25 | pamaury | 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 | saratoga | I guess the not in SVN could be made more clear |
| 17:59:22 | saratoga | something like "NOT ENABLED" |
| 17:59:47 | vaguerant | Right, I did see that but it was in reference to an already-closed issue on the tracker. |
| 18:00 |
| 18:00:05 | vaguerant | Closed with the reasoning that the implementation was now working. |
| 18:00:13 | vaguerant | I just figured the wiki was out of date. |
| 18:00:24 | pamaury | 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 | kugel | Torne: commit? |
| 18:14:19 | Torne | kugel: it seem slike the right way to go |
| 18:14:35 | Torne | kugel: i can put "review cache stuff" on my ever growing todo list but who knows if i'll get there ;) |
| 18:15:44 | kugel | saratoga: do you know why the mad_synth_thread does cpucache_invalidate() on thread exit? |
| 18:16:09 | saratoga | kugel: probably to clean up the incoherrent cache on PP |
| 18:16:12 | saratoga | let me double check that |
| 18:16:31 | kugel | 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 | Torne | 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 | Torne | but after it exits then the memory may be reused on a different core |
| 18:18:21 | Torne | so delayed writebacks would trash stuff |
| 18:18:22 | saratoga | does cpucache_invalidate flush or just dump the cache? |
| 18:18:47 | kugel | we try to not use terms like flush and dump anymore :P |
| 18:18:59 | saratoga | 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 | kugel | both |
| 18:19:12 | saratoga | 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 | Torne | saratoga: it doesn't matter by definition |
| 18:21:37 | Torne | discarding cachelines without writing back is only ever a performance optimistaion |
| 18:21:49 | Torne | it's never any more correct/safe. |
| 18:21:52 | | Join milz [0] (~kyle@S0106001ff341eb86.cg.shawcable.net) |
| 18:21:54 | saratoga | well i mean if I was accidentally deleting them without write back :) |
| 18:21:57 | kugel | Torne: once more, the current invalidate does write-back :) |
| 18:22:05 | kugel | that applies for cpucache_invalidate as well |
| 18:22:30 | Torne | oh, yeah, it matters the other way raround :) |
| 18:22:38 | Torne | nevermind |
| 18:22:43 | Torne | just ignor eme ;) |
| 18:23:13 | kugel | 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 | kugel | considering it also clears the icache, changing it to cpucache_commit should give a performance boost |
| 18:24:13 | kugel | (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 | pamaury | Apparently, I have a usb failure because of a CRC failure |
| 18:30:08 | kugel | 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 | pamaury | 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 | Torne | kugel: so yeah, dma, code loading, and multicore threading on PP are the three cases we have |
| 18:33:13 | Torne | 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 | Torne | multicore is only a problem because PP's cache is retarded |
| 18:33:30 | kugel | code loading is abstracted, except for the case where icode is copied from the binary to the location in iram |
| 18:33:32 | Torne | real SMP systems all have MESI cache coherency between cores |
| 18:33:41 | Torne | PP doesn't because it's thick as a plank |
| 18:34:24 | Torne | right, so all you need for that is a call "code_memory_modified()" or similar |
| 18:34:38 | Torne | to note that you have changed data in a region and need the caches twiddling before you execute from it |
| 18:34:42 | Torne | which ARM call "point of unification" |
| 18:34:50 | kugel | hm no, load_code_from_mem() does what we need |
| 18:35:02 | Torne | Ah good |
| 18:35:06 | Torne | and presumably nothing in apps is doing DMA either |
| 18:35:15 | kugel | 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 | Torne | so app code should only need to care about this stuff at all if it's doing multicore |
| 18:35:31 | pamaury | hum, no something is strange, the device sends wrong data but with wrong crc and then good data, ...wtf ! |
| 18:35:44 | Torne | which is only a couple of plugins and codecs.. |
| 18:37:24 | pamaury | 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:00 |
| 19:05:53 | CIA-81 | New commit by kugel (r28045): Rename cache coherency functions. ... |
| 19:07:55 | kugel | I think sd_as3525*.c does it wrong |
| 19:08:04 | CIA-81 | r28045 build result: All green |
| 19:08:20 | | Join parafin [0] (parafin@paraf.in) |
| 19:10:30 | pamaury | kugel: it what way ? |
| 19:12:29 | kugel | hm no, it should be alright |
| 19:13:53 | kugel | but I'm thinking maybe the transfer buffer for unaligned transfers should also be cached? |
| 19:14:14 | kugel | wouldn't that speedup the following memcpy()? |
| 19:14:38 | pamaury | which buffers ? |
| 19:14:58 | pamaury | 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 | kugel | pamaury: no, not all are aligned |
| 19:16:47 | pamaury | like ? |
| 19:16:55 | CIA-81 | New commit by kugel (r28046): Change sd-as3525*.c to the new cache coherency function names. |
| 19:17:03 | kugel | buffers on stack |
| 19:17:42 | TheSeven | there should *never* be usb buffers on the stack |
| 19:17:58 | kugel | I'm not talking about usb |
| 19:18:42 | | Quit hebz0rl (Remote host closed the connection) |
| 19:18:47 | pamaury | ah |
| 19:18:51 | CIA-81 | r28046 build result: All green |
| 19:20:43 | TheSeven | gevaerts: did you commit your fat buffer patch? |
| 19:21:06 | amiconn | kugel: If you want non-misleading function names you need to rename the cf one |
| 19:21:33 | kugel | didn't I do that? |
| 19:21:34 | TheSeven | 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 | amiconn | Coldfire only has an instruction cache which is hence never written back |
| 19:21:53 | gevaerts | TheSeven: I committed the FAT stack thing, yes |
| 19:22:52 | kugel | amiconn: I see, but it's named after the cpucache_* scheme which doesn't care about i/d cache separation |
| 19:23:00 | gevaerts | TheSeven: maybe check if the on-stack buffer in fat_rename() isn't allocated for the entire function? |
| 19:23:01 | amiconn | kugel: cpucache_commit_discard -> cpucache_discard |
| 19:23:20 | amiconn | There is nothing that could be committed. |
| 19:23:53 | TheSeven | commit_discard shluld be an alias then |
| 19:23:54 | kugel | I know (and I didn't know it only has icache), but the cpucache_* ones are abstrated from the underlying cache |
| 19:24:07 | kugel | Torne wants to work on cleaning those up |
| 19:24:16 | amiconn | 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 | kugel | 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 | kugel | 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 | shuffle2 | maybe you shouldn't rename them then? :P |
| 19:28:19 | kugel | but I think there ought to be something like cache_sync_after_code_load() for all platforms (modifying only icache) |
| 19:29:08 | amiconn | 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 | amiconn | 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 | amiconn | icache only -> needs invalidating, before or after load doesn't matter |
| 19:32:50 | amiconn | dcache only -> needs flushing after load |
| 19:33:01 | kugel | no |
| 19:33:05 | amiconn | dcache + icache -> flush dcache, invalidate icache |
| 19:33:08 | kugel | dcache only needs no action |
| 19:33:27 | TheSeven | kugel: it does |
| 19:33:29 | amiconn | unified cache -> no action, unless more than one core |
| 19:34:11 | kugel | TheSeven: why? |
| 19:34:40 | TheSeven | 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 | TheSeven | gevaerts: indeed, renaming a file from the file browser crashes. now why does that fill up an 8K-sized stack? |
| 19:35:02 | amiconn | 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 | kugel | ah yes, I see |
| 19:35:35 | gevaerts | TheSeven: Depending on compiler behaviour that one *might* still have two sectors on stack |
| 19:35:54 | TheSeven | yeah, but not four |
| 19:36:11 | gevaerts | Good point |
| 19:36:53 | gevaerts | unless it's somewhere else, outside fat.c |
| 19:37:03 | TheSeven | main thread stack peak is at 51% (so slightly above 4K) if I navigate directly to the debug menu upon boot |
| 19:37:27 | gevaerts | that's a lot... |
| 19:37:58 | TheSeven | well, it's the peak value |
| 19:38:36 | TheSeven | 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 | kugel | 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 | TheSeven | btw. should we make that menu also show the current stack usage? |
| 19:39:38 | kugel | seems easy on cf and standard arm and pp502x, but the asm in pp5002 scares me |
| 19:40:55 | amiconn | TheSeven: Same on Clip+. On Recorder (hwcodec) it's 48% without voice, 59% with voice enabled |
| 19:41:09 | amiconn | So those 51% certainly don't come from sector buffers |
| 19:41:59 | gevaerts | 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 | amiconn | kugel: PP5002 is very easy too, even though we don't know the details of that cache controller |
| 19:44:22 | kugel | 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 | amiconn | Iiuc *you* are suggesting this |
| 19:45:14 | kugel | 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 | amiconn | (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 | gevaerts | 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 | gevaerts | 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:00 |
| 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 | Guest27285 | anyone familiar with the channel setup in wavplay.c? |
| 20:07:14 | * | gevaerts finds another sector buffer :\ |
| 20:10:46 | n1s | Guest27285: nope, but if you ask your question maybe someone can answer or someone sees it in the logs and answers |
| 20:14:16 | Torne | amiconn: i might see about changing all the cache stuff to just ask for semantics; see my discussion with kugel earlier |
| 20:14:27 | Torne | amiconn: but th eold names for the dcache stuff suck :) |
| 20:14:38 | amiconn | why? |
| 20:14:48 | Torne | because they're inconsistent with what most of the world uses those terms to mean |
| 20:15:01 | Torne | invalidate doesn't actually write any data back to memory anywhere else that i'm aware of |
| 20:15:07 | Torne | certainly ARM's docs don't use it that way |
| 20:16:26 | Guest27285 | 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 | gevaerts | 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 | TheSeven | gevaerts: urgh... i didn't expect those structs to turn up on the stack |
| 20:18:02 | Torne | i can't see how the new ones can be ambiguous |
| 20:18:09 | TheSeven | they don't really belong there either, do they? |
| 20:18:14 | Torne | but anyway, i would like semantic names |
| 20:18:20 | gevaerts | I think they don't, but... |
| 20:18:24 | n1s | Guest27285: wait wavplay.c, are you using an old archos? |
| 20:18:34 | TheSeven | why doesn't it just open those dirs in the pool? |
| 20:18:44 | Torne | 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 | gevaerts | Even on a 512-byte stack system that uses more than 1KB... |
| 20:18:53 | gevaerts | *sector |
| 20:20:53 | amiconn | Torne: I pointed out the very first ambiguity. Furthermore a proper rename involves changing all calls imo, not just providing aliases |
| 20:21:14 | Torne | amiconn: the point was to change them as they were verified to be correct.. |
| 20:21:20 | amiconn | If the only problem was that invalidate actually did flush+invalidate, I would have renamed that single function |
| 20:21:27 | Torne | since it's likely that they are not all now |
| 20:21:42 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 20:21:45 | Torne | (flush is also a terrible word because that means different things on different systems also) |
| 20:22:10 | amiconn | 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 | Guest27285 | OK, I think it's wavplay.c, I was browsing it late last night. I'm using an old olympus modrobe |
| 20:23:35 | Torne | amiconn: well, there is that. PP sucks, though ;) |
| 20:23:45 | Torne | its specialness is not a good reason for anything much. |
| 20:24:10 | Torne | 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 | amiconn | The cf case I mentioned |
| 20:26:03 | Torne | i don't see what's inconsistent about that |
| 20:26:15 | Torne | just because it doesn't have a dcache doesn't mean anything calling it should care |
| 20:26:27 | gevaerts | 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 | Torne | amiconn: the combinations should, ideally, *all exist* on all platforms |
| 20:27:19 | Torne | and then code can just call them without caring |
| 20:27:32 | Torne | 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 | Torne | 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 | Torne | the fact that it doesn't actually need to do that much on CF is irrelevant |
| 20:29:22 | Torne | 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 | Torne | that's why it's not renamed, so the old calls can be updated based on individual requirements |
| 20:29:48 | TheSeven | 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 | kugel | amiconn: cpucache_invalidate did write-back on other archs, which isnt what people expect |
| 20:30:28 | amiconn | [20:21:16] <amiconn> If the only problem was that invalidate actually did flush+invalidate, I would have renamed that single function |
| 20:30:59 | Torne | 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 | Torne | and that doesn't solve the problem that some things might be calling that when they actually want just weaker semantics |
| 20:31:20 | Torne | i.e. a potential performance improvement |
| 20:31:27 | TheSeven | gevaerts: any idea what that first fat_opendir is good for? (the /* create a temporary file handle */ one) |
| 20:31:30 | kugel | we wanted new names which are clear and not influenced by vendor manuals which use them differently |
| 20:31:48 | Torne | 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 | Torne | and substitute those everywhere, leavin the actual clean/invalidate/etc as internals of the target specific code |
| 20:32:14 | Torne | imo :) |
| 20:32:57 | Torne | 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 | Torne | because PP is stupid |
| 20:33:02 | Torne | :) |
| 20:33:58 | gevaerts | TheSeven: no idea |
| 20:34:38 | kugel | 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 | kugel | because there's no dcache* |
| 20:35:04 | TheSeven | gevaerts: and the second one should probably be a fat_file |
| 20:38:58 | gevaerts | 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 | TheSeven | a* |
| 20:58:59 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:03:40 | gevaerts | 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 | TheSeven | can we remove the newdir arg from fat_create_dir? |
| 21:06:30 | | Quit Guest27285 (Quit: Page closed) |
| 21:07:19 | gevaerts | hm, the memset in mkdir_uncached is unneeded at least :) |
| 21:09:26 | TheSeven | is fat_create_dir used from anywhere else? |
| 21:09:35 | | Join Jerom [0] (~jerome@95.171.148.36) |
| 21:14:16 | gevaerts | apparently not |
| 21:16:42 | Jerom | pamaury and funman, thanks for the usb driver :) |
| 21:25:48 | TheSeven | gevaerts: your patch seems to work fine and get rid of the stkovs |
| 21:25:55 | TheSeven | at least the file browser ones |
| 21:25:59 | TheSeven | let's try some plugins |
| 21:26:44 | TheSeven | 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 | TheSeven | blackjack runs into an undefined instruction |
| 21:28:12 | TheSeven | hm, all the plugins seem to be broken |
| 21:28:21 | * | TheSeven re-extracts the zip |
| 21:29:15 | gevaerts | r28045 only renames things, right? It shouldn't actually change anything? |
| 21:29:31 | kugel | yea |
| 21:30:05 | TheSeven | haha |
| 21:30:25 | TheSeven | re-extracting the zip fixed it, so there was probably file system or ftl screwup |
| 21:30:38 | TheSeven | now i entered blackjack, the menu came up, and when i hit "quit" it locked up |
| 21:31:05 | gevaerts | TheSeven: filesystem screwup after an untested fat.c patch? Unlikely! ;) |
| 21:31:19 | TheSeven | really unlikely in that case |
| 21:32:00 | TheSeven | that "quit blackjack" lockup is reproducible |
| 21:33:05 | TheSeven | ew... |
| 21:33:43 | kugel | 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 | TheSeven | and *loads* of plugins are still stuck with a backdrop-only screen |
| 21:34:40 | TheSeven | i just read back and compared the .rockbox folder, it's fine |
| 21:35:07 | gevaerts | Did you try plugins recently without this patch? |
| 21:35:26 | TheSeven | that patch can't affect reading, so i'm deducing that either current svn is broken or they're stkov'ing |
| 21:37:05 | TheSeven | increasing the stack size didn't affect the bavior |
| 21:37:08 | TheSeven | behavior* |
| 21:38:42 | * | gevaerts tends to be suspicious of rename-only changes that affect binsize |
| 21:39:06 | TheSeven | the fun part: blackjack works perfectly, apart from locking up when trying to quit |
| 21:41:52 | TheSeven | 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 | TheSeven | 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 | CIA-81 | New commit by nls (r28047): keybox: do not leak filehandle when the wrong password is entered. |
| 21:54:15 | gevaerts | Are multiple simultaneous operations from different threads using the same dirent pointer allowed? |
| 21:55:59 | CIA-81 | r28047 build result: All green |
| 22:00 |
| 22:00:31 | | Join Xerion [0] (~xerion@84.25.7.202) |
| 22:04:08 | kugel | gevaerts: I doubt it |
| 22:05:17 | kugel | gevaerts: the sim uses a single dirent for all dir operations, so there should only be one thread ever using dirents :) |
| 22:05:29 | gevaerts | 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 | gevaerts | kugel: really? That sounds broken... |
| 22:07:10 | kugel | exactly my thought |
| 22:07:25 | kugel | it seems to work though, but I avoided that in the android port |
| 22:07:38 | kugel | (where the host's dirent is used anyway) |
| 22:08:03 | gevaerts | Maybe nothing in core keeps a dirent open for a longer time |
| 22:09:39 | kugel | 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 | kugel | recurse* |
| 22:17:14 | | Join vaguerant [0] (3aaf4cc7@wikipedia/vague-rant) |
| 22:18:37 | vaguerant | 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 | n1s | vaguerant: it's not enabled in the the builds yet |
| 22:25:15 | vaguerant | n1s, right, I edited /firmware/export/config/sansaclipplus.h as suggested here though with no results. |
| 22:25:35 | vaguerant | Well. Some results, but not the kind which include USB access. |
| 22:25:56 | n1s | 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 | n1s | i'd suggest waiting until it is enabled in the svn source then unless you want to hack on t |
| 22:26:40 | n1s | *it |
| 22:30:02 | bertrik | vaguerant, seems to work for me for reading (just tried), I'm not really comfortable using it for writing though |
| 22:35:51 | TheSeven | 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 | CIA-81 | New commit by kugel (r28048): Cleanup io.c a bit. |
| 22:41:04 | | Quit liar (Ping timeout: 258 seconds) |
| 22:41:44 | CIA-81 | r28048 build result: 156 errors, 0 warnings (kugel committed) |
| 22:42:41 | CIA-81 | New commit by kugel (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 | CIA-81 | r28049 build result: All green |
| 22:47:49 | | Quit krazykit (Quit: bbl) |
| 22:59:00 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 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 | kugel | *oops* |
| 23:08:17 | | Quit anewuser (Ping timeout: 258 seconds) |
| 23:08:37 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 23:09:16 | ascheel | 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 | ascheel | 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 | pixelma | sounds like you only installed the bootloader and not the build |
| 23:13:37 | ascheel | 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 | gevaerts | 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 | ascheel | followed the directions, pixelma. mkamsboot [OF] [bootloader] [outputfile.bin] |
| 23:16:28 | pixelma | 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 | ascheel | then move outputfile.bin to device root and rename to fuzpa.bin (OF name) |
| 23:16:47 | ascheel | pixelma, understood |
| 23:17:38 | ascheel | *sigh* yeah I missed that somehow. |
| 23:21:10 | ascheel | And that has it rolling. Thanks again! |
| 23:22:23 | | Join threeothree [0] (generic@server1.unitedservers.de) |
| 23:26:39 | CIA-81 | New commit by kugel (r28050): Revert r27972 to fix FS #11610 (but in a way android builds still work). |
| 23:27:13 | gevaerts | kugel: DEBUGF("aaa\n"); ? |
| 23:27:16 | CIA-81 | New commit by kugel (r28051): Oops, remove left-over DEBUGFs. |
| 23:27:26 | gevaerts | :) |
| 23:27:26 | kugel | gevaerts: :) |
| 23:28:08 | alexbobP | I wonder if anyone's working on porting gnugo to rockbox... |
| 23:28:26 | alexbobP | it has a nice go plugin but it's useless when I'm all alone :( |
| 23:28:29 | CIA-81 | r28050 build result: All green |
| 23:29:23 | | Join simonrvn [0] (simon@209.191-ppp.3menatwork.com) |
| 23:30:44 | CIA-81 | 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 | ascheel | What wiki software do you guys use on rockbox.org? |
| 23:43:14 | ascheel | Sorry, that's more appropriate for #rockbox-community |
| 23:43:22 | saratoga | http://www.rockbox.org/wiki/WebHome |
| 23:43:25 | saratoga | says foswiki |
| 23:43:45 | ascheel | 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 | Drise | Hey guys. Do we know if the new Fuze v2's like the old Fuze v2's? |
| 23:51:50 | Drise | *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) |
icon identifies that the person is a core developer (has commit access).