[06:28:52] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 246 seconds) [06:30:24] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [09:11:30] *** Quits: Dgby714 (~dgby714@nala.villavu.com) (Ping timeout: 276 seconds) [09:17:03] *** Joins: Dgby714 (~dgby714@nala.villavu.com) [09:20:36] *** Quits: Dgby714 (~dgby714@nala.villavu.com) (Client Quit) [09:26:15] *** Joins: Dgby714 (~dgby714@nala.villavu.com) [09:35:12] *** Quits: krnlyng (~liar@83.175.90.24) (Ping timeout: 255 seconds) [10:47:56] *** Joins: krnlyng (~liar@83.175.90.24) [11:46:53] *** Quits: krnlyng (~liar@83.175.90.24) (Ping timeout: 256 seconds) [11:48:45] *** Joins: krnlyng (~liar@83.175.90.24) [13:59:42] *** Quits: krnlyng (~liar@83.175.90.24) (Ping timeout: 265 seconds) [14:00:55] *** Joins: krnlyng (~liar@83.175.90.24) [14:48:29] *** Quits: krnlyng (~liar@83.175.90.24) (Ping timeout: 256 seconds) [15:54:33] *** Joins: krnlyng (~liar@83.175.90.24) [17:22:21] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 256 seconds) [17:23:08] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [18:50:46] prof_wolfff: I'm available during the next hours in case I can help you with boot debugging etc ;) [19:03:31] TheSeven: hi! ATM i have 2 ipods, 80Gb with emCORE + RB and a thin 160Gb with OF, there is a 128Kb container for DFU and a util program to make the .dfu installer, the installer makes a copy of norboot on NOR 'free' space and copies the dualbootloader where the OF was [19:04:18] the dual bootloader is bases on the ipodnano2g RB bootloader, it checks for the buttons and loads into memory RB or OF [19:07:24] only tried once to load and execute the dfu-loader, with no luck, ATM i am adding a few functions to debug using the buzzer... [19:10:38] might want to add disk/diagmode to the bootloader (using the usual apple key combos) in the long run, should be easy [19:10:52] how exactly are you building the DFU loader? [19:11:00] are you doing any lowlevel HW init? [19:11:59] at DFU stage, only the most basic parts of the SoC are initialized (only stuff that's independent of the board that the SoC is sitting on, so especially no I2C, PMU, SDRAM, LCD or clickwheel) [19:12:44] the nano2g bootloader isn't expecting that, because it gets loaded by apple's flash bootloader which takes care of initializing that stuff [19:13:30] on the emCORE side of things, the required glue is in emCORE Loader (for flash boot), and the bootstub (for DFU boot). both are very similar. [19:14:24] prof_wolfff: so I guess this is what you're looking for: http://websvn.freemyipod.org/filedetails.php?repname=freemyipod&path=%2Fapps%2Finstaller-ipodclassic%2Fbootstub%2Fbootstub.S [19:14:25] the .dfu loader is build using a util that inserts the dfu-installer.bin + the dualbootloader.bin into a prebuilt (pwnage) 128Kb container [19:14:45] ok, so you're already wrapping the RB bootloader into that stub thing? [19:14:55] using this? http://websvn.freemyipod.org/filedetails.php?repname=freemyipod&path=%2Fapps%2Finstaller-ipodclassic%2Ftools%2Fstubembed.py [19:16:41] yes, the dfu-installer copies original NOR boot (128Kb) into free space in NOR and then copies the dualbootloader were original NORBOOT was [19:18:22] er, wait, let me align on what you're doing here... [19:18:36] the dual-bootloader must take care not to use SDRAM until it detects RB is selected to be launched, this is because apparently OF (an DRAM) could be in hibernated state [19:18:38] so flashing your code already works, but the flashed code doesn't boot properly? [19:19:54] hm, I guess you should just unhibernate if OF is hibernated, no matter what the user selects [19:20:02] that's kinda the expected user experience I'd guess [19:20:33] using menu+select reboot to switch OSes [19:20:44] hm... maybe the FTL won't be too happy about that [19:21:44] ah wait, we're on classic here... disk retracts might be a problem there [19:22:19] but yeah, RB bootloader is usually living in SRAM anyway, and we don't need anywhere near as much RAM as on the nano2g because we don't need to keep all those FTL tables [19:22:19] ATM i am trying not to use (write) the SDRAM because it may contain data and if the user is selecting to launch OF then the thing could crash, if OF is selected then the copy of NORBOOT is copied into IRAM and executed like a normal OF boot [19:22:40] heh, that actually works? [19:22:45] yes there is other problem with disk retracts and what hey call the "battery trap" [19:23:20] the battery trap is easy enough to fix, and current emCORE builds should be taking care of that [19:23:37] just don't even try to spin up if you're below some battery voltage [19:23:48] and show a warning screen instead [19:24:09] if RB is selected then SDRAM can be used and the bootloader code (containing display and hardisk drivers) coppied to SDRAM and executed [19:24:40] hm I think even that should be able to live in SRAM easily [19:25:02] should be much smaller than on the nano, where it allocates a chunk of SDRAM in addition to SRAM [19:25:13] so for code but not data (display buffer i.e) [19:25:14] deferring OF boot to apple's bootloader is an interesting idea... kinda similar to what they're doing on the sansas [19:26:22] my approach would likely have been a bit different - always booting with full drivers, then taking care of loading the OF myself, getting rid of apple's bootloader altogether [19:26:52] but that might be biased by the trouble that we had with apple's bootloader destroying the FTL on nano2g [19:28:10] another advantage is that we don't need to care about the flash layout if we nuke apple's bootloader - but I guess the flash layout is consistent enough, and will always have a free consecutive 128K chunk somewhere, ideally always in the same place [19:29:17] this is a first try, i decided to copy the NORBOOT in IRAM because this simulates a normal OF boot assuring all things are ok [19:30:03] yeah I'm just saying that we do know how to boot the OF and disk/diagmode ourselves after initializing all the RB drivers these days - so you might as well do that if it turns out to be more convenient [19:30:52] the flash layout in classics, is a filesystem (like the 5G) that fills from top to button (on my Classics there is free space where the NORBOOT ends, offset 32Kb+128Kb) [19:31:26] yes, that matches my observations as well, I'm just not sure how consistent that is if ipods have went through bootloader updates etc. [19:32:03] and there are several versions of NORBOOT around for the classics [19:32:20] possibly tied to hardware generations [19:32:30] i have also same doubt, it seems some times the itunes copies additional files for disk check, but ii am not sure on that [19:33:11] I've found some junk in areas marked as free space that looked like factory burn-in testing code [19:33:16] called phoenix something [19:34:16] btw, how are you flashing this to the ipod? through DFU already? [19:35:10] heh, another thing to watch out for: updates of your RB bootloader code shouln't overwrite the NORBOOT copy with the old version of themselves ;) [19:35:57] yes, i am using the ipoddfu.py [19:36:23] so you have a working flasher that takes care of the norboot relocation + flashing of your stuff? [19:38:38] iirc (maybe i only think on that) the installer looks for the GUIDs (87021.0 container) to detect the OF or RB already installed, there is also a dfu-uninstaller.dfu [19:42:39] i have code for these things, probably with lot of bugs and bad address..., i hope to have a bit of time the next days to start debugging it,also i suspect there would be need to patch something on the FAT filesystem or the hdd driver because of the hidden partition [19:49:18] i am available for testing anything on a classic 2g [19:55:49] user980104: thanks!, i am trying the code will be easy to adapt to other targets, it seems nano 2G is very similar and nano3G is almost identical to the Classic6G (flash is the major difference), i dont know much about the nano4G [19:56:25] prof_wolfff: no, the I think, for some reason, the rockbox FAT driver can actually mount a stock-partitioned ipod [19:56:37] not quite sure why it works, but it seems to, mysteriously [20:00:00] i am not sure if it will work for the 6G, it seems the hidden partition is implemented in a different way that in the 5G, but ATM i have not looked at this too much [22:07:00] *** Quits: prof_wolfff (~prof_wolf@213.37.48.54.dyn.user.ono.com) (Ping timeout: 264 seconds) [22:19:45] *** Joins: prof_wolfff (~prof_wolf@213.37.48.54.dyn.user.ono.com) [22:28:18] I've actually tried it with emcore-based dualboot and it seems to just work fine