[00:03:21] TheSeven: did you manage to access the svn repo? i haven't added the key you posted, because you didn't make it clear what type it is [00:04:10] also, are you going to commit the "OF enabler" targetinit code, or you're still tweaking it? [00:31:11] user890104: haven't attempted to access it yet [00:31:22] user890104: I'm still trying to figure out what's making the 3g OF crash [00:31:34] once that's fixed it will hit svn [00:32:38] user890104: if you want to help speed things up, you could have a go at implementing SMART in emcore disk mode [00:33:33] (or rather ata passthrough) [00:33:47] the kernel code for that should be in the tree that I sent you a while ago [00:34:03] I'd like to verify that this actually works before committing it [01:08:06] this OF crash is getting more and more mysterious [01:09:08] I'm observing some seemingly impossible register corruption [01:09:21] at least in two places [01:09:56] dumping r0 at 22002eb8 results in 39a000b4, should be 00000005 [01:11:45] and dumping r6 at 08034ccc results in 089aed2c, should be a copy of the r0 value [01:12:08] some quick checks on other regs suggest that the dumping mechanism is working [01:13:31] or wait, the r0 dump is trashed [01:34:35] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 250 seconds) [01:36:08] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [03:04:58] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [03:05:21] *** Joins: bcobco (~bcobco@77.225.204.119) [04:41:54] *** Quits: bcobco (~bcobco@77.225.204.119) (Ping timeout: 250 seconds) [04:57:47] *** Joins: bcobco (~bcobco@77.225.204.119) [06:11:44] *** Quits: bcobco (~bcobco@77.225.204.119) (Ping timeout: 260 seconds) [06:16:41] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 250 seconds) [06:18:22] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [06:19:14] *** Joins: bcobco (~bcobco@77.225.204.119) [06:39:49] *** Quits: steffengy (~quassel@p57B48CC2.dip0.t-ipconnect.de) (Disconnected by services) [06:39:50] *** Joins: steffengy1 (~quassel@p57B4879B.dip0.t-ipconnect.de) [10:03:47] *** Joins: Kebianizao (~kvirc@99.1.219.87.dynamic.jazztel.es) [11:53:02] *** 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/) [13:16:30] *** Joins: Kebianizao (~kvirc@99.1.219.87.dynamic.jazztel.es) [17:55:14] did anyone know that there is a classic 4G? [17:57:45] i didn't [17:58:00] did they fix the bootrom exploit? [18:05:39] no [18:05:46] but apparently the firmwares aren't compatible [18:05:52] apple 3g firmware crashes on 4g [18:06:03] seems like my "3g" is in fact a 4g [18:06:19] which needs 2.0.4 or later due to an additional LCD type [18:06:30] er, 2.0.5 [18:20:27] todo: fix USB console [18:20:42] todo: fix USB bulk downloadfile [18:31:06] nah [18:31:08] mine is a 3g [18:31:18] but nevertheless requires 2.0.4, doesn't work with 2.0.3 [18:31:19] WTF [18:31:31] 4g firmware reboots instantly [18:31:39] so... does anyone have a 4g= [18:40:57] so... 1g=1.0.x, 2g=?, 3.0g=2.0.3/2.0.4, 3.1g=2.0.4 only, 4g=2.0.5 only [18:57:18] TheSeven: I think i do, but I stopped following the project long time ago [18:57:33] anyway is there smth you'd like me to try? [18:58:13] first of all I'd like to have a SYSCFG dump of that one to verify that it's indeed a 4g [18:58:31] do you have emcore on it and the emcore tools set up somewhere? [19:08:57] yes, I do. but I don't have the time right. Just let me know what are the steps and I'll write you back later... [19:08:59] sry :/ [19:16:11] emcore.py memalign 0x10 0x1000 [19:16:15] note the address [19:16:42] emcore.py readbootflash 0

0x1000 [19:16:59] emcore.py downloadfile

0x1000 syscfg.bin [19:17:03] emcore.py free

[19:18:14] the syscfg.bin file will contain a a string "rVwH", usually at offset 0x54 [19:19:01] then there will be four zero bytes, then "00 02 13 00" or "00 03 13 00" [19:19:08] the latter would suggest that it's a 4g [19:34:20] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [19:34:46] *** Joins: bcobco (~bcobco@77.225.204.119) [20:01:03] TheSeven: what about mine? do you still keep my syscfg dump? [20:01:12] ah, you're looking for the software version [20:01:20] i'll check mine when i get home [20:01:20] no, hardware version [20:01:24] but for 4g hardware [20:01:38] i was talking about "2g=?" [20:01:56] yes, I don't know that, but I don't need to know it either ;) [20:02:02] ah ok [20:02:09] I was just attempting to summarize how this correlates [20:03:35] what about the connection between hw version and the actual bytes in HwVr? [20:03:52] s/hw version/generation/ [20:20:57] that seems to be straightforward [20:21:13] 0 = 1g, 1 = 2g, 2 = 3g, and probably 3 = 4g [20:21:31] at least 2.0.5 seems to require a 3 in there in order to boot on a 3g ;) [20:49:01] ah, i see [21:45:28] user890104: do you also have problems with downloading more than 4KB from the ipod? [21:46:04] haven't done anything with it in a while, can do any testing you need [21:46:12] download how? emcore.py? [21:46:16] yes [21:46:24] everything >4k seems to fail [21:46:47] well... how did i manage to send you a syscfg dump then [21:47:34] svn head, right? [21:47:36] not sure, I also wasn't aware of that issue until today [21:47:38] yes [21:57:41] TheSeven: btw, just added your second ssh key [21:58:11] hm, doesn't seem to work though [21:59:47] can you paste the whole public part again? [22:01:22] ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAzxoCHSUbobViF2WwymBq6Soa/C/DkM7A4Nu0Lkuj9ptk1benSkHA+WwD8KsQ3ima/4Vp1uWKTNjwuinMmq7BtZtHB9kscPxF6olyoQYNVbIexoFfYl+fVI1oRYHeNh/pibDFLWB8pp5oaYdFGBR0nDww/GaxeJwBY2XCX8qYddJGV0cnINA3FeBeDdPoQ9AdCeN+AEnzGuqk/FWsp6EhyYbm8VbWJ2Ji0btDKQy39pycTMVD8GOi7M0ktJ9ZNEUP95EhLHRQKsYbvFUPjsoSzQ225tqUaro8mE10ul405u9NVtxZvqorqVmDo1zSlb0jWCogognGvZC3Fv/jhXK72Q== rsa-key-20140628 [22:02:17] ok, try again [22:03:10] just use a regular ssh client to connect as svn@svn.freemyipod.org [22:04:40] and, while we're at it, you can authorize this one as well: [22:04:40] ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqLoHhbpn+BKZNI7kFteNmGnbnVvxnneTSQ3zeJDg/nv3UrvquaN600NntaG8ppKvRFmM6EsJiv04ZRMlFhVbWz1vnxYDmO1gXcmHjzVoE+dbvIybV86lW5ANE0GJ5/ZXqBJw3JcagiaY6cYFs9HTxReODk2HT5o1Pu8LWu2Qq+yZukyBHdC57X7H4LqovOHYpmuyBEOHMYrZOf/6/8xIHWt880Y1eydjm89k/khAmLwkSg17pw8oE5RoO8KxDw5Z6/roUb7lC9za5X9pmcxTnKHahmtxItUC34lqyOdO5IQnVx+nvOdkpqlof9ZY3JRgXTdtbY20S6X4AerJuZU0l theseven@gmx.net [22:05:22] the first one (with putty on windows) still says "the server refused our key" [22:06:26] Jul 19 22:05:09 freemyipod sshd[28407]: Connection closed by xx.xx.xx.xx [preauth] [22:06:46] yes, that was me cancelling it when it asked me for a password for user "svn" [22:08:00] ah, i see [22:08:16] http://paste.pm/raw/i9g [22:08:30] that's /home/svn/.ssh/authorized_keys [22:08:38] do you see anything wrong? [22:09:24] New commit by theseven (r960): emCORE: iPod Classic: Properly detect external power and charging state http://is.gd/HQJLLi [22:09:33] the 3rd one (on linux) works [22:09:59] so I guess putty is the culprit... [22:10:06] and the bot is still alive :) [22:11:16] New commit by theseven (r961): emCORE: iPod Classic: Apple firmware dualboot support http://is.gd/zAMDsM [22:11:18] yay, now i can draw a "plug" icon inside the battery indicator, when the ipod is charging [22:11:18] ok, found it [22:14:23] New commit by theseven (r962): emCORE: Improve disk error reporting during startup http://is.gd/kxEk7Z [22:15:46] New commit by theseven (r963): emCORE: Allow booting if there's no battery present http://is.gd/mpKHgh [22:18:57] user890104: did you check if downloadfile works for you? [22:19:11] I'm really confused how that bug crept in [22:23:45] i'm looking for a dock connector cable at the moment [22:24:05] the bug is highly timing dependent [22:24:19] a single cprintf makes it go away for 4K transfers, but it still happens near the end of huge transfers [22:24:35] I guess it's something with the AHB master of FIFO watermarks [22:26:34] uhm, umsboot locked up the ipod two times in a row [22:26:48] the first showing nothing but a black screen [22:27:01] uh? [22:27:12] and the second it wasn't even able to do that, and stayed in the emcore bootmenu [22:27:29] run through debugger or bootmenu? [22:27:32] finally, i got it running [22:27:34] bootmenu [22:27:58] r959 [22:28:03] just tried that on my 3g and got lcd confusion. hm... [22:29:54] only the first time though [22:29:57] now it works flawlessly [22:30:41] yes, it happens from time to time [22:31:43] are you done committing for the moment? i'm going to make a full rebuild [22:32:28] yes [22:32:59] ok [22:34:30] is there a way to produce automatic n2g build? [22:34:57] i'm going to use the 128k pwnage bootstrap for classic and n4g [22:35:14] we could probably use cached bootstrappers somehow [22:35:19] it's a waste of space, but these are only testing builds after all [22:35:51] i.e. define the signature for various container sizes somewhere [22:36:06] ah, i see [22:37:30] keep 32 of those available in 8-10% increments between 16K and 128K or something [22:37:37] and pick the closest fitting one in the script [22:37:48] (if no device is available, otherwise generate an ideal one) [22:38:15] that seems like a good tradeoff [22:38:41] for nano2g you need to sign the final binary though [22:40:16] i can hook up my n2g to my RPi and make some API for remote signing, but i don't think it's worth the effort [22:42:53] can you please fix the warnings in /umsboot/src/cpu/arm/util.c? [22:43:19] we also have some serious bugs on nano2g, and not many users at all [22:43:45] so we can probably just drop the signed parts from the autobuilds [22:44:26] actually, we don't have any autobuilds at the moment [22:44:51] it's just me logging in as user build, and running ./build.sh [22:45:16] which warnings? I'm just getting errors! :P [22:45:22] which can probably be automated, but i haven't had enough time to make it [22:45:24] and those seem to be gcc bugs [22:45:33] src/cpu/arm/util.c: In function 'memmove': [22:45:33] src/cpu/arm/util.c:546:1: warning: control reaches end of non-void function [-Wreturn-type] [22:45:33] src/cpu/arm/util.c: In function 'memset': [22:45:33] src/cpu/arm/util.c:173:1: warning: control reaches end of non-void function [-Wreturn-type] [22:45:36] these [22:46:18] well how can one fix these? [22:47:25] we should probably move everything that's naked into assembly files, but then we run into another bug with weak symbols [22:50:48] can you just put a return statement at the end, in order to make gcc happy? [22:52:51] hm, do that if you want to, but I just use a newer gcc which figures this out by itself ;) [22:53:29] ah, i see [22:53:35] so are you experiencing this usb bug or not? [22:54:06] i'm still signing the files [22:55:07] huh, what do you need to sign? [22:58:36] i'm making builds for all targets [22:58:42] so i can update them all [22:59:00] n2g, n4g and classic [22:59:08] actually, just run it on n4g [22:59:26] also on touch2g [22:59:36] hm [23:00:02] without any delay, the first packet lacks 16 bytes, cancelling the transfer [23:00:59] with a little bit of delay, or with dma disabled, it works, unless the last packet is not full, in that case it gets lost completely [23:37:09] http://files.freemyipod.org/~build/ is up-to-date [23:46:00] (there are also some openiBoot builds from my git repo as a bonus) [23:51:37] TheSeven: re 4g. lsusb tells it is "Apple, Inc. iPod Nano 4.Gen ". If I'm correct emcore.py requires a device running emcore, isn't it? [23:52:03] Kebianizao: not nano, classic ;) [23:54:10] blargh [23:54:43] overlapping fifos [23:54:45] very funny [23:54:55] oops! I thought nano was the topic [23:55:17] well, looks nano4g is still stalled then [23:55:51] TheSeven: http://paste.pm/raw/i9k [23:55:58] no problems with downloadfile here [23:56:06] on 4 different targets [23:57:37] interesting [23:57:42] it only started very recently here as well [23:57:53] but I found an obvious bug, so let's fix that