[00:11:08] *** Joins: [Franklin] (~franklin@unaffiliated/franklin) [00:25:58] *** Quits: [Franklin] (~franklin@unaffiliated/franklin) (Ping timeout: 256 seconds) [00:27:43] *** Joins: [Franklin] (~franklin@cpe-71-71-39-6.triad.res.rr.com) [03:38:09] *** Quits: [Franklin] (~franklin@cpe-71-71-39-6.triad.res.rr.com) (Quit: Lost terminal) [05:48:46] *** Quits: krnlyng (~liar@83.175.90.24) (Ping timeout: 252 seconds) [05:51:50] *** Joins: krnlyng (~liar@83.175.90.24) [06:22:36] *** Joins: luyikei (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) [06:26:21] *** Quits: goom (~go4m@cpe-66-25-153-174.satx.res.rr.com) (Read error: Connection reset by peer) [06:26:48] *** Joins: goom (~go4m@cpe-66-25-153-174.satx.res.rr.com) [06:48:23] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 265 seconds) [06:49:28] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [10:47:16] *** Quits: luyikei (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) (Read error: Connection reset by peer) [10:50:02] *** Joins: luyikei (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) [18:29:12] *** Quits: luyikei (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) (Read error: Connection reset by peer) [22:06:59] prof_wolfff: my approach would be ripping that EFI stuff out completely and replacing it with something sane [22:07:37] actually emcore can already do everything we need, we just need to pick out those goodies and assemble them into something smaller / easier to install/use [22:08:34] if you can get the EFI stuff to boot rockbox that would be even nicer, but IIUC that would require finding a vulnerability in there which we don't have so gar [22:08:35] far* [22:09:48] there's that 128KB flash section that contains the EFI bootloader, I'd just completely rewrite that with out own one that replicates the functionality of apple's one (booting OSOS, disk mode, diagmode) and additionally allowing to boot rockbox [22:10:25] I'd probably build that based on the rockbox bootloader for nano2g [22:11:05] yes, at this moment we can patch the flash, or maybe patch the OSOS as ipodpatcher does [22:11:37] OSOS has some nasty sigchecks that we can't seem to get around with the current apple bootloader (only an old classic 1g version has a vulnerability there) [22:12:10] so it seems like we can't avoid flashing through the DFU exploit for now [22:13:15] i was looking for a way to use de DXE drivers [22:13:30] probably easier to rip them out and rewrite them [22:13:53] we basically have all the code that we need already, it just needs to be put together [22:15:29] so whe basically need two things: [22:15:29] 1. a rockbox bootloader (with dualboot support) which does [22:15:29] - initialize the basic hardware (basically clone norloader) [22:15:29] - show a fancy logo [22:15:29] - initialize the clickwheel and check for button combinations being pressed, handle those [22:15:31] - boot rockbox/OSOS/diskmode/whatever [22:15:32] yes, i am not sure what is the best approach: rewrite peicore to find the rockbox.ipod in the FAT partition or try to use the existing drivers, really ATM i dont know if these drivers had access to the FAT partition [22:15:33] 2. a DFU flasher which contains that bootloader binary, signs it on-device using HW crypto and writes it to that 128KB flash section, replacing apple's bootloader [22:15:56] 3. a PC side tool (ideally built into the rockbox utility) to take care of initiating the DFU process [22:16:40] what's the reason for sticking with EFI in the first place? [22:16:56] IMO figuring out the driver interfaces will be more effort than using our own drivers [22:17:10] i think i had all the info for phase 2. and 3. :) [22:18:15] a non-EFI approach would likely have quicker boot times, and more importantly will not depend on a particular apple bootloader version being installed [22:18:32] if EFI drivers can be used, it will be easier to port it to the Nanos, otherwise we must include support for hdd and FAT, there is not much space in the first 128Kb of flash, don known how the rest of the flash is organized [22:19:46] so your long term goal is basically hosting rockbox as a EFI module, reusing the EFI drivers for flash access even from the main firmware? [22:21:55] i was looking to the BDS module, it decides what to boot, i wonder if it is possible to execute or own BDS and then launch rockbox.ipod as ussual, but i think this is only an option, i am not sure if non-EFI is better [22:22:32] my point is that there's little reason to stick with EFI on the classic, it seems to only complicate things there (both technically and legally) [22:23:02] i am also not sure if the FAT partition can be accesed using EFI drivers or only the hidden FW partition [22:23:02] on the nanos, there might be an advantage of driver reusability, however that only really helps us if we can use those from the main firmware as well [22:23:16] well that wouldn't be much of a problem [22:23:28] we could write some RB loader stub into the hidden partition [22:23:35] (or into flash) [22:26:52] so, what do you think it is the best way to go from now, start implementing the non-EFI loader, or try to see if an EFI approach is suitable? [22:28:37] the non-EFI requires to join the exiting code for emcore-loader + hdd driver + fat filesystem, it seems not much complicated [22:29:46] possibly it also should include support to load emCore from FAT? [22:30:22] prof_wolfff: if you want to mess with EFI, I won't hold you back, but I expect a non-EFI solution to be much less work (and most importantly less reverse engineering) [22:31:02] I probably wouldn't bother about emcore for that new thing. after all it's an effort to get rockbox rid of emcore ;) [22:31:10] the people who want to use emcore can just flash it [22:31:29] (the audience for that is mostly developers anyway) [22:32:24] emCore was very useful for me to test the Classic hardware [22:33:10] i am a bit worried for the size of the loader, i hope i can fit in these less than 20Kb [22:34:07] if you go non-EFI you have up to ~100KB [22:34:12] should be plenty [22:35:15] so there is free space in the rest of the flash where diagmode and diskmode are? [22:39:19] yes, there is some free space [22:39:25] not quite sure how much [22:39:52] good [22:39:57] but if you nuke EFI you have a 128K section to work with [22:40:19] (effectively a bit less because DFU is also limited to 128K and needs to contain the flashing code as well) [22:41:09] the EFI is needed for the OF boot, it can be copied to FAT an loaded when needed or it can be loaded as usual but patched to call the RB loader [22:42:20] i prefer the second if possible to avoid the need to copy the EFI somewere at installation time [23:00:34] nah, we can get rid of it altogether [23:00:47] OF dualboot support has landed in emcore already ;) [23:06:46] :) about the EFI approach, i was thinking on replace the original BDS module (boot device selection), it is an small module executed at the end of the DXE core stage, it decides what to load depending on button selection, it loads 'files' using a call to an EFI protocol, i dont know it the FAT can be reached using this interface or only the hidden FW partition, if it is possible to access the FAT using this protocol then it is e [23:06:46] asy to build a BDS, there is no need to know the interfaces for the used drivers, at this point all is done using this call (and a few more to read clickwheel and not much more, the EFI boot services are disponible and they are well documented), so the BDS will be identical for other iPods using EFI [23:45:30] *** Joins: [Franklin] (~franklin@unaffiliated/franklin)