[00:00:18] <[7]> especially if you like rockbox much better than the apple firmware :) [00:00:37] <[7]> (you don't need emcore to use rockbox on a nano2g, just install it the "regular" way using the rockbox utility and it should be fine) [00:00:59] thank you so much [00:01:00] <[Saint]> though, the FTL will still shit itself from time to time - and that bootloader does no repair. [00:01:02] well, i restored [00:01:52] <[7]> [Saint]: it does, just not quite as solid as nandfsck does [00:02:00] <[Saint]> [7]: that's the one reason I prefer emCORE [00:02:08] it seems that emCORE has been deleted [00:02:10] <[Saint]> it has a much more robust cleanup. [00:02:10] <[7]> iloader should do the trick for that as well [00:02:26] when i start the ipod i boot on Apple firmware [00:02:34] <[7]> but seriously, how often does rockbox screw up an FTL these days? [00:02:42] <[7]> I thought that had mostly been fixed [00:02:44] <[Saint]> every time you hard reset. [00:02:48] <[Saint]> EVERY time. [00:02:53] <[7]> very interesting [00:03:04] <[7]> there *is* recovery code for that in apple's bootloader [00:03:36] <[7]> if I had time, it might be worth researching what it actually cocks up on [00:03:47] <[Saint]> so, apparently they knew an abrupt power-off can cause serious issue? [00:04:09] <[7]> well the FTL behaves a bit like a journaling file system in that case [00:04:41] <[7]> if it isn't flagged as cleanly unmounted, it will load a previous checkpoint and try to find things that have changed since that point [00:04:55] <[Saint]> Oh? Interesting. [00:05:06] <[Saint]> Apple's convoluted systems never cease to amaze. [00:05:09] <[7]> there might be cases where blocks get rolled back to an older state, but the FTL is constructed in a way that should never make a block be completely gone after that [00:05:23] <[7]> well, every FTL needs that kind of logic in one way or another [00:05:32] <[7]> and this is clearly code that apple sourced from Whimory [00:06:45] <[7]> nandfsck has a very robust recovery mechanism: it scans through the whole flash, just collects what is there (with the newest copy of a page taking precedence) and then completely rebuilds the mapping tables from scratch based on that [00:06:59] <[Saint]> that's a proprietry FTL solution for several NANDs, yeah? [00:07:04] <[Saint]> re: Whimory [00:07:17] <[7]> and it also has mechanisms to reclaim free space prior to that in order to ensure that it can even write the mapping tables [00:07:42] <[7]> yes, I've seen other vendors use Whimory FTLs as well [00:07:47] <[7]> but mostly apple [00:07:52] <[Saint]> Meizu, apparently. [00:08:02] <[Saint]> m# and M6 both use it [00:08:02] <[7]> but they also use it on the iphones, so it seems to be fairly robust [00:08:07] <[Saint]> (several M6 vairants) [00:08:26] <[7]> anyway, nandfsck is a fairly slow, but robust way to recover an FTL [00:08:32] <[Saint]> also, apparently, iRivier. [00:08:35] <[7]> apple might be attempting to do something more clever [00:08:44] <[7]> and we might be confusing that in some way [00:09:03] <[Saint]> nandfsck isn't slow! the recovery of a 8GB unit takes ~1 second. [00:09:22] <[Saint]> I see this every time I need to hard-reset. I know it well ;) [00:09:22] <[7]> depends on in what kind of state the flash is [00:09:26] <[Saint]> Aha. [00:09:41] <[7]> if there was basically no write traffic since the last clean unmount it will be really quick [00:09:54] <[7]> but i've seen it take 5-10 seconds in some cases [00:10:14] <[7]> but then again, apple's firmware seems to take several seconds to even mount a cleanly unmounted FTL [00:10:37] <[7]> which is a few hundred milliseconds in emcore [00:11:15] * [Saint] is quite happy the above scenario worked out so well [00:11:26] <[Saint]> ...mortified it even happened, but, happy it worked out. [00:11:53] * [7] would have had plenty of tricks to resort to if that would have failed [00:12:06] <[7]> anyway, my ipod knowledge is getting more and more rusty :/ [00:12:11] <[Saint]> [7]: maybe you should make the install key-sequence the konami code or something ;) [00:12:32] *** Quits: liar (~liar@clnet-p09-185.ikbnet.co.at) (Remote host closed the connection) [00:12:40] <[Saint]> something "impossible" (for varying levels of possible) to hit accidentally. [00:13:06] <[7]> heh, display a clickwheel pictures on the screen, highlighting which buttons need to be pressed in which sequence [00:13:08] * [Saint] thought that sequence *was* "impossible" to hit accidentally, but, was proven wrong...bit-time. [00:13:17] <[7]> with a different random sequence for each boot [00:13:22] <[Saint]> *big-time, even [00:13:26] i repeat, it would be nice to publish the "magical sequence" [00:13:41] <[7]> javi_: it's a wiki, feel free to do it :) [00:13:50] <[Saint]> It would, yes, I'll write it up later this afternoon. [00:14:02] <[Saint]> should another user with the odd LCD type hit the same issue. [00:14:22] <[Saint]> it's assumed that they couldn;t get as far as you did, though. [00:14:27] <[Saint]> Which is the hilarious thing. [00:14:35] <[Saint]> You shouldn;t have been able to complete the install. [00:14:50] here was an user with similar situation: http://forums.rockbox.org/index.php?topic=29066.0 [00:15:10] <[7]> maybe he followed some youtube video or anything else that documents the install button combo? [00:15:26] or maybe he asked here [00:15:34] i am the first one [00:16:09] <[7]> javi_: that situation is different [00:16:31] <[7]> it seems like the whole trouble started during uninstallation for him [00:16:41] <[7]> so the display driver can't really be it [00:16:46] <[Saint]> ...and the decision to format the HDD. [00:16:59] <[Saint]> WHY do people think that'll help? Really? :) [00:17:28] <[7]> can't hurt that much either [00:17:32] <[7]> we've taken care of that [00:17:43] <[7]> in this particular case, I think somebody just doesn't know what disk mode is [00:18:00] <[7]> being stuck in the boot menu with both appleos and rockbox removed [00:18:06] <[7]> easy enough to fix usually [00:18:09] before getting inside this IRC i thought this would be dead [00:18:40] <[Saint]> they're "impossible" to brick. For varying definitions of impossible. [00:18:49] <[7]> javi_: you can't really kill these... lots of recovery methods available, it just could get a bit more complicated [00:19:40] <[Saint]> Yeah, the only thing that'll actually kill these things is a ahrdware failure. [00:19:50] good to know. [00:19:55] <[Saint]> iPods are very robust things. [00:20:42] <[Saint]> Apple makes excellent hardware, with appallingly bad firmware ;) [00:22:54] and not cheaper...250 euro in 2006 [00:23:11] cheap* [00:26:21] * [Saint] absolutely refuses to buy Apple hardware new, because of this. [00:26:35] <[Saint]> I got my Nano2Gs for somewhere around 20USD [00:27:09] <[Saint]> it was a fuckup on behalf of the seller, but, I got my Classic for 70something cents. [00:28:06] * user890104 got a classic2g 120gb for 50eur [00:28:31] (a new one here is ~230eur) [00:28:56] battery status?? [00:30:11] <[Saint]> Well...my Classic gives me 50+ hours constant playback. [00:30:17] <[Saint]> So "good enough" I say. [00:30:31] good. [00:30:35] * [Saint] <3 the CE-ATA Classic for its massive battery. [00:31:55] <[Saint]> with an SSD, the "fat Classic" ia a machine of everlasting battery death. [00:32:09] <[Saint]> 80+ hours easy. [00:33:51] amazing, good value [00:36:41] <[7]> [Saint]: the 160GB one also has a fairly beefy battery [00:36:54] <[7]> not much bigger than the 80gb one, but newer technology [00:42:12] guys, i'm leaving [00:42:30] thank you for yout help, i will donate to rockbox project [00:42:37] your* [00:43:05] greetings from barcelona,spain [00:44:09] *** Quits: javi_ (02881c7d@gateway/web/freenode/ip.2.136.28.125) (Quit: Page closed) [01:02:57] <[Saint]> [7]: isn't the 160GB one the CE-ATA one? [01:03:02] <[Saint]> the "fat Classic"? [01:14:28] <[7]> yes [01:14:30] <[7]> it is [01:14:38] <[7]> but I meant the thin 160GB one [01:14:48] <[Saint]> Aha, right. [01:15:16] <[Saint]> iirc, all the Classics except the 160GB CE-ATA model are 500mAh [01:15:28] <[Saint]> which is 850mAh [01:15:39] <[Saint]> (pretty massive difference) [01:15:57] <[7]> i know that there is a difference between the generations [01:16:09] <[7]> probably ranging from 400 to 600 or something for the thin ones [01:16:13] <[Saint]> Hum, the source comment needs changing, then. [01:16:31] <[Saint]> it states that all except the CE_ATA one are 500mAh [01:16:53] <[Saint]> if owners of other Classics can confirm the battery capacity, I'll update the source. [01:17:23] * [Saint] also needs to commit his "detect what type of Classic it is, and set the capacity accordingly if possible" patch [01:17:45] <[Saint]> ...not that the capacity really matterys, it's just for the wildly inacurate estimated runtime. [01:17:49] <[7]> I haven't opened any classics so far, but found quite a few teardowns and reviews stating different capacities [01:17:50] <[Saint]> *matters [01:18:03] <[7]> yeah, someone should fix those estimates [01:18:05] <[Saint]> Wait...wha? [01:18:19] <[Saint]> I thought you had to strip your fat Classic down? [01:18:31] <[Saint]> I recall you stating opening them was a massive bitch. [01:18:51] <[Saint]> (which is absolutely true) [01:19:49] <[Saint]> [7]: Battery level: 98%; estimated time remaining 9281min [01:19:50] <[Saint]> :P [01:20:00] <[Saint]> just a /bit/ off. ;) [01:20:03] <[7]> I didn't dare to open mine after seeing the teardown photos [01:20:12] <[Saint]> Aha. [01:20:15] <[7]> yeah, we haven't yet figured out how to access the battery current sensor [01:20:22] <[Saint]> I've opened mine a few times, it's not so bad. [01:20:40] <[Saint]> How is the runtime estimated? It definitely fluctuates. [01:20:42] <[7]> anyway, the fat one wasn't even owned by me, I had only borrowed that one to get ce-ata working [01:20:53] <[Saint]> Oh, I thought it was given to you. [01:21:05] <[Saint]> I had no idea you returned it. Good boy. [01:21:14] <[7]> capacity estimate purely based on voltage (not taking inner resistance into account), divided by a rough estimation on how much current the ipod might be consuming in the current situation [01:21:27] <[Saint]> Aha. [01:21:29] <[7]> no, it was from a friend of mine [01:21:54] <[7]> someone donated an 80GB one with that broken HDD, and the rockbox fund then "donated" the 160GB slim one [01:23:09] <[Saint]> Do you still have the one with the awesomely fucked HDD you managed to recover beyond all odds? [01:23:23] * [Saint] recalls seeing the disk image of that before repair. [01:23:35] <[Saint]> ...no fucking idea how you pulled off making that thing usable again. [01:24:36] <[7]> [Saint]: I implemented a software based sector remapping layer [01:24:48] <[7]> and scanned the exact defect patterns for about two weeks using a custom tool [01:25:03] <[7]> and it still occasionally runs into I/O errors, but at least it boots :) [01:25:24] <[7]> and yes, I still have that one [01:25:38] <[7]> it's sitting on my desk, feeling neglected [01:26:23] <[Saint]> remapping in software, does that cause huge lookup wait times? [01:26:42] <[7]> no, and I even managed to use just like 200KB of RAM for the tables [01:27:06] <[Saint]> Wow. [01:27:07] <[7]> I implemented something that roughly resembles how page tables work [01:27:18] <[Saint]> I imagined anything with heavy i/o to suffer quite badly. [01:27:24] <[Saint]> for example: lossless playback. [01:27:27] <[7]> not because of the remapping [01:27:57] <[7]> it suffers because the drive has problems accessing "good" sectors as well, and because there are additional seek times at the damaged spots [01:28:27] <[7]> drive access speed is down to about 1MB/s in areas close to the damage [01:28:32] <[Saint]> Aha, right. The reason I imagined the remapping may cause issue is that there's no guarantee of anything being contiguous. [01:28:32] <[7]> but perfectly fine in large good areas [01:28:52] <[7]> the remapping works in a way that just skips across bad sectors [01:28:58] <[7]> no spare area at the end or something like that [01:29:00] <[Saint]> I imagine it behaves similarly to a very badly fragmented HDD. [01:29:14] <[7]> it doesn't [01:29:20] <[Saint]> ..wow. [01:29:35] <[7]> this has the disadvantage of not being able to mark additional bad sectors without completely erasing it [01:29:42] <[7]> but it works extremely well performance wise [01:30:10] <[Saint]> When I saw the graphical representation of the disk image - I honestly thought there way no way in Hell you'd recover that disk. [01:30:27] <[Saint]> that weird, repeating pattern of bad sectors. [01:31:10] <[Saint]> Any idea what caused it? The pattern suggested to me that the head was banging against the platter - with some type of regularity. [01:31:29] <[Saint]> There was definitely a pattern to it. [01:31:50] <[7]> well, I figured out some bugs of the drive's firmware [01:32:20] <[7]> which made some good sectors appear to be bad, because the drive would internally try to optimize and cache things, and get stuck on a bad sector close to a good one [01:32:42] <[Saint]> Did you ever send any of this upstream? Does Apple even have a method for being able to do so? (I suppose not). [01:32:52] <[Saint]> {to both} [01:33:04] <[7]> after finding a way to prevent the firmware from doing that, there was some repetitive pattern that looks like a scratch across the surface, along with some random "dirt" in some areas (circular scratch?) [01:33:37] <[7]> toshiba is to blame for the buggy firmware here [01:33:42] <[Saint]> I thought it looked as though the head was slamming against the platter with some form of regular pattern. [01:33:58] <[7]> mostly for ignoring the "disable read ahead" and "disable write cache" commands, despite claiming to support them [01:43:35] *** Joins: cyb3rkn19ht (~cyb3rkn19@pool-72-66-124-83.washdc.fios.verizon.net) [02:45:45] *** Quits: [Saint] (~quassel@rockbox/user/saint) (Remote host closed the connection) [03:56:34] *** Joins: [Saint] (~saint@rockbox/user/saint) [06:19:51] *** Quits: cyb3rkn19ht (~cyb3rkn19@pool-72-66-124-83.washdc.fios.verizon.net) (Remote host closed the connection) [06:32:04] *** Quits: [7] (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [06:32:11] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [09:51:51] *** Joins: STeeF (~STeeF@office.hostnetbv.nl) [10:46:30] *** Joins: liar (~liar@83.175.83.185) [23:57:33] *** Joins: cyb3rkn19ht (~cyb3rkn19@pool-72-66-124-83.washdc.fios.verizon.net)