| 00:02:48 | | Quit Topy44 (Ping timeout: 240 seconds) |
| 00:06:40 | dfkt | does anyone know which four color/brightness hex values a 2 bit screen can display without interpolating? |
| 00:07:08 | dfkt | besides 000000 and FFFFFF i mean :) |
| 00:07:41 | funman | dfkt: 0, 1, 2 and 3 |
| 00:08:51 | dfkt | that doesn't help for backdrop images |
| 00:09:08 | saratoga | does it just map everything above 0x0000003 to 3? |
| 00:09:26 | saratoga | thats how i'd do it |
| 00:09:32 | saratoga | (never looked at the code though) |
| 00:09:42 | dfkt | i tried straight values like 888888 or CCCCCC, but they look interpolated on screen, brigher and darker pixels |
| 00:12:23 | funman | dfkt: what's your source ? 24bits .bmp ? |
| 00:15:19 | dfkt | 4bit bmp |
| 00:15:41 | dfkt | lowest i can go in photoshop |
| 00:15:57 | dfkt | (besides 1bit) |
| 00:16:13 | | Quit ender` (Quit: Eskimos may have 50 words for snow, but in Slovenia have at least 60 words for the states of drunkeness.) |
| 00:19:14 | dfkt | hmm.. 666666 looks good, but its double, CCCCCC doesn't |
| 00:28:29 | pamaury | hmm, this is weird, the imx233 rtc keeps a second counter but it doesn't match the number of seconds since 1/1/1980 nor 1/1/1970 as set by the OF :-/ |
| 00:29:16 | funman | pamaury: can you track it down to the birth or death of someome famous? |
| 00:32:34 | TheSeven | gah, this usb driver is all flaky |
| 00:36:37 | TheSeven | dfkt: shouldn't it be 000000, 555555, aaaaaa and ffffff? |
| 00:36:54 | | Quit bluefoxx (Ping timeout: 240 seconds) |
| 00:37:44 | TheSeven | or, if the dithering algorithm is broken, something close to that at least |
| 00:38:15 | funman | TheSeven: you've seen todays logs / FS patch ? |
| 00:38:30 | TheSeven | no, i wasn't highlighted |
| 00:39:02 | TheSeven | hm, or rather I was highlighted, but that was apparently when I was in the car |
| 00:40:18 | pamaury | funman: Sun Aug 16 04:22:04 1970 approx |
| 00:40:41 | pamaury | I did asctime(localtime(time()-imx233_rtc_seconds)) basically |
| 00:41:35 | funman | TheSeven: FS #12497 |
| 00:41:36 | fs-bluebot | http://www.rockbox.org/tracker/task/12497 Reorganize USB initialization to make it work with FreeBSD (patches, unconfirmed) |
| 00:41:45 | pamaury | so it's indeed in 1970 but something is wron |
| 00:41:46 | pamaury | g |
| 00:42:35 | plush | TheSeven: and i am still around if there are any comments or problems with my patch |
| 00:43:16 | TheSeven | a quick glance at that discussion tells me that it's a separate issue |
| 00:43:25 | TheSeven | gevaerts: fyi |
| 00:43:45 | TheSeven | in my case there's already SCSI traffic, so the descriptors must be right |
| 00:44:15 | plush | i am doing a 5gb transfer using the thus-patched rockbox usb stack right now |
| 00:44:17 | plush | all rock solid |
| 00:44:28 | plush | 3.0 MiB/s, not blazing fast but working perfectly |
| 00:44:54 | * | TheSeven is hunting down a timing issue on the s5l870x chipset |
| 00:45:05 | gevaerts | plush: it's not going to make any difference after connecting |
| 00:45:25 | plush | gevaerts: this particular patch - no |
| 00:45:37 | plush | but remember, the freebsd usb stack is quite different from those you are used to |
| 00:45:38 | TheSeven | seems like enabling logf is sufficient to make it break intermittently on nano2g as well |
| 00:45:45 | dfkt | TheSeven, thanks, and no, these values don't work either - i decided to build the background lines with empty viewports instead. 0, 1, 2, and 3 work just fine :) |
| 00:45:50 | plush | so it's nice to see that the rest of the rockbox usb stack works smoothly with it |
| 00:46:06 | gevaerts | plush: yes, but you said it used to work :) |
| 00:46:20 | gevaerts | Apart from that initialisation, nothing has changed |
| 00:46:25 | plush | gevaerts: sure. it broke several months ago though. who knows what could have bitrotted since then... |
| 00:46:27 | plush | ah, ok |
| 00:46:30 | plush | i didn't know that |
| 00:46:52 | plush | though a lot changed on the freebsd side. i moved to a new release... the host usb stack is quite different |
| 00:47:01 | plush | so it's nice to see that there was just one small kink to work out |
| 00:47:10 | plush | i remember when there was no rockbox usb stack at all |
| 00:47:13 | gevaerts | Well, maybe 'nothing' is overstated (I didn't check), but for mass storage we handle the exact same SCSI commands in exactly the same way |
| 00:48:01 | gevaerts | I remember when the rockbox usb stack corrupted every 29th to 31st byte :) |
| 00:48:35 | plush | i remember when the usb stack was off by default |
| 00:48:46 | plush | back then, freebsd would panic if a mounted disk went away |
| 00:48:56 | plush | man did i rockbox my box many times... |
| 00:49:16 | plush | ... i just couldn't resist running the flaky usb stack |
| 00:49:55 | gevaerts | It worked well for me! |
| 00:51:07 | plush | it eventually worked well, absolutely |
| 00:51:13 | plush | but there were ups and downs |
| 00:51:20 | plush | and every down meant a panicked desktop |
| 00:51:26 | * | gevaerts nods |
| 00:55:20 | gevaerts | TheSeven: could you have a look if FS #12497 (a) works at all on s5l870x, and (b) still works if you define USB_DETECT_BY_REQUEST in config.h? |
| 00:55:21 | fs-bluebot | http://www.rockbox.org/tracker/task/12497 Reorganize USB initialization to make it work with FreeBSD (patches, unconfirmed) |
| 00:55:26 | gevaerts | No real hurry |
| 00:55:51 | *** | Saving seen data "./dancer.seen" |
| 00:56:32 | * | TheSeven first tries to make that driver work at all again :) |
| 00:57:16 | gevaerts | If it works with USB_DETECT_BY_REQUEST without any other changes, we can probably take out all non-USB_DETECT_BY_REQUEST code (which isn't much any more) and remove the define entirely. After that, work on unifying USB_STATUS_BY_EVENT :) |
| 00:58:04 | gevaerts | Yes, that would be useful. A similar situation on mr500 is why I couldn't test the (b) case yet :) |
| 00:59:17 | TheSeven | damn, reverting funman's changes doesn't fix the timing trouble |
| 01:00 |
| 01:01:35 | TheSeven | gevaerts: what are possible causes of rockbox staying on the USB screen even if i unplug USB, but leaving it if I briefly re-plug and unplug it again? |
| 01:01:58 | TheSeven | this looks like the USB thread's state machine might be getting confused |
| 01:02:18 | gevaerts | The obvious one would be not seeing the disconnect |
| 01:02:39 | TheSeven | this seems to be detected by repeatedly polling vbus, so i can't see how that could get lost |
| 01:02:46 | gevaerts | Are you USB_STATUS_BY_EVENT? |
| 01:02:54 | | Quit Xerion (Ping timeout: 252 seconds) |
| 01:04:50 | * | TheSeven greps |
| 01:06:10 | gevaerts | seems not, just usb_detect called from usb_tick() |
| 01:06:17 | TheSeven | apparently |
| 01:06:57 | TheSeven | so it looks like the EXTRACTED event is getting lost |
| 01:07:30 | gevaerts | yes |
| 01:07:49 | gevaerts | I can't think of another possibility right now |
| 01:10:17 | TheSeven | well it might got lost in the usb thread's event queue (but overflows do panic, don't they?) |
| 01:10:26 | TheSeven | or it might not be broadcast to the UI thread for some reason |
| 01:11:31 | funman | TheSeven: jethead committed a fix recently for ams bootloader |
| 01:11:35 | funman | might be related |
| 01:11:38 | gevaerts | Both sound unlikely |
| 01:11:47 | gevaerts | Well, everything sounds unlikely |
| 01:12:10 | TheSeven | i've seen rapid sequences of plugging and unplugging making it go completely bonkers, so there might be some race here |
| 01:14:13 | plush | if your model requires exclusive access to the disk, requests are sent to all other threads to let go of the disk |
| 01:14:30 | plush | these seem to never get retracted if you yank the cable before the other threads have reacted |
| 01:14:31 | gevaerts | plush: all models do that :) |
| 01:14:42 | plush | also, there is a very crude mechanism for dealing with lost acks |
| 01:14:54 | plush | it just forgets about outstanding requests after a while |
| 01:15:17 | plush | i can imagine that if you unplug and replug quickly enough, you can get this outstanding-ack-amount totally out of sync with reality |
| 01:16:24 | plush | given how little i know about the rockbox usb stack, my comments may alle be wrong for what i know |
| 01:16:28 | plush | at the same time, it is very late |
| 01:16:31 | plush | conclusion: bedtime |
| 01:16:32 | plush | nn |
| 01:17:43 | gevaerts | That sort of thing could explain rapid replugging giving problems, yes |
| 01:18:11 | * | TheSeven adds debugging output |
| 01:19:01 | TheSeven | looks like it's the USB_EXTRACTED event that never reaches the USB thread |
| 01:19:44 | gevaerts | Is it posted, or not even generated? |
| 01:19:44 | TheSeven | USB_EXTRACTED == 0, right? |
| 01:20:01 | gevaerts | yes |
| 01:20:20 | TheSeven | queue_post(&usb_queue, current_status, 0); is being called |
| 01:20:26 | TheSeven | and current_status == 0 |
| 01:20:57 | TheSeven | but case USB_EXTRACTED: in usb_thread isn't reached |
| 01:21:09 | gevaerts | ok, so either the queue overflows silently, or the thread loop is blocked somewhere |
| 01:21:21 | TheSeven | but in a way that makes replugging unblock it somehow |
| 01:21:47 | gevaerts | Which again seems unlikely |
| 01:22:37 | gevaerts | hm |
| 01:22:39 | TheSeven | looks like my re-plugging isn't even being detected |
| 01:22:45 | TheSeven | it just unblocks the thread |
| 01:22:53 | TheSeven | doesn't post another INSERTED event |
| 01:23:04 | TheSeven | it just continues the regular unplugging operation |
| 01:23:38 | TheSeven | it doesn't even reach the queue_post |
| 01:24:26 | gevaerts | Maybe (vague handwaving here) one of the usb_drv_*() calls is blocking on something unexpected? I haven't looked at the driver source |
| 01:24:27 | TheSeven | so the thread must be stuck in something that unsticks as soon as there is another IRQ or something |
| 01:24:56 | gevaerts | the queue_post? |
| 01:25:10 | TheSeven | the one in usb_tick doesn't even fire the inserted event |
| 01:25:17 | TheSeven | it wakes up nevertheless |
| 01:25:43 | gevaerts | Ah, you mean the second time? |
| 01:26:14 | TheSeven | yeah |
| 01:26:18 | TheSeven | the re-plugging |
| 01:27:13 | gevaerts | I guess the "three consecutive states must be equal" thing gives it just enough time to unblock the first one |
| 01:28:55 | gevaerts | I'd say it's probably stuck deep in usb_core_handle_transfer_completion() |
| 01:29:50 | TheSeven | would that block the usb thread? |
| 01:30:16 | gevaerts | That's called in the USB_TRANSFER_COMPLETION case, so yes |
| 01:30:41 | TheSeven | ok, the last processed event id before unplugging is 3 |
| 01:30:46 | gevaerts | Conceptually that should be a different thread, but that's a waste |
| 01:30:51 | TheSeven | and it doesn't change when unplugging |
| 01:31:33 | TheSeven | grr. now it hard locked after unplugging in the main menu :/ |
| 01:31:39 | TheSeven | backlight thread is still running though |
| 01:35:06 | TheSeven | gevaerts: where are all these event IDs defined? |
| 01:35:17 | gevaerts | usb.h |
| 01:35:53 | TheSeven | so, in my case, USB_TRANSFER_COMPLETION == 3? |
| 01:36:10 | gevaerts | yes |
| 01:36:26 | * | TheSeven wonders if anything uses that blocking tx function |
| 01:36:50 | gevaerts | Which doesn't mean much, because after you're connected, on a non-hotswap device you're only ever going to get transfer completions until you disconnect |
| 01:38:32 | gevaerts | control replies are usually sent using the blocking variant |
| 01:39:49 | TheSeven | yep, gets stuck in there |
| 01:39:59 | TheSeven | sending an 18 byte packet on ep0 which never gets acked |
| 01:40:13 | TheSeven | so this is actually caused by the same issue that's causing the mass storage trouble |
| 01:42:38 | | Join remlap1 [0] (~Patrick@190.28.169.217.in-addr.arpa) |
| 01:43:32 | gevaerts | That's probably good. Looking for one bug is nicer than looking for two bugs :) |
| 01:44:07 | | Quit remlap (Ping timeout: 240 seconds) |
| 01:45:55 | TheSeven | hm, the state of the endpoint before setting up the transfer is ENABLE ACTIVE NAK |
| 01:46:03 | TheSeven | and a reserved bit :/ |
| 01:47:03 | TheSeven | ah, right, that's endpoint traversal order stuff |
| 01:47:19 | TheSeven | ok, so that EP should be NAKing all requests that it gets |
| 01:53:37 | TheSeven | after setting it up it's stuck trying to TX the packet, so apparently the host isn't attempting to read it any more |
| 01:53:57 | | Quit pamaury (Remote host closed the connection) |
| 01:54:06 | TheSeven | grrrr |
| 01:54:27 | * | TheSeven was just about to ask pamaury whether he still has the sniffer, and if yes, whether he can get hold of a nano2g |
| 02:00 |
| 02:01:36 | dfkt | i cleaned the x5 uisim image, if someone's interested to update that in svn... before: http://img.elektrokrishna.com/images/13412775178824696756.bmp - after: http://img.elektrokrishna.com/images/85325079796256414883.bmp |
| 02:03:00 | dfkt | that one was *really* dirty ;) |
| 02:06:07 | | Quit bertrik (Ping timeout: 240 seconds) |
| 02:10:00 | | Quit n1s (Quit: Ex-Chat) |
| 02:16:43 | | Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
| 02:20:14 | TheSeven | heh, plugging USB during shutdown also causes really funny reactions |
| 02:31:24 | * | [Saint] noticed that once. |
| 02:38:19 | * | TheSeven finally has a clue what might be going on |
| 02:38:33 | TheSeven | gevaerts: are you still awake? |
| 02:38:49 | TheSeven | this is a conceptual problem of our usb architecture once again... |
| 02:40:01 | | Quit Rob2223 (Quit: Rob2223) |
| 02:40:36 | [Saint] | That sounds expensive... ;) |
| 02:46:11 | | Join Rob2222 [0] (~Miranda@p4FFF2563.dip.t-dialin.net) |
| 02:52:50 | * | TheSeven has a hacky workaround for it, but this should be redesigned properly |
| 02:53:16 | [Saint] | What's the issue? |
| 02:55:55 | *** | Saving seen data "./dancer.seen" |
| 02:56:54 | | Join engrpaul [0] (8d9eb3e2@gateway/web/freenode/ip.141.158.179.226) |
| 02:57:11 | engrpaul | hello? |
| 02:58:22 | engrpaul | I have a Sansa Clip+ that just locked up after rockbox database initialization |
| 02:58:39 | engrpaul | bricked? No screen after holding power button |
| 02:58:47 | engrpaul | nothing on USB |
| 02:58:49 | TheSeven | [Saint]: well, in some cases, if it took too long for a request to be processed, the response wasn't ready before the host asked for it |
| 02:59:16 | engrpaul | I have the unit open and the battery is OK |
| 02:59:40 | TheSeven | and in these cases the endpoint wasn't set up correctly, causing the host's requests to be ignored instead of being NAKed properly (meaning "try again later") |
| 03:00 |
| 03:00:14 | TheSeven | after a small number of retries the host would time out, before the ipod has even prepared the response |
| 03:00:33 | TheSeven | and once it has prepared it, the host isn't asking for it anymore => the ipod is stuck waiting for the host to read the response |
| 03:01:17 | TheSeven | engrpaul: connect to usb, hold the power button for like 15 seconds, release it, and a couple of seconds later briefly press it |
| 03:01:24 | TheSeven | does anything turn up on the USB bus? |
| 03:05:19 | engrpaul | when I plug it in, I get a "duh duh" sound in win7, tried to install device software but failed |
| 03:07:06 | engrpaul | "UNDEF storage USB device" shows up under drives in device manager |
| 03:22:37 | engrpaul | do you think it's bricked? TIA 4UR help |
| 03:51:47 | | Part jlbiasini |
| 04:00 |
| 04:00:49 | | Join NolenJHej [0] (~NolenJHej@50-48-2-127.dsl1.monr.ny.frontiernet.net) |
| 04:01:24 | NolenJHej | Hi |
| 04:01:29 | | Nick NolenJHej is now known as NolenJHeju (~NolenJHej@50-48-2-127.dsl1.monr.ny.frontiernet.net) |
| 04:01:50 | | Quit NolenJHeju (Client Quit) |
| 04:02:01 | | Join NolenJHeju [0] (~NolenJHej@50-48-2-127.dsl1.monr.ny.frontiernet.net) |
| 04:05:03 | | Join BlindWanderer [0] (~c0fb7d28@www.haxx.se) |
| 04:06:06 | engrpaul | My clip+ stopped working after database refresh, power button reset doesn't work, can anyone help? |
| 04:10:06 | BlindWanderer | I'm pretty sure r31430 broke saving playlists on Sansa c200 (v1), if the file is located at "/playlists/all.m3u8" when saving it shows the path as "/./playlists.all.m3u8" which fails. |
| 04:10:51 | BlindWanderer | naturally if you edit the path it works but you aren't given that option when adding a file to a different playlist. |
| 04:12:40 | jhMikeS | there's more than just that broken by using "/." |
| 04:13:40 | | Quit Misan (Remote host closed the connection) |
| 04:19:20 | | Part engrpaul |
| 04:20:50 | | Join engrpaul [0] (~8d9eb3e2@www.haxx.se) |
| 04:21:20 | | Quit engrpaul (Client Quit) |
| 04:23:54 | | Quit amiconn (Disconnected by services) |
| 04:23:56 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:24:01 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:24:55 | | Quit pixelma (Disconnected by services) |
| 04:24:58 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:25:00 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:26:18 | | Quit TheSeven (Disconnected by services) |
| 04:26:31 | | Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) |
| 04:30:23 | | Join help-me-unbrick- [0] (~8d9eb3e2@www.haxx.se) |
| 04:31:23 | | Quit help-me-unbrick- (Client Quit) |
| 04:37:36 | BlindWanderer | I didn't notice a bug on flyspray for it... |
| 04:41:00 | jhMikeS | There isn't afaik. |
| 04:45:09 | | Quit curtism (Quit: Live Long and Prosper) |
| 04:50:23 | | Quit BlindWanderer (Quit: CGI:IRC) |
| 04:55:57 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:14:18 | | Quit MethoS- (Read error: Connection reset by peer) |
| 05:18:23 | | Quit NolenJHeju (Ping timeout: 252 seconds) |
| 05:26:32 | | Join Rob2223 [0] (~Miranda@p4FFF0C78.dip.t-dialin.net) |
| 05:30:31 | | Join NolenJHeju [0] (~NolenJHej@50-48-2-127.dsl1.monr.ny.frontiernet.net) |
| 05:30:57 | | Quit Rob2222 (Ping timeout: 276 seconds) |
| 05:36:14 | | Join toa [0] (~toa@24-240-92-57.dhcp.mdsn.wi.charter.com) |
| 05:41:40 | toa | Hi, I recently bought myself a Sansa Clip Zip and was interested in putting Rockbox on it. However, I see it's listed as unstable and not recommended "unless you know what you are doing". From reading the forums it seems to be fairly complete, but I'd rather not brick my new device. Is there any chance of that happening (assuming no lightning storms, power failures, etc) if I use the standard Rockbox installer? |
| 05:57:30 | | Quit NolenJHeju () |
| 05:57:52 | | Join NolenJHeju [0] (~NolenJHej@50-48-2-127.dsl1.monr.ny.frontiernet.net) |
| 05:58:48 | NolenJHeju | Wait, toa, you're still here right? (I just d/c'd.) |
| 06:00 |
| 06:00:26 | NolenJHeju | Anyway, I was just in the same situation as you, but the regular installer doesn't have the Clip Zip listed. Detect Devices or whatever didn't do it for me either. |
| 06:00:33 | NolenJHeju | However, I found this: http://anythingbutipod.com/forum/showthread.php?t=66292 |
| 06:00:58 | NolenJHeju | Worked just fine for me. Just got Rockbox running, actually. |
| 06:01:29 | toa | NolenJHeju, Yes, I'm still here. Just saw your message. |
| 06:02:29 | toa | Let me take a look at t. |
| 06:02:30 | toa | *it |
| 06:04:20 | toa | I haven't been able to find conclusive information as to if it flashes the player overwriting the original factory firmware or if it runs in a dual-boot capacity. I have ipodlinux installed on my ancient iPod, which runs in this dual-boot manner. |
| 06:05:17 | toa | If it's the former, is there any way to reflash it to its original state? |
| 06:06:03 | | Quit NolenJHeju (Ping timeout: 276 seconds) |
| 06:19:34 | toa | Looking at the port status, there is "Release bootloaders and installation tools" listed. The rest seems fairly trivial, like a splash screen for the clock and graphics for sudoku. |
| 06:20:19 | toa | Also, the port status is from the 13th. |
| 06:22:27 | | Join Strife89 [0] (~Strife89@69.160.178.222) |
| 06:37:45 | | Join Jack87 [0] (Jack87@nasadmin/admin/jack87) |
| 06:40:36 | Jack87 | just have a quick question while im still looking at the FAQs and manuals for the answer but if anyone knows it would be great. Does RockBox support FM radio on sansa e200 series and can it record from radio? |
| 06:42:11 | | Quit toa (Changing host) |
| 06:42:11 | | Join toa [0] (~toa@unaffiliated/toa) |
| 06:42:35 | toa | Jack87, is that a capability of the regular firmware? |
| 06:44:03 | Jack87 | toa, I believe so, to be honest I havent turned it on for years just found it and want to bring it back to life |
| 06:44:07 | | Quit Keripo (Quit: Leaving.) |
| 06:44:16 | Jack87 | I am reading the Sansa FAQ right now and it talks about the radio but its a bit unclear |
| 06:46:36 | Jack87 | well the Rockbox FAQ for sansa that is |
| 06:47:47 | toa | Still checking, Jack87 |
| 06:48:30 | Jack87 | toa, thanks me to :-) |
| 06:49:09 | Jack87 | ya so FM recording is present on the original firmware |
| 06:53:45 | toa | I haven't found anything definitive, but I would bet that it will work. |
| 06:54:32 | toa | If not, it's stable and installs as dual-boot so you can still load the original firmware or uninstall it completely if you wish. |
| 06:55:19 | Jack87 | toa, thank you, I appreciate your insight. i think i will do just that. |
| 06:56:00 | *** | Saving seen data "./dancer.seen" |
| 06:57:03 | Jack87 | should i first install latest sandisk firmware? |
| 06:57:50 | toa | I don't see why not, but I admit I haven't installed Rockbox recently. |
| 06:58:06 | toa | Jack87, find out if it is v1 or v2 of the e200. |
| 06:58:27 | toa | http://www.rockbox.org/wiki/SansaE200Port#Identification_of_version |
| 06:58:31 | Jack87 | From what i can tell its a version 1 as the girmware reads v1.02.12 currently |
| 06:59:14 | Jack87 | do you know if its even supported on v2? |
| 07:00 |
| 07:01:00 | Jack87 | firmware** |
| 07:02:25 | toa | Jack87, I think it's supported on both. |
| 07:02:50 | toa | Yes, it is. |
| 07:02:58 | Jack87 | thats good to know. its sad SDHC drivers are not present on v1 official firmware |
| 07:03:55 | Jack87 | i wonder if its possible to mod the OFW to include the drivers and manually isntall it. (but i guess thats not what this channel is for anyway) |
| 07:05:01 | | Join chkktri_ [0] (~user@85.26.231.9) |
| 07:05:13 | toa | Jack87, possibly, if you're savvy. |
| 07:05:21 | toa | Take a look at http://www.rockbox.org/wiki/SansaAMS if you haven't already. |
| 07:05:38 | toa | The original firmware is available for download. |
| 07:05:40 | Jack87 | haha i wish i was savy enough. maybe in a year or so |
| 07:05:45 | Jack87 | awesome thanks |
| 07:05:59 | Jack87 | ill prolly dig around in it :) |
| 07:07:05 | toa | sounds good |
| 07:09:02 | Jack87 | ill prolly dig around in it :);9 |
| 07:09:05 | Jack87 | :(* |
| 07:10:06 | Jack87 | anyway rockbox seem awesome! and very well organized and put together. exciting stuff |
| 07:10:21 | toa | Does anyone here have any experience with Rockbox on a Clip Zip? |
| 07:10:49 | toa | Jack87, I agree. I'm looking forward to installing it when I can. |
| 07:11:02 | toa | Jack87, not that I have any major qualms with the original firmware. |
| 07:11:19 | Jack87 | toa, I think i ran into something on the wiki saying clip zip was not supported? but i am not sure |
| 07:11:54 | Jack87 | toa, ya original sansa firmware does a lot (its not like its an ipod ;-) ) but the support for SDHC is lacking on e200v1 |
| 07:12:23 | toa | Jack87, Yeah, you're right. It's not completely finished, but I'm trying to discern its current status. |
| 07:13:02 | Jack87 | sorry it says its unstable for th sansa clip |
| 07:13:19 | Jack87 | http://www.rockbox.org/wiki/SansaClip#Sansa_Clip_Zip_port_status |
| 07:13:57 | toa | Jack87, well the device was apparently only released in October, so they've made quick work. |
| 07:14:30 | Jack87 | ya thats awesome... i mean that link is status of like 2 weeks ago |
| 07:27:27 | Jack87 | So both Rockbox and OFW access the same partition of where the media is kept right?? |
| 07:29:11 | | Quit CaptainKewl (Ping timeout: 252 seconds) |
| 07:41:23 | | Quit [Saint] (Remote host closed the connection) |
| 07:46:13 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 07:54:55 | | Join saratoga_ [0] (9803c31c@gateway/web/freenode/ip.152.3.195.28) |
| 08:00 |
| 08:05:34 | funman | yeah |
| 08:06:17 | funman | toa: to install clip zip bootloader follow instructions on wiki: SansaAMS |
| 08:06:34 | funman | you need to build mkamsboot from source or use funman/mkamsboot-1.5/">http://people.videolan.org/~funman/mkamsboot-1.5/ binaries |
| 08:08:11 | funman | http://www.rockbox.org/wiki/SansaClip#Sansa_Clip_Zip_port_status (a bit outdated) |
| 08:08:57 | toa | funman, was that videolan link for me? |
| 08:09:17 | funman | yeah |
| 08:09:38 | funman | these binaries will go on rockbox.org when the admin comes back from holidays |
| 08:09:44 | | Quit Strife89 (Remote host closed the connection) |
| 08:09:56 | * | funman off |
| 08:11:02 | toa | Oh, OK. So it is going to be a very short time before the Clip Zip is officially supported? |
| 08:11:33 | toa | funman, the other items on the to-do list seemed rather trivial. |
| 08:12:25 | toa | Oh, the port status just updated. |
| 08:13:18 | ze | if i'd taken 2 extra minutes to look i probably would've got a clip zip for xmas, but i'm pretty happy with my new clip+ anyway :p |
| 08:15:43 | toa | ze, from what I've read in reviews, the differences aren't that major, if you set aside the color screen. |
| 08:15:55 | [Saint] | I was looking for new flash based targets as mine were aging, and like a light from above Apple started the Nano1G replacement program. |
| 08:16:41 | ze | toa: yeah... i noticed one amazon review says the microsd doesn't protrude the tiny bit it does on the + |
| 08:16:56 | ze | which i kinda feel like sticking some tape over just to make sure that sucker doesn't pop out |
| 08:17:00 | ze | heh |
| 08:17:52 | ze | that 32G could disappear in the blink of an eye if it were to go flying :p |
| 08:18:23 | toa | It's still pretty secure in there, despite the protrusion, I imagine. |
| 08:18:56 | toa | [Saint], they don't happen to have a 2nd gen iPod replacement program too, do they? |
| 08:19:10 | toa | I'm referring to the original 2G 5/10/20GB iPod :P |
| 08:19:59 | ze | hmm well it does seem to be able to eject if pressed just as far in as flush with the body |
| 08:20:23 | [Saint] | toa: no :) |
| 08:30:19 | [Saint] | I don't think the 2G iPod ever burned anyone's house down. |
| 08:44:42 | | Join kevku [0] (x@2001:470:28:773::) |
| 08:49:05 | | Quit saratoga_ (Quit: Page closed) |
| 08:52:20 | | Join Strife89 [0] (~Strife89@69.160.178.222) |
| 08:56:05 | *** | Saving seen data "./dancer.seen" |
| 08:56:17 | | Quit [Saint] (Remote host closed the connection) |
| 09:00 |
| 09:01:13 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 09:04:29 | | Join Horscht [0] (~Horscht@p57B57CB4.dip.t-dialin.net) |
| 09:04:29 | | Quit Horscht (Changing host) |
| 09:04:29 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 09:04:53 | | Quit Zambezi (Changing host) |
| 09:04:54 | | Join Zambezi [0] (Zulu@unaffiliated/zambezi) |
| 09:07:16 | | Quit Horschti (Ping timeout: 255 seconds) |
| 09:07:59 | | Join ze0_ [0] (ze@tardis.yi.org) |
| 09:08:30 | | Quit ze (Ping timeout: 268 seconds) |
| 09:08:36 | | Nick ze0_ is now known as ze (ze@tardis.yi.org) |
| 09:10:32 | | Nick [Saint] is now known as [Saint_] (~Saint]@unaffiliated/saint/x-8516940) |
| 09:10:40 | | Nick [Saint_] is now known as [Saint__] (~Saint]@unaffiliated/saint/x-8516940) |
| 09:10:49 | | Nick [Saint__] is now known as [Saint___] (~Saint]@unaffiliated/saint/x-8516940) |
| 09:10:57 | | Nick [Saint___] is now known as [Saint] (~Saint]@unaffiliated/saint/x-8516940) |
| 09:10:57 | DBUG | Enqueued KICK [Saint] |
| 09:13:03 | | Nick [Saint] is now known as [Saint_] (~Saint]@unaffiliated/saint/x-8516940) |
| 09:13:03 | DBUG | Enqueued KICK [Saint_] |
| 09:13:08 | | Nick [Saint_] is now known as [Saint__] (~Saint]@unaffiliated/saint/x-8516940) |
| 09:13:08 | DBUG | Enqueued KICK [Saint__] |
| 09:13:08 | *** | Alert Mode level 1 |
| 09:13:12 | | Nick [Saint__] is now known as [Saint___] (~Saint]@unaffiliated/saint/x-8516940) |
| 09:13:12 | DBUG | Enqueued KICK [Saint___] |
| 09:13:12 | *** | Alert Mode level 2 |
| 09:13:25 | | Nick [Saint___] is now known as [Saint] (~Saint]@unaffiliated/saint/x-8516940) |
| 09:13:25 | DBUG | Enqueued KICK [Saint] |
| 09:13:25 | *** | Alert Mode level 3 |
| 09:22:25 | | Quit toa (Remote host closed the connection) |
| 09:23:26 | *** | Alert Mode OFF |
| 09:35:56 | | Join nosa [0] (~m00k@adsl-74-235-26-132.clt.bellsouth.net) |
| 09:36:05 | | Quit Strife89 (Remote host closed the connection) |
| 09:36:15 | | Quit nosa-j (Ping timeout: 268 seconds) |
| 09:36:15 | | Nick nosa is now known as nosa-j (~m00k@adsl-74-235-26-132.clt.bellsouth.net) |
| 10:00 |
| 10:11:45 | davo | hi all, do video4fuze video formats get recognized by rockbox? |
| 10:15:49 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 10:22:34 | davo | i'm running sansa fuze v2 ,and after browsing the directory stucture, perhaps my mistake is adding the videos to the sansa default /VIDEOS directory instead should I be putting them somewhere down inside the .rockbox/ directory? :/ |
| 10:24:45 | [Saint] | Its wise to keep user media out of /.rockbox/ but the directory structure doesn't matter...that video format is simply unsupported. |
| 10:26:01 | davo | thanks [Saint], after a video search I found http://www.rockbox.org/wiki/PluginVideo, and other video links on the wiki, might these be better options? |
| 10:27:09 | [Saint] | I'm not sure what you're asking there...if you use a supported video format, it will "just work". |
| 10:28:01 | davo | well i've downloaded some videos that are recognized when I start the sansa fuze in the factory mode, but are not recognized in rockbox files directory |
| 10:28:03 | [Saint] | If you're on Windows, WinFF is a useful tool for converting video for Rockbox targets. |
| 10:28:31 | davo | thanks, i'll look into that, but i'm mostly a dedicated linux user |
| 10:28:47 | davo | i see How To Convert Most Videos to RVF (Linux) on http://www.rockbox.org/wiki/VideoTutorial |
| 10:28:51 | [Saint] | That's to be expected. Rockbox doesn't support the same formats as the OF does. |
| 10:29:13 | davo | ah good to know |
| 10:29:36 | davo | i'll try the tutorial and looks like it should work |
| 10:29:46 | [Saint] | WinFF should run happily in Wine. |
| 10:30:18 | [Saint] | It has presets for Rockbox targets for resolution and framerate. |
| 10:31:33 | davo | okay sounds good, the linux method looks interesting, but i'll give the WinFF a shot first |
| 10:31:39 | davo | thanks for your help [Saint] |
| 10:38:40 | davo | [Saint], i've got winFF running happily in wine just as you said, in regards to the rockbox target, which are the resolution and framerate? XviD? |
| 10:41:03 | [Saint] | The resolution should match the target, it should have presets for your target. In the case it doesn't, there's probably another target with the same screen resolution. |
| 10:43:27 | [Saint] | Even though I have one, I can't remember the screen resolution of the Fuze off the top of my head :-S |
| 10:46:05 | davo | oh ok no worries, i'll give each a try and see which work, thanks :-) |
| 10:47:13 | | Join stoffel [0] (~quassel@pD9E4213E.dip.t-dialin.net) |
| 10:52:32 | topik | xvid wont work though |
| 10:52:53 | topik | mpeg-1 only i think |
| 10:56:07 | *** | Saving seen data "./dancer.seen" |
| 10:57:23 | | Join ender` [0] (~ender@foo.eternallybored.org) |
| 11:00 |
| 11:03:47 | | Join yottabyte [0] (~yottabyte@c-24-10-205-191.hsd1.ut.comcast.net) |
| 11:06:30 | | Join JdGordon| [0] (~jonno@login.ok-labs.com) |
| 11:06:30 | | Quit JdGordon| (Changing host) |
| 11:06:30 | | Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) |
| 11:13:07 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 11:17:44 | davo | hm, only presets winFF offers are MS Compatible AVI, XviD FullScreen, XviD Widescreen, XviD Widescreen Anamorphic. |
| 11:18:17 | davo | if xvid wont work, I just tried MS Compatible AVI and doesn't recognize |
| 11:19:01 | davo | oh crap, my bad, i was listing the presets, i failed to look under the Convert to: menu X-x |
| 11:19:32 | davo | this looks like what [Saint] was refering to, i do see Rockbox option here now. :) my mistake |
| 11:20:22 | [Saint] | Sorry buddy...I should have been more explicit. My mistake. |
| 11:21:17 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
| 11:21:19 | davo | oh not at all [Saint], in fact i am infamous for overlooking things, and i'm thankful for any help i get :) |
| 11:22:29 | | Join lorenzo92 [0] (~chatzilla@host125-104-dynamic.17-79-r.retail.telecomitalia.it) |
| 11:28:38 | lorenzo92 | kugel: hey ;) |
| 11:28:56 | lorenzo92 | kugel: did you see yesterday the pastie with the bench, right? |
| 11:35:28 | | Quit remlap1 (Quit: Leaving.) |
| 11:38:15 | | Quit yottabyte (Quit: Lost terminal) |
| 11:56:48 | | Quit stoffel (Ping timeout: 240 seconds) |
| 11:58:14 | | Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) |
| 12:00 |
| 12:01:41 | jlbiasini | hello: iks rockbox.org down? |
| 12:02:03 | jlbiasini | I cannot connect to the site |
| 12:05:31 | | Part jlbiasini |
| 12:05:49 | | Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) |
| 12:06:43 | | Quit [Saint] (Ping timeout: 268 seconds) |
| 12:12:09 | | Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) |
| 12:16:22 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 12:16:53 | | Quit jlbiasini (Ping timeout: 252 seconds) |
| 12:19:31 | lorenzo92 | jlbiasini: seems working for me... |
| 12:20:23 | lorenzo92 | kugel: an interesting module is also r0PMU.ko...easy ioctls to understand, seems to handle also charging on/off and maybe sleep mode for the cpu |
| 12:21:09 | lorenzo92 | kugel: gives also if end of charge or not (uses some ascoded rregisters of course) |
| 12:25:33 | kugel | lorenzo92: yeah we can get eoc through other modules indeed |
| 12:25:41 | gevaerts | [7]: *why* wasn't the endpoint set up properly? |
| 12:25:59 | kugel | I saw your paste |
| 12:26:02 | lorenzo92 | kugel: interesting. Default charging current is 55 mA |
| 12:26:07 | gevaerts | Ah, a related commit |
| 12:26:42 | lorenzo92 | kugel: need to see in the OF... |
| 12:28:20 | | Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) |
| 12:31:44 | kugel | lorenzo92: that seems low |
| 12:32:20 | lorenzo92 | kugel: ya, strange...calculating with 55 mA is about 10 hours of recharging lol...Uhm I guess the charging thing somewhere else |
| 12:32:29 | lorenzo92 | maybe in the "minivet" device |
| 12:33:05 | kugel | saratoga: did you have a gnuplot cmd line for battery benches? |
| 12:33:14 | kugel | lorenzo92: or didnt you make graphs? |
| 12:35:39 | lorenzo92 | kugel: I did them iin calc :) |
| 12:36:01 | lorenzo92 | if you want I share the odf... |
| 12:36:04 | kugel | sure |
| 12:37:06 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 12:38:29 | lorenzo92 | kugel: http://dl.dropbox.com/u/38710278/R0_discharge.ods |
| 12:43:38 | | Join y4n [0] (y4n@unaffiliated/y4ndexx) |
| 12:44:13 | | Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) |
| 12:47:54 | kugel | lorenzo92: thanks |
| 12:48:11 | kugel | lorenzo92: will commit the pm stuff along with the battery courves then |
| 12:48:34 | lorenzo92 | ;) |
| 12:49:14 | lorenzo92 | kugel: are some other benches needed? |
| 12:53:56 | kugel | lorenzo92: you can do a full bench if you like, but it#s not necessray |
| 12:54:25 | lorenzo92 | kugel: okay I'll do that when the autoshutdown is fixed ;) |
| 12:56:11 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:05:13 | pamaury | hmm, apparently the fuze+ OF uses a persistent register to store the adjustment to the second counter to do to reach 1/1/1970 :-/ |
| 13:05:19 | | Quit bluefoxx (Ping timeout: 240 seconds) |
| 13:06:37 | gevaerts | pamaury: didn't the AMS sansas do something similar, related to DRM? |
| 13:06:58 | pamaury | I don't know, the sansa AMS driver has some hardcoded values |
| 13:07:17 | pamaury | but here, the OF stores it in a persistent register and allows itself to write it ! |
| 13:07:23 | pamaury | I'm still reversing the code |
| 13:08:40 | pamaury | but you're right, it might be a way to prevent "rolling-back" in time |
| 13:17:10 | | Quit chkktri_ (Ping timeout: 252 seconds) |
| 13:22:53 | bertrik | pamaury, as I understand it, the OF never really adjusts the RTC, it just adjusts this offset |
| 13:23:09 | bertrik | (for the AMSes) |
| 13:24:49 | bertrik | the hardcoded values in our RTC drivers are not very accurate and will still need adjustment both in rockbox and in the OF to get the time right |
| 13:35:15 | lorenzo92 | pamaury: oh! interesting, also yp-r0's OF does something strange like that with the time!! |
| 13:35:44 | lorenzo92 | in our case this value is saved in a small part (1mb) of the nand |
| 13:35:55 | lorenzo92 | where also other settings are stored like region code... |
| 13:35:57 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 13:37:33 | lorenzo92 | it is a numeric value but I still don't understand what is its meaning (an example of an old dump is 63119625672) |
| 13:38:51 | lorenzo92 | pamaury: I cannot understand the meaning of doing that: rb time using directly ascodec works perfectly and doesn't lose any precision |
| 13:39:30 | | Join chkktri_ [0] (~user@ip-78-139-196-175.danet.in) |
| 13:44:15 | | Join lovasoa [0] (~olojkine@78.251.21.108) |
| 13:48:51 | amiconn | tts and encoder option handling in configure is fundamentally broken :( |
| 13:49:34 | | Quit lorenzo92 (Quit: ChatZilla 0.9.88 [Firefox 8.0/20111115183813]) |
| 13:50:36 | amiconn | When tts options contain a space, it seems to only use the part up to the first space, even when quoting them twice on the commandline (so they end up still quoted in the Makefile): −−ttsopts='"option1 option2"' -> it only uses option1 |
| 13:51:03 | amiconn | And when encoder options contain a space, voice.pl fails due to borken argument passing |
| 13:52:12 | amiconn | This used to work a while ago, although 'make reconf' has been broken for a long time already when it comes to these arguments |
| 13:52:58 | amiconn | Also the default encoder options seem to be gone? |
| 13:55:00 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 13:56:26 | pamaury | lorenzo92 (for the logs): it's better if rb does as the OF for compatibility |
| 14:00 |
| 14:00:05 | | Quit chkktri_ (Ping timeout: 240 seconds) |
| 14:03:27 | | Join JdGord [0] (~AndChat@pa58-109-128-175.pa.nsw.optusnet.com.au) |
| 14:17:12 | | Join chkktri_ [0] (~user@85.26.231.36) |
| 14:21:54 | | Part jlbiasini |
| 14:30:42 | | Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) |
| 14:35:20 | CIA-88 | New commit by kugel (r31471): Enable (and fix) battery_bench on hosted targets. |
| 14:35:27 | CIA-88 | New commit by kugel (r31472): ypr0: Proper battery curve measured with battery_bench. |
| 14:35:47 | CIA-88 | New commit by pamaury (r31473): imx233/fuze+: implement rtc (time only, alarm still to implement) |
| 14:36:49 | CIA-88 | r31470 build result: 216 errors, 6 warnings (kugel committed) |
| 14:37:30 | | Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) |
| 14:38:31 | CIA-88 | r31473 build result: 218 errors, 8 warnings (pamaury committed) |
| 14:40:34 | | Quit [Saint] (Read error: Connection reset by peer) |
| 14:40:36 | | Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 14:50:08 | CIA-88 | New commit by pamaury (r31475): imx233: forgot a file |
| 14:51:26 | kugel | CIA-88 isn't following :) |
| 14:51:39 | | Quit [Saint_] (Remote host closed the connection) |
| 14:52:12 | CIA-88 | r31475 build result: All green |
| 14:55:46 | pamaury | it missed a commit |
| 14:56:12 | *** | Saving seen data "./dancer.seen" |
| 14:56:18 | jlbiasini | ok the time is now working :) thx |
| 14:56:58 | [7] | gevaerts: because cancel_all_transfers resets (and deconfigures) the endpoints and they were previously only reconfigured on the first transfer |
| 14:57:02 | | Quit chkktri_ (Read error: Connection timed out) |
| 14:57:30 | [7] | IMO they should be configured while requesting them, but that isn't re-done after resetting the driver |
| 14:57:34 | | Join chkktri_ [0] (~user@85.26.231.36) |
| 14:58:33 | gevaerts | Why does cancel_all_transfers deconfigure endpoints? |
| 14:59:19 | | Join stoffel [0] (~quassel@pD9E4213E.dip.t-dialin.net) |
| 14:59:55 | [7] | that's probably just a bug |
| 15:00 |
| 15:00:25 | [7] | but currently they aren't configured before the first call to that as well, and that's a conceptual problem |
| 15:00:41 | | Quit bluefoxx (Quit: 5a 65 75 73 73 2d 73 6f 64 64 69 74 2d 66 75 63 6b 2c 20 49 27 6c 6c 20 62 65 20 62 61 63 6b 2e 2e 2e) |
| 15:01:22 | [7] | generally speaking the endpoints should be enabled/disabled based on which configuration is chosen by the host |
| 15:01:41 | gevaerts | Yes and no |
| 15:01:42 | [7] | currently we seem to get away with just enabling them all the time, because the host doesn't really care |
| 15:02:07 | gevaerts | We only present one single configuration, so we *know* what the host will choose |
| 15:02:28 | [7] | you're ignoring the "unconfigured" state :) |
| 15:02:45 | [7] | initially only EP0 should be active until the host sends set_config 1 |
| 15:02:56 | [7] | and a set_config 0 should theoretically disable them again |
| 15:03:09 | gevaerts | Define "active" |
| 15:04:00 | gevaerts | A host must never talk to an endpoint on an unconfigured device, so it shouldn't matter what the device controller thinks about that endpoint in that state |
| 15:04:24 | gevaerts | ARC configures endpoints from usb_drv_set_address() |
| 15:04:47 | [7] | "USB Active Endpoint: Applies to IN and OUT endpoints. Indicates whether this endpoint is active in the current configuration and interface. The core clears this bit for all endpoints after detecting a USB reset. After receiving the SetConfiguration and SetInterface commands, the application must program endpoint registers accordingly and set this bit." |
| 15:05:08 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 15:05:24 | [7] | I don't know for sure what this bit is doing, but if it's zero the core seems to just ignore all traffic on that EP, not even NAKing it |
| 15:05:40 | [7] | (possibly STALLing it though, no idea) |
| 15:05:51 | gevaerts | Well yes, it makes sense to not NAK on enpoints you're not using |
| 15:06:46 | [7] | the problem is that the core clears that bit by itself if it detects a bus reset, and the only place where the driver can currently set it again is in cancel_all_transfers which seems a bit backwards to me |
| 15:07:00 | | Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) |
| 15:07:17 | gevaerts | But still, in practice, for the device classes we support, the endpoints are known at connect time, so waiting until SetConfiguration or SetInterface shouldn't be needed unless the controller somehow intercepts those and unconfigures itself when seeing them (but I can't imagine it doing that) |
| 15:07:59 | gevaerts | The *only* cases where multiple configurations are ever used use vendor-specific drivers |
| 15:08:19 | [7] | the problem is that the bus reset might happen after request_endpoint is called |
| 15:08:58 | [7] | so we need to re-enable the EPs in this situation |
| 15:09:19 | gevaerts | Where do you enable endpoints? |
| 15:09:40 | [7] | after yesterday's commit in the bus reset and cancel_all_transfers handler |
| 15:09:56 | gevaerts | ARC does it in set_address |
| 15:09:59 | [7] | prior to that it was done before every transfer, which was too late |
| 15:10:18 | gevaerts | Well yes, it has to be done once somewhere at the beginning of the connection |
| 15:11:05 | gevaerts | bus reset should be ok, cancel_all_transfers depends on whether that one also disables the endpoints (if it doesn't, it also doesn't need to enable them again). |
| 15:11:16 | [7] | currently I'm just enabling all EPs, as a slightly cleaner solution I could check which of them (but usually all) were requested previously |
| 15:11:38 | gevaerts | We should probably have a usb_drv_enable_endpoints() call and control this from usb_core, so all drivers behave the same for this |
| 15:11:51 | lovasoa | kugel: Now that you know how to detect if charger is plugged in, don't you think that it would be a good idea to boot OF when USB is connected at boot time? (because RB can't connect to USB yet) |
| 15:12:04 | [7] | gevaerts: yeah, that's what I wanted to propose |
| 15:12:16 | [7] | currently both cancel_all_transfers and the bus reset handler call reset_eps which enables them, should be fine until we find a cleaner solution |
| 15:13:06 | Ctcp | Ignored 5 channel CTCP requests in 2 minutes and 28 seconds at the last flood |
| 15:13:06 | * | gevaerts nods |
| 15:13:26 | [7] | however this doesn't seem to have been the only race condition |
| 15:13:54 | [7] | i can now add logf or even splashf calls without breaking it instantly, but the original bug still persists |
| 15:14:41 | [7] | windows reads a couple hundred sectors, and at some (seemingly random) point in time there's a transfer that never gets a completion event for a still unknown reason |
| 15:15:25 | [7] | and if I add some logging (and thus delays) this issue mysteriously disappears :/ |
| 15:15:47 | gevaerts | hm, actually, resetting *all* endpoints in cancel_all_transfers() could be racy. Only non-0 endpoints should be touched after connection, really |
| 15:16:20 | [7] | hm, shouldn't be, because the host is waiting for a zero-byte response when this is called |
| 15:16:34 | gevaerts | hm, true |
| 15:16:38 | [7] | so we can safely prime EP0 OUT at least |
| 15:17:03 | [7] | and re-enabling an enabled EP0 IN is basically a no-op |
| 15:17:03 | gevaerts | Well, wait, hm |
| 15:17:19 | gevaerts | Yes, it depends on whether you disable it first or not |
| 15:17:58 | [7] | actually I think this enable bit doesn't even exist for EP0, the hardware forcibly enables that one |
| 15:18:11 | [7] | so attempting to set it to 1 while priming it shouldn't hurt |
| 15:18:20 | gevaerts | ok |
| 15:19:10 | CIA-88 | r31474 build result: 4 errors, 0 warnings (kugel committed) |
| 15:19:49 | [7] | the only situation where this might fail is if the host-side ack to a non-zero-byte response is set up before cancel_all_transfers, but AFAICT we don't do that anywhere (it doesn't make sense (conceptually) either) |
| 15:20:16 | * | gevaerts nods |
| 15:22:45 | | Quit JdGord (Quit: Bye) |
| 15:24:33 | | Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) |
| 15:24:58 | gevaerts | [7]: I suspect the best way forward would be to get the tracer to you |
| 15:25:15 | [7] | I'm not sure about that |
| 15:25:36 | | Quit thegeek (Ping timeout: 252 seconds) |
| 15:25:48 | [7] | this one seems to be related to ATA somehow |
| 15:26:10 | [7] | the question is whether this relationship is purely based on timing or whether there's more to that |
| 15:26:11 | | Quit MethoS- (Remote host closed the connection) |
| 15:28:44 | gevaerts | related as in ATA vs ramdisk makes a difference, or as in the bug is on the ATA side? |
| 15:29:05 | * | [7] suspects both |
| 15:29:24 | [7] | at least it doesn't seem to happen on nano2g and it doesn't seem to happen if I only ever do single-sector transfers |
| 15:30:05 | jlbiasini | what is morse input? Doesn't this need a line in jack to work? |
| 15:30:37 | gevaerts | jlbiasini: no, you tap a button |
| 15:30:49 | jlbiasini | ah ok |
| 15:32:10 | | Quit bluefoxx (Quit: 5a 65 75 73 73 2d 73 6f 64 64 69 74 2d 66 75 63 6b 2c 20 49 27 6c 6c 20 62 65 20 62 61 63 6b 2e 2e 2e) |
| 15:32:32 | funman | [7]: r31469, is that needed in usb-drv-as3525v2? iirc it was not |
| 15:32:43 | gevaerts | [7]: this could be caused by the usb driver not handling back to back usb_drv_send_nonblocking() request (i.e. each one immediately following the transfer completion of the previous one, with a near-0 delay) |
| 15:33:55 | * | [7] can't see a reason for that |
| 15:35:01 | [7] | that would be even worse on the nano |
| 15:35:37 | gevaerts | hm, no. usb_storage uses 64K blocks on non-SD targets, so disk blocks, USB transfers, and SCSI request size should all be the same |
| 15:36:55 | gevaerts | hm, anyone with an AMSv1 target around? USB uses 63K buffers on those, and I wonder if that's a good idea and if 32K or 24K wouldn't be faster |
| 15:37:37 | gevaerts | hm |
| 15:38:15 | gevaerts | no, that's not true. It uses 24K |
| 15:38:31 | funman | gevaerts: you need testing? I can use my clipv1 |
| 15:38:40 | gevaerts | Actually, it's half true |
| 15:39:19 | gevaerts | funman: yes, set READ_BUFFER_SIZE to 24K or 32K in usb_storage.c, and see if it makes a speed difference |
| 15:39:35 | gevaerts | WRITE_BUFFER_SIZE is already 24K because it's SD |
| 15:40:25 | gevaerts | This should really be tuned for every pair of storage type and usb controller. There's some speed hiding there |
| 15:41:20 | jlbiasini | pamaury: so i still have to implement morse keymaps so you can wait a little more before commiting my keymaps update |
| 15:41:59 | CIA-88 | New commit by kugel (r31470): ypr0: Enable battery voltage read-out, charging monitoring and charger detection. ... |
| 15:42:12 | CIA-88 | New commit by gevaerts (r31476): The AMSv1 driver limitation that disallows 64K transfers is a USB core limitation, not a CPU limitation, so use the appropriate defines to test for it |
| 15:44:08 | CIA-88 | r31476 build result: All green |
| 15:45:13 | | Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) |
| 15:46:27 | funman | gevaerts: gevaerts should i test r31476 or 31475 ? |
| 15:47:31 | gevaerts | funman: whichever you like. r31476 shouldn't change anything, all AS3525 players use USBOTG_AS3525 |
| 15:48:16 | gevaerts | I just didn't like checking for the CPU define to change driver parameters if there's a perfectly good driver define |
| 15:48:35 | funman | true |
| 15:48:58 | gevaerts | That ends up with things like using CHARCELL to mean Player, or HWCODEC to imply sh, or (worse) MMC to mean ondio |
| 15:52:41 | funman | hm i reproduced FS #12485 |
| 15:52:42 | fs-bluebot | http://www.rockbox.org/tracker/task/12485 Seeking in .ape file doesn't work (bugs, unconfirmed) |
| 15:52:47 | funman | FS #12475 * |
| 15:52:48 | fs-bluebot | http://www.rockbox.org/tracker/task/12475 Crash while playing audio (bugs, unconfirmed) |
| 15:53:42 | funman | gevaerts: 642236416 octets (642 MB) copiés, 150,357 s, 4,3 MB/s |
| 15:53:58 | funman | that's unmodified r31475 performance (63kb) |
| 15:54:16 | funman | rebooting to test a new build since Linux keeps crashing .. |
| 15:54:29 | gevaerts | Tell it not to do that! ;) |
| 15:58:06 | funman | i use dd bs=5120 btw |
| 15:59:38 | gevaerts | hm, that will influence things |
| 16:00 |
| 16:00:10 | gevaerts | Most OSes (I don't know about freebsd!) use 64K blocks for USB communication |
| 16:00:15 | funman | tell me which settings i should use to not test under influence |
| 16:00:54 | gevaerts | 64K would be best |
| 16:01:08 | | Join CaptainKewl [0] (captainkew@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com) |
| 16:01:41 | gevaerts | You can use larger, but then the kernel will split it up |
| 16:01:42 | funman | same bs=5120 with buffer set to 32kb : 3,3MB/s |
| 16:01:56 | amiconn | kugel: Shouldn't it be possible to make the db commit work without reboot now, using buflib? |
| 16:01:59 | gevaerts | hm, maybe the kernel also combines those? |
| 16:02:02 | | Quit benedikt93 (Quit: Bye ;)) |
| 16:02:04 | funman | you want dd bs=64k now? |
| 16:02:04 | [7] | apparently |
| 16:02:17 | amiconn | When dircache is disabled, that is (when it's enabled that already works) |
| 16:02:17 | gevaerts | ok, it should probably be left at 63 then |
| 16:02:23 | gevaerts | Yes |
| 16:02:39 | [7] | how does dd bs=1048576 of=/dev/null behave? |
| 16:03:20 | funman | [7]: ? |
| 16:03:29 | gevaerts | [7]: the same as bs=64K I think, at least on linux. I don't know how windows behaves for dd, but for file transfers it uses 64K max |
| 16:03:49 | * | [7] tries to confirm that theory :) |
| 16:04:22 | gevaerts | [7]: you might actually try setting WRITE_BUFFER_SIZE lower on classic to work around your bug |
| 16:04:26 | [7] | what's limiting it to 63K btw? |
| 16:04:47 | funman | 63, and not 64, you mean? |
| 16:04:49 | gevaerts | The comment says that on AMSv1 the driver doesn't do transfers larger than 65535 bytes |
| 16:04:51 | [7] | yes |
| 16:05:00 | funman | DMA register iirc |
| 16:05:12 | gevaerts | Due to not implementing transfer chaining I think |
| 16:06:18 | * | gevaerts thinks usb_storage should really have simple readahead, or that at least that should be tried |
| 16:06:47 | gevaerts | That will slow down random accesses, but it should speed up sequential reads a lot |
| 16:07:32 | [7] | only attempt readahead if the previous transfer size == 64K? |
| 16:07:53 | gevaerts | yes, that sounds like a good optimisation |
| 16:10:36 | | Join marcol07_Marek_L [0] (~4e628860@www.haxx.se) |
| 16:11:03 | gevaerts | It's more complex than I'd want though. You need another thread to keep the usb thread running (which you have to for e.g. HID), unless some kind soul adds asynchronous disk IO |
| 16:12:51 | | Quit Horscht (Quit: Verlassend) |
| 16:13:01 | gevaerts | hm, no, we do that already really |
| 16:13:12 | * | gevaerts was confusing READ and WRITE :\ |
| 16:13:46 | funman | [7]: do you have usb-s3c6400x changes in progress? |
| 16:13:53 | gevaerts | Anyway, I'm leaving for now |
| 16:13:59 | funman | i'll start merging at least some code |
| 16:15:32 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
| 16:16:54 | [7] | funman: I'm currently trying to figure out what's going on with the classic, but don't have local changes right now (except for debugging stuff) |
| 16:17:02 | funman | ok i'll start right away |
| 16:18:20 | kugel | amiconn: yes |
| 16:19:42 | jlbiasini | Ok could someone you know this device explain me how morse is supposed to work? just typing once morseinput key to toogle and then do whatever sequence with the morseselect key? |
| 16:20:03 | jlbiasini | I can't get this working on the fuze+ |
| 16:21:01 | jlbiasini | does is need doubletouch (like holding morseinput wjile doing sequence with morseselect ? |
| 16:25:57 | jlbiasini | I think that if ever one day someone come complaining about this I will then implement it |
| 16:26:18 | jlbiasini | :) |
| 16:26:27 | * | [7] is amazed by windows doing single sector reads while scanning the fat |
| 16:26:45 | funman | jlbiasini: good idea ;) |
| 16:31:27 | jlbiasini | funman: I've got tenth of manual compilation error because some keymaps was not set for whatever lunatic unkown fonctions/option that no one care about. Manual = nightmare |
| 16:32:55 | funman | yeah |
| 16:33:06 | funman | output log is difficult to parse also :/ |
| 16:40:05 | jlbiasini | funman: do you know what does that means: Is there a specific format to follow on png file? I try do have some file like the other but I can't get rid of this... Or should I just ignore it? : Cannot determine size of graphic in rockbox_interf |
| 16:40:08 | jlbiasini | ace/images/ss-virtual-keyboard-240x320x16.png (no BoundingBox) |
| 16:41:02 | jlbiasini | hoho this image is not even from me!! |
| 16:41:15 | jlbiasini | ok I suppose this could be ignored then |
| 16:41:18 | funman | no clue, that's the kind of problem i'm speaking about |
| 16:41:25 | funman | is that a warning? an error? is it fatal? |
| 16:41:43 | jlbiasini | a warning |
| 16:43:47 | jlbiasini | there is also a ! LaTeX Error: There's no line here to end. |
| 16:44:21 | jlbiasini | seems to be related to some \\ but there where there before me... |
| 16:44:34 | CIA-88 | New commit by funman (r31477): usb-s3c6400x.c: move usb_detect and usb_enable |
| 16:46:25 | funman | jlbiasini: compare to a working manual build |
| 16:46:38 | CIA-88 | r31477 build result: All green |
| 16:47:41 | | Quit chkktri_ (Read error: Connection timed out) |
| 16:48:16 | | Join chkktri_ [0] (~user@85.26.231.36) |
| 16:48:20 | funman | [7]: do we really need to handle builds without USBSTACK ? |
| 16:56:16 | *** | Saving seen data "./dancer.seen" |
| 16:58:15 | CIA-88 | New commit by theseven (r31469): usb-s3c6400x: Fix endpoints being enabled too late |
| 16:58:53 | * | [7] laughs at CIA-88 |
| 16:58:56 | [7] | funman: don't think so |
| 16:59:19 | Torne | okay this versioning thing is a real annoyance |
| 16:59:37 | Torne | i am tempted to give up and let it just emit SHAs for now |
| 17:00 |
| 17:00:08 | Torne | or.. hm |
| 17:01:00 | funman | Torne: i'm sure we'll figure out something, won't we? |
| 17:01:30 | Torne | git describe is annoying because it's kinda.. retroactive |
| 17:01:48 | Torne | the versions of commits that already exist (and may have been built) might change because of newly created tags |
| 17:02:32 | funman | if a user give the version, will it be easy to find which build he uses exactly? |
| 17:02:50 | funman | it's the most important question to ask |
| 17:03:21 | Torne | hm. that depends. |
| 17:03:38 | Torne | ther eisn't an easy way to go from tag+commits to a hash, no |
| 17:03:47 | Torne | the describe output is only parseable if you actually inlcude the SHA |
| 17:03:59 | Torne | git can only count backwards, not forwards |
| 17:04:03 | Torne | because forwards is ambiguous |
| 17:04:35 | Torne | this is probably true of all schemes that are going to produce a number that increases with subsequent builds :) |
| 17:04:48 | Torne | unless we just tag all the builds at the master. |
| 17:05:21 | Torne | which we could, but that won't identify anything that doesn't correspond to a build |
| 17:12:08 | funman | what's wrong with the last sha again? |
| 17:12:22 | Torne | entirely meaningless to users |
| 17:12:26 | Torne | no way to even tell which is newer |
| 17:14:36 | Torne | if you tell someone that their bug is fixed in r42332 this means something perfectly comprehensible; if you tell them it's fixed in ac73f2d then they can't easily tell if that's in any given build without a source checkout to ask git questions on |
| 17:17:11 | CIA-88 | New commit by funman (r31478): usb-s3c6400x: move usb_init_device |
| 17:17:20 | funman | Torne: you can tell the bug is fixed in last build |
| 17:17:27 | | Quit liar (Read error: Connection timed out) |
| 17:17:35 | Torne | technically not :) |
| 17:17:39 | funman | why? |
| 17:17:44 | Torne | maybe it's not been built yet |
| 17:17:47 | Torne | or been pushed ot master |
| 17:17:59 | Torne | or is on another branch |
| 17:18:09 | funman | we only have one branch don't we? |
| 17:18:48 | funman | now we say 'fixed in 3.10' or 'fixed in current build' |
| 17:18:49 | CIA-88 | r31478 build result: All green |
| 17:19:17 | funman | or at worst 'just fixed, wait 2 minutes for the build to appear' |
| 17:19:27 | funman | or 'there's a patch not committed yet' |
| 17:20:55 | funman | for users there's only last release and last build which counts |
| 17:21:04 | funman | developers can find commits themselves or we can help them |
| 17:23:04 | Torne | meh |
| 17:23:11 | Torne | how do we want to format it, then? |
| 17:24:19 | funman | short sha? |
| 17:24:55 | Torne | some kidn of prefix might be good to distinguish mostly-numeric hashes from svn revnos ;) |
| 17:25:10 | Torne | git describe uses 'g' |
| 17:26:06 | funman | i don't think we need a prefix to make the distinction |
| 17:26:16 | funman | the number of digits itself should be enough |
| 17:27:39 | | Quit stoffel (Ping timeout: 244 seconds) |
| 17:29:28 | | Join dreamlayers [0] (~bgjenero@rockbox/developer/dreamlayers) |
| 17:32:25 | Torne | done :) |
| 17:32:29 | Torne | though CIA hasn't noticed |
| 17:33:17 | Torne | for revisions that correspond exactly to svn it will still print the svn revision |
| 17:33:25 | Torne | for anything else it will just use the short SHA1 |
| 17:34:07 | CIA-88 | r31480 build result: All green |
| 17:35:08 | funman | cia has y2k12 bug possibly |
| 17:35:17 | Torne | heh |
| 17:35:27 | funman | Torne: that's nice to use svn numbers |
| 17:35:46 | funman | by the way do we go through old commits to put correct author information? (patch by xxx) |
| 17:36:31 | | Quit [7] (Disconnected by services) |
| 17:36:42 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 17:37:29 | | Part lovasoa |
| 17:37:38 | CIA-88 | New commit by torne (r31479): Remove bzr support from tools/version.sh. ... |
| 17:44:52 | Torne | no |
| 17:48:00 | CIA-88 | New commit by dreamlayers (r31481): Fix FS #12499 - Directory playback fails after saving playlist ... |
| 17:53:42 | CIA-88 | New commit by theseven (r31482): usb_core: Fix typo in comment |
| 17:57:11 | * | TheSeven really likes it when logf fixes bugs |
| 17:57:44 | dreamlayers | File creation fails in paths under /./, so HOME_DIR breaks some things. |
| 17:59:45 | | Join tails___ [0] (~user@83.149.48.69) |
| 18:00 |
| 18:02:10 | | Quit chkktri_ (Ping timeout: 252 seconds) |
| 18:04:34 | * | TheSeven spots a really really nasty race condition |
| 18:05:07 | | Quit jhMikeS (Ping timeout: 240 seconds) |
| 18:07:13 | TheSeven | hm, seems like the hardware takes care of this |
| 18:08:26 | | Quit Horscht (Quit: Verlassend) |
| 18:08:33 | | Join chkktri_ [0] (~user@85.26.231.102) |
| 18:10:19 | | Quit tails___ (Ping timeout: 252 seconds) |
| 18:10:57 | CIA-88 | New commit by torne (r31480): Fix up tools/version.sh for git transition. ... |
| 18:13:35 | * | Torne pokes CIA |
| 18:35:51 | | Quit marcol07_Marek_L (Quit: CGI:IRC (Ping timeout)) |
| 18:35:58 | TheSeven | gevaerts: looking at the OTG's registers, it seems like a "Session End Detected: The core sets this bit when the b_valid signal is deasserted." event is what's killing the connection |
| 18:36:17 | * | TheSeven wonders how this can depend on logf-triggered timing changes |
| 18:36:53 | TheSeven | this always happens while waiting for a CSW ack |
| 18:37:23 | | Join remlap1 [0] (~Patrick@190.28.169.217.in-addr.arpa) |
| 18:37:37 | | Quit remlap1 (Client Quit) |
| 18:38:28 | | Quit remlap (Ping timeout: 240 seconds) |
| 18:42:34 | TheSeven | hm, or rather the CSW isn't accepted any more once this happened, but that interrupt gets asserted even slightly before that |
| 18:43:33 | TheSeven | just after a data stage transfer completion |
| 18:44:42 | | Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) |
| 18:53:13 | | Quit chkktri_ (Read error: Connection reset by peer) |
| 18:56:17 | *** | Saving seen data "./dancer.seen" |
| 18:59:40 | TheSeven | hm, additionally a suspend and bus reset is logged |
| 19:00 |
| 19:07:01 | TheSeven | gevaerts: is it normal that our MSC code continues the currently running operation (i.e. attempts to send data stages, CSWs, ...) even if a bus reset occurred in the middle of the operation? |
| 19:17:53 | | Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) |
| 19:18:31 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 19:24:13 | CIA-88 | New commit by alle (r31483): Update the Russian translation (FS #12420 by James Hunt) |
| 19:26:06 | CIA-88 | r31483 build result: All green |
| 19:31:54 | CIA-88 | New commit by dreamlayers (r31484): Fix FS #7631 : Archos V2 and FM Recorder charging screen problems ... |
| 19:32:00 | | Join nosa [0] (~m00k@adsl-74-235-26-132.clt.bellsouth.net) |
| 19:32:33 | | Quit nosa-j (Ping timeout: 268 seconds) |
| 19:32:33 | | Nick nosa is now known as nosa-j (~m00k@adsl-74-235-26-132.clt.bellsouth.net) |
| 19:33:02 | | Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 19:33:43 | CIA-88 | r31484 build result: All green |
| 19:34:59 | funman | 12 commits incoming .. |
| 19:35:05 | funman | 13 actually |
| 19:38:47 | | Quit fs-bluebot (Ping timeout: 240 seconds) |
| 19:39:24 | | Quit bluebrother^ (Ping timeout: 244 seconds) |
| 19:39:46 | CIA-88 | New commit by alle (r31485): Minor corrections to the Russian translation |
| 19:40:20 | | Join fs-bluebot [0] (~fs-bluebo@f053154213.adsl.alicedsl.de) |
| 19:41:05 | | Join bluebrother [0] (~dom@f053154213.adsl.alicedsl.de) |
| 19:41:05 | | Quit bluebrother (Changing host) |
| 19:41:05 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 19:41:53 | CIA-88 | r31485 build result: All green |
| 19:43:33 | CIA-88 | New commit by funman (r31486): usb-drv-as3525v2: move interrupt disable |
| 19:43:42 | CIA-88 | New commit by funman (r31487): usb_init_device(): move prototype to usb.h ... |
| 19:43:58 | CIA-88 | New commit by funman (r31488): move usb_pin_init() declaration to PP's system-target.h ... |
| 19:44:03 | CIA-88 | New commit by funman (r31489): usb_plugged() is PP only |
| 19:44:06 | jlbiasini | pamaury: keymaps are ready -> http://www.rockbox.org/tracker/task/12405#comment42043 could you commint them? |
| 19:44:10 | CIA-88 | New commit by funman (r31490): usb_drv_connected() is declared in usb_drv.h |
| 19:44:17 | CIA-88 | New commit by funman (r31491): firewire/usb_remove/insert_int: move to system-target.h |
| 19:44:19 | CIA-88 | New commit by funman (r31492): delete usb-target.h content redundant with PP usb-target.h |
| 19:44:25 | CIA-88 | New commit by funman (r31493): gigabeats usb-target: merge in system-target.h |
| 19:44:28 | CIA-88 | New commit by funman (r31494): USBOTG_ARC's USB_DRIVER_CLOSE: move to config.h |
| 19:44:36 | CIA-88 | New commit by funman (r31495): creative zvm isp1583 defines: move to isp1583.h ... |
| 19:44:39 | CIA-88 | New commit by funman (r31496): onda usb code: merge into .c file |
| 19:44:48 | CIA-88 | New commit by funman (r31497): onda 747/777 : move USB_STATUS_BY_EVENT to config |
| 19:44:54 | | Quit dreamlayers (Ping timeout: 252 seconds) |
| 19:44:55 | | Quit amithkk (Ping timeout: 252 seconds) |
| 19:44:56 | jlbiasini | wtf? the guy is commiting one year work or what??? |
| 19:44:56 | | Quit jae (Ping timeout: 252 seconds) |
| 19:45:03 | jlbiasini | :) |
| 19:45:05 | CIA-88 | New commit by funman (r31498): usb-target.h: remove |
| 19:45:22 | funman | no just small separated commits .. |
| 19:45:22 | CIA-88 | r31486 build result: All green |
| 19:45:40 | CIA-88 | New commit by kugel (r31474): Fix simulator reds. |
| 19:45:52 | * | TheSeven slaps CIA-88 |
| 19:46:13 | | Quit Utchybann (Ping timeout: 252 seconds) |
| 19:46:16 | * | TheSeven kicks CIA-88 |
| 19:46:16 | CIA-88 | ow |
| 19:46:24 | TheSeven | hm, that still responds... |
| 19:46:42 | | Join jae [0] (~jae@dedicated.jaerhard.com) |
| 19:47:01 | | Join amithkk [0] (u4289@gateway/web/irccloud.com/x-xaafjvbjxdcjdqsc) |
| 19:47:01 | | Quit amithkk (Changing host) |
| 19:47:01 | | Join amithkk [0] (u4289@2buntu/writers/amithkk) |
| 19:47:06 | * | funman rubs CIA-88's tummy |
| 19:47:06 | CIA-88 | *purr* |
| 19:47:15 | TheSeven | heh |
| 19:47:21 | * | TheSeven didn't know that one yet |
| 19:47:26 | funman | http://cia-vc.googlecode.com/svn/trunk/cia/LibCIA/IRC/Bots.py |
| 19:47:53 | CIA-88 | r31482 build result: All green |
| 19:48:08 | CIA-88 | r31498 build result: 25 errors, 4 warnings (funman committed) |
| 19:48:10 | | Join dreamlayers [0] (~bgjenero@bas4-windsor12-1279287645.dsl.bell.ca) |
| 19:48:10 | | Quit dreamlayers (Changing host) |
| 19:48:10 | | Join dreamlayers [0] (~bgjenero@rockbox/developer/dreamlayers) |
| 19:48:15 | funman | not that bad |
| 19:49:59 | TheSeven | hm, looks like there's once again a usb thread deadlock, but it's outside the storage code this time |
| 19:50:05 | CIA-88 | New commit by funman (r31499): imx233: fix power_input_status() |
| 19:50:14 | TheSeven | and doesn't seem to be in a usb_drv function either |
| 19:50:22 | jlbiasini | what could cause all the reference from manual to get undefined? I have tenth of message like: "LaTeX Warning: Reference `ref:Contextmenu' on page 161 undefined on input line" while compiling and no table of contents... see FS #12492 |
| 19:50:23 | fs-bluebot | http://www.rockbox.org/tracker/task/12492 add fuze+ manual (patches, unconfirmed) |
| 19:50:33 | TheSeven | heh, that's the downside of git-svn |
| 19:50:46 | CIA-88 | New commit by funman (r31500): onda: remove now inlined USB_INIT_GPIO() |
| 19:51:13 | * | TheSeven accuses funman of juggling with code :) |
| 19:51:20 | funman | TheSeven: which downside? |
| 19:51:26 | funman | TheSeven: i just wanted r31500 :) |
| 19:51:50 | jlbiasini | * jlbiasini is going to test hid again as he is getting suspicious ;) |
| 19:52:02 | TheSeven | you won't see the reds before you've committed another dozen things, causing lots of revisions that can't be built, which might make bisecting a bit more tricky |
| 19:52:13 | * | TheSeven tells jlbiasini about /me |
| 19:52:34 | CIA-88 | r31499 build result: 18 errors, 4 warnings (funman committed) |
| 19:52:43 | funman | TheSeven: true |
| 19:52:58 | funman | but one by one commits can break equally |
| 19:53:00 | * | jlbiasini thanks TheSeven about that |
| 19:53:10 | funman | that's a downside about gazillions of targets i'd say |
| 19:53:36 | TheSeven | if you do one by one commits, you notice the breakage earlier and repair it before committing the rest |
| 19:54:12 | funman | right |
| 19:54:33 | jlbiasini | no fun! |
| 19:54:40 | jlbiasini | :D |
| 19:54:53 | CIA-88 | r31500 build result: All green |
| 19:55:12 | funman | fuze+ delta is suspicious |
| 19:56:08 | pamaury | it's because of the way I define the fuze+ memory, some are in cached memory, some not, and the end and begin symbols are not of the same type :) |
| 19:56:19 | TheSeven | http://pastie.org/3103147 is more suspicious |
| 19:56:22 | funman | pamaury: was that for me ? |
| 19:56:34 | pamaury | funman: yes |
| 19:56:47 | funman | i don't understand |
| 19:57:25 | pamaury | I thought you were talking of the fuze+ memory usage reported on dev.cgi which is over 1Gb :) |
| 19:57:29 | funman | usb_thread has not the same size |
| 19:57:34 | funman | no, about the delta |
| 19:58:04 | pamaury | indeed, 250 bytes of such a small thing :-s |
| 19:58:08 | pamaury | *for |
| 19:58:24 | funman | things* |
| 19:58:38 | funman | different sizes in old.elf and rockbox.elf: 360 456 __seq.2119 |
| 19:58:43 | funman | __seq ? |
| 19:59:01 | funman | ah but a lot of symbols have changed names.. |
| 19:59:22 | funman | function old new delta |
| 19:59:23 | funman | usb_configure_drivers - 188 +188 |
| 19:59:30 | funman | i must have added/removed an unwanted define |
| 20:00 |
| 20:01:02 | | Join robin0800 [0] (~robin0800@149.254.61.216) |
| 20:01:02 | pamaury | hm, __seq is only used in the lcd driver, that seems weird |
| 20:01:13 | funman | bloat-o-meter.py output is better |
| 20:01:35 | jlbiasini | usb storage and hid still work on f+ let's check charging... |
| 20:02:01 | funman | ah if it works i'll just ignore it |
| 20:03:35 | jlbiasini | pamaury: I saw that some device have a usbcharge key, that block usb storage on connection in order to keep playing music while charging unstead of stopping everytrhing. Would it be possible on the F+? |
| 20:03:50 | | Join deameyes [0] (~deameyes@65.29.251.49) |
| 20:04:09 | pamaury | any key does that iirc |
| 20:04:19 | funman | yeah saratoga changed that quite recently |
| 20:05:12 | jlbiasini | pamaury: funman: right! |
| 20:05:23 | deameyes | when writing a char with the value 0 it doesn't seem to be written to the file in rockbox. Could it be that the char is being overwritten and I need to use seek? |
| 20:08:44 | | Quit dreamlayers (Ping timeout: 252 seconds) |
| 20:08:59 | | Join dreamlayers [0] (~bgjenero@rockbox/developer/dreamlayers) |
| 20:10:31 | dreamlayers | funman: the fuze+ binsize delta may be due to USB_DRIVER_CLOSE not being defined |
| 20:11:31 | pamaury | in power-imx233.c ? |
| 20:11:43 | jlbiasini | pamaury: another thing I noticed about rb and usb on F+ is that it prevent my laptop to boot if connected!! |
| 20:12:05 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 20:12:27 | pamaury | jlbiasini: I noticed the fuze+ OF marks a partition as bootable, that's probably the reason |
| 20:13:16 | funman | dreamlayers: hm |
| 20:13:18 | | Join marcol07 [0] (~4e628860@www.haxx.se) |
| 20:13:23 | dreamlayers | USB_DRIVER_CLOSE used to be defined in imx233/usb-target.h. I guess it's only needed in the bootloader. |
| 20:13:51 | funman | oh |
| 20:13:57 | funman | it must have been caused by r31494 |
| 20:14:23 | dreamlayers | config.h only defines it in the bootloader for CONFIG_USBOTG == USBOTG_ARC. I wonder if that's correct. |
| 20:14:54 | funman | afaict all PP have USBOTG_ARC |
| 20:15:35 | jlbiasini | pamaury: I have some test to do on that to be sure about where exactly it come from. IIRC it was also block boot process while already in progress (i.e. after bios stuff, while os boots) and it was with rb not OF |
| 20:16:31 | pamaury | then that's probably an OS problem, a device shouldn't be able to prevent boot |
| 20:17:27 | * | pamaury leaves for a while |
| 20:19:27 | funman | plug some usb key and see if^Wthat it's the same |
| 20:22:20 | CIA-88 | r31469 build result: All green |
| 20:26:34 | CIA-88 | r31481 build result: All green |
| 20:27:16 | CIA-88 | r31479 build result: All green |
| 20:28:28 | jlbiasini | funman: of course and only the fuze+ block it |
| 20:29:26 | jlbiasini | and this is not an OS problem, it's debian! :d |
| 20:30:32 | jlbiasini | funman: what was those commit on usb? some cleanup? |
| 20:32:01 | funman | removal of usb-target.h |
| 20:32:27 | funman | all sort of crap^Wthings accumulated in here |
| 20:33:12 | jlbiasini | a yes I understand |
| 20:33:40 | funman | and a lot of empty files (with just a copyright notice) |
| 20:36:00 | | Quit marcol07 (Quit: CGI:IRC (EOF)) |
| 20:36:37 | | Quit liar (Ping timeout: 252 seconds) |
| 20:37:21 | dreamlayers | funman: thanks for that cleanup |
| 20:40:53 | | Quit robin0800 (Ping timeout: 244 seconds) |
| 20:44:20 | | Join vpv [0] (vpv@fedora/vpv) |
| 20:44:32 | funman | np |
| 20:44:48 | * | TheSeven has a new suspicion about the classic usb trouble |
| 20:46:47 | vpv | Hi all. Is there an easy way of getting any debugging information when a get a "data abort"? I was getting one with a Fuze V2 with a podcast ogg file, but now I can't seem to reproduce the problem. |
| 20:47:05 | funman | TheSeven: what does usb_attach do ? |
| 20:47:43 | TheSeven | vpv: exact crash message + exact revision number (or even better, the corresponding .elf file) |
| 20:48:10 | TheSeven | that might enable developers to figure out where exactly it crashed |
| 20:50:26 | TheSeven | funman: no clue. I implemented it as usb_enable(true), which I'm sure I just copied from somewhere |
| 20:50:36 | vpv | TheSeven: ok, thanks. I'm using the 3.10 release, I'll do a bit more testing in case I'll see the problem again. I did reset my settings though, that may also have "fixed" it. |
| 20:50:58 | funman | TheSeven: yeah i'm wondering why it differs from as3525v23 |
| 20:51:02 | funman | -21 |
| 20:51:14 | funman | vpv: you can try a current build also |
| 20:51:16 | TheSeven | what does it do for that one? |
| 20:53:47 | funman | nothing |
| 20:53:52 | vpv | itit seems I really can't reproduce it anymore, which in some sense is also good. I had the file in a playlist and now I tried copying the same file to the device again and using the same playlist and it seems to work. |
| 20:55:14 | funman | now i'm tempted to add usb-target.h again for s5l870x and as3525v2 |
| 20:55:35 | funman | or put needed defines in usb-s3c6400x.h and add 2 .c fiels |
| 20:56:22 | *** | Saving seen data "./dancer.seen" |
| 20:56:43 | funman | seems better |
| 20:57:48 | gevaerts | deameyes: how are you writing? |
| 20:58:38 | TheSeven | gevaerts: looks like this USB core doesn't like setting up IN transfers on different endpoints in rapid succession |
| 20:59:17 | | Join robin0800 [0] (~robin0800@genkt-056-221.t-mobile.co.uk) |
| 20:59:58 | gevaerts | TheSeven: hid things? |
| 21:00 |
| 21:00:08 | TheSeven | might be related |
| 21:00:29 | TheSeven | but in this case a get config descriptor request that windows issues for no apparent reason |
| 21:00:31 | funman | TheSeven: USB_STATUS_BY_EVENT and USB_DETECT_BY_CORE are not defined for nano2g :/ |
| 21:01:03 | TheSeven | funman: yes, because I have never managed to make that work (didn't have time to debug it at that time) |
| 21:01:30 | funman | as3525v2 has them, can you figure it out? |
| 21:01:52 | | Quit dreamlayers (Quit: back later) |
| 21:01:58 | TheSeven | gevaerts: in this particular case I've observed that a 4K data stage followed by a control response causes the control transfer to lock up (never complete, with the registers saying 1 packet 0 bytes left) |
| 21:02:04 | | Quit deameyes (Quit: IRC webchat at http://irc2go.com/) |
| 21:02:17 | TheSeven | and an undocumented bit in the interrupt register getting set |
| 21:02:27 | gevaerts | weird |
| 21:02:30 | * | TheSeven suspects this is related to FIFOs |
| 21:02:56 | TheSeven | all bulk endpoints seem to share a common 512byte fifo |
| 21:03:12 | funman | TheSeven: usb is not needed for nano2g bootloader? |
| 21:03:25 | TheSeven | needed in terms of what? |
| 21:04:31 | funman | let me rephrase |
| 21:04:33 | TheSeven | we don't have a bootloader USB mode if you mean that (ipods are basically unbrickable) |
| 21:04:37 | funman | usb storage is not needed for classic bootloader? |
| 21:04:48 | TheSeven | there is no such thing as a classic bootloader |
| 21:05:02 | funman | ok |
| 21:08:30 | CIA-88 | New commit by funman (r31501): usb-drv-as3525v2: cosmetics |
| 21:08:35 | CIA-88 | New commit by funman (r31502): Remove USBOTG_AS3525v2 |
| 21:10:40 | CIA-88 | r31501 build result: All green |
| 21:13:33 | CIA-88 | r31502 build result: 24 errors, 1779 warnings (funman committed) |
| 21:13:52 | funman | grmbl |
| 21:14:50 | CIA-88 | New commit by funman (r31503): typo |
| 21:17:15 | CIA-88 | r31503 build result: 24 errors, 18 warnings (funman committed) |
| 21:20:40 | | Part jlbiasini |
| 21:20:55 | CIA-88 | New commit by funman (r31504): fix r31502: USBOTG_AS3525v2 doesn't exist anymore |
| 21:23:31 | CIA-88 | r31504 build result: All green |
| 21:29:10 | CIA-88 | New commit by bertrik (r31505): Make local functions static in clock and chessbox plugin |
| 21:30:07 | | Quit remlap (Read error: Connection reset by peer) |
| 21:31:25 | CIA-88 | r31505 build result: All green |
| 21:38:48 | CIA-88 | New commit by funman (r31506): usb-s3c6400x: start factorization |
| 21:41:08 | CIA-88 | r31506 build result: All green |
| 21:42:24 | funman | TheSeven: what about usb_drv_set_test_mode() ? any problem on implementing it for nano2g ? |
| 21:44:54 | | Join Utchybann [0] (~Utchy@rps6752.ovh.net) |
| 21:55:43 | funman | is TexasRockbox on irc ? |
| 21:59:00 | | Quit robin0800 (Quit: Leaving) |
| 21:59:18 | | Join robin0800 [0] (~robin0800@genkt-051-221.t-mobile.co.uk) |
| 22:00 |
| 22:01:11 | funman | s3c6400x.c has one struct per endpoint while other drivers have one struct per endpoint per dir |
| 22:01:22 | funman | it could affect ep0 as it's bidir |
| 22:11:50 | TheSeven | funman: just use the test thingy from your driver if you have one, I just haven't bothered :) |
| 22:11:59 | TheSeven | (this function isn't used anywhere, is it?) |
| 22:12:33 | TheSeven | and regarding the endpoint structs, this is confusing me a bit as well... but I don't think it's what's causing the current trouble |
| 22:13:19 | funman | yes it's used |
| 22:13:30 | TheSeven | hm, what is it good for? |
| 22:13:43 | funman | not sure about it but i can't use one struct per endpoint on amsv2 so there are a few bits i can't merge |
| 22:13:48 | funman | absolutely no clue |
| 22:13:55 | TheSeven | set_feature test things? |
| 22:13:59 | | Join nosa [0] (~m00k@adsl-74-235-26-132.clt.bellsouth.net) |
| 22:14:33 | TheSeven | funman: feel free to rework that endpoint state stuff, the way it's currently done in s3c6400x certainly isn't sane :) |
| 22:14:58 | TheSeven | so if you manage to factor out the target specific parts, i'd just throw away the rest of that driver |
| 22:15:11 | CIA-88 | New commit by funman (r31507): usb-drv-as3525v2.h: remove |
| 22:15:23 | funman | TheSeven: i can't test on nano2g |
| 22:15:38 | TheSeven | I can take care of that |
| 22:17:27 | CIA-88 | r31507 build result: All green |
| 22:17:40 | | Quit nosa-j (Ping timeout: 248 seconds) |
| 22:17:40 | | Nick nosa is now known as nosa-j (~m00k@adsl-74-235-26-132.clt.bellsouth.net) |
| 22:18:12 | CIA-88 | New commit by funman (r31508): usb-s3c6400: use more complete functions from usb-drv-as3525v2 ... |
| 22:20:33 | CIA-88 | r31508 build result: All green |
| 22:21:01 | | Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) |
| 22:22:49 | CIA-88 | New commit by funman (r31509): usb-drv-as3525v2.c: merge in usb-s3c6400x.c ... |
| 22:23:28 | TheSeven | funman: is this nano2g-only so far or is it also supposed to work on the classic? |
| 22:24:29 | funman | i don't think i've made nano2g-only changes |
| 22:24:42 | TheSeven | ok |
| 22:25:00 | funman | i enabled some bootloader bits for classic though by doing s/IPOD_NANO2G/USBOTG_S3C6400X/ but it shouldn't matter |
| 22:25:13 | CIA-88 | r31509 build result: All green |
| 22:25:34 | TheSeven | if you changed the order of the register writes in usb_reset, n1s should probably test it, too |
| 22:25:34 | funman | btw which loop iteration you prefer |
| 22:25:43 | TheSeven | his ipod seems to be more picky about those than mine |
| 22:25:50 | funman | i = out ? 2 : 1; i < USB_NUM_ENDPOINTS; i += 2 |
| 22:25:59 | funman | or int8_t[] lists of in and out endpoints |
| 22:26:23 | TheSeven | well, the latter is more clear but probably more bloat |
| 22:26:25 | funman | += 2 looks simpler |
| 22:26:40 | funman | we could use that and have a comment |
| 22:26:56 | TheSeven | maybe we should get rid of those completely and detect the endpoints at runtime |
| 22:27:19 | TheSeven | do the AMS chipsets have the same endpoint configuration? |
| 22:27:44 | funman | they have one more |
| 22:27:53 | TheSeven | in that case I'd say go for autodetection |
| 22:28:00 | funman | also i don't know if the HWCFG registers exist on nano2g |
| 22:28:07 | funman | that's why i put the defs in as3525v2.h |
| 22:28:17 | TheSeven | what is that? |
| 22:28:51 | funman | see r31507 |
| 22:29:06 | funman | endpoints type & number |
| 22:31:35 | TheSeven | funman: I think these regs are present... at least somewhere :) |
| 22:32:29 | TheSeven | GHWCFG1 is definitely present, not sure about the other ones |
| 22:37:52 | | Join alienkid10 [0] (~alienkid@unaffiliated/alienkid10) |
| 22:38:18 | alienkid10 | is the RB RTC and my OF RTC synced? (using Fuze+ here not sure if it matters) |
| 22:40:27 | | Quit robin0800 (Ping timeout: 240 seconds) |
| 22:42:08 | | Quit bieber (Read error: Operation timed out) |
| 22:45:00 | | Join robin0800 [0] (~robin0800@149.254.60.156) |
| 22:45:34 | | Join chkktri_ [0] (~user@n18-c87.client.tomica.ru) |
| 22:54:18 | TheSeven | funman: if you're interested: |
| 22:54:18 | TheSeven | C:\Users\Admin\Desktop>emcore hexdump 0x38400044 0x10 4 4 2 1 |
| 22:54:19 | TheSeven | Connected to emCORE Debugger v0.2.2 r836 running on iPod classic |
| 22:54:19 | DBUG | Enqueued KICK TheSeven |
| 22:54:19 | TheSeven | 38400040: 00000264 228F60D0 082000E8 | d... .`.".. .| |
| 22:54:19 | TheSeven | 38400050: 1BF08030 |0... | |
| 22:54:45 | TheSeven | Connected to emCORE Debugger v0.2.2 r836 running on iPod nano 2g |
| 22:54:45 | TheSeven | 38400040: 01F07003 000FEDEB E8D1E9C1 | .p.. ........| |
| 22:54:45 | TheSeven | 38400050: 00000000 |.... | |
| 22:55:00 | TheSeven | er, wrong base address |
| 22:56:26 | *** | Saving seen data "./dancer.seen" |
| 22:56:34 | TheSeven | Connected to emCORE Debugger v0.2.2 r836 running on iPod nano 2g |
| 22:56:34 | TheSeven | 38800040: 00000264 228DD9D0 050004E8 | d... ..."....| |
| 22:56:34 | TheSeven | 38800050: 01F08001 |.... | |
| 22:56:47 | | Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) |
| 22:56:47 | TheSeven | so the endpoints are the same, but the rest isn't |
| 22:59:32 | | Quit perrikwp (Ping timeout: 252 seconds) |
| 23:00 |
| 23:01:42 | | Quit alienkid10 (Quit: bye) |
| 23:01:58 | | Quit benedikt93 (Quit: Bye ;)) |
| 23:02:19 | TheSeven | hm, if i interpret that information correctly this means that the FIFO is bigger than I thought |
| 23:08:25 | | Quit chkktri_ (Ping timeout: 240 seconds) |
| 23:16:37 | | Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) |
| 23:18:56 | | Nick perrikwp_ is now known as perrikwp (~quassel@cpe-024-163-024-033.triad.res.rr.com) |
| 23:25:54 | | Quit y4n (Quit: AMIGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAHAHAAAAAAAAAAAAHAHAAA) |
| 23:35:46 | | Join chkktri_ [0] (~user@109-227-209-014.nts.su) |
| 23:38:38 | funman | TheSeven: the rest can be removed or #if'd out i guess, we don't need it now that the driver works ok |
| 23:39:09 | funman | and registers need to go in usb-s3c6400x.h |
| 23:41:32 | TheSeven | funman: I just parsed the data: http://www.freemyipod.org/wiki/USB_OTG_features |
| 23:42:09 | TheSeven | (and spotted some previously-unknown features) |
| 23:42:19 | TheSeven | especially the fact that we seem to have even more endpoints is nice :) |
| 23:43:02 | funman | TheSeven: hmm bidi endpoints also? |
| 23:43:10 | TheSeven | apparently |
| 23:43:27 | funman | iirc there was only in or out EPs when i checked on amsv2 |
| 23:43:36 | funman | i'll get you the regdumps (not today tho) |
| 23:43:44 | TheSeven | yeah, that's what I probed back then as well |
| 23:44:01 | TheSeven | but I didn't try the ones in the middle after I found that reg :) |
| 23:44:09 | funman | :o) |
| 23:45:23 | | Join Osix [0] (~saurpriva@cpe-72-231-148-65.nycap.res.rr.com) |
| 23:45:42 | TheSeven | funman: where did you find docs on that register btw? |
| 23:45:50 | TheSeven | the s3c6400x datasheet doesn't mention them |
| 23:45:57 | TheSeven | are they listed in some AMS datasheet? |
| 23:47:57 | saratoga | whats BIDI? |
| 23:49:06 | TheSeven | bidirectional |
| 23:52:54 | | Quit davo (Quit: Lost terminal) |
| 23:58:14 | | Quit perrikwp (Ping timeout: 240 seconds) |
icon identifies that the person is a core developer (has commit access).