[04:03:57] *** Quits: bcobco (~bcobco@77.228.124.149) (Ping timeout: 246 seconds) [04:17:10] *** Joins: bcobco (~bcobco@77.228.124.149) [04:38:33] *** Quits: bcobco (~bcobco@77.228.124.149) (Ping timeout: 240 seconds) [04:49:07] *** Joins: bcobco (~bcobco@77.228.124.149) [06:14:54] *** Joins: steffengy (~quassel@p5088FD79.dip0.t-ipconnect.de) [06:17:44] *** Quits: steffengy1 (~quassel@p5088F4E4.dip0.t-ipconnect.de) (Ping timeout: 250 seconds) [06:47:08] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 260 seconds) [06:48:38] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [12:48:25] *** Dgby714_ is now known as Dgby714 [13:26:21] *** Quits: steffengy (~quassel@p5088FD79.dip0.t-ipconnect.de) (Disconnected by services) [13:26:22] *** Joins: steffengy1 (~quassel@p57B48E67.dip0.t-ipconnect.de) [18:08:21] hi [18:08:48] im on a classic2g [18:09:16] i have noticed that when emcore boots, the hdd spins up. [18:09:32] selecting rockbox makes the hdd spin down [18:09:51] and when rockbox start, hdd spin up again. [18:09:58] thats a bit odd [18:10:02] or maybe im wrong [18:11:29] what about keeping hdd always on? too much spin cycles are not good [18:11:50] 0.2.3 r919 [18:11:52] m [18:12:59] also, im testing that version with diskmode [18:13:11] seems to work with some performance issues [18:13:24] any newer/better version to test? [18:13:26] thanks in advance [18:13:58] <[Saint]> what you speak of isn't possible. [18:14:11] <[Saint]> control has to be passed off from emCORE to Rockbox. [18:14:16] <[Saint]> this is unavoidable. [18:16:06] i though that. what about the possibility to start emcore without hdd? then rockbox spins up the hdd. this way there is only one power cycle, now two for the same objetive [18:16:46] <[Saint]> Nope. We keep config files on the disk that we need access to. [18:17:08] <[Saint]> This really isn't a big deal. [18:17:52] <[Saint]> Back when CE-ATA disks weren't being properly shut down...it was a little problematic, but even then, it wasn't a big deal. [18:18:17] i had to replace HDD once. since then im a bit worried. no enough money you know [18:18:50] <[Saint]> The reason you had to replace the HDD has nothing to do with Rockbox or emCORE> [18:19:03] <[Saint]> Frankly, the firmware on these disks is BULLSHIT. [18:19:07] <[Saint]> We can't fix that. [18:19:13] <[Saint]> They're broken by design. [18:19:54] one more question [18:20:16] in rockbox: what time is recommeded for DISK SPINDOWN ? [18:21:05] <[Saint]> There's really no reason at all for you to touch this setting. [18:21:14] i think i broke the hdd because i once set this value to a very low time, very frequent spin cycles... now im on 90seconds [18:21:40] <[Saint]> That has a much higher likelihood of prematurely damaging the HDD. [18:21:52] <[Saint]> Just leave it as the sensible default. [18:22:21] i dont remember the default value. maybe 30s? [18:22:30] <[Saint]> Not even close. [18:22:47] <[Saint]> You can reset the default value of any setting via the context menu. [18:23:12] oh thanks [18:23:14] 5s [18:23:21] seems too low for me [18:23:26] bcobco: emergency retracts are even worse than spindowns [18:23:33] <[Saint]> ^ this [18:23:51] <[Saint]> Not to mention you'll be needlessly ravaging your battery. [18:24:09] and if we hand over control to code that isn't hdd-aware, the drive would 1. spin until the battery is empty, 2. then crash hard, not parking heads etc. [18:24:24] so we always spin down the disk before booting into another firmware [18:24:57] <[Saint]> (and do so safely on CE-ATA since ~30 or so revisions ago) [18:25:06] <[Saint]> ...can't thank you enough for that, btw. [18:25:14] thanks for clarifications! [18:25:18] <[Saint]> I seem to be the only one with CE-ATA variants. [18:25:41] i finally installed a 160GB toshiba hard disk in a 120gb ipod [18:25:55] emcore has a 20 second spindown timeout [18:26:11] no idea what rockbox's default is, but that only counts when navigating through folders without dircache anyway [18:26:28] in all other cases rockbox spins down the disk when it knows that it's done accessing it [18:26:53] <[Saint]> 5s [18:27:14] <[Saint]> (is Rb's default spindown time) [18:27:23] well, as long as you have dircache on, that setting should only have an effect in some plugins etc., but not during normal music player use [18:27:34] <[Saint]> And, yes, you're quite right. Its only really relevant in a small subset of situations. [18:27:49] <[Saint]> The rest of the time Rb will take care of itself and spin down when it knows it can. [18:29:04] is that similar to the behavior of the orig.firmw.? [18:29:18] <[Saint]> No idea. [18:29:29] neither i [18:30:20] somewhat [18:30:45] apple probably has a longer idle timeout, but also accesses the disk more often I think [18:31:52] well. the big power saver is turning off the lcd screen. good work [18:32:14] before that, battery drained quickly [18:32:32] the lcd screen should make less than 10% runtime difference [18:33:50] regarding diskmode, any new version to test? im testing one that user890104 gave to me some months ago [18:34:26] <[Saint]> The LCD isn't really responsible for much draw at all... [18:34:56] *** Joins: n1s (~n1s@c-a2e470d5.010-215-7570701.cust.bredbandsbolaget.se) [18:34:56] *** Quits: n1s (~n1s@c-a2e470d5.010-215-7570701.cust.bredbandsbolaget.se) (Changing host) [18:34:56] *** Joins: n1s (~n1s@rockbox/developer/n1s) [18:57:21] *** Joins: steffengy (~quassel@p5088F5CC.dip0.t-ipconnect.de) [19:00:21] *** Quits: steffengy1 (~quassel@p57B48E67.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) [22:14:26] *** Quits: n1s (~n1s@rockbox/developer/n1s) (Quit: Ex-Chat) [23:15:11] *** Joins: franklin (~franklin@cpe-071-071-071-105.triad.res.rr.com) [23:15:18] sup TheSeven [23:15:26] ok, so just add a new fastboot option then? [23:15:31] (continuing from #rockbox) [23:15:49] until you have something usable, just use emcore.py to upload whatever you want to boot via usb [23:15:58] no need to integrate it into the boot menu [23:16:02] ah ok [23:16:22] and no matter what I can still get to dfu mode, right? [23:16:31] so if i wipe the flash, it's still fine? [23:16:51] yes, but you should make a backup of your syscfg block [23:16:57] how? [23:17:00] otherwise you can't go back to the apple firmware [23:17:09] I never wanted to go back to OF [23:17:11] :) [23:17:12] that block contains vital information such as the model and serial number, hardware type, ... [23:17:22] oh... how? [23:17:28] I'd just make an image of the whole boot flash just in case [23:17:33] first thing: get the emcore debugging tools working [23:17:37] then use emcore.py to dump the flash [23:17:52] you need libusb, pyusb 1.0.0, and the tools from our svn [23:18:00] if you're on windows, you'll need a driver as well [23:18:05] and which revision should I use? 859 or 968? [23:18:18] I'd suggest to upgrade to svn head [23:18:32] (i am on svn head :)) [23:18:54] then use svn head tools as well [23:20:07] I get a TON of errors compiling elf2emcoreapp [23:20:37] I'd say the tools aren't the best :P [23:20:45] (hardcoded paths) [23:21:05] ls [23:22:27] the hardcoded paths should only be relative inside the svn repository [23:22:36] and elf2emcoreapp is a beast, yes [23:22:46] it's a fork of elf2flt, which is even worse [23:23:50] elf2emcoreapp doesn't even compile [23:24:44] any advice? [23:25:28] BTW, have you considered migrating to git? [23:38:56] at this point I don't see an advantage in migrating [23:39:19] and I know that elf2emcoreapp doesn't compile if you don't pass it the right args (see readme) [23:39:24] it's a bit tricky to get right [23:39:47] you don't need it at this stage though, so I'd just ignore it for now [23:48:08] ok [23:49:49] UMSBoot doesn't compile either... [23:50:06] (I'm going to use it as a reference to as how the LCD/USB works)