[02:03:06] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:03:07] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Read error: Connection reset by peer) [02:20:08] *** Quits: liar (~liar@clnet-p09-185.ikbnet.co.at) (Ping timeout: 245 seconds) [05:02:34] *** Quits: [Saint] (~saint@rockbox/user/saint) (Remote host closed the connection) [05:03:39] *** Joins: [Saint] (~saint@rockbox/user/saint) [06:51:44] *** Quits: [7] (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [06:51:53] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [08:03:07] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [08:03:08] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [08:59:59] *** Joins: [Saint_] (~saint@rockbox/user/saint) [09:01:38] *** Quits: [Saint] (~saint@rockbox/user/saint) (Disconnected by services) [09:01:44] *** [Saint_] is now known as [Saint] [11:29:53] *** Quits: x56 (~0x56@sillytitties.com) (Ping timeout: 240 seconds) [11:30:43] *** Joins: x56 (~0x56@sillytitties.com) [12:01:47] hm, lots of breakage all over the place with newer tool versions [12:04:31] <[Saint]> I boggled at: "Given that I read the FAQ that versions of EmCOre above r836 won't erase anything that's on the filesystem on the iPod, I wasn't too worried" [12:08:58] it's even more funny because I, being the one who wrote the code in question, still don't get WHY it doesn't erase the drive in the first place. it is absolutely supposed to erase it unless it detects a previous emcore installation on the FLASH. Which can't possibly be there. [12:09:57] <[Saint]> I have emCORE'ed a fucktonne of Classics - never failed once. [12:10:32] things seem to be much worse with usb3 and win8 [12:10:59] <[Saint]> I just loved the "given the fact I read something on some audiophile site that claimed otherwise, I completely ignored the installer telling me I would lose all my data..." [12:11:22] well, users... [12:11:22] <[Saint]> "I was surprised when I lost all my data" [12:11:28] <[Saint]> :) [12:11:48] anyway, I'm pondering to do one last attempt at a bunch of things: [12:12:01] 1. fix various things that broke in the build system [12:12:26] 2. reimplement emcore's USB stack from scratch (or rather cherrypick most of it from another project I've been working on) [12:12:26] <[Saint]> one last attempt == "emCORE - final"? [12:12:41] 3. reimplement the emcore debugging interface to not occupy any endpoints [12:12:56] 4. allow for userspace to dynamically claim endpoints [12:13:15] 5. implement USB mass storage support within an emcore app [12:13:26] <[Saint]> 6. dual-boot :P [12:13:54] 7. implement some app that emulates USB CDROM drives based on ISO files on the ipod :) [12:14:24] <[Saint]> there's possibly something worthwhile looking at sitting on gerrit by gevaerts [12:14:30] <[Saint]> wrt: ISO [12:14:48] well that should be mostly trivial once we have USB mass storage in emcore [12:15:12] it would be awesome if it could emulate a CD burner and WRITE to an ISO file though :) [12:15:24] very helpful for capturing the output of some rescue media builder tools etc. [12:15:39] <[Saint]> aha - this is what I was thinking of: http://gerrit.rockbox.org/r/#/c/67/ [12:15:48] <[Saint]> Change Id4c7bc41: Add preliminary support for loopback-mounting a disk image. [12:20:07] Well [12:20:26] I have something that does mass storage from a file, which at the time half worked, by accident [12:20:43] (due to various unmounts not closing all files and things) [12:21:09] I did *not* implement the SCSI commands you need to be a CD drive though [12:21:35] * [Saint] wants to be a CD drive [12:21:39] lol [12:27:21] regarding dualboot: i'd be happy to support anyone who wants to pull this off [12:27:31] it can't be *that* complicated [12:27:46] it's just a rather tedious task to figure out what's wrong with our I2C driver [12:29:17] the root cause of dualboot not working is a lockup in apple's i2c driver, likely caused by that one expecting to take over a different hardware state than it gets from our code [12:29:59] this is one of the things where good old ibugger can be very helpful [12:30:50] because it can easily be embedded into an apple firmware image and jumped to from basically any CPU state, so you just have to inject a jump instruction somewhere to launch ibugger if that location is reached [12:31:02] and can dump the hardware state at that point of course [12:43:49] *** Quits: [Saint] (~saint@rockbox/user/saint) (Quit: something is a sick puppy here...) [12:52:16] *** Joins: [Saint] (~saint@rockbox/user/saint) [14:03:05] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:03:05] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [14:05:50] *** Joins: liar (~liar@clnet-p09-185.ikbnet.co.at) [14:42:47] wait, what? emCORE development is going to continue again? [14:42:50] \o/ [14:44:37] i would love to help testing/debugging anything s5l ipod-related, and maybe get involved in development of something [14:58:04] *** Quits: liar (~liar@clnet-p09-185.ikbnet.co.at) (Read error: Connection reset by peer) [16:13:07] user890104: well, at least I'm trying to fix things up sufficiently to make them compile again :) [16:55:32] Farthen: are you around? [16:56:01] Farthen, user890104: can you explain the reasoning behind r856? it looks broken to me... [17:23:59] *** Quits: [Saint] (~saint@rockbox/user/saint) (Remote host closed the connection) [17:24:56] *** Joins: [Saint] (~saint@rockbox/user/saint) [17:25:31] TheSeven: let me see [17:28:03] it should check if the pointer is not null, rather than the data at that address, right? [17:34:51] well that's what it does, but does that make sense? Especially if a few lines further down it is still the value that's being checked? [17:35:37] IIUC the pointer can never ever be NULL [17:35:59] *** Joins: bcobco (~bcobco@77.225.204.93) [17:36:40] but I might of course be wrong, it's been ages since I wrote that stuff [17:37:05] i thought that bootinfo.firmware, pointing to NULL means that boot->load_from_file failed for some reason [17:38:01] yes, but the *location* of the bootinfo.firmware variable (which &bootinfo.firmware is) should be constant non-zero [17:38:14] I'm fairly sure that one of the two checks is wrong [17:38:20] ah, i see [17:38:31] hi [17:38:39] it's a pointer, pointing to a pointer, right? [17:39:26] probably [17:40:02] i have received updates from websvn. im glad to help testing here on an ipodclassic (120gb). just please let me know if you need tester [17:40:27] the fix looks broken, but there must have been a reason why that was committed. i.e. there must have been some breakage that it (magically?) fixed [17:40:39] what the hell could that have been... [17:40:51] the fix was committed on january 2nd, which is even more fishy [17:41:20] because it might have been committed just before, or just after, that emergency fix release [17:41:27] do we have it in the latest release or not? [17:41:46] IIRC the reason for the emergency release was some issue with installation on some models, nothing in this area [17:47:20] hm, that fix indeed went into the emergency release [17:48:00] which seems completely odd, as that would break OF boot on the nano2g AFAICT [17:48:28] hm [17:48:31] "iPod Nano 2G [17:48:31] iPod nano 2g builds taken down due to some problems with booting the original firmware. Stay tuned for another update." [17:48:48] this isn't conclusive... [17:49:25] but I think the real reason for the hotfix release was r858: "installer-ipodclassic: Remove init.emcoreapp on install again (reverts the change from r835) [17:49:25] This is needed for any fastboot user upgrading from the latest release with a CE-ATA iPod classic." [17:54:30] <[Saint]> ah, yes, that got you into a really shitty situation. [17:54:46] <[Saint]> I think I discovered that with a nano2g. [17:54:48] hm, damn, I read the diff the wrong way round [17:55:10] kinda fishy how that & got in there in the first place, but that commit was actually *removing* it, so now it makes sense [17:56:37] TheSeven: yes, it removes the "&" [17:56:59] and yes, this was one of the reasons why the release was broken, on nano2g [17:57:24] i ran into it personally, right after you released the previous version [18:00:51] so now the next step would be porting the new USB code base to UMSboot [18:01:26] (well, assuming that the generated binaries actually work, now that this thing finally compiles again) [18:02:22] I've switched it to the latest TNT toolchain now, which is based on linaro GCC [18:04:20] *** Joins: benedikt93 (~benedikt9@unaffiliated/benedikt93) [18:31:00] *** Quits: benedikt93 (~benedikt9@unaffiliated/benedikt93) (Quit: Bye ;)) [20:03:09] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [20:03:09] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [20:19:19] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Read error: Connection reset by peer) [20:19:44] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [20:29:35] hm, my emcore build panics during boot [20:29:50] looks like a null pointer call [20:35:04] hm, something hooks a timer IRQ to a null pointer [20:40:34] hm, only happens on nano2g, not on the classic [20:41:40] on the classic it looks like HDD access is broken though [20:43:30] hm, ipod classic installer crashes with garbage text printed to the LCD console. WTF. [20:46:28] * TheSeven loves this kind of odd breakage [20:51:34] can someone get me the emcore.elf file of an svn head nano2g build using the old rockbox toolchain? [20:51:34] user890104? [21:22:12] hm, this is a timing problem [21:22:20] the code is too fast with the new toolchain [21:22:43] one microsecond of delay in the right spot (end of the timer IRQ handler) fixes it for some reason [21:54:00] * user890104 tries to find his ubuntu VM image, that has his fmi-related development tools installed [21:54:32] I think the kernel is running fine now, but elf2emcoreapp is broken as well [21:54:54] elf2emcoreapp compiled on my machine, never worked for me [21:55:20] hopefully, i have a build of yours, that runs fine on my machine [21:55:23] or wait... that's already broken in the elf. wtf. [21:58:51] hm, looks like it got screwed with during linking [21:59:05] something's trashing the constant pool [22:01:46] disassembly: http://pastie.org/pastes/8171787/text (check those .word lines) [22:04:42] source code after macro expansion: http://pastie.org/pastes/8171803/text [22:05:36] kinda funny that not only the explicit .ltorg pool in there is smashed, but also the one generated by gcc for the additional constants [22:06:54] hm, or maybe these constants are even correct [23:01:28] ok, so elf2emcoreapp isn't generating any relocation info for some reason [23:01:47] user890104: is that also the problem that you were observing? [23:39:58] <[Saint]> TheSeven: pounce on bluebrother in #rockbox re: rbutil [23:40:09] <[Saint]> he's really the man to speak to about such things [23:42:00] <[Saint]> (and currently talking about an rbutil integration much weirder than the classic needs ;))