| 00:05:11 | | Join __builtin [0] (~xray@cpe-75-177-76-62.triad.res.rr.com) |
| 00:05:11 | | Quit __builtin (Changing host) |
| 00:05:11 | | Join __builtin [0] (~xray@rockbox/developer/builtin) |
| 00:07:51 | | Quit __builtin (Client Quit) |
| 00:08:33 | | Quit cc___ (Quit: WeeChat 1.6) |
| 00:09:44 | | Join __builtin [0] (~xray@cpe-75-177-76-62.triad.res.rr.com) |
| 00:09:44 | | Quit __builtin (Client Quit) |
| 00:12:08 | | Join _builtin [0] (~xray@cpe-75-177-76-62.triad.res.rr.com) |
| 00:12:08 | | Quit _builtin (Changing host) |
| 00:12:08 | | Join _builtin [0] (~xray@rockbox/developer/builtin) |
| 00:12:30 | | Quit _builtin (Client Quit) |
| 00:13:27 | | Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
| 00:13:55 | | Quit cc___ (Client Quit) |
| 00:15:21 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
| 00:19:14 | | Join __builtin [0] (~xray@rockbox/developer/builtin) |
| 00:20:24 | | Join Mihail [0] (25d44641@gateway/web/cgi-irc/kiwiirc.com/ip.37.212.70.65) |
| 00:21:20 | | Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) |
| 00:21:32 | Mihail | furrywolf: ping |
| 00:23:04 | __builtin | hmm, it seems like the easiest way to approach this port is by writing a SDL wrapper |
| 00:23:36 | __builtin | or maybe I could just port SDL, who knows? :D |
| 00:33:40 | | Quit funman (Changing host) |
| 00:33:40 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 00:39:53 | | Join Jinx [0] (Dojo@unaffiliated/jinx) |
| 00:41:36 | furrywolf | pong? |
| 00:42:30 | Mihail | have time for debug? |
| 00:42:36 | furrywolf | a bit. |
| 00:43:17 | Mihail | install this build http://knk.square7.ch/rb/rockbox-fuzev1-usb-4.zip |
| 00:43:32 | furrywolf | while you were asleep, there seemed to be several opinions that you should switch back to the interrupt-driven code, then figure out why it doesn't work on the devices it doesn't work on, rather than trying to figure out why the non-interrupt one doesn't work on mine. |
| 00:43:55 | *** | Saving seen data "./dancer.seen" |
| 00:45:07 | | Quit alexweissman (Remote host closed the connection) |
| 00:45:10 | Mihail | in rockbox-fuzev1-usb-3.zip I disable all interrupts for read and write, but we still have problem |
| 00:45:54 | furrywolf | hrmm, my internet connection is extra-sucky today... might be a few minutes. |
| 00:48:28 | Mihail | in new bulild try connect usb for few seconds (5-10) and then disconnect it. If player not freeze - press system > debug > dump log file |
| 00:48:49 | furrywolf | downloaded |
| 00:49:54 | | Quit [Saint] (Ping timeout: 258 seconds) |
| 00:49:56 | furrywolf | stuck at main menu, not enumerating. |
| 00:50:07 | * | furrywolf waits ten seconds |
| 00:50:24 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 00:50:31 | Mihail | try again |
| 00:50:58 | furrywolf | still on main menu, still attempting to enumerate and failing. |
| 00:51:32 | furrywolf | on unplug, briefly flashes the usb plug screen then returns to main menu |
| 00:51:51 | Mihail | menu work? |
| 00:52:48 | furrywolf | after unplugging, yes. it's always come back to life after the cable was unpluged, except for when in panics. |
| 00:53:22 | furrywolf | nothing is happening differently after 5-10 seconds compared to previous builds. linux keeps trying to enumerate it. |
| 00:53:45 | Mihail | reboot player and connect usb for few seconds (5-10) and then disconnect it. Then select system > debug > dump log file |
| 00:54:21 | furrywolf | I just dumped the log file, rebooting into bootloader usb now. |
| 00:54:41 | Mihail | upload .rockbox/logf.txt from player |
| 00:56:34 | furrywolf | I take it the log is limited in size? looks like the end of a log, not a whole log. |
| 00:57:16 | furrywolf | I can try plugging and unplugging quicker. |
| 00:57:24 | Mihail | ok |
| 00:57:57 | | Quit funman (Ping timeout: 240 seconds) |
| 00:58:52 | | Join funman [0] (~fun@chui-pas.net) |
| 01:00 |
| 01:00:27 | furrywolf | does your client not have working dcc? |
| 01:00:44 | Mihail | no |
| 01:00:51 | furrywolf | ... your client sucks. :P |
| 01:01:03 | Mihail | just web |
| 01:02:12 | furrywolf | blah, my internet connection is really sucking today. |
| 01:02:20 | furrywolf | http://fw.bushytails.net/tmp/logf.txt |
| 01:03:52 | furrywolf | when the usb cable is connected, the ui immediately freezes. linux attempts to enumerate it, and fails. when the cable is unplugged, then it jumps to the usb plug screen for a fraction of a second, then back to the main menu. |
| 01:04:08 | furrywolf | with the dev build before, it would usually show the usb plug screen, then fail. |
| 01:04:56 | furrywolf | these builds don't seem to loop like the head dev build was doing - it would visibly keep connecting and disconnecting, while yours tend to just freeze. |
| 01:04:57 | | Nick Strife1989 is now known as Strife89 (~quassel@adsl-98-80-194-228.mcn.bellsouth.net) |
| 01:05:17 | Mihail | logf show problem, I need a bit time to think |
| 01:05:40 | furrywolf | are you trying to use the interrupt-based older code, or the non-interrupt newer code? |
| 01:06:19 | Mihail | non-interrupt |
| 01:06:21 | furrywolf | slightly related: does it charge in bootloader usb mode? |
| 01:06:32 | Mihail | yes |
| 01:06:40 | furrywolf | I like interrupt-driven asynchronous code better. :P |
| 01:06:54 | | Quit xorly (Ping timeout: 255 seconds) |
| 01:07:37 | Mihail | have many problems with it and no one can fix it |
| 01:07:49 | furrywolf | why can no one fix it? |
| 01:07:54 | furrywolf | also, at least for me, it has no problems. lol |
| 01:08:10 | Mihail | we don't have datasheet for i2c2 |
| 01:08:48 | furrywolf | that harms fixing the non-interrupt one too |
| 01:09:35 | Mihail | amsv2 players have bunch of problems with old code - freezeы and panics |
| 01:10:10 | Bilgus | I'd almost rather go back to the original and work on the amsv2 problem since I have a physical unit to test on |
| 01:10:46 | Bilgus | furrywolf you said you had coding experience feel like doing some dev? |
| 01:11:01 | furrywolf | I generally consider asynchronous i/o with ISRs to be better, just because it's the right way of doing it. |
| 01:11:29 | furrywolf | Bilgus: I have far more projects than time and energy. I just wanted to make my mp3 player work so I could make my jobsite radio play music. lol |
| 01:11:56 | furrywolf | this started as "I'll just install rockbox, shouldn't take more than 5 minutes..." |
| 01:13:23 | furrywolf | also, my experience is it takes a lot of time to get up to speed on a new codebase. |
| 01:13:57 | * | furrywolf has no idea how rockbox works, and has never done usb coding |
| 01:14:25 | Mihail | general - yes asynchronous i/o with ISRs to be better, but for I2C2 we have bigger overhead for interrupt version and it overcomplicated |
| 01:14:42 | | Quit ender` (Quit: Patriotism is, fundamentally, a conviction that a particular country is the best in the world because you were born in it. — George Bernard Shaw) |
| 01:14:52 | Mihail | * in general |
| 01:15:34 | furrywolf | it could be worse... you could be bit-banging a gpio pin. :) |
| 01:17:38 | furrywolf | the old code has a number of error and sanity checks the new code lacks |
| 01:17:49 | __builtin | woot! SDL compiles!!! (-ish) |
| 01:17:56 | furrywolf | like actually seeing if reads returned anything |
| 01:18:18 | Mihail | it not used |
| 01:18:57 | __builtin | though I don't have any drivers that actually do anything :P |
| 01:21:47 | __builtin | and I also have a version of SDL from 2014 for some reason |
| 01:22:16 | furrywolf | hrmm, the as3525 has usb otg... seems that should be able to be used for something. :) |
| 01:22:34 | | Quit Jinx (Quit: Sad day in USA) |
| 01:24:17 | pamaury | furrywolf: iirc the hardware is not wired for otg |
| 01:24:21 | pamaury | so you can't use it |
| 01:27:21 | pamaury | Mihail: you could try to use an intermediate solution use tick_task |
| 01:27:24 | furrywolf | meh, yeah, the datasheet I found tells you the addresses of the i2c registers, but not what to do with them. |
| 01:27:30 | * | __builtin decides to only write drivers for the "useful" parts of SDL |
| 01:29:43 | furrywolf | what datasheet was used to write the code? or is it based on dumping stock firmware and reverse-engineering? |
| 01:29:55 | pamaury | probably reverse engineering |
| 01:31:43 | pamaury | Mihail: you cannot mutex_lock in tick_task (since it's called from IRQ) but what you can do is have a state machine with three states: IDLE, REQ, WAIT. IDLE means nothing to do, REQ means 'please start a read of ENDR0' and WAIT means 'waiting for this read to finish'. The INT_AUDIO simply moves the code from IDLE to REQ (if it was IDLE). Then REQ starts a read (or does nothing if there is an i2c operation in progress) and of course sets a |
| 01:31:43 | pamaury | variable tht prevent any other operation in the mean time. Then WAIT checks if read is finished, if it is, it does what is necessary and release the 'lock'. |
| 01:33:51 | pamaury | Mihail: otherwise if there are thread regularly doing i2c operations (like powermgm peraps ?). Then I suggest you simply defer the ENRD0 read to this thread. It would work like this: INT_AUDIO sets a (volatile) variable to 1. The i2c read function checks if this variable is 1 and if it is, it first does a read to ENRD0 and only then does the read it was supposed to. This way you get a thread to do the operation for you and you can safely lock |
| 01:34:04 | furrywolf | www.keil.com/dd/docs/datashts/ams/as3525_ds.pdf does seem to cover it a bit, around page 157 |
| 01:34:24 | pamaury | furrywolf: the whole point is that we don't know what changed in amsv2 |
| 01:34:37 | pamaury | and the code was broken in amsv2 |
| 01:35:30 | Mihail | ok, thanks! I try it later. As I already say - furrywolf's case not related to mutex |
| 01:37:57 | pamaury | still, mutex lock in irq context is no no, this needs to be fixed |
| 01:38:28 | Mihail | sure |
| 01:38:39 | lebellium | pamaury: hum I put some songs onto my E580, unplug it, and now when it boots it's stuck on the boot selection screen. Nothing happens when I select Walkman and I can't move to Rockbox with the keys. The reset hole doesn't help. It's still recognized by the computer. |
| 01:38:41 | pamaury | and jhMikeS says that if an IRQ takes too long it results in weird things |
| 01:39:02 | pamaury | lebellium: are you sure you don't have the hold key on ? |
| 01:39:11 | lebellium | oh |
| 01:39:12 | lebellium | -_- |
| 01:39:29 | pamaury | I need to add code to provide some HOLD key indicator, |
| 01:39:32 | lebellium | that probably means I should have a sleep |
| 01:39:45 | pamaury | to be fair it happened to me at least several times |
| 01:40:53 | lebellium | is there a way to power it off from the bootloader screen? Or am I obliged to enter walkman? |
| 01:41:56 | furrywolf | there's a lot of stuff on this chip. |
| 01:42:35 | pamaury | lebellium: no currently you have to go to OF |
| 01:42:56 | lebellium | ok |
| 01:43:07 | Mihail | pamaury: yes, but i2c2 quite fast even on amsv1 (see i2c2_transfer()) - we measure "wait for transfer" - at normal case it was 2000-3000 |
| 01:43:26 | pamaury | 2000 what ? |
| 01:43:28 | lebellium | I'll go to sleep now. I can't believe I didn't notice hold switch was ON .... |
| 01:43:55 | Mihail | int i = 10000; while (I2C2_DACNT != 0 && i−−); |
| 01:44:51 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
| 01:45:54 | pamaury | not too bad |
| 01:45:55 | | Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) |
| 01:46:07 | pamaury | so if you busy poll in IRQ it still does not work ? |
| 01:46:26 | pamaury | did you post the code somewhere ? |
| 01:48:10 | * | pamaury goes to bed |
| 01:48:27 | Mihail | http://knk.square7.ch/rb/i2c2.patch |
| 01:50:16 | furrywolf | is the interrupt-based code not working on v2 players due to a change in the SoC, or in external hardware? |
| 01:50:27 | pamaury | isn't that still locking in IRQ ? (I *guess* it will be okay since mutex_lock will always succeed but still) |
| 01:51:46 | Mihail | if we have lock in interrupt - player should freeze, right? but it still work after usb disconnect |
| 01:52:12 | pamaury | I just mean that you are still indirectly calling mutex_lock() is IRQ context |
| 01:52:15 | pamaury | that's completely undefined |
| 01:53:50 | pamaury | even if you know that the mutex is not locked |
| 01:54:08 | * | pamaury is tired and goes to bed |
| 01:56:00 | furrywolf | googling suggests both v1 and v2 are as3525... did the internals change much? |
| 01:58:42 | | Quit pamaury (Ping timeout: 255 seconds) |
| 01:59:15 | Mihail | not much but enough to have problems :) |
| 01:59:30 | furrywolf | what doesn't work with v2? |
| 02:00 |
| 02:01:13 | Mihail | all works but we don't know how do somethings |
| 02:01:24 | | Quit ZincAlloy (Quit: Leaving.) |
| 02:03:17 | furrywolf | hrmm. |
| 02:03:26 | furrywolf | how do you know how to do them in a non-interrupt fashion? lol |
| 02:06:40 | furrywolf | brb, time to fire up the generator. |
| 02:06:55 | Mihail | I looked at old code - early it was non-interrupt |
| 02:07:02 | jhMikeS | if you have to lock out interrupts when the voltage is low you're doing something wrong |
| 02:09:10 | jhMikeS | my v2 blows up quickly enough though. |
| 02:09:35 | Mihail | it not dependent from voltage value, it freeze as start often read and write to i2c2 |
| 02:09:45 | jhMikeS | one problem with blocking in set_cpu_frequency is that it should not be reentered |
| 02:10:06 | jhMikeS | it didn't before introducing the scaling stuff |
| 02:11:25 | Mihail | it freeze not only with scaling, sometime it freeze just at poweroff |
| 02:13:06 | furrywolf | why do problems in this code only affect usb/power stuff, and not break audio control, which seems to be off the same bus? |
| 02:14:40 | jhMikeS | there is an interesting thing with the interrupt driver with read/write pmu, if ints are disabled and you don't wait right after each request being queued (to run the loop that calls the routine), it freezes |
| 02:15:40 | jhMikeS | furrywolf: I was just messing with it and I'm a bit stumped though I never had issues without scaling enabled |
| 02:16:26 | Mihail | as before i2c2 used rarely |
| 02:17:33 | jhMikeS | I checked a bunch of stuff. |
| 02:18:08 | Mihail | furrywolf: try http://knk.square7.ch/rb/rockbox-fuzev1-usb-5.zip - I completely remove mutex as pamaury say |
| 02:18:24 | furrywolf | downloading. |
| 02:19:23 | jhMikeS | interrupts need to be on though, not masked during every transfer |
| 02:20:31 | jhMikeS | unless you like messing up recordings and such |
| 02:21:05 | Mihail | yes, but it most easy way for test |
| 02:21:46 | Mihail | later we should fix as pamaury say |
| 02:22:31 | Mihail | don't call it directly from interrup |
| 02:23:30 | furrywolf | no USB at all. does not respond to plugging, is not identified by pc. |
| 02:23:35 | jhMikeS | Mihail: I don't think the old code is "too complicated". It straighforward, though maybe not entirely correct in every way. |
| 02:23:56 | furrywolf | it doesn't freeze, but it doesn't do anything else, either, and the host doesn't detect it being plugged in. |
| 02:24:38 | Mihail | furrywolf: can you dump and upload logf again? |
| 02:25:44 | * | jhMikeS 's just going to patch his devices with the old code to work the way they should. |
| 02:26:51 | Mihail | jhMikeS: IMHO - old code overkill, as i2c2 quite fast. |
| 02:27:08 | furrywolf | http://fw.bushytails.net/tmp/logf.03.txt |
| 02:29:39 | | Quit skapazzo (Quit: Lost terminal) |
| 02:31:24 | Mihail | http://knk.square7.ch/rb/rockbox-fuzev1-usb-6.zip |
| 02:31:31 | jhMikeS | Mihail: I disagree 110% with that |
| 02:32:44 | jhMikeS | I don't really care though. I'll stick with what works and meets PCM deadlines without convoluted tick task fuckery |
| 02:33:08 | Mihail | did you have skip in PCM with new code? |
| 02:35:54 | jhMikeS | You will have them. The old driver was being run with interrupts masked to do two transfers in a row, so more like how it is now anyway. It was changed to queue them and block. |
| 02:39:12 | Mihail | I mean current rockbox. As I say - now I disable interrupts just for test |
| 02:41:24 | furrywolf | -6 is back to the previous behavior. freezes while usb cable is connected, unfreezes on removal, doesn't enumerate. |
| 02:41:45 | furrywolf | http://fw.bushytails.net/tmp/logf.04.txt |
| 02:43:03 | furrywolf | I dislike the busy loop polling to see if the transfer has finished. |
| 02:43:59 | *** | Saving seen data "./dancer.seen" |
| 02:45:25 | furrywolf | so you set the data count to how many bytes you want to read/write, and the chip clears it when done? have a link to the datasheet this is in? |
| 02:45:43 | Mihail | yes, but we in this case with i2c2 we polling very low time. Interrupt version even bit slower than non-interrupt. |
| 02:46:48 | furrywolf | what does ascodec_endofch do? |
| 02:47:25 | furrywolf | it looks like an isr, but INT_AUDIO does that... |
| 02:47:52 | furrywolf | I'm trying to familiarize myself with your codebase, as I have absolutely no idea how it all works. :) |
| 02:49:06 | Mihail | ascodec_endofch will return true if we have "end of charging" event |
| 02:49:26 | Mihail | http://knk.square7.ch/rb/rockbox-fuzev1-usb-7.zip |
| 02:49:29 | jhMikeS | furrywolf: yeah, you burn a lot of cycles. a bit faster isn't really that important as much as doing other stuff in the meantime. |
| 02:49:36 | furrywolf | why is it wrapped in disable_irq_save? |
| 02:50:32 | Mihail | to prevent corruption if irq try set it |
| 02:51:34 | furrywolf | then why isn't ascodec_chg_status? :) |
| 02:51:46 | furrywolf | I don't think it's related to the usb problem in the slightest, it just seems odd. |
| 02:52:27 | | Join fs-bluebot_ [0] (~fs-bluebo@xd9beed56.dyn.telefonica.de) |
| 02:54:39 | | Quit fs-bluebot (Ping timeout: 260 seconds) |
| 02:55:37 | | Quit bluebrother (Ping timeout: 240 seconds) |
| 02:57:39 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 02:58:02 | Bilgus | I found a 2s3525 that list revisions AS3525A/B/C (C22O22, C22O23) https://www.mediafire.com/?u3bj8b3b6ulybml |
| 03:00 |
| 03:04:37 | furrywolf | looks the same as the one I found, but with a stupidly annoying watermark. |
| 03:05:36 | Bilgus | two revisions newer |
| 03:05:51 | Mihail | furrywolf: try http://knk.square7.ch/rb/rockbox-fuzev1-usb-7.zip and I go to sleep |
| 03:08:46 | Bilgus | yours listed AS3525A C21O20 AS3525B C21O20 AS3525B C22O22 this one has C 22023 |
| 03:08:55 | furrywolf | downloading |
| 03:13:40 | furrywolf | typical non-working. (freezes on plug, flashes usb image on unplug) |
| 03:14:10 | furrywolf | http://fw.bushytails.net/tmp/logf.05.txt |
| 03:17:18 | Mihail | thanks! I'll try fix it tomorrow |
| 03:18:03 | | Quit Mihail (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 03:19:03 | furrywolf | cyas |
| 03:20:11 | furrywolf | does usb_insert_int() do something that doesn't work if interrupts are disabled? |
| 03:28:04 | | Quit jhMikeS (Ping timeout: 240 seconds) |
| 03:31:14 | furrywolf | hrmm! |
| 03:32:19 | furrywolf | the old code reads (and thus clears) IRQ_ENRD_1 and IRQ_ENRD_2 as well as IRQ_ENRD_0. is it getting stuck because one of these is getting triggered on usb connect, and not cleared? |
| 03:33:46 | furrywolf | I don't see anything in there that would get poked on usb changes, though. nevermind. |
| 03:34:43 | furrywolf | and I think I read the offsets wrong. What are the extra two bytes the old code is reading? |
| 03:38:44 | furrywolf | yeah, it is reading the other two. but I don't see any usb or charger bits in them. |
| 03:45:24 | furrywolf | other than the RTC interrupt |
| 03:46:32 | furrywolf | and the ADC... |
| 03:46:33 | furrywolf | hrmm |
| 03:57:38 | furrywolf | you're enabling "Generate irq for push-pull, active high, irq on rtc+adc change", but it doesn't look like you ever read or clear them. |
| 03:57:38 | furrywolf | that I can find, with my very limited understanding of the code. |
| 03:58:10 | furrywolf | blah, I don't want to deal with setting up a whole build environment for this. |
| 03:58:35 | furrywolf | anyone who knows the code better, and isn't asleep, want to comment on if this could in any way be related? |
| 03:59:59 | furrywolf | I guess it won't actually cause any problems... it just generates useless interrupts that don't do anything. |
| 04:00 |
| 04:01:05 | furrywolf | but my arm knowledge is quite limited. |
| 04:04:47 | furrywolf | also, my internet connection has gone from mostly useless to pretty much entirely useless, so I'm done with reading code tonight. |
| 04:19:35 | | Join _mt_ [0] (~MT@c-71-199-205-58.hsd1.tn.comcast.net) |
| 04:37:30 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
| 04:38:45 | | Quit JanC (Killed (wilhelm.freenode.net (Nickname regained by services))) |
| 04:38:45 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
| 04:44:02 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:17:46 | __builtin | alright, this is turning out to be more complicated than I expected |
| 05:18:10 | __builtin | SDL compiles to about a megabyte, doing nothing whatsoever |
| 05:18:29 | | Quit _mt_ (Ping timeout: 240 seconds) |
| 05:23:00 | | Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-46-53-167-211.telecom.by) |
| 05:23:44 | __builtin | whatever uses this abomination is definitely going in an overlay |
| 06:00 |
| 06:03:04 | | Quit gluytium (Read error: Connection reset by peer) |
| 06:18:01 | | Quit [7] (Ping timeout: 258 seconds) |
| 06:18:21 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:44:04 | *** | Saving seen data "./dancer.seen" |
| 06:47:37 | | Quit furrywolf (Ping timeout: 276 seconds) |
| 08:00 |
| 08:03:09 | | Join parchd [0] (~parchd@unaffiliated/parchd) |
| 08:44:08 | *** | Saving seen data "./dancer.seen" |
| 08:58:45 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 10:00 |
| 10:14:32 | | Quit [Saint] (Read error: Connection reset by peer) |
| 10:27:42 | | Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) |
| 10:31:13 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:36:28 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 10:44:12 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:03:57 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:4c3f:1dcf:322c:7455) |
| 11:18:28 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 12:00 |
| 12:04:28 | * | jhMikeS seems to have solved the issue with the interrupt I2C driver and voltage scaling. it's not the i2c driver. set_cpu_frequency was being called from a tick task in action.c (gui_unboost_callback). |
| 12:04:44 | * | jhMikeS kicks buschel in the nuts |
| 12:14:32 | pamaury | lol |
| 12:14:42 | pamaury | actually I was suspecting that |
| 12:20:29 | jhMikeS | my v2 scales voltage happily but I can't run it as low as 0.875 V or whatever ridiculously low setting |
| 12:21:11 | jhMikeS | pamaury: y u no follow through? *glares disapprovingly* ;) |
| 12:24:07 | pamaury | jhMikeS: I woke up this morning reading the logs and I suddently thought "what is someone does cpu scaling in IRQ ?" but didn't have time to investigate |
| 12:24:48 | pamaury | jhMikeS: actually I wonder if adding some extra checks in various places (like mutex_lock and cpu scaling) to panic if called from irq would be useful |
| 12:24:53 | pamaury | at least on debug builds |
| 12:29:24 | | Join dfkt [0] (~dfkt@unaffiliated/dfkt) |
| 12:29:25 | jhMikeS | I put in a panic in set_cpu_frequency if the processor mode wasn't 0x1f, then backtracked once it turned up a positive |
| 12:30:15 | jhMikeS | pamaury: probably. they aren't there because, well, you should do it right and we like lightweight functions but this one turns up all too often |
| 12:31:26 | jhMikeS | btw, I don't know what the minimum safe voltage is. I just set it to 1.0V and it's happy. I just know that the setting of 0.875V is not stable. |
| 12:31:48 | jhMikeS | I also turned on regulator ramping 42uS |
| 12:32:19 | jhMikeS | not sure if that matters though since it I was just tweaking stuff and left it there |
| 12:32:44 | pamaury | Mihail is the one who lowered voltage on the ams I think |
| 12:33:10 | jhMikeS | risky |
| 12:33:59 | jhMikeS | the high is 1.1875 and the low seems to be experimentally tweaked per target |
| 12:35:05 | jhMikeS | it's doubful it |
| 12:35:22 | jhMikeS | 's a good idea to do that. one chip might be fine really low while others not |
| 12:35:34 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 12:37:19 | pamaury | yeah 0.875 seems really low, I think we should use a safe setting |
| 12:37:28 | jhMikeS | amsv1 is running 1.20/1.10 |
| 12:37:39 | pamaury | voltage is not *that* important to justify running so close to the edge |
| 12:37:54 | pamaury | and that might have unpredictable consequences |
| 12:38:11 | jhMikeS | amsv1 is running 1.1875 and as low as 0.750 V ! |
| 12:38:44 | jhMikeS | at the point where it's dependent on a particular chip and maybe even temp is bad |
| 12:41:11 | pamaury | I suggest we revert the bad commit to go back to async ascodec read and maybe discuss with Mihail to revert some of those voltages |
| 12:42:13 | jhMikeS | somehow though this action.c boosting has to be redone. 38.4MHz UI is damned sluggish without the boosting |
| 12:44:15 | *** | No seen item changed, no save performed. |
| 12:45:07 | jhMikeS | pamaury: btw, yes, unpredicable and unstable. if I run 0.8750V, the player just sticks at a white screen on boot. it's too low if everything can't function. |
| 12:47:19 | pamaury | yeah clearly this should be reverted |
| 12:52:34 | pamaury | how does gui boost works ? |
| 12:53:21 | pamaury | I wonder if we should have some generic irq deferred work, so one can defer some work to a thread when irq is unsafe |
| 12:58:43 | jhMikeS | most CPUs take too long to set a new frequency to safely do it in an ISR since the function isn't reenterable and they'd have to be blocked. |
| 12:59:22 | pamaury | I know, that's why we need to do this work on a thread |
| 13:00 |
| 13:01:12 | jhMikeS | I don't think it needs a new thread. just do it on the action / button waits. if boosted, loop with a timeout instead of blocking. easy |
| 13:03:02 | jhMikeS | I have a patch that removed a separate thread for scrolling lines that does that and it works nicely, running it all on the main thread |
| 13:12:16 | | Join Senji_ [0] (~Senji@85.187.103.250) |
| 13:15:04 | | Quit Senji (Ping timeout: 240 seconds) |
| 13:20:04 | | Join Senji [0] (~Senji@85.187.103.250) |
| 13:23:08 | | Quit Senji_ (Ping timeout: 264 seconds) |
| 13:49:00 | | Join dys [0] (~dys@tmo-110-215.customers.d1-online.com) |
| 13:50:54 | dys | these Onkyo DAC-HA300 and TRAC HA-P90SD really scream "port rockbox to me" |
| 13:51:14 | dys | price is quite steep, but still cheaper than the iRivier jukeboxes when they came out |
| 13:53:49 | dys | s/TRAC/TEAC/ |
| 13:57:53 | | Join dys` [0] (~dys@tmo-113-64.customers.d1-online.com) |
| 13:58:09 | | Quit dys (Ping timeout: 240 seconds) |
| 14:00 |
| 14:03:21 | pamaury | At 600 bucks, that's very steep indeed |
| 14:06:41 | dys` | street prices appears to be around 350€ here |
| 14:07:10 | | Nick dys` is now known as dys (~dys@tmo-113-64.customers.d1-online.com) |
| 14:09:01 | pamaury | what soc is it based on ? |
| 14:09:16 | lebellium | I don't see the point of comparing them with the 2003-2004 iRiver jukeboxes |
| 14:09:38 | dys | there's a Rockchip RK3188 in there |
| 14:11:22 | pamaury | seriosuly, a quad core Cortex-A9 for a music player is crazy |
| 14:12:00 | dys | but easy to port to :-) |
| 14:13:09 | pamaury | depends on what it runs |
| 14:13:43 | pamaury | if it's linux or android kernel + libc then relatively easy. If it's android not really |
| 14:13:47 | dys | the firmware downloads they provide are about 1.5MB |
| 14:13:51 | Bilgus | pamaury: currently button_get() boosts if behind on the queue, Action.c the boost on any return from button_get() with a timeout |
| 14:13:53 | dys | i don't think android fits in there |
| 14:14:14 | dys | pamaury true, but still way better than messing with badly documented DSPs |
| 14:14:20 | Bilgus | sorry button.c is where the first boost happens |
| 14:15:45 | Bilgus | currently *in button.c -> button_get() boosts if behind on the queue, in Action.c it again boosts on any return from button_get() with a timeout |
| 14:16:01 | Bilgus | that reads better sorry just woke up |
| 14:17:02 | pamaury | jhMikeS says he has patches |
| 14:17:49 | dys | hmm, the firmware images have very low entropy, but contain legibile strings. maybe just some XORing going on or something |
| 14:18:06 | dys | s/contain/contain no/ |
| 14:19:40 | * | dys probably has his puzzle for the weekend |
| 14:20:54 | Bilgus | I wonder if this might be the problem someone was having with flac? NO, Opus a few months ago and I gave him FW with a long timeout that seemed to help |
| 14:24:03 | pamaury | dys: assuming it's XOR, loop for very repetitive patterns |
| 14:24:18 | Bilgus | jhMikeS, I think the reason 'someone' used a timeout is because /* most every action takes two rounds through get_action_worker, |
| 14:24:18 | Bilgus | * once for the keypress and once for the key release, |
| 14:24:18 | Bilgus | * actions with pre_button codes take even more to quote myself |
| 14:24:24 | jhMikeS | Bilgus: I have my fuzev2 running voltage scaling + interrupt-based I2C and it's been going for hours already |
| 14:25:41 | jhMikeS | First item in bucket list is fix button boosting |
| 14:25:51 | dys | legibile: please don't spoil my excuses for getting one :-) |
| 14:26:02 | dys | i mean lebellium |
| 14:26:12 | lebellium | aha |
| 14:28:38 | Bilgus | I think bringing all the button_gets back to button.c would be a good idea as well, currently its passing its queue around getting events from all over |
| 14:28:40 | | Join skapazzo [0] (~skapazzo@151.9.205.1) |
| 14:29:09 | | Quit Strife89 (Ping timeout: 240 seconds) |
| 14:30:20 | | Join gluytium [0] (U2FsdGVkX1@ma.sdf.org) |
| 14:31:10 | Bilgus | extern struct event_queue button_queue; |
| 14:31:15 | Bilgus | https://github.com/Rockbox/rockbox/search?utf8=✓&q=button_queue |
| 14:32:06 | | Join Mihail [0] (25d455c1@gateway/web/cgi-irc/kiwiirc.com/ip.37.212.85.193) |
| 14:32:11 | Mihail | jhMikeS: you have white screen on boot with rockbox from git (without any changes) on your player? |
| 14:32:19 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 14:32:27 | Mihail | I don't understand point to revert to interrupt version. Non interrupt version can work even in interrupts. For interrupt version we should rework scaling and make it more complicated. But what profit? You talk about possible skips in pcm, but I don't have it, even when send pcm without dma. Are you have real test case with pcm skips? |
| 14:32:28 | jhMikeS | no, I have it only when the voltage is too low, as is your setting |
| 14:32:55 | | Join _mt_ [0] (~MT@c-71-199-205-58.hsd1.tn.comcast.net) |
| 14:32:56 | jhMikeS | the interrupt version technically should too but were not doing that because scalings take too long |
| 14:33:24 | Mihail | don't understand - rockbox from git already have 0.85v |
| 14:33:36 | jhMikeS | it's not all about AMS. those functions are not reentrant and cannot have interrupts disabled the whole time |
| 14:34:07 | jhMikeS | If everything doesn't work at a certain voltage, it's too low. |
| 14:34:59 | jhMikeS | I didn't tweak around to find the absolute minimum, I just set it to 1.0V and I never get a white screen. 0.875 gives one every time. |
| 14:35:45 | Mihail | why you don't report early? |
| 14:37:41 | Mihail | which exactly player (name and variant) have? |
| 14:38:02 | | Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) |
| 14:38:55 | Mihail | what mean 'because scalings take too long' ? How long? Are you have skips? |
| 14:40:57 | jhMikeS | it's generally true for any target |
| 14:41:08 | jhMikeS | it takes too long to lock out interrupts |
| 14:41:25 | jhMikeS | PLL relocks can take milliseconds |
| 14:42:33 | Mihail | so why no one reports about skips in this case? |
| 14:42:35 | jhMikeS | that would destroy interrupt latency since IIS fifos generally have a few microseconds |
| 14:43:59 | jhMikeS | because this case is slightly less bad than it was in the first place |
| 14:44:16 | *** | Saving seen data "./dancer.seen" |
| 14:56:41 | Mihail | for AMSv2 DAC we have FIFO for 112 samples = 2.5 ms |
| 14:57:55 | * | pamaury thinks disabling interrupts during voltage scaling is a very bad idea |
| 14:58:28 | pamaury | it may be disabled during very specific parts of it only, the one that really need it (if any) |
| 14:59:11 | Mihail | why? If you want I can check how it long |
| 14:59:41 | Bilgus | So I gather the AS3525 is actually using defines from the AS3514? |
| 15:00 |
| 15:00:10 | Mihail | yes |
| 15:00:13 | pamaury | Bilgus: the AS3525 kinds of includes an AS3514 |
| 15:00:26 | pamaury | if my memory serves |
| 15:02:01 | pamaury | well disabling interrupts for a whole milliseconds is bad, that's asking for trouble |
| 15:02:12 | pamaury | especially when it is not necessary |
| 15:02:57 | pamaury | jhMikeS: which codes disables interrupt during frequency scaling ? is that specific to ams ? |
| 15:03:23 | | Quit Bilgus (Remote host closed the connection) |
| 15:04:15 | | Join paulk-collins [0] (~paulk@gagarine.paulk.fr) |
| 15:04:28 | | Join Bilgus [0] (~Bilgus@gateway/tor-sasl/bilgus) |
| 15:06:30 | jhMikeS | Mihail: it says 32 words for I2SIN |
| 15:07:47 | jhMikeS | I think the actual margin is like 4 words (when a DMA interrupt is asserted) |
| 15:08:26 | jhMikeS | it's the reserve at the time it requests more data that counts, that's your margin |
| 15:09:00 | jhMikeS | or, for recording, when it's about to top out and lose new audio data |
| 15:21:30 | Mihail | I don't hear skips at recording, but I try check it more careful. Also I'll measure how long scaling switching, so we can decide is we really need interrupt version or not |
| 15:38:46 | jhMikeS | we don't because we're not going to scale in an ISR |
| 15:41:16 | jhMikeS | besides, technically, the interrupt one was also intended to run in an ISR or with them disabled but needs to be tweaked for that after some changes |
| 15:49:39 | | Quit parchd (Ping timeout: 240 seconds) |
| 16:00 |
| 16:00:26 | | Join bertrik [0] (~bertrik@5354321C.cm-6-5a.dynamic.ziggo.nl) |
| 16:00:27 | | Quit bertrik (Changing host) |
| 16:00:27 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 16:05:24 | | Quit atsampson (Quit: new kernel time) |
| 16:09:20 | Mihail | jhMikeS: BTW calling unboost even from interrupt should not be problem for interrupt version as it set voltage after we exit from interrupt. Old code should have problems only if we boost from interrupt. Also at most case it not just feeze (as should be with low voltage and boosted frequency) but show strange panic. So I not sure is you have real |
| 16:09:20 | Mihail | solution to fix it. |
| 16:11:08 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 16:13:21 | | Part shdwprince ("Textual IRC Client: www.textualapp.com") |
| 16:13:56 | | Join Saratoga_ [0] (32b117cb@gateway/web/freenode/ip.50.177.23.203) |
| 16:14:34 | Saratoga_ | We tested voltages for a long while and then set a minimum with a margin above the lowest voltage reported to fail |
| 16:14:48 | Saratoga_ | As far as I know we haven't had much trouble since |
| 16:15:02 | Saratoga_ | Which player needed more voltage? |
| 16:16:19 | | Quit _mt_ (Ping timeout: 255 seconds) |
| 16:22:06 | | Quit dys (Ping timeout: 258 seconds) |
| 16:24:33 | Bilgus | IIRC fuzev2? |
| 16:26:15 | Saratoga_ | Should be raised for that player then |
| 16:26:48 | Saratoga_ | I don't think many people have it, so we may not have got a fair estimate of what voltages it needs |
| 16:27:51 | | Join johnb3 [0] (~johnb3@p5B296362.dip0.t-ipconnect.de) |
| 16:28:30 | johnb3 | I believe the report was for fuze *v1*. My two fuze v2 work just fine. |
| 16:28:33 | Saratoga_ | Oh as 3514 is the audio codec used on the Sansa e200v1 inside the pp5024, after pp was bought, Sandisk switched to ams for the whole CPU, and the same DAC and pmu is used in the as3525v1 |
| 16:29:01 | Saratoga_ | We didn't change the voltage on amsv1 |
| 16:29:21 | Saratoga_ | Or was that recently? |
| 16:34:44 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
| 16:36:08 | | Quit Saratoga_ (Ping timeout: 260 seconds) |
| 16:36:47 | Mihail | no, jhMikeS have problem on AMSv2. furrywolf have problem on fuze v1 but it not related to scaling. As you can see from logf his player abnormal call INT_AUDIO. Old code just hide this problem. |
| 16:44:17 | *** | Saving seen data "./dancer.seen" |
| 16:50:16 | | Join furrywolf [0] (~randyg@107.25.156.213) |
| 16:52:37 | furrywolf | Mihail: awake? |
| 17:00 |
| 17:00:26 | pamaury | It's unclear to me, jhMikeS found out that gui boosting can call voltage scaling in IRQ context, this is very unsafe, who knows what can result from this |
| 17:00:57 | Mihail | furrywolf: yes but bit busy |
| 17:02:12 | Mihail | pamaury: unboosting, why it should be unsafe? |
| 17:02:46 | furrywolf | Mihail: ok. I was looking through the source last night trying to spot functional differences between the old and new code. One difference is the old code reads (and clears) AS3514_IRQ_ENRD1 and AS3514_IRQ_ENRD2 as well as AS3514_IRQ_ENRD0, but the new code only clears AS3514_IRQ_ENRD0. You have ADC interrupts turned on, which set a bit in AS3514_IRQ_ENRD2, but it never gets cleared anywhere I can find. |
| 17:03:05 | furrywolf | I doubt this is related to the USB issue, but it's a bug anyway. :) |
| 17:03:08 | pamaury | as we explained before, on almost all targets, frequency and voltage scaling is a blocking operation, it may 1) take a long time 2) call some blocking op like mutex_lock, etc. |
| 17:03:19 | pamaury | gui boosting code has to be fixed |
| 17:03:38 | Mihail | furrywolf: where it clears AS3514_IRQ_ENRD0? |
| 17:03:47 | furrywolf | reading it clears it |
| 17:04:10 | furrywolf | at least from my understanding of the datasheet |
| 17:04:26 | Mihail | yes, it should |
| 17:04:30 | furrywolf | the old code reads all three, the new code only reads one |
| 17:05:48 | furrywolf | I can't see it causing the usb problem though. |
| 17:06:04 | furrywolf | unless something only does an adc read while charging |
| 17:06:51 | Mihail | ascodec_write(AS3514_IRQ_ENRD2, IRQ_PUSHPULL | IRQ_HIGHACTIVE); - ADC interrupts should be disabled |
| 17:07:38 | Mihail | just wrong comment string |
| 17:07:48 | | Join dys [0] (~dys@tmo-112-132.customers.d1-online.com) |
| 17:08:41 | furrywolf | d'oh, I must have been looking at the old version, and not noticing it changed since the comment didn't change. |
| 17:08:43 | * | furrywolf kicks self |
| 17:08:45 | | Join Strife89 [0] (~quassel@adsl-98-80-186-111.mcn.bellsouth.net) |
| 17:09:08 | furrywolf | never mind, then. :) |
| 17:09:48 | Bilgus | do you yipe when kicking self? |
| 17:11:00 | Bilgus | I'm suprised that the debounce time doesn't get set anywhere |
| 17:11:50 | furrywolf | I've just been trying to spot differences in what the new and old code actually does |
| 17:12:18 | Mihail | according to datasheet it should be 512ms be default. I try change it last night - no success. |
| 17:14:21 | Bilgus | yeah thats right since you write the whole register 0 it would be default |
| 17:20:28 | | Quit Senji (Ping timeout: 240 seconds) |
| 17:20:37 | | Part robertd1 |
| 17:22:31 | furrywolf | the new code seems to do an awful lot in an interrupt handler |
| 17:23:53 | | Join Senji [0] (~Senji@85.187.103.250) |
| 17:36:14 | | Join _mt_ [0] (~MT@2601:482:4402:7b60:219d:6a90:ed20:ac06) |
| 17:38:56 | chrisjj | pamaury, re your question about the BSoPowerOff on nowdt build, pressing power key does power-on the device. No reset required. As before, the state appears to be the regular power off state. |
| 17:40:18 | chrisjj | Hence my question at https://www.rockbox.org/irc/log-20170120#20:13:22 |
| 17:44:41 | chrisjj | Re your puzzlement of https://www.rockbox.org/irc/log-20170120#20:38:48 , arer you saying cd8b33327_nowdt build differs from lcd_fix build ONLY is having no lcd_fix patch and having the nowdt patch? |
| 17:45:23 | pamaury | I don't know, if I knew I would solve the problem obviously |
| 17:48:43 | pamaury | one thing I need to check is if frequency scaling parameters are valid for STMP3700, maybe the code sets a voltage or frequency that the imx233 can handle but not the stmp3700 |
| 17:50:03 | pamaury | I'll send you a new patch to try later, I'm busy right now |
| 17:59:43 | Bilgus | So given a list of mixed time values what is more intuitive eg. mins and sec 00:00s, 00:10s 00:20s .. 01:00min 01:30min or 00:00min 00:10min.. 01:00min |
| 18:00 |
| 18:01:41 | Bilgus | and I guess the third would be 00:00s 00:10s.. 01:00s |
| 18:01:43 | | Quit xorly (Ping timeout: 260 seconds) |
| 18:02:27 | furrywolf | does it need a label? |
| 18:03:50 | Mihail | pamaury: I got result: 2-3 us for changing frequency, 190 us for ascodec_read and 1.7 ms for ascodec_write_pmu. So I agree - better not call ascodec_write_pmu with disabled interrupts. ascodec_read should be ok in any case. |
| 18:03:59 | | Join Senji_ [0] (~Senji@85.187.103.250) |
| 18:04:18 | Bilgus | yes the ranges could be hh:mm:ss.mss or any sequential combination thereof |
| 18:05:14 | Bilgus | the most common are hh:mm, mm:ss, and ss.mss |
| 18:05:56 | pamaury | Mihail: sound ok, just disable interrupts when it's really small. That + jhMikeS's patch for not calling freq/volt scaling in interrupt should hopefully solve the problem |
| 18:06:25 | fs-bluebot_ | Build Server message: New build round started. Revision c6299b2, 255 builds, 12 clients. |
| 18:06:27 | | Quit Senji (Ping timeout: 245 seconds) |
| 18:07:40 | pamaury | Mihail: ^ this commit |
| 18:09:19 | Bilgus | I think max unit seems most intuitive |
| 18:10:21 | jhMikeS | oh bloody hell |
| 18:11:24 | jhMikeS | that typos gonna make the build table bleed (when !defined HAVE_ADJUSTABLE_CPU_FREQ) |
| 18:18:03 | | Quit _mt_ (Remote host closed the connection) |
| 18:19:47 | | Join Senji [0] (~Senji@85.187.103.250) |
| 18:21:56 | | Quit Senji_ (Ping timeout: 264 seconds) |
| 18:23:59 | fs-bluebot_ | Build Server message: Build round completed after 1053 seconds. |
| 18:24:00 | fs-bluebot_ | Build Server message: Revision c6299b2 result: 553 errors 133 warnings |
| 18:24:50 | jhMikeS | whee |
| 18:27:37 | | Quit prof_wolfff (Ping timeout: 240 seconds) |
| 18:28:06 | pamaury | lol |
| 18:28:20 | pamaury | well done |
| 18:29:44 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:30:14 | | Quit shdwprince (Client Quit) |
| 18:30:30 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:31:01 | | Quit shdwprince (Client Quit) |
| 18:31:21 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:31:49 | | Quit shdwprince (Client Quit) |
| 18:32:02 | fs-bluebot_ | Build Server message: New build round started. Revision da46457, 255 builds, 12 clients. |
| 18:32:08 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:32:37 | | Quit shdwprince (Client Quit) |
| 18:32:57 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:33:25 | | Quit shdwprince (Client Quit) |
| 18:33:46 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:33:48 | | Quit bertrik (Ping timeout: 260 seconds) |
| 18:34:13 | | Quit shdwprince (Client Quit) |
| 18:34:32 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:35:01 | | Quit shdwprince (Client Quit) |
| 18:35:21 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:35:49 | | Quit shdwprince (Client Quit) |
| 18:36:00 | Mihail | furrywolf: your player abnormally often call INT_AUDIO - I not sure is it software or hardware problem (it flood with event "end of charge"), I can't reproduce this behavior on others players. Try: http://knk.square7.ch/rb/rockbox-fuzev1-usb-8.zip |
| 18:36:10 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:36:37 | | Quit shdwprince (Client Quit) |
| 18:36:57 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:37:25 | | Quit shdwprince (Client Quit) |
| 18:37:46 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:38:13 | | Quit shdwprince (Client Quit) |
| 18:38:32 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:39:01 | | Quit shdwprince (Client Quit) |
| 18:39:22 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:39:49 | | Quit shdwprince (Client Quit) |
| 18:40:07 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 18:40:37 | | Quit shdwprince (Client Quit) |
| 18:40:53 | | Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) |
| 18:44:21 | *** | Saving seen data "./dancer.seen" |
| 18:45:54 | fs-bluebot_ | Build Server message: Build round completed after 832 seconds. |
| 18:45:55 | fs-bluebot_ | Build Server message: Revision da46457 result: All green |
| 18:49:36 | | Join bertrik [0] (~bertrik@5354321C.cm-6-5a.dynamic.ziggo.nl) |
| 18:49:37 | | Quit bertrik (Changing host) |
| 18:49:37 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 18:51:21 | | Quit furrywolf (Read error: Connection reset by peer) |
| 18:52:40 | | Quit Strife89 (Ping timeout: 256 seconds) |
| 19:00 |
| 19:08:31 | | Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) |
| 19:12:25 | | Quit Mihail (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 19:13:42 | | Join furrywolf [0] (~randyg@107.25.156.213) |
| 19:16:12 | __builtin | uhh, gevaerts: http://forums.rockbox.org/index.php/topic,51640.msg236192/boardseen.html#new |
| 19:16:58 | __builtin | something's up with the theme site |
| 19:36:16 | | Join saratoga_ [0] (47ae84f2@gateway/web/freenode/ip.71.174.132.242) |
| 19:36:52 | saratoga_ | would there be some easy way to have a function call for disabling GUI boost? its quite annoying in some plugs (e.g. test_*) since user input may change the frequency |
| 19:37:31 | saratoga_ | ideally i suppose it would be specific to the WPS/filebrowser screens, but a simple fix would be to let plugins disable it as needed |
| 19:42:32 | saratoga_ | https://www.rockbox.org/tracker/task/13098 |
| 19:46:51 | gevaerts | __builtin: that's a full week ago! |
| 19:47:29 | | Quit furrywolf (Read error: Connection reset by peer) |
| 19:47:45 | __builtin | oh... |
| 19:47:56 | * | __builtin never browses those sections of the forums |
| 19:48:14 | __builtin | so they're all "new" to me :P |
| 19:48:38 | gevaerts | You could also have verified the claim :) |
| 19:51:43 | __builtin | well, you did fix it, right? |
| 19:52:13 | saratoga_ | has anyone ever looked at all those random SSD mod errors people always report on the forums for the ipod 6g? |
| 19:52:48 | gevaerts | __builtin: it's been fixed, yes |
| 20:00 |
| 20:00:11 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 20:00:31 | | Join shdwprince [0] (~textual@31.129.102.143) |
| 20:12:05 | | Quit funman (Changing host) |
| 20:12:05 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 20:27:15 | fs-bluebot_ | Build Server message: New build round started. Revision 3e73866, 255 builds, 13 clients. |
| 20:44:24 | *** | Saving seen data "./dancer.seen" |
| 20:46:52 | fs-bluebot_ | Build Server message: Build round completed after 1177 seconds. |
| 20:46:52 | fs-bluebot_ | Build Server message: Revision 3e73866 result: 0 errors 283 warnings |
| 20:56:27 | fs-bluebot_ | Build Server message: New build round started. Revision 28bf763, 255 builds, 13 clients. |
| 21:00 |
| 21:10:46 | __builtin | alright, this is much better |
| 21:10:56 | | Quit saratoga_ (Quit: Page closed) |
| 21:11:01 | * | __builtin is working with SDL1.2 now |
| 21:11:36 | __builtin | it actually fits in the plugin buffer! :D |
| 21:16:33 | fs-bluebot_ | Build Server message: Build round completed after 1206 seconds. |
| 21:16:34 | fs-bluebot_ | Build Server message: Revision 28bf763 result: All green |
| 21:23:48 | | Quit saratoga (Quit: Page closed) |
| 21:29:37 | | Quit thomasjfox (Quit: Konversation terminated!) |
| 21:41:21 | | Quit bertrik (Ping timeout: 276 seconds) |
| 21:45:08 | | Join furrywolf [0] (~randyg@107.25.156.213) |
| 22:00 |
| 22:04:57 | | Quit michaelni (Ping timeout: 240 seconds) |
| 22:06:23 | | Join Strife89 [0] (~quassel@adsl-98-80-187-172.mcn.bellsouth.net) |
| 22:12:53 | Bilgus | I've decided the max unit needs to go after the time so 00:01min is 1 sec and 01:00min is 1 minute |
| 22:18:04 | | Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) |
| 22:22:32 | | Join athidhep [0] (~afoakf@unaffiliated/athidhep) |
| 22:32:15 | | Quit dfkt (Disconnected by services) |
| 22:32:29 | | Join dfkt [0] (~dfkt@unaffiliated/dfkt) |
| 22:44:26 | *** | Saving seen data "./dancer.seen" |
| 22:44:32 | dys | hmm, the firmware image doesn't appear to be scrambled at all |
| 22:44:36 | dys | http://www.intl.onkyo.com/support/firmware/dacha300_fw/DAC_HA300_b19.zip (3M) |
| 22:44:45 | dys | file entropy rendered as hilbert space-filling curve: http://ansel.ydns.eu/~andreas/DAC_HA300_b19.png (512k) |
| 22:44:53 | dys | arm-objdump -Mforce-thumb -b binary -m armv5 -D # yields some assembly that makes sense for the medium-entropy regions later in the file |
| 22:45:01 | dys | I still find it highly disturbing that there are no legible strings _at all_ in it |
| 22:45:13 | pamaury | there are no strings though, that's suspicious |
| 22:46:00 | pamaury | but to be fair, a 3MB firmware sounds suspicious too |
| 22:46:20 | dys | some disassembly snippets make sense, i.e. systematic register use, branches before illegal instructions, etc |
| 22:50:23 | pamaury | dys: had a very quickly look and this doesn't look like valid code to me |
| 22:52:41 | dys | ja, regarding the firmware size, it might be worth figuring out what kind of flash chip this: https://vk.com/wall-83451106_16 |
| 22:52:56 | dys | s/this/this is/ |
| 22:56:17 | dys | here's an assembly excerpt from 2/3 into the file http://paste.debian.net/909886/ |
| 22:57:25 | dys | ah, maybe the branches make sense since switching to thumb since there are so few bits for the target… |
| 22:58:28 | dys | hard to make these look outlandish |
| 22:59:39 | pamaury | dys: it's doesn't make sense though, this is thumb code and RK3188 has Cortex A9 which only runs in ARM mode |
| 22:59:52 | dys | pamaury: oooh, i see |
| 23:00 |
| 23:00:10 | pamaury | let me double check |
| 23:00:13 | pamaury | I might be wrong |
| 23:00:38 | pamaury | ah no I'm wrong, it has 16-bit and 32-bit thumb mode |
| 23:00:42 | pamaury | so I take it back |
| 23:01:47 | dys | ack, just saw that wikipedia advertises Thumb-2 support for the A9 |
| 23:03:16 | pamaury | yeah this definitely looks like valid Thumb code |
| 23:04:44 | pamaury | a bit surprising to be honest, why compile to Thumb on such a processor ? |
| 23:09:07 | | Quit snow_bckspc (Ping timeout: 252 seconds) |
| 23:13:55 | dys | i still couldn't find a data sheet for the flash chip, but if it turns out to be a small NOR one, it might make some sense to go thumb |
| 23:15:09 | dys | I've not found a pic of the back of the pcb yet (at least the adc must be on there) |
| 23:15:52 | dys | s/adc/dac/ |
| 23:16:04 | pamaury | why on earth would you put a small NOR chip and two big RAMs chip... |
| 23:16:31 | pamaury | but yeah I guess it makes sense if you put it that way. Doesn't quite explain where are the strings though |
| 23:16:59 | dys | might be worth getting one just for figuring out its mysteries :-) |
| 23:17:05 | | Quit shdwprince (Quit: Textual IRC Client: www.textualapp.com) |
| 23:22:53 | | Join snow_bckspc [0] (~snow_bcks@ganon.dot-server.net) |
| 23:32:11 | | Join Mihail [0] (25d44c81@gateway/web/cgi-irc/kiwiirc.com/ip.37.212.76.129) |
| 23:32:35 | Mihail | furrywolf: ping |
| 23:33:26 | | Join gbl08ma [0] (~gbl08ma@ec2-52-23-151-127.compute-1.amazonaws.com) |
| 23:34:25 | | Join Milardo [0] (1805b463@gateway/web/freenode/ip.24.5.180.99) |
| 23:35:08 | Milardo | Hi, has there been any progress on Sony NWZ-E350 series-rockbox? |
| 23:37:09 | furrywolf | pong! |
| 23:38:12 | Mihail | furrywolf: your player abnormally often call INT_AUDIO - I not sure is it software or hardware problem (it flood with event "end of charge"), I can't reproduce this behavior on others players. Try: http://knk.square7.ch/rb/rockbox-fuzev1-usb-8.zip |
| 23:38:18 | lebellium | Milardo: not yet |
| 23:39:18 | Milardo | according to the logs i actually asked this question nearly a year ago, just checking in to see if any work's been done on that series |
| 23:39:46 | lebellium | eh |
| 23:40:00 | lebellium | work on the linux-based SOny players started later |
| 23:40:45 | Milardo | whats that |
| 23:41:47 | lebellium | Your E350 appears to be linux-based |
| 23:42:15 | Milardo | ok |
| 23:42:16 | lebellium | so it won't be the same kind of port as the E360/E370/E380 already supported |
| 23:42:23 | Milardo | oh ok |
| 23:42:38 | Milardo | may i ask whose working on it? |
| 23:42:44 | lebellium | pamaury is working on it |
| 23:43:53 | Milardo | is he/she on the channel now? |
| 23:44:12 | lebellium | He is here as you can see in the users lists |
| 23:44:14 | __builtin | Milardo: yes, he is |
| 23:44:21 | lebellium | he might be busy or away though |
| 23:44:44 | Milardo | ok |
| 23:45:24 | Milardo | is there a progress log for those players yet? |
| 23:46:28 | lebellium | He got a working bootloader and Rockbox running on E460/E470/E580 and A10. But currently there is a sound issue |
| 23:47:07 | pamaury | hi, I've been very busy the past two week, the only progress "log" is g#1481 |
| 23:47:08 | fs-bluebot_ | Gerrit review #1481 at http://gerrit.rockbox.org/r/1481 : Initial commit for the Sony NWZ linux port and NWZ-E460 (WIP) by Amaury Pouly |
| 23:48:40 | Milardo | hi pamaury, do you think that there will be a rockbox build in the near future? |
| 23:49:06 | Milardo | for that series |
| 23:50:42 | pamaury | not until we sort the sound issue |
| 23:51:48 | Milardo | ok |
| 23:52:08 | Milardo | so did this work just start this year? |
| 23:52:20 | Milardo | says jan 8 2017 |
| 23:52:49 | pamaury | I did some ground work years ago, but recently (like a few monts ago) I resumed it |
| 23:52:58 | Milardo | ok |
| 23:53:10 | lebellium | don't look at the patch date |
| 23:53:13 | Milardo | which player do you have to work on(physically) |
| 23:53:17 | lebellium | there was another patch before :P |
| 23:53:25 | Milardo | i have the nwz e353 us version |
| 23:53:34 | Mihail | pamaury: is it software (alsa driver) or hardware sound isssue? |
| 23:54:32 | Milardo | ok |
| 23:55:17 | pamaury | I have E450, E460 and E580, lebellium has E580 and A15, wodz has E470, robertd has A860 on top of that. I think we have a good sampling of existing players |
| 23:55:47 | | Join kugel [0] (~kugel@ip5b42cab9.dynamic.kabel-deutschland.de) |
| 23:55:47 | | Quit kugel (Changing host) |
| 23:55:47 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 23:55:59 | pamaury | sometimes there is no sound at all, sometimes there is sound but it's completely distorted |
| 23:56:12 | pamaury | I think there is a problem with the codec configuration |
| 23:56:30 | Milardo | ok |
| 23:57:12 | Mihail | distorted in analog (clipping) or digital (skips)? |
| 23:57:28 | Milardo | well this is good news to hear, from last year it didn't seem a build was viable |
icon identifies that the person is a core developer (has commit access).