Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2011-12-31

00:02:48 Quit Topy44 (Ping timeout: 240 seconds)
00:06:40dfktdoes anyone know which four color/brightness hex values a 2 bit screen can display without interpolating?
00:07:08dfktbesides 000000 and FFFFFF i mean :)
00:07:41funmandfkt: 0, 1, 2 and 3
00:08:51dfktthat doesn't help for backdrop images
00:09:08saratogadoes it just map everything above 0x0000003 to 3?
00:09:26saratogathats how i'd do it
00:09:32saratoga(never looked at the code though)
00:09:42dfkti tried straight values like 888888 or CCCCCC, but they look interpolated on screen, brigher and darker pixels
00:12:23funmandfkt: what's your source ? 24bits .bmp ?
00:15:19dfkt4bit bmp
00:15:41dfktlowest i can go in photoshop
00:15:57dfkt(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:14dfkthmm.. 666666 looks good, but its double, CCCCCC doesn't
00:28:29pamauryhmm, 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:16funmanpamaury: can you track it down to the birth or death of someome famous?
00:32:34TheSevengah, this usb driver is all flaky
00:36:37TheSevendfkt: shouldn't it be 000000, 555555, aaaaaa and ffffff?
00:36:54 Quit bluefoxx (Ping timeout: 240 seconds)
00:37:44TheSevenor, if the dithering algorithm is broken, something close to that at least
00:38:15funmanTheSeven: you've seen todays logs / FS patch ?
00:38:30TheSevenno, i wasn't highlighted
00:39:02TheSevenhm, or rather I was highlighted, but that was apparently when I was in the car
00:40:18pamauryfunman: Sun Aug 16 04:22:04 1970 approx
00:40:41pamauryI did asctime(localtime(time()-imx233_rtc_seconds)) basically
00:41:35funmanTheSeven: FS #12497
00:41:36fs-bluebothttp://www.rockbox.org/tracker/task/12497 Reorganize USB initialization to make it work with FreeBSD (patches, unconfirmed)
00:41:45pamauryso it's indeed in 1970 but something is wron
00:41:46pamauryg
00:42:35plushTheSeven: and i am still around if there are any comments or problems with my patch
00:43:16TheSevena quick glance at that discussion tells me that it's a separate issue
00:43:25TheSevengevaerts: fyi
00:43:45TheSevenin my case there's already SCSI traffic, so the descriptors must be right
00:44:15plushi am doing a 5gb transfer using the thus-patched rockbox usb stack right now
00:44:17plushall rock solid
00:44:28plush3.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:05gevaertsplush: it's not going to make any difference after connecting
00:45:25plushgevaerts: this particular patch - no
00:45:37plushbut remember, the freebsd usb stack is quite different from those you are used to
00:45:38TheSevenseems like enabling logf is sufficient to make it break intermittently on nano2g as well
00:45:45dfktTheSeven, 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:50plushso it's nice to see that the rest of the rockbox usb stack works smoothly with it
00:46:06gevaertsplush: yes, but you said it used to work :)
00:46:20gevaertsApart from that initialisation, nothing has changed
00:46:25plushgevaerts: sure. it broke several months ago though. who knows what could have bitrotted since then...
00:46:27plushah, ok
00:46:30plushi didn't know that
00:46:52plushthough a lot changed on the freebsd side. i moved to a new release... the host usb stack is quite different
00:47:01plushso it's nice to see that there was just one small kink to work out
00:47:10plushi remember when there was no rockbox usb stack at all
00:47:13gevaertsWell, 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:01gevaertsI remember when the rockbox usb stack corrupted every 29th to 31st byte :)
00:48:35plushi remember when the usb stack was off by default
00:48:46plushback then, freebsd would panic if a mounted disk went away
00:48:56plushman did i rockbox my box many times...
00:49:16plush... i just couldn't resist running the flaky usb stack
00:49:55gevaertsIt worked well for me!
00:51:07plushit eventually worked well, absolutely
00:51:13plushbut there were ups and downs
00:51:20plushand every down meant a panicked desktop
00:51:26*gevaerts nods
00:55:20gevaertsTheSeven: 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:21fs-bluebothttp://www.rockbox.org/tracker/task/12497 Reorganize USB initialization to make it work with FreeBSD (patches, unconfirmed)
00:55:26gevaertsNo 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:16gevaertsIf 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:04gevaertsYes, that would be useful. A similar situation on mr500 is why I couldn't test the (b) case yet :)
00:59:17TheSevendamn, reverting funman's changes doesn't fix the timing trouble
01:00
01:01:35TheSevengevaerts: 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:58TheSeventhis looks like the USB thread's state machine might be getting confused
01:02:18gevaertsThe obvious one would be not seeing the disconnect
01:02:39TheSeventhis seems to be detected by repeatedly polling vbus, so i can't see how that could get lost
01:02:46gevaertsAre you USB_STATUS_BY_EVENT?
01:02:54 Quit Xerion (Ping timeout: 252 seconds)
01:04:50*TheSeven greps
01:06:10gevaertsseems not, just usb_detect called from usb_tick()
01:06:17TheSevenapparently
01:06:57TheSevenso it looks like the EXTRACTED event is getting lost
01:07:30gevaertsyes
01:07:49gevaertsI can't think of another possibility right now
01:10:17TheSevenwell it might got lost in the usb thread's event queue (but overflows do panic, don't they?)
01:10:26TheSevenor it might not be broadcast to the UI thread for some reason
01:11:31funmanTheSeven: jethead committed a fix recently for ams bootloader
01:11:35funmanmight be related
01:11:38gevaertsBoth sound unlikely
01:11:47gevaertsWell, everything sounds unlikely
01:12:10TheSeveni've seen rapid sequences of plugging and unplugging making it go completely bonkers, so there might be some race here
01:14:13plushif your model requires exclusive access to the disk, requests are sent to all other threads to let go of the disk
01:14:30plushthese seem to never get retracted if you yank the cable before the other threads have reacted
01:14:31gevaertsplush: all models do that :)
01:14:42plushalso, there is a very crude mechanism for dealing with lost acks
01:14:54plushit just forgets about outstanding requests after a while
01:15:17plushi 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:24plushgiven how little i know about the rockbox usb stack, my comments may alle be wrong for what i know
01:16:28plushat the same time, it is very late
01:16:31plushconclusion: bedtime
01:16:32plushnn
01:17:43gevaertsThat sort of thing could explain rapid replugging giving problems, yes
01:18:11*TheSeven adds debugging output
01:19:01TheSevenlooks like it's the USB_EXTRACTED event that never reaches the USB thread
01:19:44gevaertsIs it posted, or not even generated?
01:19:44TheSevenUSB_EXTRACTED == 0, right?
01:20:01gevaertsyes
01:20:20TheSeven queue_post(&usb_queue, current_status, 0); is being called
01:20:26TheSevenand current_status == 0
01:20:57TheSevenbut case USB_EXTRACTED: in usb_thread isn't reached
01:21:09gevaertsok, so either the queue overflows silently, or the thread loop is blocked somewhere
01:21:21TheSevenbut in a way that makes replugging unblock it somehow
01:21:47gevaertsWhich again seems unlikely
01:22:37gevaertshm
01:22:39TheSevenlooks like my re-plugging isn't even being detected
01:22:45TheSevenit just unblocks the thread
01:22:53TheSevendoesn't post another INSERTED event
01:23:04TheSevenit just continues the regular unplugging operation
01:23:38TheSevenit doesn't even reach the queue_post
01:24:26gevaertsMaybe (vague handwaving here) one of the usb_drv_*() calls is blocking on something unexpected? I haven't looked at the driver source
01:24:27TheSevenso the thread must be stuck in something that unsticks as soon as there is another IRQ or something
01:24:56gevaertsthe queue_post?
01:25:10TheSeventhe one in usb_tick doesn't even fire the inserted event
01:25:17TheSevenit wakes up nevertheless
01:25:43gevaertsAh, you mean the second time?
01:26:14TheSevenyeah
01:26:18TheSeventhe re-plugging
01:27:13gevaertsI guess the "three consecutive states must be equal" thing gives it just enough time to unblock the first one
01:28:55gevaertsI'd say it's probably stuck deep in usb_core_handle_transfer_completion()
01:29:50TheSevenwould that block the usb thread?
01:30:16gevaertsThat's called in the USB_TRANSFER_COMPLETION case, so yes
01:30:41TheSevenok, the last processed event id before unplugging is 3
01:30:46gevaertsConceptually that should be a different thread, but that's a waste
01:30:51TheSevenand it doesn't change when unplugging
01:31:33TheSevengrr. now it hard locked after unplugging in the main menu :/
01:31:39TheSevenbacklight thread is still running though
01:35:06TheSevengevaerts: where are all these event IDs defined?
01:35:17gevaertsusb.h
01:35:53TheSevenso, in my case, USB_TRANSFER_COMPLETION == 3?
01:36:10gevaertsyes
01:36:26*TheSeven wonders if anything uses that blocking tx function
01:36:50gevaertsWhich 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:32gevaertscontrol replies are usually sent using the blocking variant
01:39:49TheSevenyep, gets stuck in there
01:39:59TheSevensending an 18 byte packet on ep0 which never gets acked
01:40:13TheSevenso 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:32gevaertsThat'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:55TheSevenhm, the state of the endpoint before setting up the transfer is ENABLE ACTIVE NAK
01:46:03TheSevenand a reserved bit :/
01:47:03TheSevenah, right, that's endpoint traversal order stuff
01:47:19TheSevenok, so that EP should be NAKing all requests that it gets
01:53:37TheSevenafter 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:06TheSevengrrrr
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:36dfkti 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:00dfktthat 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:14TheSevenheh, 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:33TheSevengevaerts: are you still awake?
02:38:49TheSeventhis 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:11engrpaulhello?
02:58:22engrpaulI have a Sansa Clip+ that just locked up after rockbox database initialization
02:58:39engrpaulbricked? No screen after holding power button
02:58:47engrpaulnothing on USB
02:58:49TheSeven[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:16engrpaulI have the unit open and the battery is OK
02:59:40TheSevenand 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:14TheSevenafter a small number of retries the host would time out, before the ipod has even prepared the response
03:00:33TheSevenand 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:17TheSevenengrpaul: connect to usb, hold the power button for like 15 seconds, release it, and a couple of seconds later briefly press it
03:01:24TheSevendoes anything turn up on the USB bus?
03:05:19engrpaulwhen I plug it in, I get a "duh duh" sound in win7, tried to install device software but failed
03:07:06engrpaul"UNDEF storage USB device" shows up under drives in device manager
03:22:37engrpauldo 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:24NolenJHejHi
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:06engrpaulMy clip+ stopped working after database refresh, power button reset doesn't work, can anyone help?
04:10:06BlindWandererI'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:51BlindWanderernaturally if you edit the path it works but you aren't given that option when adding a file to a different playlist.
04:12:40jhMikeSthere'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:36BlindWandererI didn't notice a bug on flyspray for it...
04:41:00jhMikeSThere 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:40toaHi, 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:48NolenJHejuWait, toa, you're still here right? (I just d/c'd.)
06:00
06:00:26NolenJHejuAnyway, 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:33NolenJHejuHowever, I found this: http://anythingbutipod.com/forum/showthread.php?t=66292
06:00:58NolenJHejuWorked just fine for me. Just got Rockbox running, actually.
06:01:29toaNolenJHeju, Yes, I'm still here. Just saw your message.
06:02:29toaLet me take a look at t.
06:02:30toa*it
06:04:20toaI 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:17toaIf 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:34toaLooking 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:19toaAlso, 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:36Jack87just 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:35toaJack87, is that a capability of the regular firmware?
06:44:03Jack87toa, 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:16Jack87I am reading the Sansa FAQ right now and it talks about the radio but its a bit unclear
06:46:36Jack87well the Rockbox FAQ for sansa that is
06:47:47toaStill checking, Jack87
06:48:30Jack87toa, thanks me to :-)
06:49:09Jack87ya so FM recording is present on the original firmware
06:53:45toaI haven't found anything definitive, but I would bet that it will work.
06:54:32toaIf 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:19Jack87toa, thank you, I appreciate your insight. i think i will do just that.
06:56:00***Saving seen data "./dancer.seen"
06:57:03Jack87should i first install latest sandisk firmware?
06:57:50toaI don't see why not, but I admit I haven't installed Rockbox recently.
06:58:06toaJack87, find out if it is v1 or v2 of the e200.
06:58:27toahttp://www.rockbox.org/wiki/SansaE200Port#Identification_of_version
06:58:31Jack87From what i can tell its a version 1 as the girmware reads v1.02.12 currently
06:59:14Jack87do you know if its even supported on v2?
07:00
07:01:00Jack87firmware**
07:02:25toaJack87, I think it's supported on both.
07:02:50toaYes, it is.
07:02:58Jack87thats good to know. its sad SDHC drivers are not present on v1 official firmware
07:03:55Jack87i 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:13toaJack87, possibly, if you're savvy.
07:05:21toaTake a look at http://www.rockbox.org/wiki/SansaAMS if you haven't already.
07:05:38toaThe original firmware is available for download.
07:05:40Jack87haha i wish i was savy enough. maybe in a year or so
07:05:45Jack87awesome thanks
07:05:59Jack87ill prolly dig around in it :)
07:07:05toasounds good
07:09:02Jack87ill prolly dig around in it :);9
07:09:05Jack87:(*
07:10:06Jack87anyway rockbox seem awesome! and very well organized and put together. exciting stuff
07:10:21toaDoes anyone here have any experience with Rockbox on a Clip Zip?
07:10:49toaJack87, I agree. I'm looking forward to installing it when I can.
07:11:02toaJack87, not that I have any major qualms with the original firmware.
07:11:19Jack87toa, I think i ran into something on the wiki saying clip zip was not supported? but i am not sure
07:11:54Jack87toa, ya original sansa firmware does a lot (its not like its an ipod ;-) ) but the support for SDHC is lacking on e200v1
07:12:23toaJack87, Yeah, you're right. It's not completely finished, but I'm trying to discern its current status.
07:13:02Jack87sorry it says its unstable for th sansa clip
07:13:19Jack87http://www.rockbox.org/wiki/SansaClip#Sansa_Clip_Zip_port_status
07:13:57toaJack87, well the device was apparently only released in October, so they've made quick work.
07:14:30Jack87ya thats awesome... i mean that link is status of like 2 weeks ago
07:27:27Jack87So 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:34funmanyeah
08:06:17funmantoa: to install clip zip bootloader follow instructions on wiki: SansaAMS
08:06:34funmanyou need to build mkamsboot from source or use funman/mkamsboot-1.5/">http://people.videolan.org/~funman/mkamsboot-1.5/ binaries
08:08:11funmanhttp://www.rockbox.org/wiki/SansaClip#Sansa_Clip_Zip_port_status (a bit outdated)
08:08:57toafunman, was that videolan link for me?
08:09:17funmanyeah
08:09:38funmanthese 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:02toaOh, OK. So it is going to be a very short time before the Clip Zip is officially supported?
08:11:33toafunman, the other items on the to-do list seemed rather trivial.
08:12:25toaOh, the port status just updated.
08:13:18zeif 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:43toaze, 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:41zetoa: yeah... i noticed one amazon review says the microsd doesn't protrude the tiny bit it does on the +
08:16:56zewhich i kinda feel like sticking some tape over just to make sure that sucker doesn't pop out
08:17:00zeheh
08:17:52zethat 32G could disappear in the blink of an eye if it were to go flying :p
08:18:23toaIt's still pretty secure in there, despite the protrusion, I imagine.
08:18:56toa[Saint], they don't happen to have a 2nd gen iPod replacement program too, do they?
08:19:10toaI'm referring to the original 2G 5/10/20GB iPod :P
08:19:59zehmm 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:57DBUGEnqueued KICK [Saint]
09:13:03 Nick [Saint] is now known as [Saint_] (~Saint]@unaffiliated/saint/x-8516940)
09:13:03DBUGEnqueued KICK [Saint_]
09:13:08 Nick [Saint_] is now known as [Saint__] (~Saint]@unaffiliated/saint/x-8516940)
09:13:08DBUGEnqueued 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:12DBUGEnqueued 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:25DBUGEnqueued 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:45davohi all, do video4fuze video formats get recognized by rockbox?
10:15:49 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
10:22:34davoi'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:01davothanks [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:01davowell 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:31davothanks, i'll look into that, but i'm mostly a dedicated linux user
10:28:47davoi 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:13davoah good to know
10:29:36davoi'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:33davookay sounds good, the linux method looks interesting, but i'll give the WinFF a shot first
10:31:39davothanks for your help [Saint]
10:38:40davo[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:05davooh 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:32topikxvid wont work though
10:52:53topikmpeg-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:44davohm, only presets winFF offers are MS Compatible AVI, XviD FullScreen, XviD Widescreen, XviD Widescreen Anamorphic.
11:18:17davoif xvid wont work, I just tried MS Compatible AVI and doesn't recognize
11:19:01davooh crap, my bad, i was listing the presets, i failed to look under the Convert to: menu X-x
11:19:32davothis 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:19davooh 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:38lorenzo92kugel: hey ;)
11:28:56lorenzo92kugel: 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:41jlbiasinihello: iks rockbox.org down?
12:02:03jlbiasiniI 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:31lorenzo92jlbiasini: seems working for me...
12:20:23lorenzo92kugel: 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:09lorenzo92kugel: gives also if end of charge or not (uses some ascoded rregisters of course)
12:25:33kugellorenzo92: yeah we can get eoc through other modules indeed
12:25:41gevaerts[7]: *why* wasn't the endpoint set up properly?
12:25:59kugelI saw your paste
12:26:02lorenzo92kugel: interesting. Default charging current is 55 mA
12:26:07gevaertsAh, a related commit
12:26:42lorenzo92kugel: need to see in the OF...
12:28:20 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at)
12:31:44kugellorenzo92: that seems low
12:32:20lorenzo92kugel: ya, strange...calculating with 55 mA is about 10 hours of recharging lol...Uhm I guess the charging thing somewhere else
12:32:29lorenzo92maybe in the "minivet" device
12:33:05kugelsaratoga: did you have a gnuplot cmd line for battery benches?
12:33:14kugellorenzo92: or didnt you make graphs?
12:35:39lorenzo92kugel: I did them iin calc :)
12:36:01lorenzo92if you want I share the odf...
12:36:04kugelsure
12:37:06 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
12:38:29lorenzo92kugel: 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:54kugellorenzo92: thanks
12:48:11kugellorenzo92: will commit the pm stuff along with the battery courves then
12:48:34lorenzo92;)
12:49:14lorenzo92kugel: are some other benches needed?
12:53:56kugellorenzo92: you can do a full bench if you like, but it#s not necessray
12:54:25lorenzo92kugel: okay I'll do that when the autoshutdown is fixed ;)
12:56:11***Saving seen data "./dancer.seen"
13:00
13:05:13pamauryhmm, 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:37gevaertspamaury: didn't the AMS sansas do something similar, related to DRM?
13:06:58pamauryI don't know, the sansa AMS driver has some hardcoded values
13:07:17pamaurybut here, the OF stores it in a persistent register and allows itself to write it !
13:07:23pamauryI'm still reversing the code
13:08:40pamaurybut 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:53bertrikpamaury, as I understand it, the OF never really adjusts the RTC, it just adjusts this offset
13:23:09bertrik(for the AMSes)
13:24:49bertrikthe 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:15lorenzo92pamaury: oh! interesting, also yp-r0's OF does something strange like that with the time!!
13:35:44lorenzo92in our case this value is saved in a small part (1mb) of the nand
13:35:55lorenzo92where also other settings are stored like region code...
13:35:57 Join MethoS- [0] (~clemens@134.102.106.250)
13:37:33lorenzo92it is a numeric value but I still don't understand what is its meaning (an example of an old dump is 63119625672)
13:38:51lorenzo92pamaury: 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:51amiconntts 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:36amiconnWhen 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:03amiconnAnd when encoder options contain a space, voice.pl fails due to borken argument passing
13:52:12amiconnThis 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:58amiconnAlso the default encoder options seem to be gone?
13:55:00 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
13:56:26pamaurylorenzo92 (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:20CIA-88New commit by kugel (r31471): Enable (and fix) battery_bench on hosted targets.
14:35:27CIA-88New commit by kugel (r31472): ypr0: Proper battery curve measured with battery_bench.
14:35:47CIA-88New commit by pamaury (r31473): imx233/fuze+: implement rtc (time only, alarm still to implement)
14:36:49CIA-88r31470 build result: 216 errors, 6 warnings (kugel committed)
14:37:30 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at)
14:38:31CIA-88r31473 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:08CIA-88New commit by pamaury (r31475): imx233: forgot a file
14:51:26kugelCIA-88 isn't following :)
14:51:39 Quit [Saint_] (Remote host closed the connection)
14:52:12CIA-88r31475 build result: All green
14:55:46pamauryit missed a commit
14:56:12***Saving seen data "./dancer.seen"
14:56:18jlbiasiniok 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:33gevaertsWhy 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:41gevaertsYes 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:07gevaertsWe 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:09gevaertsDefine "active"
15:04:00gevaertsA 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:24gevaertsARC 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:51gevaertsWell 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:17gevaertsBut 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:59gevaertsThe *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:19gevaertsWhere do you enable endpoints?
15:09:40[7]after yesterday's commit in the bus reset and cancel_all_transfers handler
15:09:56gevaertsARC does it in set_address
15:09:59[7]prior to that it was done before every transfer, which was too late
15:10:18gevaertsWell yes, it has to be done once somewhere at the beginning of the connection
15:11:05gevaertsbus 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:38gevaertsWe 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:51lovasoakugel: 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:06CtcpIgnored 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:47gevaertshm, 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:34gevaertshm, 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:03gevaertsWell, wait, hm
15:17:19gevaertsYes, 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:20gevaertsok
15:19:10CIA-88r31474 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:58gevaerts[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:44gevaertsrelated 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:05jlbiasiniwhat is morse input? Doesn't this need a line in jack to work?
15:30:37gevaertsjlbiasini: no, you tap a button
15:30:49jlbiasiniah 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:32funman[7]: r31469, is that needed in usb-drv-as3525v2? iirc it was not
15:32:43gevaerts[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:37gevaertshm, 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:55gevaertshm, 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:37gevaertshm
15:38:15gevaertsno, that's not true. It uses 24K
15:38:31funmangevaerts: you need testing? I can use my clipv1
15:38:40gevaertsActually, it's half true
15:39:19gevaertsfunman: yes, set READ_BUFFER_SIZE to 24K or 32K in usb_storage.c, and see if it makes a speed difference
15:39:35gevaertsWRITE_BUFFER_SIZE is already 24K because it's SD
15:40:25gevaertsThis should really be tuned for every pair of storage type and usb controller. There's some speed hiding there
15:41:20jlbiasinipamaury: so i still have to implement morse keymaps so you can wait a little more before commiting my keymaps update
15:41:59CIA-88New commit by kugel (r31470): ypr0: Enable battery voltage read-out, charging monitoring and charger detection. ...
15:42:12CIA-88New 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:08CIA-88r31476 build result: All green
15:45:13 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
15:46:27funmangevaerts: gevaerts should i test r31476 or 31475 ?
15:47:31gevaertsfunman: whichever you like. r31476 shouldn't change anything, all AS3525 players use USBOTG_AS3525
15:48:16gevaertsI just didn't like checking for the CPU define to change driver parameters if there's a perfectly good driver define
15:48:35funmantrue
15:48:58gevaertsThat ends up with things like using CHARCELL to mean Player, or HWCODEC to imply sh, or (worse) MMC to mean ondio
15:52:41funmanhm i reproduced FS #12485
15:52:42fs-bluebothttp://www.rockbox.org/tracker/task/12485 Seeking in .ape file doesn't work (bugs, unconfirmed)
15:52:47funmanFS #12475 *
15:52:48fs-bluebothttp://www.rockbox.org/tracker/task/12475 Crash while playing audio (bugs, unconfirmed)
15:53:42funmangevaerts: 642236416 octets (642 MB) copiés, 150,357 s, 4,3 MB/s
15:53:58funmanthat's unmodified r31475 performance (63kb)
15:54:16funmanrebooting to test a new build since Linux keeps crashing ..
15:54:29gevaertsTell it not to do that! ;)
15:58:06funmani use dd bs=5120 btw
15:59:38gevaertshm, that will influence things
16:00
16:00:10gevaertsMost OSes (I don't know about freebsd!) use 64K blocks for USB communication
16:00:15funmantell me which settings i should use to not test under influence
16:00:54gevaerts64K 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:41gevaertsYou can use larger, but then the kernel will split it up
16:01:42funmansame bs=5120 with buffer set to 32kb : 3,3MB/s
16:01:56amiconnkugel: Shouldn't it be possible to make the db commit work without reboot now, using buflib?
16:01:59gevaertshm, maybe the kernel also combines those?
16:02:02 Quit benedikt93 (Quit: Bye ;))
16:02:04funmanyou want dd bs=64k now?
16:02:04[7]apparently
16:02:17amiconnWhen dircache is disabled, that is (when it's enabled that already works)
16:02:17gevaertsok, it should probably be left at 63 then
16:02:23gevaertsYes
16:02:39[7] how does dd bs=1048576 of=/dev/null behave?
16:03:20funman[7]: ?
16:03:29gevaerts[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:22gevaerts[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:47funman63, and not 64, you mean?
16:04:49gevaertsThe comment says that on AMSv1 the driver doesn't do transfers larger than 65535 bytes
16:04:51[7]yes
16:05:00funmanDMA register iirc
16:05:12gevaertsDue 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:47gevaertsThat 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:53gevaertsyes, that sounds like a good optimisation
16:10:36 Join marcol07_Marek_L [0] (~4e628860@www.haxx.se)
16:11:03gevaertsIt'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:01gevaertshm, no, we do that already really
16:13:12*gevaerts was confusing READ and WRITE :\
16:13:46funman[7]: do you have usb-s3c6400x changes in progress?
16:13:53gevaertsAnyway, I'm leaving for now
16:13:59funmani'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:02funmanok i'll start right away
16:18:20kugelamiconn: yes
16:19:42jlbiasiniOk 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:03jlbiasiniI can't get this working on the fuze+
16:21:01jlbiasinidoes is need doubletouch (like holding morseinput wjile doing sequence with morseselect ?
16:25:57jlbiasiniI think that if ever one day someone come complaining about this I will then implement it
16:26:18jlbiasini:)
16:26:27*[7] is amazed by windows doing single sector reads while scanning the fat
16:26:45funmanjlbiasini: good idea ;)
16:31:27jlbiasinifunman: 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:55funmanyeah
16:33:06funmanoutput log is difficult to parse also :/
16:40:05jlbiasinifunman: 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:08jlbiasiniace/images/ss-virtual-keyboard-240x320x16.png (no BoundingBox)
16:41:02jlbiasinihoho this image is not even from me!!
16:41:15jlbiasiniok I suppose this could be ignored then
16:41:18funmanno clue, that's the kind of problem i'm speaking about
16:41:25funmanis that a warning? an error? is it fatal?
16:41:43jlbiasinia warning
16:43:47jlbiasinithere is also a ! LaTeX Error: There's no line here to end.
16:44:21jlbiasiniseems to be related to some \\ but there where there before me...
16:44:34CIA-88New commit by funman (r31477): usb-s3c6400x.c: move usb_detect and usb_enable
16:46:25funmanjlbiasini: compare to a working manual build
16:46:38CIA-88r31477 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:20funman[7]: do we really need to handle builds without USBSTACK ?
16:56:16***Saving seen data "./dancer.seen"
16:58:15CIA-88New 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:19Torneokay this versioning thing is a real annoyance
16:59:37Tornei am tempted to give up and let it just emit SHAs for now
17:00
17:00:08Torneor.. hm
17:01:00funmanTorne: i'm sure we'll figure out something, won't we?
17:01:30Tornegit describe is annoying because it's kinda.. retroactive
17:01:48Tornethe versions of commits that already exist (and may have been built) might change because of newly created tags
17:02:32funmanif a user give the version, will it be easy to find which build he uses exactly?
17:02:50funmanit's the most important question to ask
17:03:21Tornehm. that depends.
17:03:38Tornether eisn't an easy way to go from tag+commits to a hash, no
17:03:47Tornethe describe output is only parseable if you actually inlcude the SHA
17:03:59Tornegit can only count backwards, not forwards
17:04:03Tornebecause forwards is ambiguous
17:04:35Tornethis is probably true of all schemes that are going to produce a number that increases with subsequent builds :)
17:04:48Torneunless we just tag all the builds at the master.
17:05:21Tornewhich we could, but that won't identify anything that doesn't correspond to a build
17:12:08funmanwhat's wrong with the last sha again?
17:12:22Torneentirely meaningless to users
17:12:26Torneno way to even tell which is newer
17:14:36Torneif 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:11CIA-88New commit by funman (r31478): usb-s3c6400x: move usb_init_device
17:17:20funmanTorne: you can tell the bug is fixed in last build
17:17:27 Quit liar (Read error: Connection timed out)
17:17:35Tornetechnically not :)
17:17:39funmanwhy?
17:17:44Tornemaybe it's not been built yet
17:17:47Torneor been pushed ot master
17:17:59Torneor is on another branch
17:18:09funmanwe only have one branch don't we?
17:18:48funmannow we say 'fixed in 3.10' or 'fixed in current build'
17:18:49CIA-88r31478 build result: All green
17:19:17funmanor at worst 'just fixed, wait 2 minutes for the build to appear'
17:19:27funmanor 'there's a patch not committed yet'
17:20:55funmanfor users there's only last release and last build which counts
17:21:04funmandevelopers can find commits themselves or we can help them
17:23:04Tornemeh
17:23:11Tornehow do we want to format it, then?
17:24:19funmanshort sha?
17:24:55Tornesome kidn of prefix might be good to distinguish mostly-numeric hashes from svn revnos ;)
17:25:10Tornegit describe uses 'g'
17:26:06funmani don't think we need a prefix to make the distinction
17:26:16funmanthe 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:25Tornedone :)
17:32:29Tornethough CIA hasn't noticed
17:33:17Tornefor revisions that correspond exactly to svn it will still print the svn revision
17:33:25Tornefor anything else it will just use the short SHA1
17:34:07CIA-88r31480 build result: All green
17:35:08funmancia has y2k12 bug possibly
17:35:17Torneheh
17:35:27funmanTorne: that's nice to use svn numbers
17:35:46funmanby 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:38CIA-88New commit by torne (r31479): Remove bzr support from tools/version.sh. ...
17:44:52Torneno
17:48:00CIA-88New commit by dreamlayers (r31481): Fix FS #12499 - Directory playback fails after saving playlist ...
17:53:42CIA-88New commit by theseven (r31482): usb_core: Fix typo in comment
17:57:11*TheSeven really likes it when logf fixes bugs
17:57:44dreamlayersFile 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:13TheSevenhm, 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:57CIA-88New 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:58TheSevengevaerts: 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:53TheSeventhis 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:34TheSevenhm, or rather the CSW isn't accepted any more once this happened, but that interrupt gets asserted even slightly before that
18:43:33TheSevenjust 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:40TheSevenhm, additionally a suspend and bus reset is logged
19:00
19:07:01TheSevengevaerts: 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:13CIA-88New commit by alle (r31483): Update the Russian translation (FS #12420 by James Hunt)
19:26:06CIA-88r31483 build result: All green
19:31:54CIA-88New 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:43CIA-88r31484 build result: All green
19:34:59funman12 commits incoming ..
19:35:05funman13 actually
19:38:47 Quit fs-bluebot (Ping timeout: 240 seconds)
19:39:24 Quit bluebrother^ (Ping timeout: 244 seconds)
19:39:46CIA-88New 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:53CIA-88r31485 build result: All green
19:43:33CIA-88New commit by funman (r31486): usb-drv-as3525v2: move interrupt disable
19:43:42CIA-88New commit by funman (r31487): usb_init_device(): move prototype to usb.h ...
19:43:58CIA-88New commit by funman (r31488): move usb_pin_init() declaration to PP's system-target.h ...
19:44:03CIA-88New commit by funman (r31489): usb_plugged() is PP only
19:44:06jlbiasinipamaury: keymaps are ready -> http://www.rockbox.org/tracker/task/12405#comment42043 could you commint them?
19:44:10CIA-88New commit by funman (r31490): usb_drv_connected() is declared in usb_drv.h
19:44:17CIA-88New commit by funman (r31491): firewire/usb_remove/insert_int: move to system-target.h
19:44:19CIA-88New commit by funman (r31492): delete usb-target.h content redundant with PP usb-target.h
19:44:25CIA-88New commit by funman (r31493): gigabeats usb-target: merge in system-target.h
19:44:28CIA-88New commit by funman (r31494): USBOTG_ARC's USB_DRIVER_CLOSE: move to config.h
19:44:36CIA-88New commit by funman (r31495): creative zvm isp1583 defines: move to isp1583.h ...
19:44:39CIA-88New commit by funman (r31496): onda usb code: merge into .c file
19:44:48CIA-88New 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:56jlbiasiniwtf? the guy is commiting one year work or what???
19:44:56 Quit jae (Ping timeout: 252 seconds)
19:45:03jlbiasini:)
19:45:05CIA-88New commit by funman (r31498): usb-target.h: remove
19:45:22funmanno just small separated commits ..
19:45:22CIA-88r31486 build result: All green
19:45:40CIA-88New 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:16CIA-88ow
19:46:24TheSevenhm, 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:06CIA-88*purr*
19:47:15TheSevenheh
19:47:21*TheSeven didn't know that one yet
19:47:26funmanhttp://cia-vc.googlecode.com/svn/trunk/cia/LibCIA/IRC/Bots.py
19:47:53CIA-88r31482 build result: All green
19:48:08CIA-88r31498 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:15funmannot that bad
19:49:59TheSevenhm, looks like there's once again a usb thread deadlock, but it's outside the storage code this time
19:50:05CIA-88New commit by funman (r31499): imx233: fix power_input_status()
19:50:14TheSevenand doesn't seem to be in a usb_drv function either
19:50:22jlbiasiniwhat 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:23fs-bluebothttp://www.rockbox.org/tracker/task/12492 add fuze+ manual (patches, unconfirmed)
19:50:33TheSevenheh, that's the downside of git-svn
19:50:46CIA-88New commit by funman (r31500): onda: remove now inlined USB_INIT_GPIO()
19:51:13*TheSeven accuses funman of juggling with code :)
19:51:20funmanTheSeven: which downside?
19:51:26funmanTheSeven: i just wanted r31500 :)
19:51:50jlbiasini * jlbiasini is going to test hid again as he is getting suspicious ;)
19:52:02TheSevenyou 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:34CIA-88r31499 build result: 18 errors, 4 warnings (funman committed)
19:52:43funmanTheSeven: true
19:52:58funmanbut one by one commits can break equally
19:53:00*jlbiasini thanks TheSeven about that
19:53:10funmanthat's a downside about gazillions of targets i'd say
19:53:36TheSevenif you do one by one commits, you notice the breakage earlier and repair it before committing the rest
19:54:12funmanright
19:54:33jlbiasinino fun!
19:54:40jlbiasini:D
19:54:53CIA-88r31500 build result: All green
19:55:12funmanfuze+ delta is suspicious
19:56:08pamauryit'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:19TheSevenhttp://pastie.org/3103147 is more suspicious
19:56:22funmanpamaury: was that for me ?
19:56:34pamauryfunman: yes
19:56:47funmani don't understand
19:57:25pamauryI thought you were talking of the fuze+ memory usage reported on dev.cgi which is over 1Gb :)
19:57:29funmanusb_thread has not the same size
19:57:34funmanno, about the delta
19:58:04pamauryindeed, 250 bytes of such a small thing :-s
19:58:08pamaury*for
19:58:24funmanthings*
19:58:38funmandifferent sizes in old.elf and rockbox.elf: 360 456 __seq.2119
19:58:43funman__seq ?
19:59:01funmanah but a lot of symbols have changed names..
19:59:22funmanfunction old new delta
19:59:23funmanusb_configure_drivers - 188 +188
19:59:30funmani must have added/removed an unwanted define
20:00
20:01:02 Join robin0800 [0] (~robin0800@149.254.61.216)
20:01:02pamauryhm, __seq is only used in the lcd driver, that seems weird
20:01:13funmanbloat-o-meter.py output is better
20:01:35jlbiasiniusb storage and hid still work on f+ let's check charging...
20:02:01funmanah if it works i'll just ignore it
20:03:35jlbiasinipamaury: 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:09pamauryany key does that iirc
20:04:19funmanyeah saratoga changed that quite recently
20:05:12jlbiasinipamaury: funman: right!
20:05:23deameyeswhen 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:31dreamlayersfunman: the fuze+ binsize delta may be due to USB_DRIVER_CLOSE not being defined
20:11:31pamauryin power-imx233.c ?
20:11:43jlbiasinipamaury: 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:27pamauryjlbiasini: I noticed the fuze+ OF marks a partition as bootable, that's probably the reason
20:13:16funmandreamlayers: hm
20:13:18 Join marcol07 [0] (~4e628860@www.haxx.se)
20:13:23dreamlayersUSB_DRIVER_CLOSE used to be defined in imx233/usb-target.h. I guess it's only needed in the bootloader.
20:13:51funmanoh
20:13:57funmanit must have been caused by r31494
20:14:23dreamlayersconfig.h only defines it in the bootloader for CONFIG_USBOTG == USBOTG_ARC. I wonder if that's correct.
20:14:54funmanafaict all PP have USBOTG_ARC
20:15:35jlbiasinipamaury: 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:31pamaurythen 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:27funmanplug some usb key and see if^Wthat it's the same
20:22:20CIA-88r31469 build result: All green
20:26:34CIA-88r31481 build result: All green
20:27:16CIA-88r31479 build result: All green
20:28:28jlbiasinifunman: of course and only the fuze+ block it
20:29:26jlbiasiniand this is not an OS problem, it's debian! :d
20:30:32jlbiasinifunman: what was those commit on usb? some cleanup?
20:32:01funmanremoval of usb-target.h
20:32:27funmanall sort of crap^Wthings accumulated in here
20:33:12jlbiasinia yes I understand
20:33:40funmanand 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:21dreamlayersfunman: thanks for that cleanup
20:40:53 Quit robin0800 (Ping timeout: 244 seconds)
20:44:20 Join vpv [0] (vpv@fedora/vpv)
20:44:32funmannp
20:44:48*TheSeven has a new suspicion about the classic usb trouble
20:46:47vpvHi 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:05funmanTheSeven: what does usb_attach do ?
20:47:43TheSevenvpv: exact crash message + exact revision number (or even better, the corresponding .elf file)
20:48:10TheSeventhat might enable developers to figure out where exactly it crashed
20:50:26TheSevenfunman: no clue. I implemented it as usb_enable(true), which I'm sure I just copied from somewhere
20:50:36vpvTheSeven: 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:58funmanTheSeven: yeah i'm wondering why it differs from as3525v23
20:51:02funman-21
20:51:14funmanvpv: you can try a current build also
20:51:16TheSevenwhat does it do for that one?
20:53:47funmannothing
20:53:52vpvitit 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:14funmannow i'm tempted to add usb-target.h again for s5l870x and as3525v2
20:55:35funmanor put needed defines in usb-s3c6400x.h and add 2 .c fiels
20:56:22***Saving seen data "./dancer.seen"
20:56:43funmanseems better
20:57:48gevaertsdeameyes: how are you writing?
20:58:38TheSevengevaerts: 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:58gevaertsTheSeven: hid things?
21:00
21:00:08TheSevenmight be related
21:00:29TheSevenbut in this case a get config descriptor request that windows issues for no apparent reason
21:00:31funmanTheSeven: USB_STATUS_BY_EVENT and USB_DETECT_BY_CORE are not defined for nano2g :/
21:01:03TheSevenfunman: yes, because I have never managed to make that work (didn't have time to debug it at that time)
21:01:30funmanas3525v2 has them, can you figure it out?
21:01:52 Quit dreamlayers (Quit: back later)
21:01:58TheSevengevaerts: 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:17TheSevenand an undocumented bit in the interrupt register getting set
21:02:27gevaertsweird
21:02:30*TheSeven suspects this is related to FIFOs
21:02:56TheSevenall bulk endpoints seem to share a common 512byte fifo
21:03:12funmanTheSeven: usb is not needed for nano2g bootloader?
21:03:25TheSevenneeded in terms of what?
21:04:31funmanlet me rephrase
21:04:33TheSevenwe don't have a bootloader USB mode if you mean that (ipods are basically unbrickable)
21:04:37funmanusb storage is not needed for classic bootloader?
21:04:48TheSeventhere is no such thing as a classic bootloader
21:05:02funmanok
21:08:30CIA-88New commit by funman (r31501): usb-drv-as3525v2: cosmetics
21:08:35CIA-88New commit by funman (r31502): Remove USBOTG_AS3525v2
21:10:40CIA-88r31501 build result: All green
21:13:33CIA-88r31502 build result: 24 errors, 1779 warnings (funman committed)
21:13:52funmangrmbl
21:14:50CIA-88New commit by funman (r31503): typo
21:17:15CIA-88r31503 build result: 24 errors, 18 warnings (funman committed)
21:20:40 Part jlbiasini
21:20:55CIA-88New commit by funman (r31504): fix r31502: USBOTG_AS3525v2 doesn't exist anymore
21:23:31CIA-88r31504 build result: All green
21:29:10CIA-88New 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:25CIA-88r31505 build result: All green
21:38:48CIA-88New commit by funman (r31506): usb-s3c6400x: start factorization
21:41:08CIA-88r31506 build result: All green
21:42:24funmanTheSeven: 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:43funmanis 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:11funmans3c6400x.c has one struct per endpoint while other drivers have one struct per endpoint per dir
22:01:22funmanit could affect ep0 as it's bidir
22:11:50TheSevenfunman: just use the test thingy from your driver if you have one, I just haven't bothered :)
22:11:59TheSeven(this function isn't used anywhere, is it?)
22:12:33TheSevenand 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:19funmanyes it's used
22:13:30TheSevenhm, what is it good for?
22:13:43funmannot 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:48funmanabsolutely no clue
22:13:55TheSevenset_feature test things?
22:13:59 Join nosa [0] (~m00k@adsl-74-235-26-132.clt.bellsouth.net)
22:14:33TheSevenfunman: feel free to rework that endpoint state stuff, the way it's currently done in s3c6400x certainly isn't sane :)
22:14:58TheSevenso if you manage to factor out the target specific parts, i'd just throw away the rest of that driver
22:15:11CIA-88New commit by funman (r31507): usb-drv-as3525v2.h: remove
22:15:23funmanTheSeven: i can't test on nano2g
22:15:38TheSevenI can take care of that
22:17:27CIA-88r31507 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:12CIA-88New commit by funman (r31508): usb-s3c6400: use more complete functions from usb-drv-as3525v2 ...
22:20:33CIA-88r31508 build result: All green
22:21:01 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa)
22:22:49CIA-88New commit by funman (r31509): usb-drv-as3525v2.c: merge in usb-s3c6400x.c ...
22:23:28TheSevenfunman: is this nano2g-only so far or is it also supposed to work on the classic?
22:24:29funmani don't think i've made nano2g-only changes
22:24:42TheSevenok
22:25:00funmani enabled some bootloader bits for classic though by doing s/IPOD_NANO2G/USBOTG_S3C6400X/ but it shouldn't matter
22:25:13CIA-88r31509 build result: All green
22:25:34TheSevenif you changed the order of the register writes in usb_reset, n1s should probably test it, too
22:25:34funmanbtw which loop iteration you prefer
22:25:43TheSevenhis ipod seems to be more picky about those than mine
22:25:50funmani = out ? 2 : 1; i < USB_NUM_ENDPOINTS; i += 2
22:25:59funmanor int8_t[] lists of in and out endpoints
22:26:23TheSevenwell, the latter is more clear but probably more bloat
22:26:25funman+= 2 looks simpler
22:26:40funmanwe could use that and have a comment
22:26:56TheSevenmaybe we should get rid of those completely and detect the endpoints at runtime
22:27:19TheSevendo the AMS chipsets have the same endpoint configuration?
22:27:44funmanthey have one more
22:27:53TheSevenin that case I'd say go for autodetection
22:28:00funmanalso i don't know if the HWCFG registers exist on nano2g
22:28:07funmanthat's why i put the defs in as3525v2.h
22:28:17TheSevenwhat is that?
22:28:51funmansee r31507
22:29:06funmanendpoints type & number
22:31:35TheSevenfunman: I think these regs are present... at least somewhere :)
22:32:29TheSevenGHWCFG1 is definitely present, not sure about the other ones
22:37:52 Join alienkid10 [0] (~alienkid@unaffiliated/alienkid10)
22:38:18alienkid10is 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:18TheSevenfunman: if you're interested:
22:54:18TheSevenC:\Users\Admin\Desktop>emcore hexdump 0x38400044 0x10 4 4 2 1
22:54:19TheSevenConnected to emCORE Debugger v0.2.2 r836 running on iPod classic
22:54:19DBUGEnqueued KICK TheSeven
22:54:19TheSeven38400040: 00000264 228F60D0 082000E8 | d... .`.".. .|
22:54:19TheSeven38400050: 1BF08030 |0... |
22:54:45TheSevenConnected to emCORE Debugger v0.2.2 r836 running on iPod nano 2g
22:54:45TheSeven38400040: 01F07003 000FEDEB E8D1E9C1 | .p.. ........|
22:54:45TheSeven38400050: 00000000 |.... |
22:55:00TheSevener, wrong base address
22:56:26***Saving seen data "./dancer.seen"
22:56:34TheSevenConnected to emCORE Debugger v0.2.2 r836 running on iPod nano 2g
22:56:34TheSeven38800040: 00000264 228DD9D0 050004E8 | d... ..."....|
22:56:34TheSeven38800050: 01F08001 |.... |
22:56:47 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com)
22:56:47TheSevenso 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:19TheSevenhm, 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:38funmanTheSeven: the rest can be removed or #if'd out i guess, we don't need it now that the driver works ok
23:39:09funmanand registers need to go in usb-s3c6400x.h
23:41:32TheSevenfunman: I just parsed the data: http://www.freemyipod.org/wiki/USB_OTG_features
23:42:09TheSeven(and spotted some previously-unknown features)
23:42:19TheSevenespecially the fact that we seem to have even more endpoints is nice :)
23:43:02funmanTheSeven: hmm bidi endpoints also?
23:43:10TheSevenapparently
23:43:27funmaniirc there was only in or out EPs when i checked on amsv2
23:43:36funmani'll get you the regdumps (not today tho)
23:43:44TheSevenyeah, that's what I probed back then as well
23:44:01TheSevenbut I didn't try the ones in the middle after I found that reg :)
23:44:09funman:o)
23:45:23 Join Osix [0] (~saurpriva@cpe-72-231-148-65.nycap.res.rr.com)
23:45:42TheSevenfunman: where did you find docs on that register btw?
23:45:50TheSeventhe s3c6400x datasheet doesn't mention them
23:45:57TheSevenare they listed in some AMS datasheet?
23:47:57saratogawhats BIDI?
23:49:06TheSevenbidirectional
23:52:54 Quit davo (Quit: Lost terminal)
23:58:14 Quit perrikwp (Ping timeout: 240 seconds)

Previous day | Next day