| 00:00:13 | gevaerts | Actually |
| 00:00:16 | gevaerts | Well |
| 00:00:19 | gevaerts | Yes then :) |
| 00:00:44 | | Quit Provel (Ping timeout: 276 seconds) |
| 00:00:57 | TheSeven | could also have been an attempt to redo it after bus resets, with quirky drivers that clear their internal endpoint drivers AFTER calling usb_core_bus_reset |
| 00:01:50 | gevaerts | I don't remember if usb_core_init() is called before or after we know we're going to be doing charging or msc |
| 00:01:56 | TheSeven | what we're currently doing, while probably harmless, might not be fully spec compliant |
| 00:02:08 | TheSeven | we're basically enabling EP >0 before we have an address or configuration |
| 00:02:12 | gevaerts | Well |
| 00:02:23 | gevaerts | Does the spec actually care about that? |
| 00:02:37 | TheSeven | not sure if it's a SHALL or SHOULD ;) |
| 00:02:39 | gevaerts | But yes, I have this very vague memory about bus resets being involved here |
| 00:02:54 | TheSeven | a spec-compliant host SHALL probably not rely on it though ;) |
| 00:03:14 | gevaerts | I can promise you that the bit about the host doing things where this makes a difference is a MUST NOT :) |
| 00:03:38 | TheSeven | I'm currently running into problems which look like there's an unexpected STALL condition on EP1, right on the first bulk request |
| 00:03:52 | TheSeven | which I partially blame on the confusing semantics of usb_drv_request_endpoint ;) |
| 00:06:32 | gevaerts | What's the confusion? |
| 00:06:43 | gevaerts | Sure, there is a slight lack of documentation... :) |
| 00:06:57 | TheSeven | well, I wrote the driver assuming that this actually enables the hardware EP |
| 00:07:04 | TheSeven | and it somehow doesn't work, although I don't see why |
| 00:07:22 | TheSeven | could be that the hardware is doing some funny things when setting an address |
| 00:08:28 | gevaerts | I know it doesn't set anything up on ARC |
| 00:08:29 | * | TheSeven takes a look how the old driver handles this |
| 00:08:46 | gevaerts | Well |
| 00:08:48 | gevaerts | I think :) |
| 00:09:07 | gevaerts | Ah, yes |
| 00:09:16 | TheSeven | on usb-s3c6400x it seems to activate the endpoint |
| 00:09:41 | gevaerts | The ARC driver (which is the only one I know!) actually sets up the hardware endpoints from set_address() |
| 00:11:09 | TheSeven | ...which is called AFTER finishing sending the ACK for that request |
| 00:11:18 | gevaerts | The reason usb_drv_request_endpoint() is in the hardware driver and not in usb_core is really only that different hardware has different rules about which endpoints can do what |
| 00:11:50 | gevaerts | Is that a problem? We haven't had a SET_CONFIGURATION yet |
| 00:12:12 | TheSeven | it's just something to remember when looking at the code ;) |
| 00:12:37 | TheSeven | well, is there another way for the driver to know how to actually configure the EPs besides tracking the usb_drv_request_endpoint calls? |
| 00:12:50 | gevaerts | No |
| 00:13:31 | gevaerts | That could be redone to have the core remember it all, but refactoring USB is no fun |
| 00:13:42 | gevaerts | You'll *never* get testers for all hardware |
| 00:13:59 | TheSeven | hm, on the old one, cancel_all_transfers actually takes down the endpoints. i.e. if that would be called after set_address, it would probably kill it |
| 00:14:35 | gevaerts | That's called for USB_REQ_SET_CONFIGURATION |
| 00:14:53 | gevaerts | And SET_ADDRESS |
| 00:15:06 | TheSeven | DEPCTL(ep, dir) = (DEPCTL(ep, dir) & ~DEPCTL_usbactep); |
| 00:15:13 | TheSeven | for ever endpoint besides 0 |
| 00:15:47 | TheSeven | usbactep is set in usb_drv_request_endpoint |
| 00:16:04 | TheSeven | and in reset_endpoints |
| 00:16:55 | TheSeven | which in turn is done in usb_drv_init and usb_reset, and in the bus reset handler |
| 00:17:19 | TheSeven | I see neither of those happening after set_configuration |
| 00:17:56 | *** | Saving seen data "./dancer.seen" |
| 00:18:45 | gevaerts | It's in request_handler_device() |
| 00:19:36 | TheSeven | what exactly is there? |
| 00:19:54 | gevaerts | usb_drv_cancel_all_transfers() |
| 00:19:58 | TheSeven | yes |
| 00:20:17 | TheSeven | I'm wondering what recovers the damage done by that in the old driver |
| 00:24:45 | | Join audiomodder [0] (ac0215fb@gateway/web/freenode/ip.172.2.21.251) |
| 00:24:50 | audiomodder | #rockbox |
| 00:25:14 | audiomodder | hello, anyone in here? |
| 00:25:48 | --> | "yo" received from Schizoid (~schizoid@unaffiliated/surtri) |
| 00:25:59 | TheSeven | yes, 103 people, some of which might actually be awake :) |
| 00:26:04 | TheSeven | if you have a question, just ask it |
| 00:27:07 | audiomodder | great. Im a first-timer here (IRC n00b as well) but long term hardware hacker. I have some Sansa Clip+s that are bricked that I am trying to fix |
| 00:27:18 | audiomodder | using the instructions from here: http://www.rockbox.org/wiki/SansaAMSUnbrick |
| 00:27:27 | TheSeven | how are they behaving? |
| 00:28:55 | audiomodder | blank screens, flash seems corrupt / wont format |
| 00:29:10 | TheSeven | do they connect as a usb storage device? |
| 00:29:14 | TheSeven | if so, what capacity? |
| 00:29:26 | audiomodder | 4GB but they wont format |
| 00:31:22 | audiomodder | i tried using a partitioning program |
| 00:31:44 | audiomodder | and got one to partition a 100MB primary FAT16 |
| 00:32:05 | TheSeven | was it actually able to write that to the player? |
| 00:32:06 | audiomodder | (this is a different one that actually has a working display) |
| 00:32:19 | audiomodder | after many attempts, yes |
| 00:32:32 | TheSeven | after shorting those pins? |
| 00:32:39 | audiomodder | the player turned on after that, and then kept saying it needed 90MB for the database |
| 00:32:49 | audiomodder | so i gave up, shorted those pins for NAND |
| 00:33:02 | audiomodder | and it saw the full 4GB after that, doing a long format for FAT32 now... |
| 00:33:05 | TheSeven | if it came up AT ALL, this is the wrong way to go |
| 00:33:18 | audiomodder | ah OK |
| 00:33:21 | TheSeven | and with that format you have probably actually bricked it |
| 00:33:21 | audiomodder | good to know |
| 00:33:34 | audiomodder | really? even thought its the 4GB? |
| 00:33:58 | TheSeven | this is why the wiki page says to confirm things here *before* trying out anything |
| 00:34:05 | audiomodder | cause I figured I wasnt actually in NAND, since it didnt say "979.75MB" |
| 00:34:12 | audiomodder | yeah, i know.... |
| 00:34:14 | TheSeven | anyway, I'm having trouble following your steps |
| 00:34:23 | audiomodder | yeah let me start over. |
| 00:34:33 | audiomodder | I have 3 bricked players |
| 00:34:36 | TheSeven | you seem to be talking about multiple players, please number them and describe the state of each one, so we don't confuse things |
| 00:34:44 | audiomodder | yeah, sorry about that |
| 00:35:12 | * | TheSeven pings bertrik, funman, and whoever else has experiences with AMS bricks |
| 00:35:25 | audiomodder | These are all Clip+ btw |
| 00:35:43 | audiomodder | player 1 had the working LCD but said "FAT corrupted please plug into a computer and format" |
| 00:36:08 | TheSeven | ok, that one definitely doesn't need any shorting of pins then |
| 00:36:44 | audiomodder | Im using Win 7 and I tried formatting it many times, and using "EaseUS Partition Master" |
| 00:37:13 | audiomodder | It seems to me like the SSD memory is dead, no? |
| 00:38:22 | TheSeven | or you're doing something that the player doesn't support |
| 00:38:52 | TheSeven | I'm not very experienced with these sandisk devices, so I can't properly guide you through this |
| 00:38:52 | audiomodder | I have used clip+ for quite a while, bought these players as a broken lot as a hope of fixing them |
| 00:39:02 | TheSeven | what's up with the second one? |
| 00:39:08 | audiomodder | thats ok, i appreciate you talking with me |
| 00:39:30 | audiomodder | the second one plugs in, sees something but 1) no display whatsoever and 2) wont format either |
| 00:40:09 | TheSeven | so it shows as a drive as well, which capacity? |
| 00:41:34 | audiomodder | it shows 2 drive, one is 4.03MB and one is 3.69GB |
| 00:42:30 | audiomodder | (I had to use the partition program to find that info, Win 7 doesnt like the drives) |
| 00:43:40 | TheSeven | if you have a microsd card in those players, remove it, just to rule that out |
| 00:43:49 | TheSeven | this could otherwise get a bit confusing ;) |
| 00:44:20 | TheSeven | run diskmgmt.msc |
| 00:44:23 | audiomodder | no microsd in them |
| 00:44:28 | TheSeven | that will tell you where those drives are coming from |
| 00:44:41 | | Quit alexbobp (Ping timeout: 240 seconds) |
| 00:46:04 | | Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.200.73) |
| 00:46:22 | | Join alexbobp [0] (~alex@capitalthree.pwnz.org) |
| 00:46:33 | audiomodder | ah my mistake it just shows 4MB for Player 2 |
| 00:46:41 | audiomodder | 4MB RAW |
| 00:47:53 | TheSeven | as far as I can tell this one is dead. you could try shorting the pins there, but that looks like a dead internal SD |
| 00:48:23 | bertrik | my clip+ has acted funky once, I thought I fixed it by dd'ing the original firmware to it, but other people have not been able to reproduce that |
| 00:48:41 | TheSeven | bertrik: in which state? full capacity or 4MB? |
| 00:48:55 | TheSeven | I have a 4MB dead one here, JTAGging it showed a completely unresponsive internal SD |
| 00:49:01 | bertrik | it's very rare for people to successfully recover a bricked AMS player |
| 00:49:12 | TheSeven | i.e. a JTAG-booted rockbox was able to work from microSD, but couldn't access the internal one |
| 00:49:22 | bertrik | TheSeven: I don't remember |
| 00:49:22 | TheSeven | I think you did the builds for me for these tests back then ;) |
| 00:49:53 | audiomodder | so i have a Q for u all then |
| 00:50:00 | audiomodder | since these SDs appear pretty dead |
| 00:50:14 | audiomodder | can you hardware swap the internal SD from another player? |
| 00:50:17 | | Quit bluebrother (Disconnected by services) |
| 00:50:23 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 00:50:29 | audiomodder | Im very good at soldering and can do it, but dont know if the software supports that |
| 00:50:31 | TheSeven | the first one seems recoverable by software means, the second one probably not. |
| 00:50:53 | TheSeven | if they're otherwise identical devices, it swapping the flash chip might work |
| 00:51:11 | | Quit ender` (Quit: I spilled Spot Remover on my dog... Now he's gone.) |
| 00:51:17 | TheSeven | it's quite possible that it's actually some data structure on that flash that's corrupted, causing the SD controller do not boot up anymore |
| 00:51:25 | audiomodder | there are slight hardware revisions |
| 00:51:35 | audiomodder | and the chip part #s never are exactly the same |
| 00:51:37 | TheSeven | so even cloning an image of the flash chip might possibly work |
| 00:51:52 | TheSeven | (assuming the chips have exactly the same capacity and layout) |
| 00:52:08 | audiomodder | yeah they do seem to |
| 00:52:12 | audiomodder | sorry 2 convos here now |
| 00:52:15 | | Quit fs-bluebot (Ping timeout: 245 seconds) |
| 00:52:20 | audiomodder | Ill stick with the first Q |
| 00:52:37 | audiomodder | if the SD controller doesnt boot, thats when you go to NAND, right> |
| 00:52:39 | TheSeven | look up the datasheets for those particular chips, if the bank, block, page and spare sizes are identical |
| 00:52:53 | audiomodder | what is the proper way to use the NAND? (in windows) |
| 00:53:03 | TheSeven | you never access the raw nand |
| 00:53:11 | TheSeven | there's an SD card controller in between |
| 00:53:12 | audiomodder | ok |
| 00:53:29 | TheSeven | by connecting these unbricking pins you just make the player unhide its firmware partition |
| 00:53:39 | audiomodder | ahhh i see |
| 00:54:13 | TheSeven | so as long as the firmware boots, or the SD controller doesn't respond at all (4MB/32MB mode), there's little point in doing so |
| 00:54:16 | bertrik | IIRC, it has 2 copies of the firmware image in the first 30 or 32 MB |
| 00:54:27 | audiomodder | so by doing my format I deleted my own firmware and bricked it? |
| 00:54:39 | audiomodder | interesting |
| 00:54:44 | TheSeven | if you did that after unhiding the firmware, quite possibly |
| 00:54:52 | TheSeven | in that case i'd expect it to always boot into this mode now |
| 00:55:03 | TheSeven | so it might be recoverable if you have an image |
| 00:55:18 | TheSeven | which player is the one that you formatted this way? |
| 00:55:18 | audiomodder | i do have an image |
| 00:55:31 | audiomodder | and yes it boots into this mode now, with 3.69GB memory |
| 00:55:37 | audiomodder | this is Player 1 |
| 00:55:50 | audiomodder | how to I flash the image in this mode? |
| 00:56:21 | bertrik | oh, so there is a 4 MB, 32 MB and now a ~4 GB bricked mode? |
| 00:56:26 | | Join fs-bluebot [0] (~fs-bluebo@g224239084.adsl.alicedsl.de) |
| 00:56:27 | audiomodder | yes |
| 00:56:56 | audiomodder | Player 1 is a 4GB bricked on (I reformatted in recovery mode before talked to you) |
| 00:57:13 | | Quit the-kyle (Remote host closed the connection) |
| 00:57:27 | audiomodder | Player 2 is a 4MB mode, havent shorted pins yet |
| 00:58:36 | audiomodder | I also have a player 3 in 32MB mode (I tried swapping the internal SD chip, apparently unsuccessfully) |
| 00:58:40 | bertrik | audiomodder: it's all very vague. The people who managed to unbrick it, if any, didn't really document it |
| 00:59:00 | audiomodder | that sucks |
| 00:59:07 | audiomodder | I saw this: http://forums.rockbox.org/index.php?topic=29097.0 |
| 00:59:09 | bertrik | I'd try dd'ing a clppa.bin image to the 4GB one |
| 00:59:18 | audiomodder | user "Darko" said they would document it |
| 00:59:36 | bertrik | the 4 MB mode may just expose the (D)RAM and not access the flash at all |
| 00:59:56 | | Join the-kyle [0] (~kyle@kyle.tk) |
| 01:00 |
| 01:00:11 | audiomodder | unfortunately the 4GB wont format |
| 01:00:33 | audiomodder | I can get it to format sometimes by creating partitions on it, and making a small partition that seems to work |
| 01:00:46 | audiomodder | but the full 4GB wont complete a format :/ |
| 01:01:48 | bertrik | I think trying to format is no use at this stage |
| 01:02:23 | audiomodder | yeah, so how do I put clppa.bin on it then> |
| 01:02:44 | TheSeven | audiomodder: if player 1 still shows something on the display after rebooting, you haven't actually managed to corrupt the firmware |
| 01:02:56 | bertrik | with dd, it's like writing raw sectors to it |
| 01:03:19 | bertrik | careful, dd to the wrong device can screw up your HDD contents |
| 01:03:30 | audiomodder | lol Im such a n00b, I thought you meant :download" |
| 01:03:47 | audiomodder | TheSeven: there is no display now :'( I should have come here first |
| 01:03:57 | audiomodder | <<< face palm for not following inst. |
| 01:04:17 | TheSeven | in that case, you'll probably have to write the raw firmware image to it |
| 01:04:25 | audiomodder | HOWEVER, Player 1 did format!! |
| 01:04:35 | TheSeven | if that works, it should be back to where it was before |
| 01:04:37 | audiomodder | to FAT16 successfully |
| 01:04:52 | audiomodder | how do I write raw firmware image to it? |
| 01:04:57 | audiomodder | what is "dd"? |
| 01:05:18 | TheSeven | that's nonsense. it won't expect any partitioning/formatting in this mode. you only need to format the data partition of the flash, and that needs to be FAT32 |
| 01:05:24 | TheSeven | dd is a linux "disk dump" tool |
| 01:05:34 | TheSeven | you can probably use something like rawwrite for windows instead |
| 01:05:54 | audiomodder | So the clip+ does not work with FAT16? |
| 01:06:07 | audiomodder | OK Ill try FAT32 |
| 01:06:08 | TheSeven | rockbox doesn't work with fat16 as far as I know |
| 01:06:12 | TheSeven | not sure about the original firmware |
| 01:06:29 | TheSeven | but if it has no display at all, formatting won't help at this point (only after recovering the corrupted firmware) |
| 01:06:47 | TheSeven | bertrik: does clppa.bin just need to be written to the first sectors of the internal SD? |
| 01:07:22 | bertrik | yes I think so, but that's just an educated guess |
| 01:07:28 | bertrik | bed time for me |
| 01:07:53 | audiomodder | thanks for your help bertrik |
| 01:07:57 | TheSeven | well, you guess is at least more educated than mine :) |
| 01:08:08 | audiomodder | I just downloaded RawWrite for WIndows. |
| 01:08:16 | audiomodder | on startup is says "no floppy found: |
| 01:08:47 | audiomodder | and it wont let me select the Sansa drive |
| 01:08:50 | TheSeven | hm, yes, seems like that one can only do floppys |
| 01:08:51 | bertrik | just be careful you don't accidentally write to your harddisk |
| 01:08:56 | TheSeven | they did also make a dd tool though |
| 01:08:57 | audiomodder | do you know another program for windows that does this? |
| 01:09:25 | TheSeven | http://www.chrysocome.net/dd (from the same developer), but it's a command line tool |
| 01:09:35 | audiomodder | ah found it |
| 01:09:41 | TheSeven | http://sourceforge.net/projects/win32diskimager/ might be easier to use |
| 01:09:47 | audiomodder | nice just clicked on that link |
| 01:10:11 | audiomodder | ok ill try that one |
| 01:11:48 | audiomodder | OK I installed it and have it read to write |
| 01:11:57 | audiomodder | do I select MD5 Hash? |
| 01:13:07 | TheSeven | no |
| 01:13:19 | TheSeven | just select clppa.bin and the correct drive, then click write |
| 01:13:35 | audiomodder | ok |
| 01:14:05 | TheSeven | then safely eject the USB drive if possible, then power down the player |
| 01:14:13 | TheSeven | (10 second press on the power button) |
| 01:14:36 | TheSeven | if everything worked, it should boot back up normally (and possibly complain about formatting problems) after powering it back on |
| 01:16:16 | audiomodder | sweeeet!! |
| 01:16:22 | audiomodder | yeah it says FAT is corrupted again now |
| 01:16:33 | TheSeven | wow, we should probably document that this does indeed work ;) |
| 01:16:52 | | Quit bertrik (Remote host closed the connection) |
| 01:17:13 | audiomodder | yeah that would be good |
| 01:17:30 | audiomodder | so what do I do now? |
| 01:18:06 | audiomodder | diskmgmnt shows 3.69GB RAW again |
| 01:18:24 | audiomodder | display works and shows as connected |
| 01:26:14 | | Quit audiomodder (Quit: Page closed) |
| 01:26:33 | | Join audiomodder [0] (ac0215fb@gateway/web/freenode/ip.172.2.21.251) |
| 01:26:37 | audiomodder | hello? |
| 01:30:35 | audiomodder | TheSeven you are my only hope heh |
| 01:31:50 | TheSeven | audiomodder: try formatting that as fat32 |
| 01:31:57 | | Quit K1773R (Ping timeout: 260 seconds) |
| 01:32:15 | TheSeven | or, if that doesn't work for some reason, delete the partition in diskmgmt.msc, recreate it, and format it again |
| 01:33:47 | audiomodder | wow, it worked this time |
| 01:33:58 | audiomodder | I guess recovery mode was the right way to go |
| 01:34:30 | audiomodder | I put clppa.bin on it but when I uplug from PC it still says "FAT corrupted" :/ |
| 01:35:59 | audiomodder | any ideas how to get it to write the firmware now? the internal SD appears good now |
| 01:36:07 | * | TheSeven is confused |
| 01:36:26 | TheSeven | what exactly did you do now? |
| 01:37:07 | audiomodder | formatted FAT 32 |
| 01:37:14 | audiomodder | safely disconnect |
| 01:37:21 | audiomodder | and it reboots and says FAT corrupted |
| 01:37:38 | audiomodder | oh I put clppa.bin in the root before disconnect |
| 01:37:59 | TheSeven | ok, so not using win32diskimager or anything? good. |
| 01:38:07 | TheSeven | hm, not sure why it doesn't like the FAT |
| 01:38:17 | TheSeven | try completely deleting and recreating the partition |
| 01:38:32 | audiomodder | still fat32? |
| 01:38:48 | TheSeven | if that also doesn't help, check with sandisk support if there's anything special you need to do to format these (maybe they have a tool for that on their site?) |
| 01:38:49 | | Join K1773R [0] (~K1773R@unaffiliated/k1773r) |
| 01:38:50 | TheSeven | yes |
| 01:40:06 | audiomodder | maybe it needs a long format? |
| 01:40:17 | TheSeven | a quick format should be sufficient |
| 01:40:49 | audiomodder | oh holy crap batman! |
| 01:40:53 | audiomodder | it worked now!! |
| 01:41:00 | TheSeven | who'd have thought ;) |
| 01:41:03 | | Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) |
| 01:41:03 | audiomodder | <<<is a true believer |
| 01:41:16 | audiomodder | oh man youre my hero |
| 01:41:30 | TheSeven | well, this last step is probably everything that was needed to be done in the first place |
| 01:41:55 | audiomodder | so basically recover mode > reformat > diskwrite firmware > format FAT32 > install firmare |
| 01:41:59 | audiomodder | no it wasnt at all |
| 01:42:11 | audiomodder | formats didnt work before I did the long format in recovery mode |
| 01:42:23 | audiomodder | windows *hated* that internal SD |
| 01:42:32 | TheSeven | the "delete and recreate partition, format fat32" was probably everything that was necessary |
| 01:42:36 | TheSeven | how exactly did the formats fail? |
| 01:43:01 | audiomodder | it just kept saying "windows unable to complete the format" |
| 01:43:20 | audiomodder | Im pretty sure I tried deleting the partition too |
| 01:43:22 | audiomodder | maybe not |
| 01:43:36 | audiomodder | *shrug* Im glad I learned how the recovery mode works though! |
| 01:43:38 | TheSeven | weird, but I'm happy that it works again :) |
| 01:43:57 | audiomodder | hopefully I can get another one working with the new things Ive learned today too :) |
| 01:44:09 | audiomodder | I have 3 dead ones still lol |
| 01:44:27 | audiomodder | Im gonna swap the internal SD chip back onto Player 3 and do recovery |
| 01:44:32 | audiomodder | er, what we just did |
| 01:44:50 | audiomodder | the other 2 say 32MB and 4MB, so they are totally dead, no>? |
| 01:44:51 | TheSeven | that's only going to work if it appears with its full capacity |
| 01:44:58 | audiomodder | gotcha |
| 01:45:02 | TheSeven | quite likely, yes |
| 01:45:08 | audiomodder | ah thats a shame |
| 01:45:10 | TheSeven | we don't know what exactly is dead though |
| 01:45:10 | audiomodder | parts bin |
| 01:45:15 | TheSeven | either the flash chip, or the data on it |
| 01:45:30 | audiomodder | interesting |
| 01:45:44 | audiomodder | is there a way I can write this up |
| 01:45:44 | TheSeven | there are some internal data structures for the wear leveling and bad block management, if those get screwed up, it could be possible for it to fail that way |
| 01:45:57 | audiomodder | or someone else to do that? I think this info could help ppl |
| 01:46:12 | audiomodder | interesting |
| 01:46:23 | audiomodder | yeah I tried recover mode on player 2, still 4MB :/ |
| 01:46:30 | audiomodder | but Im so happy this one is working |
| 01:46:41 | audiomodder | that means spendign the $$$ on broken players was worth it after all! :) |
| 01:47:03 | TheSeven | so if you have a flash chip from a player that works (or at least ends up in the full capacity recovery mode), and one from a 4/32MB one with identical internal geometry, cloning an image from one to the other might possibly help |
| 01:47:13 | TheSeven | but you need a raw nand programmer to do that |
| 01:47:26 | TheSeven | and you'll probably have to quite some research on these things |
| 01:47:32 | audiomodder | oic |
| 01:47:37 | audiomodder | that sounds complex |
| 01:47:46 | audiomodder | i dont even know what a raw nand programmer is |
| 01:48:03 | TheSeven | then you can probably consider those devices dead |
| 01:48:40 | TheSeven | (for the record, I once had a sandisk microsd card which showed similar behavior: 32MB capacity after being flaky for a while) |
| 01:49:09 | TheSeven | (sandisk said that's clearly an RMA case, not fixable by the end user, so I got a replacement card) |
| 01:49:21 | audiomodder | oh interesting |
| 01:49:23 | audiomodder | thats good to know |
| 01:49:27 | audiomodder | i can still use the parts |
| 01:49:32 | audiomodder | headphone port, battery and all that |
| 01:49:43 | audiomodder | plus the buttons break with water damage and all that |
| 01:49:51 | TheSeven | (they also said that this was a rather common issue with that generation of cards, and wouldn't happen again with the replacement card) |
| 01:49:56 | audiomodder | ive fixed these before swapping that kinda stuff |
| 01:50:02 | audiomodder | interesting |
| 01:50:10 | audiomodder | i learned the hard way to not buy SD cards on ebay |
| 01:50:13 | audiomodder | they all did crap like that |
| 01:50:22 | TheSeven | so this kinda reminds me of Samsung's eMMC "SuperBrick" bug |
| 01:50:42 | TheSeven | so it might after all be a firmware bug of SanDisk SD cards |
| 01:51:11 | TheSeven | which in turn means it's quite likely that the SD controller in these devices could have similar bugs |
| 01:51:43 | audiomodder | interesting |
| 01:51:46 | audiomodder | i love these things tho |
| 01:51:51 | audiomodder | when I show them to people |
| 01:51:54 | audiomodder | their eyes go wide |
| 01:52:13 | audiomodder | they dont understand how it can have a built in radio and voice recorder in addition to the player |
| 01:52:20 | audiomodder | so many people stuck on the apple stuff |
| 01:55:56 | | Join adnap [0] (~adnap@cpe-24-28-68-235.austin.res.rr.com) |
| 01:56:55 | adnap | Can Rockbox for Android play from a URL? If not, does anyone know a good app that does this? |
| 01:57:25 | alexbobp | I use MX Player for handling video files and streams. (warning, free version is ad supported) |
| 01:57:27 | scorche|sh | rockbox does not - any other app would be off-topic for this channel... |
| 01:57:47 | alexbobp | scorche|sh: wait so are you saying if someone knows a useful thing to recommend it's not ok to say it? |
| 01:58:02 | alexbobp | adnap: and a free app just for streams is servestream |
| 01:58:12 | scorche|sh | alexbobp: this channel is for the discussion of rockbox - not for other items |
| 01:58:30 | scorche|sh | alexbobp: feel free to join another channel to talk about other subjects or even send a PM... |
| 01:58:36 | audiomodder | well hopefully this info gets written up somewhere |
| 01:58:52 | alexbobp | it was just a short answer to one question and the question did involve rockbox. it's over now, don't worry |
| 01:58:57 | audiomodder | for the recovery mode sansa stuff i mean |
| 02:00 |
| 02:03:22 | | Quit ZincAlloy (Quit: Leaving.) |
| 02:18:00 | *** | Saving seen data "./dancer.seen" |
| 02:21:31 | audiomodder | TheSeven, are you there? |
| 02:22:03 | audiomodder | Just wanted to let you know that the recovery mode format really seems to be what saved it |
| 02:22:22 | audiomodder | I swaped the internal SD back into player 3 and it wont format or delete the partition (its 8GB) |
| 02:22:44 | audiomodder | so I think the recovery mode format is key to saving some of these bricked players (if you do a write-up) |
| 02:27:29 | JdGordon | soap: re your forum thread about random foder advance |
| 02:31:18 | | Join ygrek [0] (~user@108.59.6.97) |
| 02:38:05 | audiomodder | OK I posted the info from earlier today here: http://forums.rockbox.org/index.php/topic,29097.0.html |
| 02:38:59 | | Quit babylonlurker (Ping timeout: 252 seconds) |
| 02:52:03 | | Quit audiomodder (Quit: Page closed) |
| 02:54:15 | soap | JdGordon, yea, what's up |
| 02:54:45 | JdGordon | oh, was just saying you should have asked in here, could have had it done over the weekend :) |
| 02:55:09 | soap | lol. |
| 02:55:31 | soap | What you mention in the thread sounds fine. This would be a plugin modification? |
| 02:56:14 | soap | and taking the weight from the parent folder is one of those important little things which makes it so much easier to manage in a large collection I didn't think of. |
| 02:57:35 | JdGordon | my plan is to fix it all so the code handles the current style and the new style so you'd only need to regen if you want to add the weights |
| 02:57:48 | JdGordon | should be pretty simple |
| 02:59:59 | | Quit AlexP (Remote host closed the connection) |
| 03:00 |
| 03:09:50 | soap | cool |
| 03:10:25 | | Quit ygrek (Ping timeout: 260 seconds) |
| 03:29:42 | | Join toehser [0] (~tom@Connqueror.Toms.NET) |
| 03:53:12 | | Join ygrek [0] (~user@108.59.6.97) |
| 04:00 |
| 04:03:25 | | Part toehser |
| 04:06:17 | | Join Strife89 [0] (~Strife89@adsl-98-80-200-248.mcn.bellsouth.net) |
| 04:15:27 | | Quit K1773R (Ping timeout: 252 seconds) |
| 04:18:02 | *** | Saving seen data "./dancer.seen" |
| 04:20:22 | | Join K1773R [0] (~K1773R@unaffiliated/k1773r) |
| 04:28:15 | | Quit amiconn (Disconnected by services) |
| 04:28:15 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:28:18 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 04:29:05 | | Quit pixelma (Disconnected by services) |
| 04:29:06 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:29:08 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 04:40:16 | [Saint] | JdGordon: regarding the multi-AA patch, tested and working fine, however...I think we can get away with this change without breaking any existing themes, or creating any new tags. |
| 04:41:02 | [Saint] | The way I see it happening is that %Cl "Just Works", if the theme only contains a single declaration - nothing changes. But the author should also have the option of using %Cl with an ident. |
| 04:41:20 | [Saint] | (this makes the code a lot more sonsistent with the way image and viewport preloads work) |
| 04:41:24 | [Saint] | *consistent |
| 04:43:34 | [Saint] | %Cl(ident, x,y,w,h,x-align,y-align) + %Cd(ident) |
| 04:43:54 | JdGordon | 2 reasons I don't want to do that |
| 04:44:25 | JdGordon | 1) Using the new tag alows me to change when the image is drawn (i.e imeeditably instead of at the end of the viewport, allows you to better control overlapping images) |
| 04:44:41 | JdGordon | 2) adding the extra optinoal ident is seriously messy in the parsing code |
| 04:44:42 | [Saint] | *inconsistent control ;) |
| 04:45:22 | JdGordon | I've always hated how the images are batch drawn at the end of each viewport |
| 04:45:24 | [Saint] | Ideally, I would like this to work the same as any other preloaded item. |
| 04:45:45 | [Saint] | And, to be perfectly honest, I think adding a new tag for this is confusing and overkill. |
| 04:45:52 | [Saint] | but, meh. |
| 04:46:45 | JdGordon | the issue is (like I keep saying but havnt looked into coding yet) next track images, and alternate images... *front*, *back*, etc |
| 04:46:48 | [Saint] | If it was done this way the theme code could be a _lot_ cleaner. |
| 04:47:03 | JdGordon | 2 tags is cleaner than 1? |
| 04:47:07 | [Saint] | AA could be preloaded just the same as images or condiditional viewports. |
| 04:47:14 | [Saint] | And wouldn;t be ties to a particular viewport. |
| 04:47:44 | [Saint] | And, 2 tags isn't necessary cleaner...no, but it is *consistent*. |
| 04:47:54 | JdGordon | it doesnt make a difference, each dimension is only loaded once |
| 04:48:27 | JdGordon | the new tag doesnt care about the viewport also |
| 04:48:50 | [Saint] | Oh - joy <rolleyes> ;) |
| 04:49:06 | JdGordon | ? |
| 04:49:12 | [Saint] | So, it could be contained in a viewport, but, not give a fuck about it...? Yay consuistency! :) |
| 04:49:40 | JdGordon | it is drawn in the viewport as usual, and rendered with the viewport |
| 04:50:02 | JdGordon | %Cl/%Cd is really not required |
| 04:50:21 | JdGordon | it may end up being required once I fix %C for this though |
| 04:50:31 | JdGordon | err, idents might be required |
| 04:50:59 | JdGordon | I would have thought you prefer knowing for sure in what order images are drawn? |
| 04:51:11 | JdGordon | in relatio to the rest of the viewport, all text and images in it? |
| 04:52:18 | JdGordon | im going for lunch, back in 20 |
| 04:52:30 | [Saint] | Perhaps I misparsed your statement, I would find it very confusing if the AA call came after a viewport declaration, but was still able to draw in the fullscreen viewport. |
| 04:52:57 | [Saint] | ANd, ultimately, I'm easy - but I do think that having it use idents would be a lot nicer for a few ways. |
| 04:54:35 | [Saint] | Knowing when the image will be drawn isn't ultimately that important IMO as you can already send things to the backdrop buffer anyway. |
| 05:00 |
| 05:05:56 | | Quit steffengy (Disconnected by services) |
| 05:05:57 | | Join steffengy1 [0] (~quassel@p57B498F8.dip0.t-ipconnect.de) |
| 05:10:38 | JdGordon | [Saint]: no, x,y are viewport relative (just as they are now) |
| 05:11:18 | [Saint] | Theh I guess I have NFI what "<JdGordon> the new tag doesnt care about the viewport also" meant. |
| 05:12:06 | JdGordon | That was in reply to you saying "<[Saint]> And wouldn;t be ties to a particular viewport." ... they arent |
| 05:12:54 | JdGordon | maybe its a misunderstanding somewhere |
| 05:13:37 | JdGordon | if you have %Xd(anything, anything, 100, 100, anything, anything) 45 times in your wps it will still only load the image on the buffer once |
| 05:13:43 | JdGordon | so it doesnt matter about idents |
| 05:14:49 | [Saint] | Hmmm...so I guess my bef simply boils down to consistency then. |
| 05:14:51 | JdGordon | also, imo your ideal situation is broken (with images also). the image size should be linked with the preload but he image position should be on the display tag, %xd(ident) really is wierd |
| 05:14:54 | [Saint] | *beef |
| 05:16:12 | JdGordon | this works with images because they are almost always only displayed in one place |
| 05:17:00 | [Saint] | I don't think the display tag has any business in governing the position, personally. |
| 05:17:09 | [Saint] | That's (historically) for the preload call. |
| 05:17:22 | JdGordon | indeed.. an accident of history imo |
| 05:18:07 | JdGordon | that last commit about reusing image buffers owuldnt be neseccary if this wasnt the case |
| 05:18:18 | [Saint] | Well, changing that is a massive, skin breaking change, and doing AA any other way adds yet another confusing aspect where elements need to be handled completely differently to their entirely similar counterpart tags. |
| 05:18:33 | [Saint] | %Cd shouldn't, in theory, be any different to %xd |
| 05:18:47 | JdGordon | which is why I've gone a new tag |
| 05:18:55 | JdGordon | but this isnt final yet so dont worry :) |
| 05:19:08 | [Saint] | that's just putting lipstick on a pig, though. ;) |
| 05:30:00 | | Join Noctem [0] (~mel@ool-457ad527.dyn.optonline.net) |
| 05:43:28 | | Quit TheSeven (Ping timeout: 264 seconds) |
| 05:45:09 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 05:59:54 | | Join steffengy [0] (~quassel@p5088FF6A.dip0.t-ipconnect.de) |
| 06:00 |
| 06:03:07 | | Quit steffengy1 (Ping timeout: 260 seconds) |
| 06:03:42 | | Quit Noctem (Quit: Konversation terminated!) |
| 06:03:57 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 06:05:49 | | Join us`0gb [0] (~0gb.us@c-71-237-219-28.hsd1.or.comcast.net) |
| 06:18:04 | *** | Saving seen data "./dancer.seen" |
| 06:18:54 | | Quit Unhelpful (Ping timeout: 240 seconds) |
| 06:29:31 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
| 06:31:36 | | Join ungali [0] (~ungali@184.64.50.234) |
| 06:31:36 | | Quit ungali (Changing host) |
| 06:31:36 | | Join ungali [0] (~ungali@unaffiliated/ungali) |
| 06:39:08 | | Join tertu [0] (~tertu@184-97-163-186.mpls.qwest.net) |
| 06:48:57 | | Quit pamaury (Ping timeout: 276 seconds) |
| 07:00 |
| 07:00:31 | | Quit tertu (Ping timeout: 260 seconds) |
| 07:11:40 | | Join GodEater [0] (~whoknows@94.3.60.123) |
| 07:11:40 | | Quit GodEater (Changing host) |
| 07:11:40 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 07:12:11 | | Join Provel [0] (~Provel@75-132-32-77.dhcp.stls.mo.charter.com) |
| 07:19:46 | | Quit jhMikeS (Ping timeout: 245 seconds) |
| 07:29:46 | | Quit ungali (Ping timeout: 245 seconds) |
| 07:29:55 | | Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) |
| 07:30:57 | | Quit JdGordon (Ping timeout: 240 seconds) |
| 07:31:28 | | Join tertu [0] (~tertu@184-97-163-186.mpls.qwest.net) |
| 07:32:50 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 07:40:52 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 07:42:23 | | Join mortalis [0] (~kvirc@213.33.220.118) |
| 07:44:26 | | Quit ygrek (Ping timeout: 252 seconds) |
| 08:00 |
| 08:18:05 | *** | Saving seen data "./dancer.seen" |
| 08:20:45 | | Join ygrek [0] (~user@108.59.6.97) |
| 08:21:54 | | Quit JdGordon_ (Ping timeout: 276 seconds) |
| 08:22:26 | | Join ygrek_ [0] (~user@108.59.6.97) |
| 08:25:17 | | Quit ygrek (Ping timeout: 240 seconds) |
| 08:30:00 | | Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.200.73) |
| 08:40:31 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:47:57 | | Quit fragilematter (Quit: Leaving.) |
| 09:00 |
| 09:00:16 | | Quit tertu (Quit: Leaving) |
| 09:04:00 | | Quit Geoff_ (Ping timeout: 252 seconds) |
| 09:04:06 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 09:08:47 | | Join Geoff_ [0] (~qua@192.3.27.126) |
| 09:10:15 | | Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) |
| 09:12:57 | | Quit Geoff_ (Ping timeout: 240 seconds) |
| 09:17:35 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:22:19 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 09:22:31 | | Quit user890104 (Quit: .) |
| 09:23:40 | | Join user890104 [0] (Venci@unaffiliated/user890104) |
| 09:25:02 | | Quit user890104 (Client Quit) |
| 09:26:10 | | Join user890104 [0] (Venci@unaffiliated/user890104) |
| 09:43:50 | | Quit adnap (Read error: Connection reset by peer) |
| 09:44:26 | | Join adnap [0] (~adnap@cpe-24-28-68-235.austin.res.rr.com) |
| 09:50:39 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 10:00 |
| 10:07:18 | TheSeven | what should we do about this? http://forums.rockbox.org/index.php/topic,29097.msg228611.html#msg228611 |
| 10:07:30 | TheSeven | I think these instructions are potentially dangerous and mostly pointless |
| 10:08:07 | TheSeven | it's mostly a "how I managed to fuck it up even more, and then recover it" story |
| 10:09:37 | wodz | imo we should delete this as potentially harmful |
| 10:09:52 | wodz | this will rise criticism though |
| 10:10:30 | TheSeven | I think that it needs some more disclaimers and warnings at the very least, and should probably be moved to the wiki |
| 10:10:43 | TheSeven | i.e. extend the AMS unbrick page |
| 10:11:20 | TheSeven | the important information is: "yes, writing clppa.bin to sector 0 of a non-booting player showing the full capacity does work, at least sometimes" |
| 10:11:46 | TheSeven | and I'm a bit puzzled why he had trouble formatting the player before doing that recovery mode mess |
| 10:14:04 | TheSeven | this "zero out the whole device in recovery mode" is something that could go into the back of our minds as a very last resort measure for otherwise non-recoverable devices |
| 10:14:06 | | Join edhelas [0] (~edhelas@2001:981:e7ba:1:863a:4bff:fe85:8a3c) |
| 10:14:08 | edhelas | hi everyone :) |
| 10:14:15 | TheSeven | but I wouldn't like to have that on the wiki |
| 10:14:57 | Nei | if all of you die it might be nice if it were written down somewhere |
| 10:15:48 | wodz | the truth is that without proper understanding how *exactly* amsv2 boots this is pure trial and fail aproach |
| 10:15:49 | edhelas | I'll put a compactflash card in my iPod Mini soon, any known issues with rockbox ? |
| 10:16:47 | TheSeven | actually I think that everything relevant is contained already in http://forums.rockbox.org/index.php/topic,29115 |
| 10:16:53 | wodz | edhelas: not that I know of. General advice is to use good cards from established brands rather then nonames |
| 10:16:56 | TheSeven | so that other post should probably just go away |
| 10:18:08 | *** | Saving seen data "./dancer.seen" |
| 10:18:22 | edhelas | wodz, I'll buy this http://www.delock.com/produkte/F_277_Adapter_61795/merkmale.html?setLanguage=en with a Kingston SDHC card |
| 10:18:49 | edhelas | I've seen that it support IDE stuffs |
| 10:20:00 | TheSeven | while they typically should (and it might be fixable in software if they don't), these things are by no means guaranteed to work with ipods and rockbox |
| 10:20:07 | wodz | eee, wait you are talking about cf<->sd converter. That is not the same as CF itself. |
| 10:20:11 | TheSeven | we've had some cases, especially on ipod classics though, where they didn't |
| 10:20:26 | edhelas | wodz, yeah I know |
| 10:20:58 | edhelas | http://forums.rockbox.org/index.php?topic=48240.0 someone already tried this brand here |
| 10:20:59 | wodz | edhelas: we had reports of failing diferent something<->sd converters in the past |
| 10:21:56 | wodz | edhelas: so basically no guarantee while I can say based on my personal experience that regular CF just works |
| 10:22:21 | edhelas | ok :) I'll try and give you a feedback |
| 10:25:42 | | Quit mc2739 (Ping timeout: 265 seconds) |
| 10:27:07 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 10:30:40 | | Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) |
| 10:35:28 | edhelas | wodz, http://www.tarkan.info/20121226/tutorials/ipod-and-sdhc-sdxc-cards some guys have successfully used this brand adapter in their iPod :) |
| 10:41:38 | wodz | edhelas: I am not saying it doesn't work. I just say that while regular CFs have been tested by many, various adapters not |
| 10:42:38 | | Quit einhirn (Ping timeout: 252 seconds) |
| 10:43:35 | edhelas | ok :) |
| 10:43:50 | TheSeven | edhelas: with those tarkan adapters in particular we have some trouble on ipod classics |
| 10:43:56 | TheSeven | only with SD cards from some brands though |
| 10:44:29 | TheSeven | the good news is that tarkan himself appeared in #freemyipod-support and tried to help debug these issues |
| 10:44:49 | TheSeven | (I hope he'll come back one day with bus traces of what's happening) |
| 10:44:54 | wodz | TheSeven: really? Thats unusual |
| 10:45:19 | TheSeven | yeah he said he has equipment to actually capture what's going on on the ata pins to see who's at fault here |
| 10:46:15 | copper | Lexar cards work for some reason, SanDisk cards don't |
| 10:46:20 | TheSeven | I think one of his customers pulled him into our channel ;) |
| 10:46:47 | edhelas | :) |
| 10:46:51 | edhelas | it's nice |
| 10:47:06 | copper | edhelas: also, battery life with my adapter from Tarkan was abysmal, but I couldn't be arsed to debug it either |
| 10:47:30 | TheSeven | I think there are several people with tarkan adapters without battery issues though |
| 10:47:33 | copper | TheSeven: my adapter is on its way to your mailbox |
| 10:47:37 | edhelas | on your ipod mini ? |
| 10:47:51 | TheSeven | so I guess that there was something wrong with this particular adapter or even adapter-card combination |
| 10:47:54 | copper | I posted it yesterday |
| 10:47:55 | TheSeven | copper: thanks :) |
| 10:48:12 | TheSeven | edhelas: that was on a classic |
| 10:48:29 | edhelas | ok :) |
| 10:49:00 | copper | TheSeven: btw, amazon refunded me before my Lexar card even left the post office |
| 10:49:02 | TheSeven | it's quite likely that the pre-classic ipods are a bit less picky |
| 10:49:07 | TheSeven | wow |
| 10:49:25 | copper | the full 110 euros |
| 10:49:29 | wodz | copper: As I said earlier - the power to hdd is hw cut when not in use so it would need to consume HUGE amount when active to see the difference |
| 10:49:52 | copper | well it will be in the hands of TheSeven |
| 10:50:17 | gevaerts | wodz: is it really cut? |
| 10:50:38 | * | gevaerts is surprised by that |
| 10:50:56 | TheSeven | gevaerts: how does ARC handle enabling of ep>0? I'm having trouble finding a suitable spot in my new driver |
| 10:51:04 | wodz | gevaerts: ask TheSeven but judging from code we mess with PMU for that |
| 10:51:05 | copper | TheSeven: keep the adapter whether you "fix" it or not, I'm done with my iPod |
| 10:52:02 | wodz | gevaerts: anyway what is so surprising? On older hardware (irivers, mpios) the power line for hdd goes through mos just for that |
| 10:52:03 | copper | though it'd be nice for future customers of Tarkan's if you guys could figure it out |
| 10:52:07 | TheSeven | yes, there's a boost-buck converter in the PMU that provides 3.3V for the HDD, which we're shutting off (apple as well) while the disk isn't "spinning" |
| 10:52:59 | | Nick JdGordon| is now known as JdGordon (~jonno@rockbox/developer/JdGordon) |
| 10:53:30 | TheSeven | gevaerts: the only place that I could set is in usb_drv_recv |
| 10:53:40 | TheSeven | that's a bit nasty though |
| 10:54:01 | TheSeven | or in usb_drv_cancel_all_transfers, which is even more counter-intuitive |
| 10:54:48 | wodz | TheSeven: usb_drv_request_endpoint() ? |
| 10:55:02 | gevaerts | TheSeven: it keeps an array of endpoint allocations (called "endpoints") which is filled by usb_drv_request_endpoint(). This array is then used by init_queue_heads() and init_endpoints() to set up the hardware. Those are called by usb_drv_set_address() |
| 10:55:08 | TheSeven | wodz: that happens *before* usb_cancel_all_transfers, which will take them down again |
| 10:55:52 | TheSeven | gevaerts: that implies that your cancel_all_transfers implementation doesn't actually disable the endpoints |
| 10:56:03 | TheSeven | well, maybe I should just leave all of them activated all the time |
| 10:56:15 | gevaerts | Does it have to? |
| 10:56:25 | gevaerts | It needs to stop transfers in progress |
| 10:56:47 | wodz | TheSeven: cancel_all_transfers should kill the ongoing transfers not deactivate endpoints imo |
| 10:57:39 | TheSeven | well, as long as we don't have to deal with multiple configurations, we can probably get away without ever disabling endpoints |
| 10:58:25 | * | gevaerts isn't sure if anyone actually ever implemented support for multiple configurations in a host stack |
| 10:58:41 | TheSeven | linux definitely supports that |
| 10:59:11 | gevaerts | How does it decide which one to pick? |
| 11:00 |
| 11:00:34 | TheSeven | it picks the first available, unless something higher level instructs it to pick another one |
| 11:00:47 | * | gevaerts nods |
| 11:00:54 | TheSeven | from e.g. libusb you can just do a set_configuration(index) to switch to a different one on the fly |
| 11:01:13 | gevaerts | The thing is that "something higher level" has to know about the specific device |
| 11:01:27 | gevaerts | Which won't be true for MSC I strongly suspect! |
| 11:01:56 | TheSeven | I'm just saying that the host stack can do it ;) |
| 11:02:25 | gevaerts | Yes, I'll admit I was wrong :) |
| 11:15:21 | * | TheSeven crosses fingers :) |
| 11:17:47 | | Quit us`0gb (Quit: http://0gb.us/) |
| 11:18:17 | TheSeven | hm, something keeps stalling EP1 IN for some reason |
| 11:23:09 | TheSeven | race condition :/ |
| 11:31:00 | | Join ZincAlloy [0] (~Adium@pD9EEA44E.dip0.t-ipconnect.de) |
| 11:34:19 | TheSeven | steffengy: around? |
| 11:43:05 | TheSeven | hm... we're getting close :) |
| 11:54:00 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 11:54:25 | TheSeven | ok, the current situation is this: |
| 11:54:36 | TheSeven | mass storage alone seems to work on linux at the first glance |
| 11:54:50 | TheSeven | haven't tested it extensively yet |
| 11:54:58 | TheSeven | hid however fails |
| 11:55:30 | TheSeven | the ipod stops responding to anything on EP0 after sending the first GET DESCRIPTOR RPIPE response |
| 11:55:56 | TheSeven | on EP1 it sends an ACK for the first CBW, but never returns a CSW |
| 11:56:16 | TheSeven | the kernel itself seems to be still alive at this point, it dies a few seconds later when the host issues a bus reset |
| 11:58:02 | TheSeven | if I disconnect it before that bus reset, we run into what looks like a lockup of the USB thread |
| 11:58:21 | TheSeven | which is a bit odd as disconnecting should cause a bus reset IRQ as well |
| 11:58:30 | TheSeven | so whatever locks up the kernel must be happening a bit later |
| 12:00 |
| 12:18:09 | *** | Saving seen data "./dancer.seen" |
| 12:40:37 | | Quit ygrek_ (Ping timeout: 240 seconds) |
| 12:53:59 | JdGordon | does anyone use the random folder advance thing? |
| 12:55:54 | | Join Misanthropos [0] (~Misanthro@frnk-4d010aae.pool.mediaWays.net) |
| 13:00 |
| 13:05:17 | | Quit pamaury (Remote host closed the connection) |
| 13:06:39 | | Quit shamus (Ping timeout: 265 seconds) |
| 13:07:20 | | Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) |
| 13:14:28 | | Quit Guest81512 (Ping timeout: 265 seconds) |
| 13:14:28 | | Join Guest70275 [0] (~Slayer@c-69-143-187-144.hsd1.va.comcast.net) |
| 13:14:28 | | Quit ender| (Ping timeout: 265 seconds) |
| 13:14:45 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 13:15:34 | | Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) |
| 13:17:18 | | Quit Zagor (Ping timeout: 265 seconds) |
| 13:18:47 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 13:19:45 | | Quit kugel (Remote host closed the connection) |
| 13:19:52 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 13:19:59 | | Join Rower [0] (husvagn@78.70.32.176) |
| 13:20:11 | | Quit knittl (Ping timeout: 265 seconds) |
| 13:20:53 | | Join knittl [0] (~knittl@unaffiliated/knittl) |
| 13:24:32 | | Quit Rower (Ping timeout: 265 seconds) |
| 13:24:46 | | Join Rower [0] (husvagn@h176n2-aeg-a11.ias.bredband.telia.com) |
| 13:27:07 | | Join Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) |
| 13:27:42 | | Join Geoff_ [0] (~qua@192.3.27.126) |
| 13:32:04 | | Quit Xerion_ (Ping timeout: 265 seconds) |
| 13:32:04 | | Quit Guest70275 (Ping timeout: 265 seconds) |
| 13:33:29 | | Join Guest70275 [0] (~Slayer@c-69-143-187-144.hsd1.va.comcast.net) |
| 13:55:16 | | Quit mortalis (Ping timeout: 265 seconds) |
| 13:57:54 | | Quit Guest70275 (Ping timeout: 265 seconds) |
| 13:59:36 | | Join Guest70275 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) |
| 14:00 |
| 14:00:26 | | Quit kugel (Quit: Lost terminal) |
| 14:04:01 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 14:12:23 | | Quit Guest70275 (Read error: Connection reset by peer) |
| 14:12:38 | | Join Guest70275 [0] (~Slayer@c-69-143-187-144.hsd1.va.comcast.net) |
| 14:18:12 | *** | Saving seen data "./dancer.seen" |
| 14:22:40 | | Quit Guest70275 (Ping timeout: 265 seconds) |
| 14:23:13 | | Join Guest70275 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) |
| 14:24:53 | | Quit Geoff_ (Remote host closed the connection) |
| 14:48:21 | | Quit Misanthropos (Ping timeout: 265 seconds) |
| 14:49:09 | | Quit Guest70275 (Ping timeout: 265 seconds) |
| 14:52:30 | | Quit ender| (Ping timeout: 265 seconds) |
| 14:53:16 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 14:54:06 | | Join ender| [0] (~ender1@2a01:260:4094:1:42:42:42:42) |
| 15:00 |
| 15:01:38 | TheSeven | WTF |
| 15:01:59 | TheSeven | pamaury, gevaerts: seems like this USB core can only send up to 127 bytes at once on EP0 |
| 15:02:10 | TheSeven | the HID REPORT descriptor is 133 bytes |
| 15:02:17 | TheSeven | that causes a lockup during enumeration |
| 15:02:25 | pamaury | that's super weird |
| 15:02:33 | TheSeven | I'll probably have to split that thing in the driver code |
| 15:02:53 | TheSeven | the transfer size field is just 7 bits on EP0 |
| 15:03:13 | gevaerts | oh |
| 15:03:15 | gevaerts | nice |
| 15:04:32 | | Join Guest70275 [0] (~Slayer@c-69-143-187-144.hsd1.va.comcast.net) |
| 15:04:33 | pamaury | TheSeven: does the core automatically splits into packets or you have to do that ? because it the latter, you already have to cut in pieces |
| 15:04:49 | TheSeven | it seems like the core does that for all but ep0 |
| 15:05:11 | | Quit Jack87 (Ping timeout: 245 seconds) |
| 15:05:17 | | Quit Rower (Quit: Hmmm...) |
| 15:05:22 | pamaury | I alwayw knew that it was rotten to the core ;) |
| 15:06:35 | wodz | haha, what a creativity of hw designers :P |
| 15:07:04 | wodz | the contest of least expected quirk or what? |
| 15:07:47 | gevaerts | "Who ever needs more than 127 byte descriptors?" |
| 15:08:16 | wodz | gevaerts: I'd expect 640 bytes to meet everybody needs :P |
| 15:08:28 | pamaury | "software can always compensate for hardware quirks he said" |
| 15:08:38 | gevaerts | wodz: now that *would* be a reasonable size! :) |
| 15:08:57 | | Quit Zagor (Ping timeout: 265 seconds) |
| 15:09:27 | wodz | how random is sram state on power up? |
| 15:09:59 | | Join Jack87 [0] (Jack87@nasadmin/admin/jack87) |
| 15:11:05 | | Join Rower [0] (husvagn@h176n2-aeg-a11.ias.bredband.telia.com) |
| 15:11:32 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 15:12:55 | | Quit wodz (Quit: Leaving) |
| 15:23:16 | | Join model [0] (~model@cscluster.minotstateu.edu) |
| 15:40:45 | | Join Misanthropos [0] (~Misanthro@frnk-4d010aae.pool.mediaWays.net) |
| 15:41:07 | TheSeven | actually I guess this field is 7 bits in order to be able to express "64 bytes", not "127 bytes" |
| 15:42:56 | | Quit mc2739 (Ping timeout: 252 seconds) |
| 15:44:51 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 15:47:17 | | Join ygrek_ [0] (~user@108.59.6.97) |
| 15:57:50 | | Join Guest81512 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) |
| 15:58:43 | | Quit Guest70275 (Ping timeout: 265 seconds) |
| 16:00 |
| 16:04:05 | | Quit Zagor (Quit: Clint excited) |
| 16:14:01 | | Quit kugel (Quit: Lost terminal) |
| 16:18:13 | *** | Saving seen data "./dancer.seen" |
| 16:24:49 | TheSeven | ok, looks like I fixed hid to not mess with storage at least |
| 16:25:05 | TheSeven | hid itself still doesn't seem to actually do anything though |
| 16:33:06 | | Quit Strife89 (Ping timeout: 245 seconds) |
| 16:33:29 | | Quit edhelas (Remote host closed the connection) |
| 16:33:32 | | Quit TheSeven (Ping timeout: 252 seconds) |
| 16:40:45 | | Quit Misanthropos (Remote host closed the connection) |
| 16:43:25 | | Join Misanthropos [0] (~Misanthro@frnk-4d010aae.pool.mediaWays.net) |
| 16:46:36 | | Join Strife89 [0] (~Strife89@2602:306:bce1:8c20:dcde:1e23:608c:9b1e) |
| 17:00 |
| 17:04:25 | | Quit petur (Quit: *plop*) |
| 17:04:29 | | Quit prof_wolfff (Ping timeout: 240 seconds) |
| 17:17:30 | | Join prof_wolfff [0] (~prof_wolf@89.141.50.204.dyn.user.ono.com) |
| 17:36:03 | | Join baudams [0] (57db6f2e@gateway/web/freenode/ip.87.219.111.46) |
| 17:40:08 | baudams | hello, is there anyone here to assist me trying to unbrick a sansa clip+? |
| 17:40:31 | baudams | shorted the pads and it is now exposing a 30.6MiB disk which I suppose is the bootloader flash |
| 17:40:53 | baudams | the device refused to boot after 3 days left disconnected and a full day left charging |
| 17:41:11 | baudams | I tried to restart it by keeping the power button >1min, by keeping power and left, and by keeping power and home |
| 17:45:05 | | Join babylonlurker [0] (~quassel@veda.xs4all.nl) |
| 17:46:02 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 17:57:54 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 17:58:31 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 18:00 |
| 18:17:13 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
| 18:18:16 | *** | Saving seen data "./dancer.seen" |
| 18:23:47 | | Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) |
| 18:31:38 | | Join bertrik [0] (~quassel@cl-1037.haa-01.nl.sixxs.net) |
| 18:31:38 | | Quit bertrik (Changing host) |
| 18:31:38 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 18:32:40 | | Quit Beta2K (Ping timeout: 245 seconds) |
| 18:32:58 | | Join Beta2K [0] (~Beta2K@2607:f1c0:841:4eff::120) |
| 18:44:40 | | Quit bertrik (Ping timeout: 272 seconds) |
| 18:50:27 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 19:00 |
| 19:00:42 | | Quit rela (Read error: Connection reset by peer) |
| 19:25:54 | | Quit ygrek_ (Ping timeout: 240 seconds) |
| 19:28:06 | | Quit mc2739 (Ping timeout: 240 seconds) |
| 19:30:01 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 19:36:16 | | Quit baudams (Quit: Page closed) |
| 19:50:03 | | Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) |
| 19:54:28 | | Quit pamaury (Ping timeout: 252 seconds) |
| 20:00 |
| 20:18:18 | *** | Saving seen data "./dancer.seen" |
| 20:36:45 | | Quit preglow (Ping timeout: 246 seconds) |
| 20:45:56 | | Quit the-kyle (Remote host closed the connection) |
| 20:46:30 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 21:00 |
| 21:00:41 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 21:02:05 | | Quit advcomp2019 (Ping timeout: 240 seconds) |
| 21:14:05 | | Join preglow [0] (~thomj@2001:840:4243:3::100) |
| 21:19:04 | | Join Blabla [0] (1f137872@gateway/web/freenode/ip.31.19.120.114) |
| 21:19:25 | | Quit Blabla (Client Quit) |
| 21:20:02 | | Join rookie [0] (1f137872@gateway/web/freenode/ip.31.19.120.114) |
| 21:22:01 | | Quit rookie (Client Quit) |
| 21:22:23 | | Join Tortelloni [0] (~chatzilla@31-19-120-114-dynip.superkabel.de) |
| 21:22:51 | Tortelloni | hi, is any developer right now online here? |
| 21:43:31 | | Quit bertrik (Ping timeout: 245 seconds) |
| 21:43:32 | | Join the-kyle [0] (~kyle@cpe-075-177-188-248.nc.res.rr.com) |
| 21:43:44 | | Quit the-kyle (Remote host closed the connection) |
| 21:43:58 | | Join bertrik [0] (~quassel@cl-1037.haa-01.nl.sixxs.net) |
| 21:43:58 | | Quit bertrik (Changing host) |
| 21:43:58 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 21:46:11 | | Join the-kyle [0] (~kyle@kyle.tk) |
| 21:57:07 | | Join kugel [0] (~kugel@91-64-116-253-dynip.superkabel.de) |
| 21:57:07 | | Quit kugel (Changing host) |
| 21:57:07 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 22:00 |
| 22:07:34 | | Quit y4n (Disconnected by services) |
| 22:07:41 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 22:10:58 | | Quit tchan (Ping timeout: 260 seconds) |
| 22:14:32 | | Quit y4n (Quit: Today is the perfect day for a perfect day.) |
| 22:18:22 | *** | Saving seen data "./dancer.seen" |
| 22:33:04 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 22:33:58 | | Quit bertrik (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 22:34:27 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 22:36:49 | bluebrother | Tortelloni: if you have a question just ask. If someone can help you they will answer as soon as they are active |
| 22:39:31 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]) |
| 22:39:52 | | Quit ruskie (*.net *.split) |
| 22:39:52 | | Quit TBCOOL (*.net *.split) |
| 22:39:52 | | Quit Elfish (*.net *.split) |
| 22:39:52 | | Quit uwe_mobile__ (*.net *.split) |
| 22:39:53 | | Quit GeekShadow (*.net *.split) |
| 22:39:53 | | Quit derf (*.net *.split) |
| 22:39:54 | | Quit KotH (*.net *.split) |
| 22:39:54 | | Quit DormantBrain (*.net *.split) |
| 22:40:01 | | Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) |
| 22:40:01 | | Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) |
| 22:40:02 | | Join KotH [0] (~attila@lou-outside.kinali.ch) |
| 22:40:05 | | Join derf [0] (~derf@static-108-18-126-14.washdc.fios.verizon.net) |
| 22:40:06 | | Join uwe_mobile [0] (~uwe@static.88-198-8-117.clients.your-server.de) |
| 22:40:08 | | Join TBCOOL [0] (~tb@c-2a91e555.09-273-73746f44.cust.bredbandsbolaget.se) |
| 22:41:02 | | Join DormantBrain [0] (~andy@2001:470:8:a61::5f92:59a1) |
| 22:41:26 | | Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) |
| 22:47:53 | | Join Prodicus [0] (~chatzilla@2605:a601:561:7701:c13:43f9:c0cd:849) |
| 22:48:41 | Tortelloni | Ok, i got a sansa clip plus. with default firrmware it isn't possible to prevent charging the battery if the sansa is conncted to the pc. is there a hidden option in rockbox with which it's possible? if not, will it integrated anyday? -given that there is an interface for it... |
| 22:56:14 | Tortelloni | it just suck the the battery is charging everytime i put some files on my sansa. and it's not possible to prohibit charging the battery by a usb-cable-mod. the only way is to do that by the firmware. therefore it would be nice if there is a possibility to do that with rockbox |
| 23:00 |
| 23:03:35 | | Quit Tortelloni (Remote host closed the connection) |
| 23:05:30 | | Quit Strife89 (Ping timeout: 240 seconds) |
| 23:07:45 | | Join Tortelloni [0] (~chatzilla@31-19-120-114-dynip.superkabel.de) |
| 23:08:49 | | Join ruskie [0] (ruskie@sourcemage/mage/ruskie) |
| 23:09:00 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 23:10:52 | | Quit Galois (Ping timeout: 1825 seconds) |
| 23:13:48 | | Quit pamaury (Remote host closed the connection) |
| 23:18:25 | | Quit Cultist (*.net *.split) |
| 23:18:46 | | Join Cultist [0] (~CultOfThe@c-98-223-211-32.hsd1.il.comcast.net) |
| 23:20:10 | | Quit amayer (Quit: Leaving) |
| 23:31:20 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 23:32:04 | | Join Strife89 [0] (~Strife89@adsl-98-80-200-248.mcn.bellsouth.net) |
| 23:32:27 | | Join RiD [0] (RiD@bl22-226-139.dsl.telepac.pt) |
| 23:33:29 | | Quit Tortelloni (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]) |
| 23:36:54 | | Quit the-kyle (Remote host closed the connection) |
icon identifies that the person is a core developer (has commit access).