--- Log for 31.12.111 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 15 hours ago 00.02.48 Quit Topy44 (Ping timeout: 240 seconds) 00.06.40 # does anyone know which four color/brightness hex values a 2 bit screen can display without interpolating? 00.07.08 # besides 000000 and FFFFFF i mean :) 00.07.41 # dfkt: 0, 1, 2 and 3 00.08.51 # that doesn't help for backdrop images 00.09.08 # does it just map everything above 0x0000003 to 3? 00.09.26 # thats how i'd do it 00.09.32 # (never looked at the code though) 00.09.42 # i tried straight values like 888888 or CCCCCC, but they look interpolated on screen, brigher and darker pixels 00.12.23 # dfkt: what's your source ? 24bits .bmp ? 00.15.19 # 4bit bmp 00.15.41 # lowest i can go in photoshop 00.15.57 # (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 # hmm.. 666666 looks good, but its double, CCCCCC doesn't 00.28.29 # 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 # pamaury: can you track it down to the birth or death of someome famous? 00.32.34 # gah, this usb driver is all flaky 00.36.37 # dfkt: shouldn't it be 000000, 555555, aaaaaa and ffffff? 00.36.54 Quit bluefoxx (Ping timeout: 240 seconds) 00.37.44 # or, if the dithering algorithm is broken, something close to that at least 00.38.15 # TheSeven: you've seen todays logs / FS patch ? 00.38.30 # no, i wasn't highlighted 00.39.02 # hm, or rather I was highlighted, but that was apparently when I was in the car 00.40.18 # funman: Sun Aug 16 04:22:04 1970 approx 00.40.41 # I did asctime(localtime(time()-imx233_rtc_seconds)) basically 00.41.35 # TheSeven: FS#12497 00.41.36 # http://www.rockbox.org/tracker/task/12497 3Reorganize USB initialization to make it work with FreeBSD (patches, unconfirmed) 00.41.45 # so it's indeed in 1970 but something is wron 00.41.46 # g 00.42.35 # TheSeven: and i am still around if there are any comments or problems with my patch 00.43.16 # a quick glance at that discussion tells me that it's a separate issue 00.43.25 # gevaerts: fyi 00.43.45 # in my case there's already SCSI traffic, so the descriptors must be right 00.44.15 # i am doing a 5gb transfer using the thus-patched rockbox usb stack right now 00.44.17 # all rock solid 00.44.28 # 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 # plush: it's not going to make any difference after connecting 00.45.25 # gevaerts: this particular patch - no 00.45.37 # but remember, the freebsd usb stack is quite different from those you are used to 00.45.38 # seems like enabling logf is sufficient to make it break intermittently on nano2g as well 00.45.45 # 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 # so it's nice to see that the rest of the rockbox usb stack works smoothly with it 00.46.06 # plush: yes, but you said it used to work :) 00.46.20 # Apart from that initialisation, nothing has changed 00.46.25 # gevaerts: sure. it broke several months ago though. who knows what could have bitrotted since then... 00.46.27 # ah, ok 00.46.30 # i didn't know that 00.46.52 # though a lot changed on the freebsd side. i moved to a new release... the host usb stack is quite different 00.47.01 # so it's nice to see that there was just one small kink to work out 00.47.10 # i remember when there was no rockbox usb stack at all 00.47.13 # 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 # I remember when the rockbox usb stack corrupted every 29th to 31st byte :) 00.48.35 # i remember when the usb stack was off by default 00.48.46 # back then, freebsd would panic if a mounted disk went away 00.48.56 # man did i rockbox my box many times... 00.49.16 # ... i just couldn't resist running the flaky usb stack 00.49.55 # It worked well for me! 00.51.07 # it eventually worked well, absolutely 00.51.13 # but there were ups and downs 00.51.20 # and every down meant a panicked desktop 00.51.26 # * gevaerts nods 00.55.20 # 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 # http://www.rockbox.org/tracker/task/12497 3Reorganize USB initialization to make it work with FreeBSD (patches, unconfirmed) 00.55.26 # 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 # 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 # Yes, that would be useful. A similar situation on mr500 is why I couldn't test the (b) case yet :) 00.59.17 # damn, reverting funman's changes doesn't fix the timing trouble 01.01.35 # 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 # this looks like the USB thread's state machine might be getting confused 01.02.18 # The obvious one would be not seeing the disconnect 01.02.39 # this seems to be detected by repeatedly polling vbus, so i can't see how that could get lost 01.02.46 # Are you USB_STATUS_BY_EVENT? 01.02.54 Quit Xerion (Ping timeout: 252 seconds) 01.04.50 # * TheSeven greps 01.06.10 # seems not, just usb_detect called from usb_tick() 01.06.17 # apparently 01.06.57 # so it looks like the EXTRACTED event is getting lost 01.07.30 # yes 01.07.49 # I can't think of another possibility right now 01.10.17 # well it might got lost in the usb thread's event queue (but overflows do panic, don't they?) 01.10.26 # or it might not be broadcast to the UI thread for some reason 01.11.31 # TheSeven: jethead committed a fix recently for ams bootloader 01.11.35 # might be related 01.11.38 # Both sound unlikely 01.11.47 # Well, everything sounds unlikely 01.12.10 # i've seen rapid sequences of plugging and unplugging making it go completely bonkers, so there might be some race here 01.14.13 # 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 # these seem to never get retracted if you yank the cable before the other threads have reacted 01.14.31 # plush: all models do that :) 01.14.42 # also, there is a very crude mechanism for dealing with lost acks 01.14.54 # it just forgets about outstanding requests after a while 01.15.17 # 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 # given how little i know about the rockbox usb stack, my comments may alle be wrong for what i know 01.16.28 # at the same time, it is very late 01.16.31 # conclusion: bedtime 01.16.32 # nn 01.17.43 # That sort of thing could explain rapid replugging giving problems, yes 01.18.11 # * TheSeven adds debugging output 01.19.01 # looks like it's the USB_EXTRACTED event that never reaches the USB thread 01.19.44 # Is it posted, or not even generated? 01.19.44 # USB_EXTRACTED == 0, right? 01.20.01 # yes 01.20.20 # queue_post(&usb_queue, current_status, 0); is being called 01.20.26 # and current_status == 0 01.20.57 # but case USB_EXTRACTED: in usb_thread isn't reached 01.21.09 # ok, so either the queue overflows silently, or the thread loop is blocked somewhere 01.21.21 # but in a way that makes replugging unblock it somehow 01.21.47 # Which again seems unlikely 01.22.37 # hm 01.22.39 # looks like my re-plugging isn't even being detected 01.22.45 # it just unblocks the thread 01.22.53 # doesn't post another INSERTED event 01.23.04 # it just continues the regular unplugging operation 01.23.38 # it doesn't even reach the queue_post 01.24.26 # 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 # so the thread must be stuck in something that unsticks as soon as there is another IRQ or something 01.24.56 # the queue_post? 01.25.10 # the one in usb_tick doesn't even fire the inserted event 01.25.17 # it wakes up nevertheless 01.25.43 # Ah, you mean the second time? 01.26.14 # yeah 01.26.18 # the re-plugging 01.27.13 # I guess the "three consecutive states must be equal" thing gives it just enough time to unblock the first one 01.28.55 # I'd say it's probably stuck deep in usb_core_handle_transfer_completion() 01.29.50 # would that block the usb thread? 01.30.16 # That's called in the USB_TRANSFER_COMPLETION case, so yes 01.30.41 # ok, the last processed event id before unplugging is 3 01.30.46 # Conceptually that should be a different thread, but that's a waste 01.30.51 # and it doesn't change when unplugging 01.31.33 # grr. now it hard locked after unplugging in the main menu :/ 01.31.39 # backlight thread is still running though 01.35.06 # gevaerts: where are all these event IDs defined? 01.35.17 # usb.h 01.35.53 # so, in my case, USB_TRANSFER_COMPLETION == 3? 01.36.10 # yes 01.36.26 # * TheSeven wonders if anything uses that blocking tx function 01.36.50 # 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 # control replies are usually sent using the blocking variant 01.39.49 # yep, gets stuck in there 01.39.59 # sending an 18 byte packet on ep0 which never gets acked 01.40.13 # 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 # 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 # hm, the state of the endpoint before setting up the transfer is ENABLE ACTIVE NAK 01.46.03 # and a reserved bit :/ 01.47.03 # ah, right, that's endpoint traversal order stuff 01.47.19 # ok, so that EP should be NAKing all requests that it gets 01.53.37 # 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 # 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.01.36 # 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 # 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 # 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 # gevaerts: are you still awake? 02.38.49 # 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 # hello? 02.58.22 # I have a Sansa Clip+ that just locked up after rockbox database initialization 02.58.39 # bricked? No screen after holding power button 02.58.47 # nothing on USB 02.58.49 # [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 # I have the unit open and the battery is OK 02.59.40 # 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.14 # after a small number of retries the host would time out, before the ipod has even prepared the response 03.00.33 # 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 # 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 # does anything turn up on the USB bus? 03.05.19 # when I plug it in, I get a "duh duh" sound in win7, tried to install device software but failed 03.07.06 # "UNDEF storage USB device" shows up under drives in device manager 03.22.37 # do you think it's bricked? TIA 4UR help 03.51.47 Part jlbiasini 04.00.49 Join NolenJHej [0] (~NolenJHej@50-48-2-127.dsl1.monr.ny.frontiernet.net) 04.01.24 # 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 # My clip+ stopped working after database refresh, power button reset doesn't work, can anyone help? 04.10.06 # 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 # 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 # 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 # I didn't notice a bug on flyspray for it... 04.41.00 # 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.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 # 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 # Wait, toa, you're still here right? (I just d/c'd.) 06.00.26 # 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 # However, I found this: http://anythingbutipod.com/forum/showthread.php?t=66292 06.00.58 # Worked just fine for me. Just got Rockbox running, actually. 06.01.29 # NolenJHeju, Yes, I'm still here. Just saw your message. 06.02.29 # Let me take a look at t. 06.02.30 # *it 06.04.20 # 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 # 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 # 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 # 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 # 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 # Jack87, is that a capability of the regular firmware? 06.44.03 # 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 # I am reading the Sansa FAQ right now and it talks about the radio but its a bit unclear 06.46.36 # well the Rockbox FAQ for sansa that is 06.47.47 # Still checking, Jack87 06.48.30 # toa, thanks me to :-) 06.49.09 # ya so FM recording is present on the original firmware 06.53.45 # I haven't found anything definitive, but I would bet that it will work. 06.54.32 # 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 # 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 # should i first install latest sandisk firmware? 06.57.50 # I don't see why not, but I admit I haven't installed Rockbox recently. 06.58.06 # Jack87, find out if it is v1 or v2 of the e200. 06.58.27 # http://www.rockbox.org/wiki/SansaE200Port#Identification_of_version 06.58.31 # From what i can tell its a version 1 as the girmware reads v1.02.12 currently 06.59.14 # do you know if its even supported on v2? 07.01.00 # firmware** 07.02.25 # Jack87, I think it's supported on both. 07.02.50 # Yes, it is. 07.02.58 # thats good to know. its sad SDHC drivers are not present on v1 official firmware 07.03.55 # 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 # Jack87, possibly, if you're savvy. 07.05.21 # Take a look at http://www.rockbox.org/wiki/SansaAMS if you haven't already. 07.05.38 # The original firmware is available for download. 07.05.40 # haha i wish i was savy enough. maybe in a year or so 07.05.45 # awesome thanks 07.05.59 # ill prolly dig around in it :) 07.07.05 # sounds good 07.09.02 # ill prolly dig around in it :);9 07.09.05 # :(* 07.10.06 # anyway rockbox seem awesome! and very well organized and put together. exciting stuff 07.10.21 # Does anyone here have any experience with Rockbox on a Clip Zip? 07.10.49 # Jack87, I agree. I'm looking forward to installing it when I can. 07.11.02 # Jack87, not that I have any major qualms with the original firmware. 07.11.19 # toa, I think i ran into something on the wiki saying clip zip was not supported? but i am not sure 07.11.54 # 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 # Jack87, Yeah, you're right. It's not completely finished, but I'm trying to discern its current status. 07.13.02 # sorry it says its unstable for th sansa clip 07.13.19 # http://www.rockbox.org/wiki/SansaClip#Sansa_Clip_Zip_port_status 07.13.57 # Jack87, well the device was apparently only released in October, so they've made quick work. 07.14.30 # ya thats awesome... i mean that link is status of like 2 weeks ago 07.27.27 # 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.05.34 # yeah 08.06.17 # toa: to install clip zip bootloader follow instructions on wiki: SansaAMS 08.06.34 # you need to build mkamsboot from source or use http://people.videolan.org/~funman/mkamsboot-1.5/ binaries 08.08.11 # http://www.rockbox.org/wiki/SansaClip#Sansa_Clip_Zip_port_status (a bit outdated) 08.08.57 # funman, was that videolan link for me? 08.09.17 # yeah 08.09.38 # 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 # Oh, OK. So it is going to be a very short time before the Clip Zip is officially supported? 08.11.33 # funman, the other items on the to-do list seemed rather trivial. 08.12.25 # Oh, the port status just updated. 08.13.18 # 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 # 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 # toa: yeah... i noticed one amazon review says the microsd doesn't protrude the tiny bit it does on the + 08.16.56 # which i kinda feel like sticking some tape over just to make sure that sucker doesn't pop out 08.17.00 # heh 08.17.52 # that 32G could disappear in the blink of an eye if it were to go flying :p 08.18.23 # It's still pretty secure in there, despite the protrusion, I imagine. 08.18.56 # [Saint], they don't happen to have a 2nd gen iPod replacement program too, do they? 08.19.10 # I'm referring to the original 2G 5/10/20GB iPod :P 08.19.59 # 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.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.11.45 # hi all, do video4fuze video formats get recognized by rockbox? 10.15.49 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.22.34 # 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 # 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 # 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 # thanks, i'll look into that, but i'm mostly a dedicated linux user 10.28.47 # 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 # ah good to know 10.29.36 # 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 # okay sounds good, the linux method looks interesting, but i'll give the WinFF a shot first 10.31.39 # thanks for your help [Saint] 10.38.40 # [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 # 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 # xvid wont work though 10.52.53 # mpeg-1 only i think 10.56.07 *** Saving seen data "./dancer.seen" 10.57.23 Join ender` [0] (~ender@foo.eternallybored.org) 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 # hm, only presets winFF offers are MS Compatible AVI, XviD FullScreen, XviD Widescreen, XviD Widescreen Anamorphic. 11.18.17 # if xvid wont work, I just tried MS Compatible AVI and doesn't recognize 11.19.01 # oh crap, my bad, i was listing the presets, i failed to look under the Convert to: menu X-x 11.19.32 # 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 # 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 # kugel: hey ;) 11.28.56 # 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.01.41 # hello: iks rockbox.org down? 12.02.03 # 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 # jlbiasini: seems working for me... 12.20.23 # 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 # kugel: gives also if end of charge or not (uses some ascoded rregisters of course) 12.25.33 # lorenzo92: yeah we can get eoc through other modules indeed 12.25.41 # [7]: *why* wasn't the endpoint set up properly? 12.25.59 # I saw your paste 12.26.02 # kugel: interesting. Default charging current is 55 mA 12.26.07 # Ah, a related commit 12.26.42 # kugel: need to see in the OF... 12.28.20 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 12.31.44 # lorenzo92: that seems low 12.32.20 # 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 # maybe in the "minivet" device 12.33.05 # saratoga: did you have a gnuplot cmd line for battery benches? 12.33.14 # lorenzo92: or didnt you make graphs? 12.35.39 # kugel: I did them iin calc :) 12.36.01 # if you want I share the odf... 12.36.04 # sure 12.37.06 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 12.38.29 # 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 # lorenzo92: thanks 12.48.11 # lorenzo92: will commit the pm stuff along with the battery courves then 12.48.34 # ;) 12.49.14 # kugel: are some other benches needed? 12.53.56 # lorenzo92: you can do a full bench if you like, but it#s not necessray 12.54.25 # kugel: okay I'll do that when the autoshutdown is fixed ;) 12.56.11 *** Saving seen data "./dancer.seen" 13.05.13 # 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 # pamaury: didn't the AMS sansas do something similar, related to DRM? 13.06.58 # I don't know, the sansa AMS driver has some hardcoded values 13.07.17 # but here, the OF stores it in a persistent register and allows itself to write it ! 13.07.23 # I'm still reversing the code 13.08.40 # 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 # pamaury, as I understand it, the OF never really adjusts the RTC, it just adjusts this offset 13.23.09 # (for the AMSes) 13.24.49 # 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 # pamaury: oh! interesting, also yp-r0's OF does something strange like that with the time!! 13.35.44 # in our case this value is saved in a small part (1mb) of the nand 13.35.55 # where also other settings are stored like region code... 13.35.57 Join MethoS- [0] (~clemens@134.102.106.250) 13.37.33 # 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 # 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 # 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 # 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 # And when encoder options contain a space, voice.pl fails due to borken argument passing 13.52.12 # 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 # Also the default encoder options seem to be gone? 13.55.00 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 13.56.26 # lorenzo92 (for the logs): it's better if rb does as the OF for compatibility 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 # New commit by 03kugel (r31471): Enable (and fix) battery_bench on hosted targets. 14.35.27 # New commit by 03kugel (r31472): ypr0: Proper battery curve measured with battery_bench. 14.35.47 # New commit by 03pamaury (r31473): imx233/fuze+: implement rtc (time only, alarm still to implement) 14.36.49 # 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 # 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 # New commit by 03pamaury (r31475): imx233: forgot a file 14.51.26 # CIA-88 isn't following :) 14.51.39 Quit [Saint_] (Remote host closed the connection) 14.52.12 # r31475 build result: All green 14.55.46 # it missed a commit 14.56.12 *** Saving seen data "./dancer.seen" 14.56.18 # 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 # 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.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 # 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 # 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 # Define "active" 15.04.00 # 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 # 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 # 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 # 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 # 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 # 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 # 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 # Well yes, it has to be done once somewhere at the beginning of the connection 15.11.05 # 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 # 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 # 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 # 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 # 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 # Well, wait, hm 15.17.19 # 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 # ok 15.19.10 # 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 # [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 # 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 # what is morse input? Doesn't this need a line in jack to work? 15.30.37 # jlbiasini: no, you tap a button 15.30.49 # 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 # [7]: r31469, is that needed in usb-drv-as3525v2? iirc it was not 15.32.43 # [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 # 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 # 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 # hm 15.38.15 # no, that's not true. It uses 24K 15.38.31 # gevaerts: you need testing? I can use my clipv1 15.38.40 # Actually, it's half true 15.39.19 # 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 # WRITE_BUFFER_SIZE is already 24K because it's SD 15.40.25 # This should really be tuned for every pair of storage type and usb controller. There's some speed hiding there 15.41.20 # pamaury: so i still have to implement morse keymaps so you can wait a little more before commiting my keymaps update 15.41.59 # New commit by 03kugel (r31470): ypr0: Enable battery voltage read-out, charging monitoring and charger detection. ... 15.42.12 # New commit by 03gevaerts (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 # r31476 build result: All green 15.45.13 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 15.46.27 # gevaerts: gevaerts should i test r31476 or 31475 ? 15.47.31 # funman: whichever you like. r31476 shouldn't change anything, all AS3525 players use USBOTG_AS3525 15.48.16 # 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 # true 15.48.58 # 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 # hm i reproduced FS#12485 15.52.42 # http://www.rockbox.org/tracker/task/12485 3Seeking in .ape file doesn't work (bugs, unconfirmed) 15.52.47 # FS#12475 * 15.52.48 # http://www.rockbox.org/tracker/task/12475 3Crash while playing audio (bugs, unconfirmed) 15.53.42 # gevaerts: 642236416 octets (642 MB) copiƩs, 150,357 s, 4,3 MB/s 15.53.58 # that's unmodified r31475 performance (63kb) 15.54.16 # rebooting to test a new build since Linux keeps crashing .. 15.54.29 # Tell it not to do that! ;) 15.58.06 # i use dd bs=5120 btw 15.59.38 # hm, that will influence things 16.00.10 # Most OSes (I don't know about freebsd!) use 64K blocks for USB communication 16.00.15 # tell me which settings i should use to not test under influence 16.00.54 # 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 # You can use larger, but then the kernel will split it up 16.01.42 # same bs=5120 with buffer set to 32kb : 3,3MB/s 16.01.56 # kugel: Shouldn't it be possible to make the db commit work without reboot now, using buflib? 16.01.59 # hm, maybe the kernel also combines those? 16.02.02 Quit benedikt93 (Quit: Bye ;)) 16.02.04 # you want dd bs=64k now? 16.02.04 # <[7]> apparently 16.02.17 # When dircache is disabled, that is (when it's enabled that already works) 16.02.17 # ok, it should probably be left at 63 then 16.02.23 # Yes 16.02.39 # <[7]> how does dd bs=1048576 of=/dev/null behave? 16.03.20 # [7]: ? 16.03.29 # [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 # [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 # 63, and not 64, you mean? 16.04.49 # The comment says that on AMSv1 the driver doesn't do transfers larger than 65535 bytes 16.04.51 # <[7]> yes 16.05.00 # DMA register iirc 16.05.12 # 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 # 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 # yes, that sounds like a good optimisation 16.10.36 Join marcol07_Marek_L [0] (~4e628860@www.haxx.se) 16.11.03 # 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 # hm, no, we do that already really 16.13.12 # * gevaerts was confusing READ and WRITE :\ 16.13.46 # [7]: do you have usb-s3c6400x changes in progress? 16.13.53 # Anyway, I'm leaving for now 16.13.59 # 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 # ok i'll start right away 16.18.20 # amiconn: yes 16.19.42 # 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 # I can't get this working on the fuze+ 16.21.01 # does is need doubletouch (like holding morseinput wjile doing sequence with morseselect ? 16.25.57 # I think that if ever one day someone come complaining about this I will then implement it 16.26.18 # :) 16.26.27 # * [7] is amazed by windows doing single sector reads while scanning the fat 16.26.45 # jlbiasini: good idea ;) 16.31.27 # 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 # yeah 16.33.06 # output log is difficult to parse also :/ 16.40.05 # 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 # ace/images/ss-virtual-keyboard-240x320x16.png (no BoundingBox) 16.41.02 # hoho this image is not even from me!! 16.41.15 # ok I suppose this could be ignored then 16.41.18 # no clue, that's the kind of problem i'm speaking about 16.41.25 # is that a warning? an error? is it fatal? 16.41.43 # a warning 16.43.47 # there is also a ! LaTeX Error: There's no line here to end. 16.44.21 # seems to be related to some \\ but there where there before me... 16.44.34 # New commit by 03funman (r31477): usb-s3c6400x.c: move usb_detect and usb_enable 16.46.25 # jlbiasini: compare to a working manual build 16.46.38 # 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 # [7]: do we really need to handle builds without USBSTACK ? 16.56.16 *** Saving seen data "./dancer.seen" 16.58.15 # New commit by 03theseven (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 # okay this versioning thing is a real annoyance 16.59.37 # i am tempted to give up and let it just emit SHAs for now 17.00.08 # or.. hm 17.01.00 # Torne: i'm sure we'll figure out something, won't we? 17.01.30 # git describe is annoying because it's kinda.. retroactive 17.01.48 # the versions of commits that already exist (and may have been built) might change because of newly created tags 17.02.32 # if a user give the version, will it be easy to find which build he uses exactly? 17.02.50 # it's the most important question to ask 17.03.21 # hm. that depends. 17.03.38 # ther eisn't an easy way to go from tag+commits to a hash, no 17.03.47 # the describe output is only parseable if you actually inlcude the SHA 17.03.59 # git can only count backwards, not forwards 17.04.03 # because forwards is ambiguous 17.04.35 # this is probably true of all schemes that are going to produce a number that increases with subsequent builds :) 17.04.48 # unless we just tag all the builds at the master. 17.05.21 # which we could, but that won't identify anything that doesn't correspond to a build 17.12.08 # what's wrong with the last sha again? 17.12.22 # entirely meaningless to users 17.12.26 # no way to even tell which is newer 17.14.36 # 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 # New commit by 03funman (r31478): usb-s3c6400x: move usb_init_device 17.17.20 # Torne: you can tell the bug is fixed in last build 17.17.27 Quit liar (Read error: Connection timed out) 17.17.35 # technically not :) 17.17.39 # why? 17.17.44 # maybe it's not been built yet 17.17.47 # or been pushed ot master 17.17.59 # or is on another branch 17.18.09 # we only have one branch don't we? 17.18.48 # now we say 'fixed in 3.10' or 'fixed in current build' 17.18.49 # r31478 build result: All green 17.19.17 # or at worst 'just fixed, wait 2 minutes for the build to appear' 17.19.27 # or 'there's a patch not committed yet' 17.20.55 # for users there's only last release and last build which counts 17.21.04 # developers can find commits themselves or we can help them 17.23.04 # meh 17.23.11 # how do we want to format it, then? 17.24.19 # short sha? 17.24.55 # some kidn of prefix might be good to distinguish mostly-numeric hashes from svn revnos ;) 17.25.10 # git describe uses 'g' 17.26.06 # i don't think we need a prefix to make the distinction 17.26.16 # 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 # done :) 17.32.29 # though CIA hasn't noticed 17.33.17 # for revisions that correspond exactly to svn it will still print the svn revision 17.33.25 # for anything else it will just use the short SHA1 17.34.07 # r31480 build result: All green 17.35.08 # cia has y2k12 bug possibly 17.35.17 # heh 17.35.27 # Torne: that's nice to use svn numbers 17.35.46 # 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 # New commit by 03torne (r31479): Remove bzr support from tools/version.sh. ... 17.44.52 # no 17.48.00 # New commit by 03dreamlayers (r31481): Fix FS#12499 - Directory playback fails after saving playlist ... 17.53.42 # New commit by 03theseven (r31482): usb_core: Fix typo in comment 17.57.11 # * TheSeven really likes it when logf fixes bugs 17.57.44 # File creation fails in paths under /./, so HOME_DIR breaks some things. 17.59.45 Join tails___ [0] (~user@83.149.48.69) 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 # 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 # New commit by 03torne (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 # 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 # 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 # 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 # 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 # hm, additionally a suspend and bus reset is logged 19.07.01 # 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 # New commit by 03alle (r31483): Update the Russian translation (FS#12420 by James Hunt) 19.26.06 # r31483 build result: All green 19.31.54 # New commit by 03dreamlayers (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 # r31484 build result: All green 19.34.59 # 12 commits incoming .. 19.35.05 # 13 actually 19.38.47 Quit fs-bluebot (Ping timeout: 240 seconds) 19.39.24 Quit bluebrother^ (Ping timeout: 244 seconds) 19.39.46 # New commit by 03alle (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 # r31485 build result: All green 19.43.33 # New commit by 03funman (r31486): usb-drv-as3525v2: move interrupt disable 19.43.42 # New commit by 03funman (r31487): usb_init_device(): move prototype to usb.h ... 19.43.58 # New commit by 03funman (r31488): move usb_pin_init() declaration to PP's system-target.h ... 19.44.03 # New commit by 03funman (r31489): usb_plugged() is PP only 19.44.06 # pamaury: keymaps are ready -> http://www.rockbox.org/tracker/task/12405#comment42043 could you commint them? 19.44.10 # New commit by 03funman (r31490): usb_drv_connected() is declared in usb_drv.h 19.44.17 # New commit by 03funman (r31491): firewire/usb_remove/insert_int: move to system-target.h 19.44.19 # New commit by 03funman (r31492): delete usb-target.h content redundant with PP usb-target.h 19.44.25 # New commit by 03funman (r31493): gigabeats usb-target: merge in system-target.h 19.44.28 # New commit by 03funman (r31494): USBOTG_ARC's USB_DRIVER_CLOSE: move to config.h 19.44.36 # New commit by 03funman (r31495): creative zvm isp1583 defines: move to isp1583.h ... 19.44.39 # New commit by 03funman (r31496): onda usb code: merge into .c file 19.44.48 # New commit by 03funman (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 # wtf? the guy is commiting one year work or what??? 19.44.56 Quit jae (Ping timeout: 252 seconds) 19.45.03 # :) 19.45.05 # New commit by 03funman (r31498): usb-target.h: remove 19.45.22 # no just small separated commits .. 19.45.22 # r31486 build result: All green 19.45.40 # New commit by 03kugel (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 # ow 19.46.24 # 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 # *purr* 19.47.15 # heh 19.47.21 # * TheSeven didn't know that one yet 19.47.26 # http://cia-vc.googlecode.com/svn/trunk/cia/LibCIA/IRC/Bots.py 19.47.53 # r31482 build result: All green 19.48.08 # 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 # not that bad 19.49.59 # hm, looks like there's once again a usb thread deadlock, but it's outside the storage code this time 19.50.05 # New commit by 03funman (r31499): imx233: fix power_input_status() 19.50.14 # and doesn't seem to be in a usb_drv function either 19.50.22 # 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 # http://www.rockbox.org/tracker/task/12492 3add fuze+ manual (patches, unconfirmed) 19.50.33 # heh, that's the downside of git-svn 19.50.46 # New commit by 03funman (r31500): onda: remove now inlined USB_INIT_GPIO() 19.51.13 # * TheSeven accuses funman of juggling with code :) 19.51.20 # TheSeven: which downside? 19.51.26 # TheSeven: i just wanted r31500 :) 19.51.50 # * jlbiasini is going to test hid again as he is getting suspicious ;) 19.52.02 # 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 # r31499 build result: 18 errors, 4 warnings (funman committed) 19.52.43 # TheSeven: true 19.52.58 # but one by one commits can break equally 19.53.00 # * jlbiasini thanks TheSeven about that 19.53.10 # that's a downside about gazillions of targets i'd say 19.53.36 # if you do one by one commits, you notice the breakage earlier and repair it before committing the rest 19.54.12 # right 19.54.33 # no fun! 19.54.40 # :D 19.54.53 # r31500 build result: All green 19.55.12 # fuze+ delta is suspicious 19.56.08 # 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 # http://pastie.org/3103147 is more suspicious 19.56.22 # pamaury: was that for me ? 19.56.34 # funman: yes 19.56.47 # i don't understand 19.57.25 # I thought you were talking of the fuze+ memory usage reported on dev.cgi which is over 1Gb :) 19.57.29 # usb_thread has not the same size 19.57.34 # no, about the delta 19.58.04 # indeed, 250 bytes of such a small thing :-s 19.58.08 # *for 19.58.24 # things* 19.58.38 # different sizes in old.elf and rockbox.elf: 360 456 __seq.2119 19.58.43 # __seq ? 19.59.01 # ah but a lot of symbols have changed names.. 19.59.22 # function old new delta 19.59.23 # usb_configure_drivers - 188 +188 19.59.30 # i must have added/removed an unwanted define 20.01.02 Join robin0800 [0] (~robin0800@149.254.61.216) 20.01.02 # hm, __seq is only used in the lcd driver, that seems weird 20.01.13 # bloat-o-meter.py output is better 20.01.35 # usb storage and hid still work on f+ let's check charging... 20.02.01 # ah if it works i'll just ignore it 20.03.35 # 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 # any key does that iirc 20.04.19 # yeah saratoga changed that quite recently 20.05.12 # pamaury: funman: right! 20.05.23 # 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 # funman: the fuze+ binsize delta may be due to USB_DRIVER_CLOSE not being defined 20.11.31 # in power-imx233.c ? 20.11.43 # 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 # jlbiasini: I noticed the fuze+ OF marks a partition as bootable, that's probably the reason 20.13.16 # dreamlayers: hm 20.13.18 Join marcol07 [0] (~4e628860@www.haxx.se) 20.13.23 # USB_DRIVER_CLOSE used to be defined in imx233/usb-target.h. I guess it's only needed in the bootloader. 20.13.51 # oh 20.13.57 # it must have been caused by r31494 20.14.23 # config.h only defines it in the bootloader for CONFIG_USBOTG == USBOTG_ARC. I wonder if that's correct. 20.14.54 # afaict all PP have USBOTG_ARC 20.15.35 # 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 # 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 # plug some usb key and see if^Wthat it's the same 20.22.20 # r31469 build result: All green 20.26.34 # r31481 build result: All green 20.27.16 # r31479 build result: All green 20.28.28 # funman: of course and only the fuze+ block it 20.29.26 # and this is not an OS problem, it's debian! :d 20.30.32 # funman: what was those commit on usb? some cleanup? 20.32.01 # removal of usb-target.h 20.32.27 # all sort of crap^Wthings accumulated in here 20.33.12 # a yes I understand 20.33.40 # 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 # 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 # np 20.44.48 # * TheSeven has a new suspicion about the classic usb trouble 20.46.47 # 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 # TheSeven: what does usb_attach do ? 20.47.43 # vpv: exact crash message + exact revision number (or even better, the corresponding .elf file) 20.48.10 # that might enable developers to figure out where exactly it crashed 20.50.26 # funman: no clue. I implemented it as usb_enable(true), which I'm sure I just copied from somewhere 20.50.36 # 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 # TheSeven: yeah i'm wondering why it differs from as3525v23 20.51.02 # -21 20.51.14 # vpv: you can try a current build also 20.51.16 # what does it do for that one? 20.53.47 # nothing 20.53.52 # 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 # now i'm tempted to add usb-target.h again for s5l870x and as3525v2 20.55.35 # or put needed defines in usb-s3c6400x.h and add 2 .c fiels 20.56.22 *** Saving seen data "./dancer.seen" 20.56.43 # seems better 20.57.48 # deameyes: how are you writing? 20.58.38 # 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 # TheSeven: hid things? 21.00.08 # might be related 21.00.29 # but in this case a get config descriptor request that windows issues for no apparent reason 21.00.31 # TheSeven: USB_STATUS_BY_EVENT and USB_DETECT_BY_CORE are not defined for nano2g :/ 21.01.03 # funman: yes, because I have never managed to make that work (didn't have time to debug it at that time) 21.01.30 # as3525v2 has them, can you figure it out? 21.01.52 Quit dreamlayers (Quit: back later) 21.01.58 # 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 # and an undocumented bit in the interrupt register getting set 21.02.27 # weird 21.02.30 # * TheSeven suspects this is related to FIFOs 21.02.56 # all bulk endpoints seem to share a common 512byte fifo 21.03.12 # TheSeven: usb is not needed for nano2g bootloader? 21.03.25 # needed in terms of what? 21.04.31 # let me rephrase 21.04.33 # we don't have a bootloader USB mode if you mean that (ipods are basically unbrickable) 21.04.37 # usb storage is not needed for classic bootloader? 21.04.48 # there is no such thing as a classic bootloader 21.05.02 # ok 21.08.30 # New commit by 03funman (r31501): usb-drv-as3525v2: cosmetics 21.08.35 # New commit by 03funman (r31502): Remove USBOTG_AS3525v2 21.10.40 # r31501 build result: All green 21.13.33 # r31502 build result: 24 errors, 1779 warnings (funman committed) 21.13.52 # grmbl 21.14.50 # New commit by 03funman (r31503): typo 21.17.15 # r31503 build result: 24 errors, 18 warnings (funman committed) 21.20.40 Part jlbiasini 21.20.55 # New commit by 03funman (r31504): fix r31502: USBOTG_AS3525v2 doesn't exist anymore 21.23.31 # r31504 build result: All green 21.29.10 # New commit by 03bertrik (r31505): Make local functions static in clock and chessbox plugin 21.30.07 Quit remlap (Read error: Connection reset by peer) 21.31.25 # r31505 build result: All green 21.38.48 # New commit by 03funman (r31506): usb-s3c6400x: start factorization 21.41.08 # r31506 build result: All green 21.42.24 # 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 # 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.01.11 # s3c6400x.c has one struct per endpoint while other drivers have one struct per endpoint per dir 22.01.22 # it could affect ep0 as it's bidir 22.11.50 # funman: just use the test thingy from your driver if you have one, I just haven't bothered :) 22.11.59 # (this function isn't used anywhere, is it?) 22.12.33 # 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 # yes it's used 22.13.30 # hm, what is it good for? 22.13.43 # 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 # absolutely no clue 22.13.55 # set_feature test things? 22.13.59 Join nosa [0] (~m00k@adsl-74-235-26-132.clt.bellsouth.net) 22.14.33 # funman: feel free to rework that endpoint state stuff, the way it's currently done in s3c6400x certainly isn't sane :) 22.14.58 # so if you manage to factor out the target specific parts, i'd just throw away the rest of that driver 22.15.11 # New commit by 03funman (r31507): usb-drv-as3525v2.h: remove 22.15.23 # TheSeven: i can't test on nano2g 22.15.38 # I can take care of that 22.17.27 # 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 # New commit by 03funman (r31508): usb-s3c6400: use more complete functions from usb-drv-as3525v2 ... 22.20.33 # r31508 build result: All green 22.21.01 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) 22.22.49 # New commit by 03funman (r31509): usb-drv-as3525v2.c: merge in usb-s3c6400x.c ... 22.23.28 # funman: is this nano2g-only so far or is it also supposed to work on the classic? 22.24.29 # i don't think i've made nano2g-only changes 22.24.42 # ok 22.25.00 # i enabled some bootloader bits for classic though by doing s/IPOD_NANO2G/USBOTG_S3C6400X/ but it shouldn't matter 22.25.13 # r31509 build result: All green 22.25.34 # if you changed the order of the register writes in usb_reset, n1s should probably test it, too 22.25.34 # btw which loop iteration you prefer 22.25.43 # his ipod seems to be more picky about those than mine 22.25.50 # i = out ? 2 : 1; i < USB_NUM_ENDPOINTS; i += 2 22.25.59 # or int8_t[] lists of in and out endpoints 22.26.23 # well, the latter is more clear but probably more bloat 22.26.25 # += 2 looks simpler 22.26.40 # we could use that and have a comment 22.26.56 # maybe we should get rid of those completely and detect the endpoints at runtime 22.27.19 # do the AMS chipsets have the same endpoint configuration? 22.27.44 # they have one more 22.27.53 # in that case I'd say go for autodetection 22.28.00 # also i don't know if the HWCFG registers exist on nano2g 22.28.07 # that's why i put the defs in as3525v2.h 22.28.17 # what is that? 22.28.51 # see r31507 22.29.06 # endpoints type & number 22.31.35 # funman: I think these regs are present... at least somewhere :) 22.32.29 # GHWCFG1 is definitely present, not sure about the other ones 22.37.52 Join alienkid10 [0] (~alienkid@unaffiliated/alienkid10) 22.38.18 # 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 # funman: if you're interested: 22.54.18 # C:\Users\Admin\Desktop>emcore hexdump 0x38400044 0x10 4 4 2 1 22.54.19 # Connected to emCORE Debugger v0.2.2 r836 running on iPod classic 22.54.19 DBUG Enqueued KICK TheSeven 22.54.19 # 38400040: 00000264 228F60D0 082000E8 | d... .`.".. .| 22.54.19 # 38400050: 1BF08030 |0... | 22.54.45 # Connected to emCORE Debugger v0.2.2 r836 running on iPod nano 2g 22.54.45 # 38400040: 01F07003 000FEDEB E8D1E9C1 | .p.. ........| 22.54.45 # 38400050: 00000000 |.... | 22.55.00 # er, wrong base address 22.56.26 *** Saving seen data "./dancer.seen" 22.56.34 # Connected to emCORE Debugger v0.2.2 r836 running on iPod nano 2g 22.56.34 # 38800040: 00000264 228DD9D0 050004E8 | d... ..."....| 22.56.34 # 38800050: 01F08001 |.... | 22.56.47 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 22.56.47 # so the endpoints are the same, but the rest isn't 22.59.32 Quit perrikwp (Ping timeout: 252 seconds) 23.01.42 Quit alienkid10 (Quit: bye) 23.01.58 Quit benedikt93 (Quit: Bye ;)) 23.02.19 # 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 # 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 # and registers need to go in usb-s3c6400x.h 23.41.32 # funman: I just parsed the data: http://www.freemyipod.org/wiki/USB_OTG_features 23.42.09 # (and spotted some previously-unknown features) 23.42.19 # especially the fact that we seem to have even more endpoints is nice :) 23.43.02 # TheSeven: hmm bidi endpoints also? 23.43.10 # apparently 23.43.27 # iirc there was only in or out EPs when i checked on amsv2 23.43.36 # i'll get you the regdumps (not today tho) 23.43.44 # yeah, that's what I probed back then as well 23.44.01 # but I didn't try the ones in the middle after I found that reg :) 23.44.09 # :o) 23.45.23 Join Osix [0] (~saurpriva@cpe-72-231-148-65.nycap.res.rr.com) 23.45.42 # funman: where did you find docs on that register btw? 23.45.50 # the s3c6400x datasheet doesn't mention them 23.45.57 # are they listed in some AMS datasheet? 23.47.57 # whats BIDI? 23.49.06 # bidirectional 23.52.54 Quit davo (Quit: Lost terminal) 23.58.14 Quit perrikwp (Ping timeout: 240 seconds)