--- Log for 08.02.116 Server: sendak.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 11 hours ago 00.21.02 Nick suYin is now known as suYin`OFF (mysuyin@server2.shellfire.net) 00.25.12 Join PurlingNayuki [0] (~Thunderbi@14.158.32.203) 00.25.25 *** Saving seen data "./dancer.seen" 00.25.33 Quit JanC (Ping timeout: 240 seconds) 00.39.46 Join JanC [0] (~janc@lugwv/member/JanC) 00.42.07 # ulmutul: any results? 00.59.19 Quit bertrik (Read error: Connection reset by peer) 00.59.20 Quit girafe (Read error: Connection reset by peer) 01.00.25 # Just compiled a build, and recording didn't work at all (always claiming "Disk full")... I will log in this channel, if I find everything. 01.07.34 Join zoktar [0] (~zoktar@78-72-46-111-no186.tbcn.telia.com) 01.07.34 Quit zoktar (Changing host) 01.07.34 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 01.14.51 Nick munch is now known as munch[HALFTIME] (~pls@gateway/shell/elitebnc/x-zmwsredvpauespea) 01.17.28 Quit ender` (Quit: I was trying to daydream, but my mind kept wandering.) 01.20.34 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 01.24.18 Quit pamaury (Ping timeout: 272 seconds) 01.24.30 Quit ulmutul (Quit: ChatZilla 0.9.92 [Firefox 44.0/20160123151951]) 01.30.03 Nick HazWard is now known as zz_HazWard (~HazWard@159.203.28.215) 01.30.41 Join Strife89|Quassel [0] (~quassel@adsl-98-80-220-250.mcn.bellsouth.net) 01.33.05 Quit Strife89 (Ping timeout: 240 seconds) 01.56.34 Quit orpheu (Ping timeout: 252 seconds) 01.58.32 Join orpheu [0] (0252b710@gateway/web/freenode/ip.2.82.183.16) 02.02.08 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 02.04.57 Quit JdGordon (Ping timeout: 264 seconds) 02.15.17 Quit krabador (Quit: Take The Time) 02.15.31 Quit uber (Quit: bye) 02.25.25 # < pamaury> wodz: on imx233, for sd/mmc 02.25.29 *** Saving seen data "./dancer.seen" 02.25.31 # what hardware uses imx233 lol 02.44.15 Nick munch[HALFTIME] is now known as munch[JOHNMADDEN (~pls@gateway/shell/elitebnc/x-zmwsredvpauespea) 02.44.40 Nick munch[JOHNMADDEN is now known as munch|JOHNMADDEN (~pls@gateway/shell/elitebnc/x-zmwsredvpauespea) 02.45.28 Quit zoktar (Ping timeout: 245 seconds) 02.47.18 Join zoktar [0] (~zoktar@78-72-46-111-no186.tbcn.telia.com) 02.47.19 Quit zoktar (Changing host) 02.47.19 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 02.48.36 Quit zoktar (Excess Flood) 02.48.51 Join zoktar [0] (~zoktar@78-72-46-111-no186.tbcn.telia.com) 02.48.51 Quit zoktar (Changing host) 02.48.51 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 03.24.43 Quit Rower (Ping timeout: 240 seconds) 03.53.49 Nick zz_HazWard is now known as HazWard (~HazWard@159.203.28.215) 03.56.16 Join ZincAlloy [0] (~Adium@pD9FB730D.dip0.t-ipconnect.de) 03.59.13 Quit ZincAlloy1 (Ping timeout: 240 seconds) 04.14.55 Quit Link8 (Ping timeout: 240 seconds) 04.17.27 Nick munch|JOHNMADDEN is now known as munch (~pls@gateway/shell/elitebnc/x-zmwsredvpauespea) 04.25.31 *** Saving seen data "./dancer.seen" 04.55.35 Join Totalled_ [0] (~Totalled@c-67-166-22-15.hsd1.co.comcast.net) 04.58.10 Quit Totalled (Ping timeout: 256 seconds) 05.10.12 Quit nosa-j (Ping timeout: 248 seconds) 05.12.48 Join nosa-j [0] (~m00k@cpe-98-24-102-26.carolina.res.rr.com) 05.20.57 Nick HazWard is now known as zz_HazWard (~HazWard@159.203.28.215) 05.29.37 Quit kugel (Excess Flood) 05.29.45 Join kugel [0] (~kugel@rockbox/developer/kugel) 05.34.45 Quit TheSeven (Ping timeout: 260 seconds) 05.35.46 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.38.46 Quit __builtin (Read error: Connection reset by peer) 05.40.18 Join __builtin [0] (~me@unaffiliated/franklin) 06.25.32 *** Saving seen data "./dancer.seen" 06.26.33 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 07.00.10 Quit sparetire (Quit: sparetire) 07.41.29 Quit ZincAlloy (Quit: Leaving.) 08.00.03 Quit amiconn (Remote host closed the connection) 08.00.04 Quit pixelma (Remote host closed the connection) 08.00.46 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 08.00.49 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 08.25.34 *** Saving seen data "./dancer.seen" 08.38.27 Join petur [0] (~petur@rockbox/developer/petur) 08.52.56 Quit orpheu (Quit: Page closed) 09.01.59 Quit Rower (Ping timeout: 264 seconds) 09.53.52 Join edhelas [0] (~edhelas@535592E7.cm-6-6c.dynamic.ziggo.nl) 10.00.51 Quit Bray90820 (Ping timeout: 248 seconds) 10.04.43 Join Bray90820 [0] (~bray90820@173-17-46-117.client.mchsi.com) 10.12.06 Quit Totalled_ (Ping timeout: 256 seconds) 10.25.37 *** Saving seen data "./dancer.seen" 10.50.38 Join Totalled [0] (~Totalled@c-67-166-22-15.hsd1.co.comcast.net) 10.52.40 Join ender` [0] (krneki@foo.eternallybored.org) 11.32.03 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.50.45 Quit pamaury (Ping timeout: 240 seconds) 12.13.51 Join pamaury [0] (amauly@clpc71.cs.ox.ac.uk) 12.13.52 Quit pamaury (Changing host) 12.13.52 Join pamaury [0] (amauly@rockbox/developer/pamaury) 12.25.38 *** Saving seen data "./dancer.seen" 12.35.23 # wodz (logs): if you are interested in testing, g#1252 contains the port of hwstub_shell to the new library (using usb directly, not network yet), that could provide useful testing/feedback 12.35.24 # 3Gerrit review #1252 at http://gerrit.rockbox.org/r/1252 : 3hwstub: port hwstub_shell to the new library by Amaury Pouly 13.43.38 Join wodz [0] (~wodz@89-77-223-98.dynamic.chello.pl) 13.44.50 # pamaury: how far are you form committing hwstub lib rewrite? 14.14.00 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 14.16.04 # pamaury: I spoted two strange things in your imx233 sd driver: 1) You end card initialization with DESELECT but only if this is MMC. Shouldn't both sd and mmc be deselected when not used? 2) At the very end of mmc initialization there is comment that mmc always supports SET_BLOCK_COUNT command (CMD23) but you set support_set_block_count[drive] = false; 14.24.32 # wodz: I need to implement commends for the network, I have all the code in place for it so it should be a matter of couple hours. Maybe more to implement forking. 14.24.35 # Ok let me see 14.25.40 *** No seen item changed, no save performed. 14.27.46 # also for hwstub rewrite, there is more needed to port qeditor, more than I expected 14.33.38 # wodz: indeed the support_set_block_count set to false looks like a bug 14.35.30 # also you are right that the card should be deselected at the end of init_sd_card 14.35.53 # :-) 14.36.51 # just a note on the subject: I found that on some cards/eMMC, it is very important to deselect the card when idle to save power 14.37.24 # despite what the spec saying it's fine to enter sleep in TRAN state, many cards seem to ignore this possibility 14.38.51 # I always read the doc as deselecting card automatically puts it in power save state 14.40.54 # yeah you might be right, anyway, just to say it provides huge power savings 14.41.38 # thanks for finding those bugs, it's really weird that I missed them, especially the CMD23 support 14.42.33 # pamaury: imx233 driver makes hilariously complicated things to allign transfers. Why it is so? IIRC there is STORAGE_NEEDS_ALLIGN which takes care of this in upper layer 14.46.27 # I don't remember, either I missed STORAGE_NEEDS_ALLIGN or there was another reason 14.48.53 # For example a grep on STORAGE_NEEDS_ALIGN reveals it's only used in some .h which is suspicious 14.51.03 # basically I don't know how what the whole alignment thing became after FS rework 14.53.46 # but you are right that it's worth looking at, there is no need for complicated code is all buffers are aligned 14.54.50 # pamaury: Do return codes from initializiation have any particular mapping imposed by something in upper layer? 14.57.12 # no, I just made sure that from the error code you can at least guess the point of error 14.57.18 # (by looking at the code) 14.58.49 # my question comes from the fact that in imx233 errors are not in order 15.00.55 # and error -12 is used twice in sd init - once for SELECT_CARD and the other time for SWITCH_FUNC 15.35.42 Join ZincAlloy [0] (~Adium@pD9FB730D.dip0.t-ipconnect.de) 15.39.40 Join sparetire [0] (~sparetire@unaffiliated/sparetire) 15.47.39 # pamaury: Do you have an idea why card may timeout on DESELECT? 15.51.44 Quit krnlyng (Quit: huiiiiii) 15.52.02 Join krnlyng [0] (~liar@178.114.103.54.wireless.dyn.drei.com) 15.53.47 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.59.44 Join krabador [0] (~krabador@unaffiliated/krabador) 16.03.35 # I hate sd spec. It is worded such you can interpret response type of cmd7 in two different ways :/ 16.18.44 Quit Rower (Ping timeout: 260 seconds) 16.24.05 Quit Totalled (Ping timeout: 240 seconds) 16.25.41 *** Saving seen data "./dancer.seen" 16.41.16 # wodz: no idea, are you sure the card is selected ? I remember reading something about deselect and timeout but this spec is so badly written 16.42.19 # pamaury: If I use regular R1 reponse I have timeout. If I use NO_RESPONSE everything seems to be ok. 16.42.48 # I think DESELECT doesn;t require a response, if my memory serves 16.43.08 # pamaury: yes you can read spec like this 16.43.17 # I'm quite busy right now but I think that's really what the spec means 16.43.30 # chekc my code to see if it matches this reading 16.44.36 # pamaury: I have one very peculiar card which succeed in selection only the first time. After deselect it doesn't want to be selected no matter what you do. 16.44.49 # weird 16.44.56 # does in work with linux ? 16.45.37 # it was very long ago I tried it on linux but IIRC it worked 16.46.09 Quit krnlyng (Ping timeout: 260 seconds) 16.48.03 Quit PurlingNayuki (Read error: Connection reset by peer) 16.48.08 Join PurlingNayuki1 [0] (~Thunderbi@14.158.32.203) 16.48.53 # well, I think it is safe to assume that this card is clearly broken 16.49.04 # though it would be interesting to see what linux does 16.50.35 Nick PurlingNayuki1 is now known as PurlingNayuki (~Thunderbi@14.158.32.203) 16.51.08 Quit krabador (Quit: Take The Time) 16.51.34 Join krnlyng [0] (~liar@83.175.90.24) 16.55.18 Quit PurlingNayuki (Read error: Connection reset by peer) 16.55.24 Join PurlingNayuki1 [0] (~Thunderbi@14.158.32.203) 16.57.52 Nick PurlingNayuki1 is now known as PurlingNayuki (~Thunderbi@14.158.32.203) 16.58.18 Join krabador [0] (~krabador@unaffiliated/krabador) 17.04.16 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 17.05.13 Join girafe [0] (~girafe@AGrenoble-651-1-477-112.w90-42.abo.wanadoo.fr) 17.29.39 Quit petur (Quit: *plop*) 17.37.40 Join Link8 [0] (~me@5ED3F691.cm-7-4d.dynamic.ziggo.nl) 17.47.43 Join Totalled [0] (~Totalled@c-67-166-22-15.hsd1.co.comcast.net) 17.52.34 Join Link7 [0] (~me@5ED3F691.cm-7-4d.dynamic.ziggo.nl) 17.53.04 Quit Link8 (Remote host closed the connection) 18.02.16 Join Mihail [0] (252d44ca@gateway/web/freenode/ip.37.45.68.202) 18.05.50 # pamaury: linux poweroff it after deselect (linux/drivers/mmc/core/sd.c _mmc_sd_suspend) 18.08.17 Quit edhelas (Ping timeout: 250 seconds) 18.12.13 Quit PurlingNayuki (Read error: Connection reset by peer) 18.12.58 Join PurlingNayuki [0] (~Thunderbi@14.158.32.203) 18.21.25 # also it have interest function - mmc_sleep (idrivers/mmc/core/mmc.c) with some "magic" after dselect 18.25.45 *** Saving seen data "./dancer.seen" 18.25.46 # Mihail: thanks, I'll have a look. Also I don't if Linux kind of assume (or optimize for the case of) one device per bus, which is definitely not the case for us 18.27.46 # I would need to read the spec, I don't know if you are allowed to power off the card after deselect and then power it on without going through full init again 18.28.11 # also you probably don't want to do that after each transfer but rather after some inactivity 18.29.57 # Probably you right. It power in suspend. But look at mmc_sleep (drivers/mmc/core/mmc.c). 18.30.24 # * power off 18.30.41 # the code seems to imply that you need to do full init sequence after power off 18.30.51 # which would make sense 18.47.41 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 18.49.00 Join fs-bluebot [0] (~fs-bluebo@xd9be4b48.dyn.telefonica.de) 18.50.43 Quit bluebrother^ (Ping timeout: 252 seconds) 18.51.46 Quit fs-bluebot_ (Ping timeout: 264 seconds) 18.57.15 # pamaury: I know what linux does which makes this weird card work! After timeout of SELECT it tries another time. Usually second attempt is successful, sometimes third. 18.57.51 # I see, might be worth implementing that 19.07.25 Quit Rower (Ping timeout: 245 seconds) 19.14.34 # pamaury: Do we have storage idle callback? If so it would be wise to deselect card there and not at the end of every transfer. 19.14.34 Quit dfkt (Read error: Connection reset by peer) 19.15.12 # wodz: yes I think so, although you also need to be careful abou the case of having several devices on the same bus 19.15.38 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.15.42 # and also compare the result of deselect vs idle deselect 19.15.59 # pamaury: ? 19.17.36 # for example if you have 1 sec idle callback and you do one access every now and then, you might end up rarely putting the card in sleep mode 19.20.19 # On the other hand with this weird card it literally crawls with select/deselect. Every select takes more than sd_cmd() timeout as it fails the first time. 19.21.38 # yeah that's a problem 19.22.24 # but your card basically will have a 1sec timeout on every operation after deselect, which makes select/deselect almost useless 19.23.12 # yep 19.23.23 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 19.24.08 # do you really like this card that much ? :-p 19.24.17 # :P 19.24.50 # I don't like it more then other test cards I try when writing sd code 19.25.13 # I guess we could have some code to see how long select takes and ajust the frequency of those based on that but that's a bit mad 19.25.28 # honestly I HATE all this sd stuff, mostly because of crap docs 19.30.37 Join lebellium [0] (~chatzilla@89-93-179-187.hfc.dyn.abo.bbox.fr) 19.33.26 Quit Link7 (Remote host closed the connection) 19.39.09 Join orpheu [0] (0252b710@gateway/web/freenode/ip.2.82.183.16) 19.47.25 # wodz: pamaury while you're working on sd cards, don't you want to look at my codepage issue with SD cards on YP-R0? \o/ 19.48.04 # not sure this is related, we are working on the low level interface to SD, you problem seems related to file system or locale 19.48.21 # Isn't it like mount option problem? Honestly I don't know hosted targets. 19.49.23 # I vaguely remember there is option for default codepage when formating fat32. UTF8 produces warning AFAIK. 19.50.18 # It may be a mount option problem but I'm not able to check it myself, I need someone knowledgeable to help me test some things 19.51.21 # on which target is that ? 19.51.21 Quit dfkt (Read error: Connection reset by peer) 19.51.29 # pamaury: YP-R0 19.51.40 # ah, that's hosted 19.52.50 # there is probably something wrong in #g332 19.52.52 # 3Gerrit review #332 at http://gerrit.rockbox.org/r/332 : 3samsungypr0: Support or mounting the microsd by Thomas Martitz 19.54.56 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 19.58.00 # honestly I have no idea, my guess is that would want to specify the locale/encoding when mounting 19.58.28 # I don't know how it is detected by default 19.58.39 # probably depends on the system's locale too 20.00.03 Quit pamaury (Remote host closed the connection) 20.00.26 # my bet is that get_current_codepage_name_linux() returns some locale which can't display accented characters :-) 20.01.55 # so we would need here to fix the codepage to Unicode or something like that instead of using the default code page? 20.07.44 # <[Saint]> "fire" 20.07.50 # first we would need to know what this function returns on R0 20.08.20 # but AFAIK this is known interoperability problem on fat 20.08.57 Nick suYin`OFF is now known as suYin (mysuyin@server2.shellfire.net) 20.10.17 # lebellium: You can try to rip off this strlcat line and instead add 'iocharset=utf8' 20.11.25 # but I am not convinced there is any good solution to your problem. 20.12.13 # like that http://pastie.org/private/yrgwl0j306cor5ugosboxg ? 20.14.16 # no 20.15.33 # http://pastie.org/10713876 20.15.39 # lebellium: ^ 20.16.12 # thanks, I'll try that. 20.18.35 # no guarantee :P 20.19.20 # at this point I can try anything :) 20.20.13 # I'm quite surprised I'm still able to compile builds! 20.25.48 *** Saving seen data "./dancer.seen" 20.28.31 Quit foolsh (Remote host closed the connection) 20.51.09 Join foolsh [0] (~bbrown@c-98-226-50-174.hsd1.in.comcast.net) 21.01.27 # wodz: it does work :) 21.02.00 # great 21.02.54 # but you think it's not a good solution, 21.02.56 # ? 21.03.34 # I think it is not general 21.10.28 # that could bother other R0 users in somes cases? 21.17.02 # lebellium: https://www.kernel.org/doc/Documentation/filesystems/vfat.txt this suggest one should use 'utf8=true' instead of 'iocharset=utf8' but I don't understand the difference 21.21.08 # "NOTE: "iocharset=utf8" is not recommended. If unsure, you should consider the following option instead." 21.21.21 # lol .... what an explaination! 21.21.33 # lebellium: or pure 'utf8' as utf8=true is not documented as valid option :P 21.36.03 # lebellium: having read about all that mess I think it is fairly safe considering you read files off sd and not write it. 21.37.40 # well I can write too 21.37.51 # when I create a directory on the microSD from Rockbox 21.39.51 # basically the problem is that with utf8 filesystem starts to be semi case sensitive. 21.40.20 # which should not happen as FAT mandates that 'file' and 'FiLe' is the same :P 21.43.41 Quit Mihail (Quit: Page closed) 21.45.23 # is it why the R0 sometimes displays my folder names in upper case and sometimes in lower case while in my Windows explorer there are all in upper cases? 21.47.26 # could be 22.01.00 # is it something that could be commited even if it's not a perfect solution? 22.01.11 # I think it can't be worse than it is currently 22.01.55 Quit wodz (Ping timeout: 240 seconds) 22.12.55 Quit Bray90820 (Ping timeout: 240 seconds) 22.15.19 Join Bray90820 [0] (~bray90820@173-17-46-117.client.mchsi.com) 22.17.09 Join hannes2 [0] (~hannes3@port-92-196-10-69.dynamic.qsc.de) 22.17.22 # the cpu scaling on sansa clip+ made it very very annoying to use 22.17.39 # takes minutes until it properly reacts after booting 22.17.45 # with audio skips 22.17.49 # i am reverting =) 22.25.50 *** Saving seen data "./dancer.seen" 22.31.37 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 23.14.47 Quit orpheu (Ping timeout: 252 seconds) 23.20.53 # saratoga: "Mihail lorenzo92: If ypr0 have de-coupling capacitors, you should try remove AUDIOSET3_HPCM_on in AS3514_AUDIOSET3". There are 4 occurrences of "AS3514_AUDIOSET3" in as3514.c. Could you tell me exactly what I should change for the test? 23.22.30 # I assume it's the one in #ifdef HAVE_AS3543 that should be changed 23.25.08 # and then should I remove the entire line "as3514_write(AS3514_AUDIOSET3, AUDIOSET3_HPCM_on | AUDIOSET3_HP_LONGSTART);" or just replace it by something like "as3514_write(AS3514_AUDIOSET3 | AUDIOSET3_HP_LONGSTART);" 23.25.12 # ? 23.25.25 # (yes, I don't understand what I'm doing) 23.26.52 # lebellium: wait a sec 23.27.55 Quit bertrik (Remote host closed the connection) 23.29.43 # lebellium: you should probably replace it by "as3514_write(AS3514_AUDIOSET3, AUDIOSET3_HP_LONGSTART);" 23.30.33 # hum wait 23.30.49 # there is a lot of #ifdef there, some lines might not apply to the YP-R0 23.32.52 # lebellium: ok if you want a quirk and dirty test, you can replace line 139 by as3514_write(AS3514_AUDIOSET3, AUDIOSET3_HP_LONGSTART); 23.33.22 # but if you want a proper patch, you will probably need to do it slightly differently because other targets might need it 23.33.50 # thank you 23.34.44 # it's just for testing for now 23.35.15 # then if it works, I need to find a kind dev willing to write a clean patch \o/ 23.37.00 # if it's just that it will be quite simple 23.51.39 # nope, unfortunately it doesn't fix the issue 23.53.17 # still a huge gap between -40 and -39dB 23.57.46 # maybe it's a bug in the volume code ? 23.57.50 # I don't know if it's surprising though since the patch introducing this issue (#g1089) doesn't modify AUDIOSET3. 23.57.53 # 3Gerrit review #1089 at http://gerrit.rockbox.org/r/1089 : 3Bypass the AS3543 audio mixer at higher volumes. by Mihail Zenkov 23.58.06 # maybe I should rather revert back the changes to AUDIOSET1 and 2 23.58.15 Join Strife89 [0] (~quassel@adsl-98-80-213-95.mcn.bellsouth.net)