[02:12:35] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:12:35] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [02:22:13] this is annoying... [02:22:30] I have a somewhat trivial change here which somehow breaks UMSboot and I just don't get why. [02:23:02] I did some changes to the framework to allow loading the IRQ vectors somewhere else than the rest of the code [02:23:10] so the code now copies the IRQ vectors into place [03:58:56] oh, come on [03:59:25] why on earth are these two blocks not equivalent!? [03:59:49] .dummy _text_end - 4 : { . += 4; . = ALIGN(1 << CACHEALIGN_BITS); } >CODE_REGION AT>CODE_REGION [03:59:49] .dummy _text_end : { . = ALIGN(1 << CACHEALIGN_BITS); } >CODE_REGION AT>CODE_REGION [04:00:04] the first one works, the second one doesn't, and removing the whole line fails as well... [04:23:13] this is impressive [04:23:29] once that linker mess is sorted out, the somewhat complex highlevel code works right out of the box :) [04:26:00] New commit by theseven (r946): UMSboot: Merge upstream changes http://is.gd/zT8YfG [04:27:17] New commit by theseven (r947): emCORE: SynopsysOTG: We can send up to 1023 packets at once http://is.gd/d1rOEO [04:28:06] New commit by theseven (r948): UMSboot: SynopsysOTG: We can send up to 1023 packets at once http://is.gd/1K7k7C [04:28:48] New commit by theseven (r949): emCORE: Add bulk transfers to USB debugger for better performance http://is.gd/EFbU12 [05:50:12] hm... [05:50:26] * TheSeven just flashed an emcore debug build, now the ipod is in a weird softbricked state [05:50:36] first it would enter into an emcore loader bootloop [05:50:54] then, after reflashing a build through DFU, it just wouldn't boot up anymore [05:51:05] <[Saint]> the fuck? [05:51:18] I can boot through DFU just fine, but it now outright refuses to boot *anything* from flash. [05:51:26] <[Saint]> Oh, is there anything I should be testing, BTW? [05:51:39] not before I found the cause of that... [06:15:53] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 264 seconds) [06:17:11] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [06:54:41] *** Quits: steffengy (~quassel@p5088FA13.dip0.t-ipconnect.de) (Disconnected by services) [06:54:41] *** Joins: steffengy1 (~quassel@p57B49A02.dip0.t-ipconnect.de) [08:12:32] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [08:12:32] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [09:56:08] *** Joins: STeeF (~STeeF@office.hostnetbv.nl) [13:58:52] New commit by theseven (r950): emCORE: Fix USB debugger bulk interface http://is.gd/okNgn0 [13:59:16] New commit by theseven (r951): libemcore: Use bulk transfers if possible http://is.gd/xD1d7v [13:59:59] New commit by theseven (r952): UMSboot: Backport upstream USB driver fixes http://is.gd/f7rZx1 [14:00:16] now that this works, why is my iPod still softbricked!? [14:00:40] uhm, what do you mean by softbricked? [14:00:50] boot straight to DFU, no matter what I do [14:00:57] ah [14:01:04] can you restore it? [14:01:22] well running an installer doesn't, so I'm a bit clueless what has happened here [14:01:47] it started to go into a boot loop where emcore loader would show its splash and it would then reboot before emcore comes up [14:02:03] re-ran an installer through DFU in an attempt to fix that, now emcore loader doesn't boot anymore either [14:02:11] i was talking about an OF restore [14:02:30] I'll try some other things first [14:03:06] (I'd like to discover the root cause before covering it up) [14:05:09] what happens if an app registers custom usb callbacks? does it unregister the bulk one you're using for memory dump? [14:05:17] yes [14:05:35] so the debugger fallbacks to ep0? [14:05:46] actually libemcore does so [14:05:52] ah, i see [14:05:55] the two interfaces are completely independent of each other [14:06:07] (they don't even know about each other on the ipod side) [14:06:30] so it can tell the difference between a bulk memory dumping interface, and a bulk interface for something else (e.g. ums)? [14:07:04] libemcore will attempt bulk if there are endpoint descriptors in the debug interface descriptor [14:07:22] and if there aren't, or if trying to use them failed, it will fall back to the EP0 interface [14:08:33] ah, so if i have a custom usb handler, it would be represented as a different interface. makes sense [14:08:52] or, in terms of windows - a composite device [14:09:13] yes [14:09:25] great :) [14:09:33] and if you register one, emcore will remove the endpoints from the descriptor of the debug interface [14:10:09] hm, looks like uploading stuff works, but downloading doesn't :/ [14:12:35] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:12:35] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [14:45:25] New commit by theseven (r953): emCORE/UMSboot: Fix some more USB trouble http://is.gd/8A9YWj [14:49:43] TheSeven: is it safe to use the HEAD revision of emCORE on my ipod? [14:50:08] i mean, i'm too lazy to copy 30 GB over usb at the moment [14:50:37] but i'm a bit curious, and would like to test it [14:50:45] user890104: I'd stay away from it until I figure out the cause of this softbricking issue [14:50:56] ok [15:05:17] user890104: do you have a known working emcore installer which already has the new USB interface? [15:05:41] I suspect that something messes up my local emcore loader builds [15:06:35] http://files.freemyipod.org/~build/ is r945 [15:06:46] and i have it installed on my devices [15:09:30] softbricks here [15:09:49] I reflashed my factory NOR image => boots into disk mode [15:09:55] then I flash that installer => stuck in DFU [15:10:36] doesn't sound good at all [15:11:10] I know that it's impossible, but this behaves as if they would have fixed the pwnage bug :P [15:11:48] so you're running that particular build on your devices and it works? [15:12:24] yes [15:12:37] my n2g also has the same revision [15:13:19] I'm talking about classics here... [15:13:37] if you have a classic with exactly that build on it, can you send me a full NOR dump of it? [15:13:43] there just must be some difference... [15:13:50] yeah, sure [15:14:07] can you give me the exact command? [15:14:19] emcore memalign 0x10 0x100000 [15:14:39] emcore readbootflash 0 0x100000 [15:14:58] emcore downloadfile 0x100000 bootflash-working.bin [15:16:49] * TheSeven spots traces of libpng in an emcore loader flash page... [15:18:04] *** Quits: el3ctrik (~el3ctrik@2a00:1c10:5:202:216:3eff:fe98:c8f1) (Ping timeout: 240 seconds) [15:27:40] hm, are we even booting through pwnage? [15:28:10] the installer looks like it would be using a symmetric device-specific signature... [15:29:53] a quick look at the flash dump suggests that either sha1 or hwkey aes is broken [15:30:08] two encrypted hashes of different things have the same value [15:34:22] IIRC only the bootstrap is encrypted on classic [15:34:39] no, the installer encrypts that during installation [15:34:47] ah, i see [15:35:22] we needed to do that because, unlike on the nano2g, the bootrom doesn't accept binaries that are symmetrically signed with the group key, only with the device key [15:36:02] now how can that encryption code suddenly start failing... [15:39:29] a quick test of hwkey AES suggests that both the device key and group key seem to be working [15:51:03] operating the SHA1 hardware registers manually through USB seems to work as well [15:57:44] hm, as far as I can tell from the bootflash contents it's the sha1 that's acting up [15:59:07] does my bootflash work on your device? [16:00:02] it can't because it's encrypted with a device key [16:00:10] I'm just looking for differences in the dumps [16:00:25] out of curiosity, is yours a 2G? [16:00:36] there are some interesting differences in the syscfg [16:01:13] the only other differences are in encrypted sections [16:01:24] most notably that those two hashes don't match [16:01:43] which is further evidence that sha1 is acting up [16:03:25] it's a 2g [16:03:41] so 2g is hw version 1 [16:03:46] and 3g is hw version 2 [16:03:49] seems to make sense [16:08:48] yep, sha1 returns all zeros [16:14:05] which byte holds the hardware id? 0x46? [16:14:11] ...or not, that was a debugging bug ;) [16:14:32] 5d [16:15:04] ah, it's in HwVr [17:03:51] hm, there's timing involved somehow [17:12:34] TheSeven: i also have a stock classic 2g nor dump, if you need one [17:12:41] from the same device [17:13:16] I'm wondering if I should just rip out hardware sha1 and use a software implementation [17:16:44] well, it worked well so far. it doesn't make sense to randomly break down [17:17:00] unless something messed up with the registers, for example [17:25:59] it's massively affected by timing from what it looks like [17:26:12] so e.g. different compiler versions could already cause trouble [17:46:42] hm, could also be cache coherency biting us again [18:29:34] New commit by theseven (r954): installer-ipodclassic: Fix 0x800 bytes of garbage data being written to boot flash http://is.gd/PBFkwM [18:30:07] (and no, that was not the cause of my problem, just something harmless that I spotted while debugging this softbrick here...) [19:19:20] unbricked it :) [19:26:02] damn it [19:26:21] the sha1 engine behaves differently depending on whether it's being booted through DFU=>UMSboot or emCORE [19:28:24] the behavior suggests that the CPU might be caching accesses to the SHA1 engine [19:30:06] New commit by theseven (r955): installer-ipodclassic: Avoid SHA1 trouble for now. We should figure out the real cause later. http://is.gd/1cHVkE [19:38:24] ok, found the culprit [19:38:33] it's umsboot 0.2's MMU init code [19:39:09] cmp r1, #0x38000000 [19:39:09] biccs r1, r1, #0xc [19:39:09] how can I possibly have a value of 0x38000c1e after that line? [19:43:52] IIUC that should calculate 0x38000c1e - 0x38000000 = 0xc1e => C=1 Z=0 => CS true => BIC 0xc => r1=0x38000c12 [20:07:34] argh [20:07:42] I've been running an old umsboot all the time [20:09:22] on the other hand this means that we have some potentially dangerous umsboot beta versions out there [20:12:35] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [20:12:35] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [20:12:37] which one? svn head? [20:13:24] no, SVN is already fixed [20:13:31] just the build that I was using wasn't [20:14:21] New commit by theseven (r956): installer-ipodclassic: Revert r955. This was caused by using broken UMSboot builds. http://is.gd/VAQWoM [20:14:36] but the build i gave you has the bug? [20:14:38] New commit by theseven (r957): UMSboot: Backport a minor pagetable init fix http://is.gd/WsgTDz [20:14:51] user890104: no, it depends through which bootstrapper you execute the build [20:15:08] and I had some broken DFU files around here [20:15:11] ah, i see [20:15:53] can you check if we have any files with md5 528047579bc6f54bafa15ad09e5446bc on our server? [20:15:59] that one is affected by that bug [20:16:26] (it's the DFU file hash, I hope it hasn't made its way into bootstrapper executables) [20:17:11] ok [20:21:57] there are none [20:22:32] and i usually overwrite the old bootstrapper EXEs [20:24:11] TheSeven: you also reverted r954 in r956 :) [20:25:09] (spotted thanks to the svn commit emails) [20:29:20] user890104: good catch :) [20:32:13] New commit by theseven (r958): installer-ipodclassic: Un-revert r954 http://is.gd/P9pt8z [21:34:29] * TheSeven now has an OF debugging tool :) [21:34:51] run it with a bunch of adresses as command line args, and it will install breakpoints at those [21:35:15] then it will print out the register state at the first breakpoint that was hit :) [21:41:08] the code lives in some unused pagetable entries ;) [21:41:29] (so highly unlikely for any OF code to mess with it) [21:48:28] *** Quits: Elfish (amba@84.201.30.174) (Ping timeout: 264 seconds) [21:56:01] *** Joins: Elfish (amba@2001:1608:12:1:13:3:3:7) [23:16:13] how does it print them ?