[00:15:35] *** Joins: Kebianizao (~kvirc@99.1.219.87.dynamic.jazztel.es) [00:16:15] *** Quits: Kebianizao (~kvirc@99.1.219.87.dynamic.jazztel.es) (Read error: Connection reset by peer) [00:17:20] *** Joins: Kebianizao (~kvirc@99.1.219.87.dynamic.jazztel.es) [01:33:07] *** Quits: Kebianizao (~kvirc@99.1.219.87.dynamic.jazztel.es) (Quit: Estaba usando KVIrc KVIrc Equilibrium 4.2.0, revision: 420, sources date: 20120701, built on: 2013-08-29 10:52:41 UTC 420 http://www.kvirc.net/) [02:20:25] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Read error: Connection reset by peer) [02:22:36] *** Joins: [Saint] (~saint@rockbox/staff/saint) [06:31:32] *** Joins: steffengy (~quassel@p57B49056.dip0.t-ipconnect.de) [06:34:38] *** Quits: steffengy1 (~quassel@p5088FB75.dip0.t-ipconnect.de) (Ping timeout: 250 seconds) [06:43:36] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 260 seconds) [06:45:09] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [08:26:51] *** Joins: goom (~goomba@cpe-72-177-165-10.satx.res.rr.com) [11:35:58] *** Quits: goom (~goomba@cpe-72-177-165-10.satx.res.rr.com) (Quit: Leaving) [14:00:03] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [14:00:23] *** Joins: [7] (~quassel@rockbox/developer/TheSeven) [17:49:29] *** Joins: benedikt93 (~benedikt9@unaffiliated/benedikt93) [18:59:10] Hi:) quite some time since I've been here for the last time... has there been any progress in the meantime? [19:39:26] <[7]> benedikt93: there has been quite a lot of progress recently, but not on new targets [19:39:53] <[7]> I've rewritten the USB driver for ipod nano2g and classic, hopefully fixing this mess once and for all [19:40:40] <[7]> we have userspace USB support in emcore, and a diskmode app for emcore, which isn't stable yet, but has SMART support (i.e. you can read the HDD's SMART data using smartmontools on a PC that the ipod is connected to) [19:41:10] <[7]> I've also fixed the problems that caused dualboot to fail [19:41:27] <[7]> (that hasn't been implemented in the installation procedure and boot menu though= [19:41:57] <[7]> and we're going to make a "native" rockbox installation method for the classic, based on a rockbox bootloader flashed to the NOR flash, not involving emcore at all [19:56:08] that seems nice. I've been wondering since I've been looking at some n3g code again (although I'm not yet sure how much time I can/want to spend on it) and couldn't even remember how much of the existing code worked for it, too.. [19:56:22] is one more installation method even worth the effort? [19:59:54] <[7]> it's more an effort to get rid of all of those emcore-related support problems [20:00:04] <[7]> making it easier for the end user [20:14:18] well, I didn't catch those recently^^ makes sense, though. The dilemma is that the nano will probably never be fully functional when nobody else works on it [20:16:45] <[7]> yes I don't think anyone has plans to get that one working [20:16:59] <[7]> one could hope that the FTL is similar to the nano2g [20:17:11] <[7]> but we have no idea at all how the PMU works [20:18:34] as far as I remeber it's not the completely the same. plus the nand controller itself is weird, which is probably not so much of a problem [20:18:58] <[7]> hm, wasn't that on the 4g? could be on both though [20:19:20] <[7]> anyway, the first step would be getting the SDRAM to work on the 3g [20:19:25] pmu and lcd code is actually what I've actually looked at the last few days [20:19:40] <[7]> LCD could hopefully be similar to the classic [20:19:43] right, that's what I failed at the last time [20:20:16] <[7]> probably some different init parameters, but largely identical code [20:20:23] I think so, the init sequences are different and distinguish several more lcds [20:20:37] <[7]> oh? more than 4? [20:21:21] need to check, but from a first glance at the classic code I thought so, but I might have gotten that wrong [20:21:36] <[7]> how are they destinguished? gpios? reading model info through the LCD interface? [20:21:56] through the interface [20:24:34] I counted 5 now, two of which are probably very similiar [20:30:36] well, I might actually give the lcd a try. I will probably just replicate the pmu code, the only thing I really _understand_ (or think so..) about it right know are the adcs [20:30:48] in how far is the n4g controller weird? [20:31:58] <[7]> I think we weren't even able to identify the most basic registers when looking at apple's messy EFI code [20:48:32] *** Quits: benedikt93 (~benedikt9@unaffiliated/benedikt93) (Quit: Bye ;)) [21:05:48] *** Joins: benedikt93 (~benedikt9@unaffiliated/benedikt93) [21:27:15] on the 3g, osos is very helpful for nand since not all of the debug information is stripped [21:32:06] *** Quits: APLU (~mulx@2a01:e34:ee29:12b0::10) (Quit: !sucide) [21:32:27] <[7]> yes, that's similar on the 2g [21:32:45] <[7]> the OF is a much larger blob though, and thus harder to disassemble [21:33:04] *** Joins: APLU (~mulx@2a01:6600:8081:2900::1) [21:34:12] on the 3g there's one large command switcher that references most of the nand code except for a few dead functions [21:46:58] so what would be the very basic requirements for running emcore except for sdram? [21:47:43] <[7]> as the SoC is otherwise supported by emcore, it would be only SDRAM and the PMU stuff required to get that working [21:48:13] <[7]> (and a lot of ifdeffing non-adapted code for other HW components that aren't essential) [21:49:45] you mean the pmu code for sdram, but nothing apart? [21:50:11] <[7]> you basically need a working bootstub [21:50:47] <[7]> which does clock, power, MMU, SDRAM and LCD (optional) setup [22:59:16] *** Joins: user890104_ (Venci@unaffiliated/user890104) [22:59:16] *** Server sets mode: +nt [23:04:10] *** Joins: Dgby714_ (~dgby714@nala.villavu.com) [23:11:00] *** Quits: user890104 (Venci@unaffiliated/user890104) (*.net *.split) [23:11:00] *** Quits: Dgby714 (~dgby714@nala.villavu.com) (*.net *.split) [23:11:01] *** user890104_ is now known as user890104