| 00:24:29 | *** | Saving seen data "./dancer.seen" |
| 00:24:34 | | Quit krnlyng (Ping timeout: 240 seconds) |
| 00:29:50 | | Join krnlyng [0] (~liar@178.114.5.162.wireless.dyn.drei.com) |
| 00:46:22 | | Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 45.0/20160201143558]) |
| 00:47:05 | | Quit petur (Quit: Leaving) |
| 01:00 |
| 01:28:59 | | Quit krnlyng (Ping timeout: 272 seconds) |
| 01:39:39 | | Quit pamaury (Ping timeout: 245 seconds) |
| 02:00 |
| 02:21:49 | | Quit krabador (Read error: Connection reset by peer) |
| 02:24:33 | *** | Saving seen data "./dancer.seen" |
| 02:29:18 | | Join krnlyng [0] (~liar@178.114.5.162.wireless.dyn.drei.com) |
| 02:29:58 | | Quit ZincAlloy (Quit: Leaving.) |
| 02:40:20 | jtdesigns01 | Mr. Somebody needs to implement material UI in rockbox. |
| 02:42:26 | [Saint] | If only we had a full theme engine... |
| 03:00 |
| 03:05:45 | | Quit foolsh_ (Ping timeout: 250 seconds) |
| 03:31:31 | | Quit Link7 (Remote host closed the connection) |
| 04:00 |
| 04:19:13 | | Quit krnlyng (Ping timeout: 276 seconds) |
| 04:24:36 | *** | Saving seen data "./dancer.seen" |
| 04:29:59 | | Join krnlyng [0] (~liar@178.114.5.162.wireless.dyn.drei.com) |
| 05:00 |
| 05:32:05 | | Quit krnlyng (Ping timeout: 240 seconds) |
| 05:36:34 | | Quit TheSeven (Ping timeout: 240 seconds) |
| 05:38:14 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 05:38:33 | | Quit Rower (Ping timeout: 240 seconds) |
| 05:47:25 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 06:00 |
| 06:12:00 | | Quit sparetire (Quit: sparetire) |
| 06:24:40 | *** | Saving seen data "./dancer.seen" |
| 06:30:28 | | Join krnlyng [0] (~liar@178.114.5.162.wireless.dyn.drei.com) |
| 06:51:45 | | Quit PurlingNayuki (Read error: Connection reset by peer) |
| 06:53:06 | | Join PurlingNayuki [0] (~Thunderbi@113.88.173.220) |
| 07:00 |
| 07:20:05 | | Join feoafka [0] (~afoakf@d23-16-73-123.bchsia.telus.net) |
| 07:20:57 | | Quit athidhep (Ping timeout: 250 seconds) |
| 07:45:27 | | Join JdGordon [0] (~jonno@ppp118-209-195-91.lns20.mel8.internode.on.net) |
| 07:45:27 | | Quit JdGordon (Changing host) |
| 07:45:27 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 07:45:55 | | Quit krnlyng (Ping timeout: 248 seconds) |
| 07:47:14 | | Quit JdGordon_ (Ping timeout: 240 seconds) |
| 08:00 |
| 08:24:41 | *** | Saving seen data "./dancer.seen" |
| 08:31:05 | | Join krnlyng [0] (~liar@178.114.5.162.wireless.dyn.drei.com) |
| 09:00 |
| 09:12:33 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 09:51:04 | | Quit krnlyng (Ping timeout: 240 seconds) |
| 09:52:51 | | Quit Rower (Ping timeout: 248 seconds) |
| 09:58:20 | | Quit bertrik (Remote host closed the connection) |
| 10:00 |
| 10:13:34 | | Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) |
| 10:19:31 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:22:30 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 10:24:42 | *** | Saving seen data "./dancer.seen" |
| 10:31:38 | | Join krnlyng [0] (~liar@178.114.5.162.wireless.dyn.drei.com) |
| 10:47:43 | | Quit bluebrother (Disconnected by services) |
| 10:47:48 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 10:48:42 | | Join fs-bluebot [0] (~fs-bluebo@xd9bef658.dyn.telefonica.de) |
| 10:50:41 | | Quit fs-bluebot_ (Ping timeout: 250 seconds) |
| 11:00 |
| 11:14:24 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 11:19:48 | | Join lebellium [0] (~chatzilla@89-93-179-187.hfc.dyn.abo.bbox.fr) |
| 11:47:10 | | Join djukon [0] (~djukon@gateway/shell/insomnia247/x-gtypbvsqtvcqkijb) |
| 11:50:43 | | Quit krnlyng (Ping timeout: 248 seconds) |
| 12:00 |
| 12:20:55 | | Quit djukon (Ping timeout: 240 seconds) |
| 12:21:16 | | Join wodz [0] (~wodz@89-77-223-98.dynamic.chello.pl) |
| 12:24:44 | *** | Saving seen data "./dancer.seen" |
| 12:25:14 | | Quit JanC (Ping timeout: 240 seconds) |
| 12:28:30 | | Join djukon [0] (~djukon@50708323.static.ziggozakelijk.nl) |
| 12:31:59 | | Join krnlyng [0] (~liar@83.175.90.24) |
| 12:39:38 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 13:00 |
| 13:20:06 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 13:22:22 | wodz | pamaury: ping |
| 13:23:25 | pamaury | wodz: pong |
| 13:23:37 | orpheu | apple: http://www.bbc.co.uk/news/technology-35502030 |
| 13:23:49 | pamaury | just saw your message |
| 13:23:55 | wodz | pamaury: I dropped you email. Hope you will have some brilliant idea |
| 13:24:13 | orpheu | imagine if this was the case with the ipods! |
| 13:24:22 | wodz | pamaury: I have literally no idea |
| 13:24:29 | pamaury | couple of ideas: check that all the constants in the code are correct (ie are you writing the proper value ?), is the register address correct ? is register size correct ? |
| 13:25:00 | pamaury | what do switch with the command ? |
| 13:25:32 | pamaury | *do you |
| 13:27:21 | wodz | sdlib_send_cmd(IF_MD(drive,) SDLIB_SWITCH_FUNC, 0x80fffff1, &rspdat, 64); |
| 13:27:31 | wodz | so switching to HS timing |
| 13:28:18 | pamaury | do you change the communication frequency too or does is freeze even with the original one ? |
| 13:28:28 | wodz | with original |
| 13:29:17 | wodz | it freezes when you write to register which starts the transfer to the card |
| 13:30:04 | pamaury | did you switch to 4-bit bus size before ? did you correctly disconnected the pull-up on cd/dat3 ? |
| 13:31:04 | wodz | I tried also to insert delay before this command and removed the card. The transfer then moves on but fails of course but this allows me to double check which values were written to registers |
| 13:31:29 | pamaury | are you sure that the clock and power setting are the same with lua and C code ? |
| 13:32:19 | wodz | pamaury: I think I checked that before |
| 13:34:42 | pamaury | it is unfortunate that you don't have anything to sniff the sd traffic, see what is happenning |
| 13:34:44 | wodz | pamaury: http://pastie.org/10711031 |
| 13:35:35 | wodz | Thats the sequence. It goes well till this SWITCH_FUNC |
| 13:36:00 | pamaury | does it use dma ? |
| 13:37:26 | wodz | pamaury: http://pastie.org/10711032 this is lua part |
| 13:38:07 | wodz | pamaury: I which sense? You can grab data with general purpose dma engine. |
| 13:38:30 | pamaury | maybe there is a problem with memory alignement ? or other constraints ? |
| 13:39:11 | pamaury | out of curiosity, how do you encode the fact that commands need to first send SD_APP_CMD ? Is that included in SDLIB_* ? |
| 13:39:25 | wodz | pamaury: yes |
| 13:40:26 | pamaury | did you try to dump the response of the card after each command to see if the error is before and the card somehow enters an error state ? |
| 13:40:41 | wodz | pamaury: hmm, good idea |
| 13:40:56 | pamaury | the looks really ok, that's frustrating ! |
| 13:42:46 | pamaury | wodz: I'm slightly concerned about the way you get the RCA |
| 13:43:06 | wodz | The things which I really can't understand is HOW this manifests. To send command to the card you basically write SD_ARG with argument, SD_CMD with command code and then SD_CMDRSP with response type expected and bit to kick it in. Now with this command the very next instruction after writing SD_CMDRSP is never executed |
| 13:43:31 | pamaury | ah no sorry, forgot that lua indices start at one ! |
| 13:49:09 | wodz | ah, I also tried various compiler flags to rule out some optimization problem. |
| 13:49:14 | pamaury | wodz: you can even go further: dump everything you write to sd registers in lua and C and compare |
| 13:50:35 | wodz | pamaury: I kinda did. I print from inside send_cmd() just after sanity checks. |
| 13:53:37 | wodz | the sd clock dumped from registers is 281250Hz so well below the limit |
| 13:55:04 | wodz | it the same in lua and C |
| 13:56:51 | pamaury | if everything is the same, it must an another factor, something related to gpio, clock or power (or dma ?) |
| 13:58:33 | wodz | what can cause write to register hang? |
| 13:59:13 | wodz | I'd expect the write to succeed but maybe give erroneous effect but not hang. |
| 13:59:58 | pamaury | a typical hang would that sd tries to communicate with a hardware block which is powered down or gated |
| 14:00 |
| 14:00:17 | pamaury | did you ungate dma properly ? |
| 14:01:18 | wodz | What if I do not consume this 64bytes of data? Could it hang the thing? |
| 14:01:34 | pamaury | probably not |
| 14:01:53 | pamaury | but you don't even reach this point right ? |
| 14:02:14 | wodz | yes it hangs earlier |
| 14:02:44 | pamaury | I mean if don't get all the data the sd card is sending, the next command will probably fail but that's all |
| 14:03:19 | wodz | Thats I understand this as well and hence it doesn't fit to what I see here |
| 14:03:21 | pamaury | can you post the code of the sdlib_* and sdc_* functions ? |
| 14:03:50 | wodz | pamaury: 1 sec |
| 14:04:39 | pamaury | I'll be back in 10/15 mon |
| 14:09:26 | wodz | http://pastie.org/10711053 - sdlib.h; http://pastie.org/10711057 - sdlib.c; http://pastie.org/10711061 - sd-drv-atj213x.c |
| 14:15:30 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 14:24:46 | *** | Saving seen data "./dancer.seen" |
| 14:24:53 | | Quit [Saint] (Remote host closed the connection) |
| 14:25:13 | pamaury | wodz: did you see g#1246 ? |
| 14:25:14 | fs-bluebot | Gerrit review #1246 at http://gerrit.rockbox.org/r/1246 : configure: allow for compiler toolchain override (with warnings) by Amaury Pouly |
| 14:25:50 | | Join [Saint] [0] (~hayden@rockbox/staff/saint) |
| 14:29:49 | wodz | pamaury: yes I saw that |
| 14:32:33 | pamaury | wodz: I might be missing something but why do you call sdc_dma_wr uncondtionnally ? shouldn't it be sdc_dma_rd in the case of the switch command for example ? |
| 14:35:04 | wodz | pamaury: where exactly? I see if (rspdat->data && datlen > 0 && !rspdat->rd) condition for calling sdc_dma_wr |
| 14:35:48 | pamaury | ok but 1) also sdc_dma_wr() is a stub ? 2) why isn't there another another test for sdc_dma_rd() ? |
| 14:36:23 | pamaury | maybe the sd block doesn't like the fact that you don't setup dma ? |
| 14:38:37 | wodz | pamaury: I experimented with this in lua. The next command fails if you do not consume data but thats it |
| 14:39:25 | wodz | and btw there is such test near the end of sdc_send_cmd() |
| 14:40:16 | pamaury | oh I see sorry, I thought would setup the dma transfer before sending the command |
| 14:41:06 | wodz | I can't remember why I did it this way actually |
| 14:42:15 | pamaury | I'm running out ideas... |
| 14:44:53 | wodz | so am I ... |
| 14:49:49 | pamaury | is there a difference in the running environement between C and lua ? |
| 14:50:07 | pamaury | any thought on g#1246 ? I'd like to commit it |
| 14:50:08 | fs-bluebot | Gerrit review #1246 at http://gerrit.rockbox.org/r/1246 : configure: allow for compiler toolchain override (with warnings) by Amaury Pouly |
| 14:52:15 | wodz | pamaury: for me it ok, commit |
| 14:52:43 | wodz | pamaury: I can't think of anything relevant |
| 14:52:45 | pamaury | how do load the C code ? through hwstub ? |
| 14:53:08 | wodz | pamaury: no, directly by adfuload |
| 14:53:24 | | Quit bertrik (Remote host closed the connection) |
| 14:53:58 | pamaury | could it be that something in the hwstub init code makes a difference ? |
| 14:56:12 | wodz | crt0.S is almost verbatim copy between the two. |
| 15:00 |
| 15:01:32 | pamaury | then I would go for full dump of what you read/write in every register, you say you kinda of did already but why only "kinda" ? |
| 15:01:58 | pamaury | there must be something if it manages to hang the whole thing |
| 15:04:34 | fs-bluebot | Build Server message: New build round started. Revision 16c915e, 255 builds, 26 clients. |
| 15:06:10 | pamaury | I also would like to commit g#1131 soon, I can probably split it into several commits if necessary. The only, possibly annoying, big change is that qeditor cannot only read v2 file after this, but of course there is the convert program for v1 -> v2 |
| 15:06:27 | fs-bluebot | Gerrit review #1131 at http://gerrit.rockbox.org/r/1131 : regtoosl/qeditor: port to the new description format (WIP) by Amaury Pouly |
| 15:08:32 | pamaury | hum, is it me or gerrit is dying ? |
| 15:08:48 | | Join sparetire [0] (~sparetire@unaffiliated/sparetire) |
| 15:09:11 | pamaury | ah finally back. |
| 15:09:43 | pamaury | wodz: also I tried to rewrite the imx233 code using the new headergen_v2 (basically removing the BF_SET macro so that it can be repurposed) and here is the result: g#1245 |
| 15:09:44 | fs-bluebot | Gerrit review #1245 at http://gerrit.rockbox.org/r/1245 : imx233: generate register headers using headergen_v2 by Amaury Pouly |
| 15:12:28 | fs-bluebot | Build Server message: Build round completed after 473 seconds. |
| 15:12:29 | fs-bluebot | Build Server message: Revision 16c915e result: 23 errors 151 warnings |
| 15:12:29 | wodz | pamaury: I'd very appreciate commiting v2 stuff. I have various temp in either v1 format or v2 and holding two sets of tools and two sets of reg description is annoying |
| 15:13:54 | pamaury | ok. I need to go through the code one last time to make sure I didn't left anything over. The only partially incomplete tool is headergen_v2 but that can be tweaked later |
| 15:14:08 | | Quit [Saint] (Remote host closed the connection) |
| 15:20:20 | | Join [Saint] [0] (~hayden@rockbox/staff/saint) |
| 15:27:29 | | Join ZincAlloy [0] (~Adium@p5B2FD510.dip0.t-ipconnect.de) |
| 15:38:13 | | Quit [Saint] (Read error: Connection reset by peer) |
| 15:43:04 | | Join [Saint] [0] (~hayden@rockbox/staff/saint) |
| 16:00 |
| 16:10:54 | | Quit krabador (Ping timeout: 240 seconds) |
| 16:11:19 | | Quit Rower (Ping timeout: 245 seconds) |
| 16:11:45 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 16:22:24 | pamaury | wodz: I've split the commit into two: g#1247 and g#1131 |
| 16:22:26 | fs-bluebot | Gerrit review #1247 at http://gerrit.rockbox.org/r/1247 : regtools: update v2 specification, library and tools by Amaury Pouly |
| 16:22:26 | fs-bluebot | Gerrit review #1131 at http://gerrit.rockbox.org/r/1131 : regtoosl/qeditor: port to the new description format by Amaury Pouly |
| 16:22:30 | pamaury | For me it's ready to push |
| 16:23:16 | wodz | pamaury: I am using some quite recent version of this here without problems so for me - go ahead and commit |
| 16:24:48 | *** | Saving seen data "./dancer.seen" |
| 16:25:20 | pamaury | ok cool |
| 16:25:30 | fs-bluebot | Build Server message: New build round started. Revision 0f701a6, 255 builds, 26 clients. |
| 16:25:39 | | Join rela_ [0] (~x@p200300764D4BD00060E1888110D8469C.dip0.t-ipconnect.de) |
| 16:29:04 | | Quit rela (Ping timeout: 240 seconds) |
| 16:30:19 | fs-bluebot | Build Server message: Build round completed after 290 seconds. |
| 16:30:20 | fs-bluebot | Build Server message: Revision 0f701a6 result: 1 errors 25 warnings |
| 16:30:21 | fs-bluebot | Build Server message: New build round started. Revision 6b9610f, 255 builds, 26 clients. |
| 16:34:44 | fs-bluebot | Build Server message: Build round completed after 264 seconds. |
| 16:34:45 | fs-bluebot | Build Server message: Revision 6b9610f result: 0 errors 33 warnings |
| 16:41:24 | fs-bluebot | Build Server message: New build round started. Revision 6e54f72, 255 builds, 26 clients. |
| 16:46:38 | fs-bluebot | Build Server message: Build round completed after 314 seconds. |
| 16:46:39 | fs-bluebot | Build Server message: Revision 6e54f72 result: 0 errors 24 warnings |
| 16:46:40 | fs-bluebot | Build Server message: New build round started. Revision 7d87ebb, 255 builds, 22 clients. |
| 16:51:48 | fs-bluebot | Build Server message: Build round completed after 310 seconds. |
| 16:51:49 | fs-bluebot | Build Server message: Revision 7d87ebb result: 0 errors 121 warnings |
| 16:52:17 | | Join Rower [0] (~husvagn@d83-183-134-99.cust.tele2.se) |
| 16:53:12 | wodz | pamaury: I compared clocks and this are the same in hwstub and in C. I checked also command responses and they are the same in lua and C. |
| 16:53:22 | pamaury | weird |
| 16:55:54 | | Quit Jack87 (Read error: Connection reset by peer) |
| 16:57:23 | pamaury | are you absolutely sure you write the same registers in the same order with the same values in C and lua ? how could it be possible ?! |
| 16:57:39 | | Join Jack87 [0] (~Jack87@nasadmin/admin/jack87) |
| 17:00 |
| 17:02:02 | wodz | now I checked if running from uncached address makes a difference but it doesn't |
| 17:04:32 | wodz | the only difference is more repetitions of acmd41 when running with cache which is obvious |
| 17:09:39 | wodz | pamaury: I checked once again the order in which registers are written is the same: ARG, CMD, CMDRSP |
| 17:10:02 | wodz | constants used for CMDRSP are the same |
| 17:12:56 | wodz | There is one big difference however. C code uses lcd to output debug info. The problem is that sd lines and lcd lines are multiplexed. But if this is the cause why on earth i triggers only this command. |
| 17:15:00 | pamaury | interesting |
| 17:15:15 | pamaury | maybe because you don't get the data ? |
| 17:16:42 | pamaury | like you lock the pins for sd, do things, unlock the pins, but the sd block is still doing things on the pins so when the lcd acquire then, something bad happens ? |
| 17:17:42 | wodz | but it hangs before I unlock so I can't see how this could happen |
| 17:18:25 | wodz | btw. who on earth had an idea to multiplex sd and lcd in DAP! |
| 17:18:31 | pamaury | is it possible that in the lock/unlock scheme you forgot some pins ? |
| 17:18:40 | pamaury | yeah that looks like a bad idea in the first place |
| 17:18:57 | pamaury | because this command is probably the first one to use DAT1,2,3 |
| 17:19:10 | pamaury | for example forgot a pullup/down |
| 17:19:24 | wodz | I use the same constants as in lua |
| 17:19:49 | wodz | I mean to drive multiplexer |
| 17:21:02 | pamaury | but lua doesn't use the lcd |
| 17:22:38 | wodz | thats true. But I just added some flipping of the muliplexer in lua to somewhat simulate this and card initialization still works. |
| 17:22:58 | wodz | so pure switching of multiplexer is correct |
| 17:23:18 | pamaury | I was more thinking about a problem that the switching forget something, and this something doesn't interfere as long as the lcd is not in use |
| 17:23:40 | pamaury | i don't know if it's even possible |
| 17:23:56 | wodz | switching code is taken from disassembly of sd driver in OF |
| 17:23:57 | pamaury | for example try to gate the lcd when doing sd operations to see |
| 17:24:22 | wodz | hmm, interesting idea, lets try |
| 17:30:13 | wodz | hmm, maybe the whole problem is not in sd but in lcd? Maybe for some reason displaying gets broken |
| 17:31:04 | pamaury | wodz: can you copy the switching code and lcd code so I can have a look at the datasheet ? |
| 17:33:21 | wodz | pamaury: switching code https://github.com/wodz/rockbox-atj213x/blob/master/firmware/target/mips/atj213x/gpio-atj213x.c lcd code https://github.com/wodz/rockbox-atj213x/blob/master/firmware/target/mips/atj213x/iriver-e150/lcd-e150.c |
| 17:34:05 | wodz | in local tree I have random delays spread in switching code but I don't see any difference actually |
| 17:36:50 | | Nick kugel__ is now known as kugel (~kugel@rockbox/developer/kugel) |
| 17:38:02 | wodz | pamaury: yep. it is lcd which is screwed up. I inserted backlight_hw_off() and this gets executed. |
| 17:40:58 | wodz | so this command somehow kills lcd transfers (data transfer?) |
| 17:41:05 | pamaury | probably |
| 17:42:35 | pamaury | but how ? it doesn't call the lcd ? |
| 17:42:46 | wodz | ? |
| 17:43:07 | pamaury | backlight_hw_off() |
| 17:43:38 | | Join ender [0] (~ender@foo.eternallybored.org) |
| 17:44:24 | | Quit Smx- (Excess Flood) |
| 17:44:47 | wodz | no it sets pwm fill factor |
| 17:44:54 | | Quit ender` (Ping timeout: 240 seconds) |
| 17:46:57 | pamaury | but you are saying that backlight_hw_off() kills the lcd transfer ? |
| 17:48:59 | | Join Smx [0] (Elite8556@gateway/shell/elitebnc/x-rftkxxuqndboaypj) |
| 17:49:00 | wodz | no, no |
| 17:49:17 | wodz | cmd6 kills all subseqent lcd transfers |
| 17:49:28 | | Join Mihail [0] (252d7c79@gateway/web/freenode/ip.37.45.124.121) |
| 17:49:43 | pamaury | ok |
| 17:51:33 | wodz | this should be possible to simulate in lua as well. |
| 17:51:59 | pamaury | could it have something to do with the SD pullup ? |
| 17:54:23 | Mihail | wodz: I have some experience with direct use of sd cards on uC (AVR). Possible I can try help. Are you sure that initialization of sd card is successful? |
| 17:56:03 | wodz | Mihail: On AVR you are using SPI mode which is a bit different. The problem seems to be in ackward multiplexing of sd and lcd lines in this particular case |
| 17:56:30 | pamaury | wodz: SD_CTL_RESE enables pullups, so when you switch the bus to 4-bit, I assume it also enables pullups on the data lines. If somehow those pullups are still on after the gpio function change, that will probably kill the lcd tranfers |
| 17:56:53 | pamaury | (assuming the chip doesn't multiplex the pullup which could be possible) |
| 17:57:24 | wodz | pamaury: ACMD42 disconnect the pull-up resistor on CD/DAT3 - at least thats how I read this command |
| 17:57:34 | pamaury | yeah but on the host side |
| 17:57:42 | wodz | pamaury: ah, I see what you mean |
| 17:59:18 | wodz | pamaury: hmm, SD_CTL_RESE is set indeed in initialization |
| 17:59:44 | pamaury | let me check the SD spec, I don't remember all the details of the on-wire format |
| 18:00 |
| 18:01:24 | wodz | hmm, OF writes 0 to SD_CTL after sd transfers |
| 18:02:59 | pamaury | the sd bus needs pullups to operate, the question is whether those are external or internal, I guess RESE is meant to be used when there are no external pullups |
| 18:03:23 | pamaury | so it probably needs to be set before the transfer, but after it you might want to disable them |
| 18:03:38 | wodz | the interesting thing is that gating clock to SD block doesn't block access to sd registers. I am curious what clock gate means in this case |
| 18:03:52 | pamaury | probably card clock gating |
| 18:04:04 | pamaury | you don't want the scaclock to be on when sending |
| 18:04:13 | pamaury | *card clock to be on when sending lcd data |
| 18:04:58 | wodz | up to cmd6 it doesn't matter but who knows |
| 18:05:32 | pamaury | what does the OF do ? |
| 18:06:19 | pamaury | up to CMD6 you don't use the data lines. I assume the SD CMD and CLK lines are not shared ? |
| 18:06:30 | Mihail | wodz: you right, but initial stage mostly same. From my experience ACMD41 should by send with one second delay between attempts. Some cards don't response correct on ACMD41, but still can be used after 5 attempts. |
| 18:07:12 | wodz | Mihail: I have the problem further in the line of initialization. ACMD41 works just fine |
| 18:07:26 | pamaury | omg, they even multiplex SD CLK and lcd CE :-o |
| 18:07:44 | pamaury | that's kind of clever actually |
| 18:08:04 | wodz | pamaury: OF uses quite complicated sequence actually |
| 18:10:43 | wodz | pamaury: oh, and OF sets unknown register in GPIO block - 0xb01c0088 |
| 18:10:58 | pamaury | that might be important |
| 18:11:24 | pamaury | it's PAD_DRV |
| 18:11:45 | wodz | pamaury: I checked that there is also 0xb01c0084 and 0xb01c008c which sticks value written into |
| 18:12:00 | pamaury | probably related to drive strength and pullups, might be exactly what we need |
| 18:12:38 | wodz | pamaury: where do you see it? |
| 18:13:25 | wodz | ah, I see it. How could I overlook it |
| 18:14:07 | wodz | OF ORs 0x23 with this register |
| 18:15:40 | pamaury | that P_D[0:3], P_D[4:7] and PA[5:0] |
| 18:15:48 | pamaury | is there a pin map ? |
| 18:16:48 | pamaury | MFCTL0 refers to A[2:0] for SD_CMD and D[7:0] for data |
| 18:17:30 | wodz | I think pinmap is in Datasheet (as opposed to programming guide) |
| 18:18:32 | wodz | hmm, I see this bits only set. I can't spot anything clearing it. |
| 18:19:33 | wodz | The set part is in function which prepares sd block to be operational |
| 18:20:12 | wodz | it sets interface width, clk freq, multiplexing and this PAD_DRV |
| 18:21:13 | wodz | The counter function which deactivates block doesn't touch PAD_DRV |
| 18:22:37 | pamaury | that's worth a try I would say |
| 18:22:50 | pamaury | since we don't really know what it does anyway |
| 18:23:41 | wodz | I'd love to reproduce this on hwstub as there is much easier to sniff around |
| 18:24:49 | *** | Saving seen data "./dancer.seen" |
| 18:27:35 | pamaury | the datasheet doesn't say much about pad driver |
| 18:28:17 | pamaury | and there is no schematic of the gpio structure |
| 18:29:16 | pamaury | but my guess is that it controls drive strength, since if you have a pullup on the bus, you might need a high drive strength to achieve good rise/fall times |
| 18:29:46 | pamaury | especially if you drive it above 10 or 20MHz |
| 18:30:01 | pamaury | like the lcd probably does |
| 18:31:00 | | Quit PurlingNayuki (Quit: PurlingNayuki) |
| 18:32:12 | pamaury | wodz: I need to leave, but i'll read the log and might be online later |
| 18:32:31 | wodz | ok, thanks for support |
| 18:36:33 | | Quit pamaury (Ping timeout: 250 seconds) |
| 18:44:00 | | Quit orpheu (Quit: Page closed) |
| 18:46:46 | | Quit Mihail (Quit: Page closed) |
| 19:00 |
| 19:12:03 | | Join orpheu [0] (0252b710@gateway/web/freenode/ip.2.82.183.16) |
| 19:14:44 | wodz | pamaury: (log) Setting PAD_DRV helps indeed. |
| 19:15:54 | wodz | pamaury: (log) I don't know yet if it solves everything but cmd6 doesn't screw up panicf() at least |
| 19:22:22 | | Quit shamus (Read error: Connection reset by peer) |
| 19:42:58 | | Join HazWard [0] (~HazWard@159.203.28.215) |
| 19:45:08 | HazWard | The android port of Rockbox is written in what language |
| 19:47:57 | | Quit krnlyng (Quit: huiiiiii) |
| 19:48:24 | | Join krnlyng [0] (~liar@178.114.5.162.wireless.dyn.drei.com) |
| 19:54:03 | rela_ | java i presume |
| 20:00 |
| 20:13:36 | wodz | wrong |
| 20:14:04 | wodz | java is only thiny wrapper around native .so library |
| 20:14:28 | wodz | Rockbox is C + small portion of asm |
| 20:14:36 | | Join krnlyng_ [0] (~liar@83.175.90.24) |
| 20:14:53 | wodz | HazWard, rela: ^ |
| 20:15:44 | HazWard | thanks! |
| 20:16:29 | wodz | HazWard: Why are you asking? |
| 20:17:45 | HazWard | I was thinking about learning a language to maybe modernize rockbox but I don't know C and Assembly |
| 20:18:12 | | Quit krnlyng (Ping timeout: 272 seconds) |
| 20:19:23 | wodz | HazWard: Modernize in which sense? |
| 20:20:10 | | Quit rela_ (Quit: Leaving) |
| 20:20:25 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
| 20:21:07 | HazWard | On android, the UI feels clunky, the core of Rockbox is amazing but the UI isn't on par with what the software can deliver |
| 20:22:30 | wodz | HazWard: You would need to drastically change the way rockbox on android port is done. This HUGE task. |
| 20:23:24 | wodz | HazWard: Kugel started work in this direction but lost interest/had no time to finish. Nobody picked that up till now. |
| 20:24:53 | *** | Saving seen data "./dancer.seen" |
| 20:25:01 | wodz | HazWard: Basically you would need to rip core part of rockbox and turn it into lib with established API. Then write UI part in java and call rockbox code from there. |
| 20:25:39 | | Nick krnlyng_ is now known as krnlyng (~liar@83.175.90.24) |
| 20:26:05 | wodz | HazWard: Not speaking about solving threading to not interfere with android runtime. |
| 20:28:26 | wodz | HazWard: And honestly now it is easier to build app around ffmpeg or something then diving into 10+ years of history |
| 20:30:07 | | Join saratoga [0] (ac3ad93e@gateway/web/freenode/ip.172.58.217.62) |
| 20:30:32 | saratoga | i think you could write a new UI and just use the rockbox codec lib as well, although that would be far from a rockbox port |
| 20:30:55 | saratoga | but really if knowing c is a problem, i think this is probably too ambitious a project |
| 20:31:18 | HazWard | ok thanks a lot for the tips wodz, and is there anything new going on with the "traditional" builds (running on DAP) |
| 20:32:04 | wodz | HazWard: from time to time, yes |
| 20:32:58 | HazWard | saratoga: learning c isn't a problem at all, I'm currently learning c# and trying things with unity3d so a new language is not a problem |
| 21:00 |
| 21:01:03 | | Quit saratoga (Quit: Page closed) |
| 21:28:29 | | Quit alexweissman () |
| 21:30:03 | | Quit krabador (Read error: Connection reset by peer) |
| 21:32:07 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 21:51:56 | | Join nlogex [0] (~filip@dhcp-108-168-15-53.cable.user.start.ca) |
| 22:00 |
| 22:13:12 | | Join webguest69 [0] (~5ab1ed69@www.haxx.se) |
| 22:13:16 | | Quit webguest69 (Client Quit) |
| 22:14:33 | | Quit djukon (Ping timeout: 240 seconds) |
| 22:16:39 | HazWard | I've installed Rockbox on an iPhone 3G (4.2.1) with OpeniBoot (iDroid) |
| 22:16:40 | | Join djukon [0] (~djukon@50708323.static.ziggozakelijk.nl) |
| 22:21:13 | | Quit mwfc (Ping timeout: 240 seconds) |
| 22:22:31 | | Join mwfc [0] (~mwfc@hephaestus.mwfc.info) |
| 22:24:54 | *** | Saving seen data "./dancer.seen" |
| 22:26:42 | HazWard | http://imgur.com/a/ucFAi |
| 22:27:56 | HazWard | https://u.teknik.io/6Mr6X.mp4 |
| 22:49:24 | | Quit wodz (Ping timeout: 240 seconds) |
| 23:00 |
| 23:08:54 | | Quit rela (Ping timeout: 240 seconds) |
| 23:15:59 | [Saint] | HazWard: Oh wow man...you /reaaaaally/ hate yourself don't you, lol. |
| 23:23:17 | HazWard | hahahahaha |
| 23:24:29 | HazWard | [Saint]: Do you still have you theme for touch devices? |
| 23:30:02 | [Saint] | I might, somewhere, on some backup snapshot - the current 320x480 cabbiev2 does indeed support touchscreen, though. |
| 23:30:42 | [Saint] | So if touch isn;t working out of the box it is probable that it's a result of some fuckery in the nature of how you got this frankendroidiOS kludge running. |
| 23:31:51 | [Saint] | I'm looking at cabbiev2.320x480x16.wps right now and it pretty clearly supports touchscreen devices. |
| 23:36:29 | | Join shamus [0] (~shmaus@ip-206-192-194-12.marylandheights.ip.cablemo.net) |
| 23:37:34 | [Saint] | What I am basically saying is that if touch isn't working for you right now, no theme that myself or anyone could supply you will make that not be the case, and you would need to debug the interaction between the iOS and Android layers and how that relates to the touchscreen. |
| 23:39:23 | HazWard | touch is perfectly working |
| 23:39:24 | | Quit Rower (Ping timeout: 250 seconds) |
| 23:39:50 | [Saint] | Oh. Then what was the intention? |
| 23:39:56 | jtdesigns01 | how do we even deal with touch in RB? |
| 23:40:04 | HazWard | changing the theme |
| 23:40:38 | [Saint] | If you dislike cabbiev2, then you don't want anything that I could supply you. |
| 23:41:10 | HazWard | haha well ok |
| 23:41:30 | HazWard | and can rockbox run as a linux application (no simulator)? |
| 23:41:39 | [Saint] | Yes. |
| 23:42:53 | [Saint] | Our configure script presents an SDL target device. |
| 23:43:06 | HazWard | where could I find a build (or do I have to build it myself) |
| 23:43:21 | [Saint] | The latter. |
| 23:45:32 | Petri152 | I love you all |
| 23:46:57 | jtdesigns01 | I`ll take that as a compliment |
| 23:55:10 | * | [Saint] has some fun with the forum quote syntax |
| 23:55:11 | [Saint] | http://forums.rockbox.org/index.php/topic,51191.msg236396.html#msg236396 |
icon identifies that the person is a core developer (has commit access).