[00:52:06] *** Quits: krnlyng (~liar@77.117.101.49.wireless.dyn.drei.com) (Ping timeout: 272 seconds) [00:53:28] *** Quits: Dgby714 (quassel@dgby.org) (*.net *.split) [00:57:44] *** Joins: Dgby714 (quassel@dgby.org) [01:08:33] *** Joins: krnlyng (~liar@77.117.101.49.wireless.dyn.drei.com) [02:07:35] *** Quits: krnlyng (~liar@77.117.101.49.wireless.dyn.drei.com) (Ping timeout: 260 seconds) [02:21:55] *** Joins: krnlyng (~liar@77.116.73.18.wireless.dyn.drei.com) [06:13:10] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 260 seconds) [06:14:13] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [12:22:47] *** Quits: [Saint] (~hayden@rockbox/staff/saint) (Quit: No Ping reply in 180 seconds.) [12:25:09] *** Joins: [Saint] (~hayden@rockbox/staff/saint) [18:56:25] TheSeven: i am looking at the existing RB bootloaders, remember did it on the past just to realize that nano2g method is not valid for ipod6g, and the only way is to take control at NOR boot, for first installation DFU seems the easier way to go, ATM i was wondering if i am right or missing something, what do you think about this? [18:57:13] DFU is the only way to get initial control on the newer 6g models [18:57:44] on the oldest series one could do something similar to the nano2g, but that doesn't work if firmware was ever updated [18:58:54] so yeah, there won't be a way around DFU for a generic installer [18:59:12] ok, so the bootloader must be installed in the NOR instead of the original NOR boot [18:59:43] not necessarily [19:00:44] what other way? [19:00:53] it might be possible to install to the firmware partition, but only by writing a device specific binary [19:00:53] and I'm not sure if that would still work with current NOR bootloaders [19:01:45] what I know is that the model key can't be used for that anymore, making it unusable as an attack vector for an installer [19:01:57] but if we let the original NOR boot to load the bootloader it must be signed with a certificate?, it seems that firmware partition files are encryption type 3 as the .dfu installer files [19:02:44] I vaguely remember that it might tolerate other encryption types as well - but I'm not sure if that was actually on the 6g or somewhere else [19:03:26] our forged certificate would likely be accepted on the firmware partition by very old 6g models that were never updated, but not by newer ones [19:03:43] even if actually they load other encryption types that we can generate using the device, it may be fixed in the future with a new Apple FW update [19:03:49] but it's just waaaay to long ago for me to remember things accurately ;) [19:04:11] yes, that's always a point. we could just downgrade it again though. [19:04:29] i have just read my old notes to remember things :) [19:04:41] I also chose the NORboot replacement, because that's something that they can't possibly mess with [19:04:54] I'm just saying that there might be other ways to do it in theory (but I doubt that they're practical) [19:06:22] it seem the only thing to choose is if the bootloader uses the original NOR boot to launch OSOS and diagmode... or to delete the ONB and implement everything on the bootloader [19:09:25] I'm always in favor of the latter as it allows us to get rid of more stuff that we can't control, but then again norboot might know better how to deal with the OF [19:10:19] I'm probably biased by norboot on the nano2g formatting the flash all the time after simple unclean shutdowns that were very well fixable (which emcore does) [19:12:33] i prefer the first approach because the original boot is preserved (the apple logo, the original battery trap) and as you said ATM i dont know every detail about the original NOR boot [19:14:21] I don't think these two things are much of an issue - we need our own battery trap for the rockbox case anyway, and the logo can also easily be taken care of [19:14:59] so I'm not fully sure what to do here - both options seem viable to me [19:15:53] are you refering to the devel menu? [19:16:30] no - to reimplementing OF boot ourselves vs. launching norboot [19:17:29] concerning the devel menu: I know [Saint] disagrees there, but IMO a devel menu can come in handy at times, although you shouldn't end up in it by accident [19:18:48] I don't know how many times these devel menus have proven helpful in diagnosing support cases where things were acting up in one way or another - removing that kinda resembles apple's design philosophy to me [19:18:49] i am going to separate the devel menu into a different patch, ATM it only appears when /.boot/emcore.bin exists and the user chooses to switch FW [19:19:23] I'd also vote to separate as much as possible of that code out into a separate binary [19:19:37] i.e. just have some kind of custom binary launcher there [19:19:57] but I guess that's what you're planning to do anyway [19:20:56] booting emcore from HDD might come in handy, but I guess some kind of USB-based code loader (which would then allow you to fire up emcore or whatever) might actually be better because it doesn't rely on HDD access working [19:21:34] and emcore often isn't particularly useful unless you're talking to it over USB, so you could as well launch it through USB in the first place [19:25:03] yes, better that way, but may be space problems if the usb driver is included in the bootloader [19:25:52] hm [19:26:21] maybe a small emcore.bin could be executed using DFU mode, mk6gboot can create a .dfu file that includes any binary [19:26:59] sure, you can boot it through DFU, but then it has to take care of much more HW init, and entering DFU all the time is just painful [19:27:15] I'm thinking more about embedding some kind of small USB loader stub binary into the RB bootloader [19:27:23] similar to the one in the nano2g's emcore loader [19:27:42] that thing is <2K of code size [19:28:44] if so there is no problem, there are more than 30Kb free [19:29:18] it's just additional work to embed that and improve it a bit [19:29:28] but I think that can be postponed until everything else is done [19:30:50] yes, and could serve as and easy alternative method to restore the iPod in case everything is lost [19:31:07] well that can just as easily be done through DFU [19:31:29] we know how to simulate what itunes does to put it back into factory state [19:32:48] but must use the Apple .dfu recovery files (?) [19:33:20] sure, but you won't get around using apple binaries if you want to write the apple firmware to it [19:41:19] true, need to do what recovery.dfu does, one way is to implement something similar tor ipodscsi into the bootloader, but i am sure someone is going to claim it is not a function of the bootloader :) [20:47:00] *** Quits: krnlyng (~liar@77.116.73.18.wireless.dyn.drei.com) (Ping timeout: 260 seconds) [20:47:41] *** Joins: krnlyng (~liar@83.175.90.24) [21:17:32] <[Saint]> TheSeven: prof_wolfff: [21:17:32] <[Saint]> I realize it might make me seem like an asshole at times, but for this bootloader, we need to be thinking about the general community - and not a tiny subset of developers. [21:18:40] <[Saint]> I don't honestly care if it has advanced features baked in, but these should only be present under specific circumstances (the presence of emcore.bin, for instance), and a causual user should never be able to accidentally do anything other than boot Rockbox or the OF. [21:19:37] <[Saint]> I realize I seem aggressive at times, but I'm pretty personally invested in making sure that ipod6g bootloader is as similar to the workflow of the existing ipod bootloaders as possible. [21:20:26] <[Saint]> My basic position is that if a user wants advanced features in a bootloader, they probably won't be using this one anyway. [21:20:46] <[Saint]> They'll almost certainly just never switch from emCORE. [21:52:51] *** Quits: krnlyng (~liar@83.175.90.24) (Quit: huiiiiii) [21:53:14] *** Joins: krnlyng (~liar@77.116.73.18.wireless.dyn.drei.com) [22:43:44] *** Joins: krnlyng_ (~liar@83.175.90.24) [22:46:22] *** Quits: krnlyng (~liar@77.116.73.18.wireless.dyn.drei.com) (Ping timeout: 265 seconds) [22:46:29] *** krnlyng_ is now known as krnlyng [23:21:09] *** Quits: krnlyng (~liar@83.175.90.24) (Quit: huiiiiii) [23:21:27] *** Joins: krnlyng (~liar@77.116.73.18.wireless.dyn.drei.com) [23:25:43] *** Quits: krnlyng (~liar@77.116.73.18.wireless.dyn.drei.com) (Client Quit) [23:26:14] *** Joins: krnlyng (~liar@83.175.90.24) [23:26:23] *** Quits: krnlyng (~liar@83.175.90.24) (Read error: Connection reset by peer) [23:29:12] *** Joins: krnlyng (~liar@77.117.6.151.wireless.dyn.drei.com)