[00:04:29] i have such binary, and even embedded it in one of my test installers (as a menu option in Tools, in the same place as on nano2g) [00:05:42] why shouldn't we have it automatically generated? it shouldn't hurt [00:10:35] I just wouldn't waste time on that at this point [00:10:56] getting the whole UMS thing into an enduser-compatible shape is a lot more important [00:17:09] i mean after getting all of the ums stuff done [00:20:00] how should i name the final app? umsd? [00:27:06] Disk Mode :P [00:29:47] i mean the actual app (*.emcoreapp) [00:30:25] and the corresponding svn folder [00:31:38] hm, just diskmode? or umsd if you like that better, but it isn't self explanatory at all [00:32:01] ok, diskmode sounds good [02:11:09] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:11:10] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [06:36:12] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 245 seconds) [06:37:37] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [08:06:20] *** Quits: Elfish (amba@84.201.30.174) (Remote host closed the connection) [08:11:05] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [08:11:06] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [08:43:12] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [08:44:07] *** Joins: [Saint] (~saint@rockbox/staff/saint) [10:19:31] *** Joins: n1s (~n1s@nl118-168-30.student.uu.se) [10:19:31] *** Quits: n1s (~n1s@nl118-168-30.student.uu.se) (Changing host) [10:19:31] *** Joins: n1s (~n1s@rockbox/developer/n1s) [11:03:58] TheSeven: my first attempt at a diskmode app crashes emcore's kernel :) [11:05:19] http://paste.pm/g87.c [11:07:00] what kind of crash? [11:08:06] http://paste.pm/g88.js [11:09:38] i.e. just freeze? [11:09:44] looks like it happens when i call storage_read_sectors_md [11:09:45] yes [11:09:57] a few hints: [11:10:05] and the lcd console text is corrupted [11:10:13] 1. don't reallocate the transfer buffers for every transfer [11:10:47] get two 64K buffers for double buffering or something [11:11:04] how is the lcd console corrupted? [11:11:13] junk at the lower end? [11:11:19] and the upper [11:11:57] can be artifacts from DMA continuing after the crash [11:12:25] http://i.imgur.com/anYz6Tp.jpg [11:12:55] yeah, that's a typical pattern [11:13:38] i know that it's not a good idea to allocate buffers on every operation, that's just a test version [11:13:44] not quite sure what's causing that, but it happens often after a freeze [11:14:14] i'm trying to make it work somehow, then i'll optimize it [11:14:15] so you're sure that you're getting stuck in storage_read_sectors_md? [11:15:07] if so, try making that call fail (e.g. by passing an out of bounds sector number) [11:15:29] i made it fail by passing an unaligned pointer [11:15:44] then i used memalign instead of malloc :) [11:16:03] oh, I think I see the problem already [11:16:10] how do i print a pointer using cprintf? [11:16:27] how do you define "printing a pointer"? [11:16:35] the address where it points [11:16:45] %08X or something? [11:17:23] cprintf doesn't care if the number to print is a pointer or not ;) [11:17:53] but the problem is trivial [11:18:14] you're calling the console and storage APIs from IRQ mode [11:19:33] ah [11:20:33] you'll definitely need a worker loop in your main thread [11:21:04] while (!ejected && usbmanager_get_connected()) sleep(200000); [11:21:05] here? [11:21:07] yes [11:21:22] replace the sleep [11:21:56] you'll need a wakeup to notify it from IRQ mode [11:22:22] then "sleep" by blocking on that wakeup with a timeout for polling the connected state [11:22:43] (and of course handle any other work if the wakeup has fired) [11:23:19] well, that's more complicated that i thought [11:25:21] what units does sleep use? miliseconds or microseconds? [11:25:33] everything is microseconds in emcore [11:29:23] so just replace the sleep(200000); with a wakeup_wait(&your_wakeup, 200000); [11:29:43] if that returns THREAD_OK, someone woke it up [11:29:48] i.e. there's work to do [11:30:01] otherwise it will return THREAD_TIMEOUT [11:30:39] then do a wakeup_signal(&your_wakeup); from IRQ mode if you need to defer some work to usermode [11:31:12] oh, and don't forget wakeup_init(&your_wakeup); of course [11:31:25] your_wakeup is a struct wakeup [11:31:39] so wakeup_signal exits irq mode, then returns? [11:31:47] no [11:32:05] wakeup_signal wakes up your main loop, then returns [11:32:29] so after that, if you return from the IRQ handler, at some point your main loop will continue [11:32:49] there's no way to do long-running things synchronously from IRQ mode [11:35:12] how do i declare variables that are shared between irq and the other code? volatile? [11:37:43] I don't think you need that [11:38:34] from usermode things should basically look like wakeup_wait() did whatever happened in IRQ mode [11:39:35] you will of course need to take care of the case that the usermode code is in the middle of doing something when an IRQ comes in [11:41:27] however as there can't be multiple SCSI requests at the same time, the IRQ really shouldn't ever want to request something from userspace while that's already doing something [11:42:16] you don't need to worry about race conditions with the wakeup itself [11:42:25] the kernel takes care of those [11:46:22] rockbox handles this problem at an interesting level: [11:46:39] they defer the whole USB transfer completion handling to userspace [11:48:29] not sure if that's a good idea though [12:18:53] TheSeven: can you spot the mistake: http://paste.pm/g89.c [12:19:33] i'm reading different data on every read (and probably writing too) [12:20:24] line 300 [12:20:26] 399 [12:21:54] you're sending the read result before the read actually happened [12:22:03] you need to move that to the userspace part [12:22:58] ah ... [12:23:21] what about the rest of the code? [12:24:59] cur_cmd.sector += maxlen / storage_info.sector_size; [12:24:59] cur_cmd.count -= MIN(cur_cmd.count, maxlen / storage_info.sector_size); [12:25:31] can probably also be moved to userspace [12:25:43] ok [12:26:37] where does the CSW for a write get sent? [12:27:41] ah right [12:27:46] hm, another few bugs there [12:28:15] 1. you don't make sure that a write actually completes before queueing the next one, trashing the buffer of the previous one [12:28:55] 2. what are you doing in line 677? [12:29:26] why are you queueing a write there? I don't think you even have any data to write there yet [12:31:33] well i just replaced the ramdisk reads and writes with the storage api, haven't looked what the code actually does in details [12:32:11] I wouldn't have expected a ramdisk write there... [12:32:28] let me have a look [12:34:00] oh, I see the reason [12:34:09] hint: receive_block_data is ASYNC [12:34:33] that's just *starting* an RX transfer on a buffer [12:35:04] so you can't just write to disk after that call [12:35:11] you need to move that to handle_xfer_complete [12:35:24] in fact you have another one there, but in the wrong place as well [12:35:47] currently you're losing the last block (the send_csw(0) case) [12:36:16] completely kill the line 677 block [12:36:28] and move the line 769 block into line 762 [12:36:30] then it might work [12:38:48] so i leave just the receive_block_data() call at line 675? [12:39:05] yes [12:39:09] ok [12:49:08] *** Joins: Elfish (amba@2001:1608:12:1:13:3:3:7) [12:57:58] TheSeven: storage reads seem to work [12:58:14] http://paste.pm/g8b.c [12:59:39] and why the hell windows reads the first 28593 sectors? looks like read caching [13:00:19] also, trying to unmount a corrupted filesystem produces a data abort [13:01:06] i seem to be missing something about the writes, and the filesystem gets corrupted [13:06:50] [12:28:15] 1. you don't make sure that a write actually completes before queueing the next one, trashing the buffer of the previous one [13:06:59] how do i check if the write completed? [13:08:15] that's the most recent code: http://paste.pm/g8c.c [13:11:15] user890104: windows reads the whole FAT while connecting [13:11:47] ah, i see [13:12:37] start RX of the next packet when the write finishes (from userspace) [13:13:07] (for good performance this will need double buffering) [13:16:52] also, try to locate the code line that data aborts on unmount [13:24:30] i think i fixed the writes: http://paste.pm/g8d.c [13:31:51] TheSeven: what should i set SCSI_FORMAT_CAPACITY_FORMATTED_MEDIA to? [13:32:02] it's used here: [13:32:03] tb.format_capacity_data.block_size = htobe32(storage_info.sector_size); [13:32:03] tb.format_capacity_data.block_size |= htobe32(SCSI_FORMAT_CAPACITY_FORMATTED_MEDIA); [13:32:52] I think that's just a flag bit [13:32:56] no need to mess with it [13:35:26] how do i implement double buffering? [13:36:10] i get a transfer speed of ~10MB/s (without the cprintf code) :) [13:36:17] Many people have asked that :) [13:36:45] that's actually MUCH better than I had expected ;) [13:38:07] user890104: so does it seem to work reliably now? [13:45:36] TheSeven: yes, it does [13:45:49] gevaerts: do you have any insight on whether windows properly caches USB drives? [13:45:50] i'm installing rockbox at the moment, using the diskmode app [13:46:07] as in: would it make sense to add a few MB of block level cache on the device? [13:46:29] TheSeven: it's been a while, but I seem to remember it depends on things like the removable bit [13:46:50] I've never been able to fully understand windows/rockbox performance :) [13:47:11] Well [13:47:18] I figure it will always so reasonably good read caching, so keeping an MRU cache of read blocks is probably pointless [13:47:23] I *hope* it does some read caching [13:47:29] * gevaerts nods [13:48:20] Write caching is where possible gains are, if you can do things like reordering, or just plainly not writing things like the FAT for a while [13:48:27] write caching would also only help by optimizing the pipelining of writes, or if the same block is written multiple times (FAT?) [13:48:45] Thinking about that gave me a headache though, so I never got around to it :) [13:49:43] It might make sense to trace what blocks they write, and then look at the filesystem together with that trace and figure out exactly what they're doing [13:50:34] FAT write caching will hopefully only help with many tiny files [13:50:49] which isn't the typical workload here, except for rockbox updates [13:51:17] reordering... hm... [13:51:35] Well, it all depends! [13:51:58] If windows assumes you might unplug the device at any time, it could conceivably update the FAT after every few blocks [13:52:10] Or the directory entry [13:52:18] I don't know if it does either of those though [13:53:24] hm, in that case this is what I would do: write data to free blocks, write the clusterchain to the FAT, write the directory entry, done [13:54:22] anyway, seems like the best effort vs. performance tradeoff is likely just double buffering writes to pipeline them [13:54:40] That's a no-brainer I'd say [13:55:12] for reads... hm, we'll either have to read ahead or split up the reads into multiple operations [13:55:35] Yes [13:55:48] IIRC splitting didn't gain much [13:56:12] 50% split can only gain 50% performance while causing a 100% increase in overhead [13:56:23] Which device are you trying to optimise for? [13:56:26] 25% split can only gain 75% performance while causing a 300% increase in overhead, etc [13:56:32] ipod classic [13:56:37] FIY: windows reads the FAT sector by sector, while winhex reads it 8 sectors at a time [13:56:45] FYI* [13:56:49] Remember that hdds have their own caching and probably do readahead already [13:57:08] er, WHAT? windows reads the FAT in 4K chunks!? [13:57:19] So it depends on the transfer speed, not the platter read speed [13:57:20] during that initial scan? or after that? [13:57:27] during the initial scan [13:57:42] now that's bullshit [13:57:49] then it accesses it at 8 sectors/read [13:58:10] reading a few hundred MB of FAT data 4K at a time while mounting. wow, windows, you're dumb. [13:58:36] that's where the initial delay comes from [13:58:43] gevaerts: yes, these definitely do internal readahead [13:59:54] Well, if windows really does that, yes, you do want your own readahead :) [14:00:13] Disk IO may be cheap with dma and disk-side readahead, but it's not *free* [14:00:51] If you do double buffering, it can be effectively free for writing though [14:01:09] as we can't easily cancel disk I/O, I'd go for an adaptive system which enables reading ahead if there were like 8 consecutive read ops [14:01:14] i have successfully installed rockbox and the full set of themes for ipodclassic, uploaded some tracks and got rockbox to play them [14:01:18] using the diskmode app [14:01:22] and disables it after a few consecutive misses [14:01:44] TheSeven: I'd consider just rounding up to sensible sizes [14:02:23] If you pick 64k, that won't impact "normal" transfers at all [14:02:41] And it's low enough not to make much of a difference to the disk IO time I'd expect [14:02:50] * gevaerts remembers that on ipod video his naive ramdisk implementation was *slower* on write than the hdd with dma [14:08:10] I guess it will have a noticable impact on things like enumerating the directory tree [14:08:35] so my approach would be to have a 2x 64KB aligned readahead buffer [14:11:05] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:11:05] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [14:11:39] so to make things easier I'd allocate a total of four 64KB chunks: two for read and two for read [14:11:50] er, lol [14:11:57] two for read and two for write of course [14:12:50] always one "current" and one "next" one, which swap roles after each chunk [14:12:56] for write: [14:14:20] receive data to next, ensure that userspace is done, swap buffers, enqueue userspace write for current [14:19:41] TheSeven: would you like to test the performance of the app on linux? i have commited the source code to the svn [14:20:11] (i can send you a build if you don't want to waste time building it) [14:21:20] how do I access SVN these days? [14:21:31] I'm getting connection refused on https://svn.freemyipod.org [14:21:31] svn://svn.freemyipod.org/ [14:21:58] yes, i haven't had the time to setup SSL [14:22:15] but for committing there's SVN+SSH access [14:23:33] so your code is still in umstest? [14:24:23] no, it's in apps/diskmode [14:24:46] ok [14:26:48] There's one detail you don't want to miss [14:27:02] Make sure you invalidate the read buffers if there's a write to those blocks [14:27:09] (or copy them over) [14:27:58] uhm, it seems that the commit faile for some reason [14:28:07] now why does emcore.py not find my ipod [14:29:00] did you update libemcore.py? [14:29:13] I did an svn up on the whole tree [14:29:26] Oh, and also, check for end of disk. You don't want to do wrong stuff if the host asks for end of disk - 32K :) [14:32:27] *** Joins: bcobco (~bcobco@77.225.204.119) [14:34:05] hm, neither finds the ipod with python 2 nor 3 [14:34:39] seems like it uses libusb 1.x shipped with my distro [14:34:46] (wow, they indeed finally ship that!) [14:35:09] er, pyusb, not libusb [14:35:57] and still only in the PPA :/ [14:39:53] about the caching and that stupid microsoft os that reads sector by sector, can we just read the whole FAT table in RAM, then use it as a read cache, and discard it permanently (well, until the app is restarted) after the first FAT table write? [14:40:52] the FAT can be much bigger than 100MB [14:41:10] and to make matters worse there's two copies of that [14:41:16] ah, ok then [14:41:42] now how do I get my emcore.py working... [14:42:25] well, i might have broken it with my changes [14:43:46] that's what i changed: http://websvn.freemyipod.org/comp.php?repname=freemyipod&compare[]=/@911&compare[]=/@912 [14:53:35] user890104: seems like my ipod reports class ff:ff:ff while you're looking for ff:00:00 [14:53:58] well... it's supposed to be ff:00:00 [14:54:10] that's class ff, subclass 0 [14:54:25] and proto 0 [14:56:51] damn [14:57:05] we need to get a release out with the new USB protocol ;) [14:57:33] and the disk mode app? :) [14:57:40] yes [14:59:18] first we have a couple of issues to deal with: [14:59:28] 1. data abort in disk_unmount() [14:59:35] 2. data abort in rename() [14:59:39] :) [15:00:16] tell me the code lines! [15:00:18] can we update our fs/storage drivers from rockbox? [15:00:31] you can try to do so if you want [15:00:35] it could have been fixed in the meantime [15:00:41] I doubt that [15:02:29] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [15:02:55] *** Joins: bcobco (~bcobco@77.225.204.119) [15:03:44] argh. my toolchain is broken. [15:04:07] you can use freemyipod.org's server if you want [15:04:13] rebuilding that will take a while [15:04:26] it has the toolchain installed, and it's *fast* [15:04:27] but I'll have to do it for something else as well [15:05:03] i can make a shell account for you [15:33:40] hm... umsboot doesn't compile with the new toolchain [15:33:57] weird "undefined reference" errors [15:45:58] gcc (Linaro GCC 4.7-2012.08) 4.7.2 20120731 (prerelease) [15:46:01] that's my version [15:46:13] of the TNT toolchain [15:46:19] host version: gcc (Ubuntu/Linaro 4.6.4-1ubuntu1~12.04) 4.6.4 [15:46:40] I've just built latest TNT [15:46:48] and it seems to have some bug :/ [15:47:19] use 4.7 then [15:47:33] $ arm-none-eabi-ld --version [15:47:33] GNU ld (GNU Binutils) 2.24 [15:47:54] $ arm-none-eabi-gcc --version [15:47:54] arm-none-eabi-gcc (GCC) 4.9.0 20140316 [15:48:40] everything from the project builds fine with 4.7 [15:48:49] and my ld is 2.22 [15:49:19] I think I was on something newer than 4.7 before [15:51:15] well, this versions seems to work fine, so i won't update it until something breaks because of that :) [16:20:43] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [16:21:10] *** Joins: bcobco (~bcobco@77.225.204.119) [16:30:22] * user890104 makes a menu entry for disk mode in the classics' boot menu [17:00:52] * TheSeven still wonders what kind of weird symbol problems the new GCC has [17:01:06] too bad I'll run into the very same mess with my STM projects as well :/ [17:03:24] i have some weird gcc issues when compiling emcorefs [17:03:39] gcc 4.4 works fine, while gcc 4.5+ doesn't [17:04:54] http://paste.pm/g8e.js [17:05:28] (the second command line is the successful build, no error messages) [17:06:05] btw: running umsboot from the non-themed bootmenu locks up the ipod [17:08:02] user890104: that one is simple [17:08:10] make -lusb-1.0 the last argument and it will work [17:08:39] hm, and move -lfuse to the end as well [17:08:58] CFLAGS += -O2 -Wall -Wextra -Werror $(shell pkg-config --cflags --libs fuse libusb-1.0) [17:09:14] which one of these should be last? :) [17:10:06] ah, now it works. thanks! [17:10:40] newer gccs discard symbols in libs that aren't requested before they're imported [17:14:40] in my case it's doing *something* to the symbols that apparently prevents ASM code from using them [17:15:02] seems like moving the whole pkg-config output to the end of the gcc command line works fine [17:15:17] yes [17:16:17] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [17:16:38] so they must be after the source files, right? [17:16:39] *** Joins: bcobco (~bcobco@77.225.204.119) [17:16:56] yes [17:17:20] and if the libs need each other it gets even more funny [17:40:44] [17:06:04] btw: running umsboot from the non-themed bootmenu locks up the ipod [17:40:53] TheSeven: any ideas about this one? [17:41:02] not at all [17:45:13] it's happening at random [17:49:06] what should we do when the user exits disk mode? launch the bootmenu? [17:49:37] sounds like a plan [17:56:55] we need a window manager and a task switcher/manager :) [17:57:01] lol [17:57:37] i forgot file manager, too [17:58:36] actually, drawing the bootmenu's framebuffer over the console's framebuffer over and over, while scrolling the clickwheel in debug mode, locks up the ipod at some point [18:06:50] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [18:07:14] *** Joins: bcobco (~bcobco@77.225.204.119) [18:34:18] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [18:35:12] *** Joins: bcobco (~bcobco@77.225.204.119) [18:46:37] *** Quits: Elfish (amba@2001:1608:12:1:13:3:3:7) (Ping timeout: 245 seconds) [18:56:41] TheSeven: is SMART implemented in rockbox? [19:02:25] no [19:02:32] and that's exactly the reason why we need it here ;) [19:09:14] ah, i see [19:26:45] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [19:27:09] *** Joins: bcobco (~bcobco@77.225.204.119) [19:52:47] *** Joins: Elfish (amba@2001:1608:12:1:13:3:3:7) [19:56:00] * user890104 thinks about how cool would be to write an emcore app for nano4g that would expose the internal accelerometer as an usb hid game controller [20:11:06] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [20:11:06] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [20:22:06] *** Quits: bcobco (~bcobco@77.225.204.119) () [20:24:28] *** Joins: bcobco (~bcobco@77.225.204.119) [20:31:29] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [20:31:54] *** Joins: bcobco (~bcobco@77.225.204.119) [20:33:33] *** Quits: n1s (~n1s@rockbox/developer/n1s) (Quit: Ex-Chat) [20:34:01] <[Saint]> I'm not sure how I feel about this work. [20:34:49] <[Saint]> It seems kinda odd to pile work into a third party boot loader based filesystem shim to work around no one wanting to touch USB in Rockbox proper. [20:50:12] [Saint]: that's fighting talk! :) [20:57:16] [Saint]: fixing USB in rockbox could break something else [20:57:39] having a separate emCORE app that does mass storage can be debugged more easily [20:58:24] and it's surely the quicker way to get SMART going [20:59:02] also rockbox is much easier to get into a state where it will lockup during boot etc. [20:59:14] you need something to recover from such situations [20:59:56] heck, I'd even have a go at fixing rockbox's USB problem if I could even reproduce it! [21:00:55] That's easy to fix! [21:01:00] Start with the nano2g one :) [21:03:26] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [21:03:52] *** Joins: bcobco (~bcobco@77.225.204.119) [21:05:02] TheSeven: any idea where should i start looking for information on how to implement SMART? [21:05:21] maybe the linux scsi drivers? [21:05:24] smartmontools source code [21:05:53] I think Torne once looked at SMART [21:06:06] also http://sourceforge.net/apps/trac/smartmontools/wiki/USB [21:07:34] ANSI INCITS 431-2007 [21:09:43] ush, is there an emCORE API to send ATA commands from an app? [21:09:48] uhm* [21:11:42] not yet, that will need to be added [21:11:44] http://www.t10.org/cgi-bin/ac.pl?t=f&f=sat3r05b.pdf [21:11:55] (the form will happily accept any junk) [21:12:49] One of the required fields was missing, your email address is not valid, or you did not click the checkbox saying you agree to the INCITS Guest Notification. [21:12:58] i guess i entered way too much junk :) [21:13:56] you can ignore anything before chapter 12 [21:15:21] just those two commands? sound easy [21:15:52] <[Saint]> What happens to this work going forward? I mean, is the idea still a stable Rockbox port, or is freemyipod forking? [21:16:20] <[Saint]> As we know emCORE isn't coming with it, if a stable port is the intention. [21:16:27] the emcore code base is easier to experiment with [21:16:34] <[Saint]> So, what happens to fancy filesystem shim? [21:18:22] I currently don't see a viable plan to fully integrate the required components for it to work on its own into rockbox [21:19:31] so emcore will be around for a while, and we can make use of it to help work around problems [21:19:44] <[Saint]> I thought you had your own driver you suspect would make all this just go away? [21:20:23] <[Saint]> I seem to recall talk of this from many many moons ago. [21:20:25] yes, but it needs to be ported to rockbox [21:20:37] and that's also just part of the problem [21:21:17] the emcore disk mode app is the quicker way to get USB mass storage through the new driver [21:21:33] porting it to rockbox should of course be done nevertheless [21:22:11] <[Saint]> I guess what I'm saying is that if the intent is to get a stable port, shouldn't things move /away/ from emCORE? This work seems to (for now at least) make the bonds even tighter. [21:22:31] <[Saint]> Forgive my possible ignorance here if there's something I'm missing. [21:23:26] do you have a plan for that? [21:23:31] it's a hell of a lot of work [21:23:33] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [21:23:56] *** Joins: bcobco (~bcobco@77.225.204.119) [21:24:01] I'd rather have something that works now, than an ideal solution that's never finished [21:25:15] <[Saint]> While I agree in part, its problematic as it means the "right" fix is even less likely to eventuate. [21:25:35] <[Saint]> And the port will be stuck in limbo. [21:25:56] <[Saint]> ...unless you guys fork, of course. [21:26:04] fork what? [21:26:06] Fork *what* exactly? [21:26:14] i have a plan: using libwdi for installing dfu drivers from rockbox utility, making a working port of ipoddfu.py to C (unlike mine, which doesn't work), making a rockbox bootloader based on emcoreldr, ???, profit! [21:26:14] * gevaerts is confused [21:26:36] <[Saint]> Rockbox for the 6G. So the project has a future in one place. [21:27:22] I don't see how a fork would help anything [21:27:59] me too [21:28:55] we should be able to provide an app that installs emcore then launches rockbox utility [21:29:10] but i would prefer if rbutil does all of this stuff [21:29:21] no, we should integrate installing emcore into the rockbox utility [21:29:29] yes, exactly [21:29:29] exactly [21:29:31] :) [21:30:12] <[Saint]> That's the problem I'm thinking of, or part of it, would emCORE ever be the official boot loader? [21:30:28] <[Saint]> I was under the impression that flatly wasn't happening. [21:30:34] you won't have another choice for now [21:30:51] <[Saint]> That doesn't mean rbutil need support it. [21:31:14] well, unless someone steps up to reimplement the required parts of it in rockbox of course [21:31:38] the thing about the classics is that it's the one kind of ipod that definitely NEEDS to be NOR-flashed [21:31:50] a thing that rockbox was trying to avoid all the time [21:32:07] so this doesn't map well onto rockbox's current installation and boot infrastructure [21:32:38] <[Saint]> Which brought me to my line of thinking where freemyipod took over completely. [21:32:39] unless we find a signed .ipsw with one of the old firmwares, so we can fool norloader into booting our stuff [21:33:16] but that's only for 1g, not sure if there's a vulnarable 2g/3g version [21:33:23] there isn't [21:34:00] sticking with the apple bootloader on the classic is just nonsense [21:34:34] so rockbox needs a nor-based bootloader which does at least offer a disk mode [21:34:52] and what about dualboot? there's a bug in the i2c driver IIRC, right? [21:35:16] yes, we know the dualboot problem is related to i2c somehow [21:36:34] any way to debug it further? for example a logic analyzer connected to the i2c pins on the board? [21:38:10] no, it's apple's driver that gets the i2c interface into a locked up state if we've previously talked to it [21:38:39] so you basically need to debug apple's code [21:38:56] can we patch it, then flash the loader back? [21:39:01] or attempt to capture the difference in register states between an apple-only boot and an emcore boot [21:39:08] like we did with the volume limit on nano2g [21:39:19] and a dec-hex bug IIRC [21:39:34] we first need to find out the reason [21:39:45] the i2c interface of this chip is a bit odd [21:40:47] there's some weird glue logic between the APB and the actual I2C bus logic [21:51:36] *** Quits: bcobco (~bcobco@77.225.204.119) () [21:53:49] *** Joins: bcobco (~bcobco@77.225.204.119) [22:15:43] TheSeven: do you know which SoCs of the S5L87xx series support USB OTG? [22:16:00] all of them IIUC [22:16:29] why are you asking? [22:17:02] i just remembered there is an ipodlinux app to transfer data between two ipods [22:17:15] and i'm wondering what they used [22:17:32] ipodlinux isn't s5lxxxx [22:17:36] ah, the ipodlinux mirror is down [22:17:40] yes, i know it's PP [22:17:41] I guess they probably used firewire for that [22:18:35] i see [22:19:26] anyway, implementing a host-side usb stack sounds way too complicated for me [22:27:08] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [22:27:32] *** Joins: bcobco (~bcobco@77.225.204.119)