[00:34:38] TheSeven: i'm almost done with the complete build process (including the dfu bootstrappers for classic and nano4g) [00:35:01] i just need to encrypt the n2g image [00:39:30] make: *** No rule to make target `ls.x', needed by `build/installer-ipodnano4g.elf'. Stop. [00:39:40] uhm... is this supposed to build at all? :) [00:56:50] TheSeven: your ipod classic build of rockbox works fine on my win7x64 laptop \o/ [00:57:48] i got lucky and transferring it using disk mode (because i had screwed up the fallback image) didn't corrupt anything [00:58:17] i'll finish the n2g build and let you know [00:58:37] btw n4g also works with svn head (usb too) [00:59:35] updated/signed bootstrappers: http://files.freemyipod.org/~build/tools/ [01:00:14] they look good to me, i can replace the ipodclassic one that's used for installation if you don't mind [01:09:21] a working installer that has your build as a fallback image: http://files.freemyipod.org/~build/apps/installer-ipodclassic.ubi [01:21:05] TheSeven: there's a difference in how usb hid behaves on classic and n2g [01:21:17] on classic, it installs fine but does nothing [01:21:51] on n2g, it also installs but windows shows error 10 on the hid device (device cannot start) [01:23:43] uhm... 350 kB/s write speed on n2g [01:25:02] * TheSeven wonders if that was any better with the old driver [01:25:48] user890104: can you post your review results on gerrit? [01:26:57] yeah, i just want to test it without hid first [01:27:04] read speed is around 650 kB/s [01:27:23] n2g installer: http://files.freemyipod.org/~build/apps/installer-ipodnano2g.ubi [01:55:32] TheSeven: can you debug a rockbox crash? [01:56:13] stack overflow, pc: 08069130 sp: 00008158 A: 08069188 [01:56:56] triggered by switching themes on n2g, the last one (which triggered it) was "Rockbox modern" [01:57:18] and i was using your build [02:01:51] also, ROLO is still broken on n2g, it locks up at a point where Executing is drawn over Flushing storage buffers [02:02:08] so it reads "Executingtorage buffers" :) [02:03:49] but it works on the classic [02:11:09] TheSeven: speed with hid disabled (n2g): read ~5 MB/s, write ~2.7 MB/s [02:12:33] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:12:33] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [02:12:34] also, if i eject and enable hid, then connect it again, it looks like it crashed (but windows still enumerates the usb device up to some point, then gives up and lists it as non operational) [02:16:10] with hid enabled, read speed = write speed = ~750 kB/s [02:16:27] (my pc was overloaded when i got the lower results) [02:16:59] i'll sum these up tomorrow in gerrit, going to sleep now [02:18:40] user890104: so the slow transfer speeds are obviously related to HID problems, and HID doesn't work anyway [02:18:55] => we should disable it in any official builds for now, but we should of course find the cause regardless [02:21:10] haven't tested if this is true for classic [04:24:34] *** Joins: go2m (~goomba@cpe-72-177-176-215.satx.res.rr.com) [04:48:07] <[Saint]> Holy shit. [04:48:14] <[Saint]> I just read the logs from *-support. [04:48:31] <[Saint]> I don't thinkl we can take *anything* that guy has said, in past or in future,seriously. [06:16:17] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 252 seconds) [06:17:56] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [06:55:42] *** Joins: steffengy (~quassel@p5088FA13.dip0.t-ipconnect.de) [06:58:32] *** Quits: steffengy1 (~quassel@p5088F782.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) [07:37:23] *** Joins: goom (~goomba@cpe-72-177-176-215.satx.res.rr.com) [07:38:23] *** Quits: go2m (~goomba@cpe-72-177-176-215.satx.res.rr.com) (Ping timeout: 264 seconds) [07:46:21] *** Quits: goom (~goomba@cpe-72-177-176-215.satx.res.rr.com) (Quit: Leaving) [08:12:33] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [08:12:33] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [11:34:05] *** Quits: krnlyng (~liar@83.175.90.24) (Quit: huiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii) [11:38:46] *** Joins: krnlyng (~liar@83.175.90.24) [14:12:31] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:12:32] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [14:36:35] [Saint]: there are two things that one can at least attempt to do: [14:37:03] 1. a single-click solution. if there is just one step to be done, one can't possibly mix up steps or do other nonsense in between. [14:37:14] 2. just try to keep that kind of users away from us ;) [14:39:11] <[Saint]> Pessimistic it may be, but I have the feeling that guy would have the ability to fuck up, or convolute, even the simplest of tasks. [14:39:24] <[Saint]> People like him fuck things up. Its what they do. [18:23:52] looks like the recent USB changes broke the emCORE USB console [18:40:06] i only tested getprocinfo just to see if there's any usb communication [20:12:32] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [20:12:32] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [20:57:18] * TheSeven has a funny idea [20:58:47] * user890104 wonders what it is [21:01:44] * TheSeven considers adding the old bulk interface back into the emcore debugger [21:02:03] at least while no other apps use usb [21:02:58] and then I'm going to make a mini-kernel based on UMSboot's framework which emulates the memory up/download and exec parts of emcore's interface, as a replacement for ibugger [21:03:42] what for? [21:04:04] mostly because I don't want to debug why ibugger doesn't work anymore when launched through emcore [21:04:24] and I need something much less invasive than emcore to poke into the OF boot process [21:05:05] and the bulk interface is needed for transfer speed reasons [21:05:26] uploading an OF image or even downloading a full memory and HW state dump is painfully slow with the EP0 interface [21:05:36] that 64 byte block size really hurts it [21:05:42] with bulk we can easily do 256K at once [21:06:05] and zero-copy on top of that ;) [21:06:10] yeah, performance of emCOREFS via EP0 sucks^H^H^H^H^His really bad [21:06:21] ...another reason to get bulk back in [21:06:37] i was thinking about something like a "debug helper" app [21:06:50] I think I'm going to register it as kind of a "default app" of the USB manager [21:06:58] but built into the kernel [21:07:15] i see [21:07:39] I'd like to avoid the need for libemcore to have a set of target-specific binaries to upload [21:07:55] and given how trivial this thing is, it won't really enlarge the kernel either [21:08:20] I'll keep it isolated from the other interface though [21:08:57] so it's going to be an app (a separate thread), but launched by default (like initthread)? [21:09:05] it will just present two endpoints in the interface, which you can start a transfer on by sending a control request directed to that endpoint [21:09:12] it's threadless [21:09:17] just a bunch of callbacks [21:09:57] basically just two endpoint descriptors/objects added to the interface with a SETUP received callback and maybe a transfer finished one [22:39:38] user890104: should basically be this: http://paste.pm/hci.c [23:21:31] wow. that worked first try. [23:21:35] both ipod and pc side