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

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

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

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2017-01-21

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:32Mihailfurrywolf: ping
00:23:04__builtinhmm, it seems like the easiest way to approach this port is by writing a SDL wrapper
00:23:36__builtinor 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:36furrywolfpong?
00:42:30Mihailhave time for debug?
00:42:36furrywolfa bit.
00:43:17Mihailinstall this build http://knk.square7.ch/rb/rockbox-fuzev1-usb-4.zip
00:43:32furrywolfwhile 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:10Mihailin rockbox-fuzev1-usb-3.zip I disable all interrupts for read and write, but we still have problem
00:45:54furrywolfhrmm, my internet connection is extra-sucky today... might be a few minutes.
00:48:28Mihailin 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:49furrywolfdownloaded
00:49:54 Quit [Saint] (Ping timeout: 258 seconds)
00:49:56furrywolfstuck at main menu, not enumerating.
00:50:07*furrywolf waits ten seconds
00:50:24 Join [Saint] [0] (~sinner@rockbox/staff/saint)
00:50:31Mihailtry again
00:50:58furrywolfstill on main menu, still attempting to enumerate and failing.
00:51:32furrywolfon unplug, briefly flashes the usb plug screen then returns to main menu
00:51:51Mihailmenu work?
00:52:48furrywolfafter unplugging, yes. it's always come back to life after the cable was unpluged, except for when in panics.
00:53:22furrywolfnothing is happening differently after 5-10 seconds compared to previous builds. linux keeps trying to enumerate it.
00:53:45Mihailreboot player and connect usb for few seconds (5-10) and then disconnect it. Then select system > debug > dump log file
00:54:21furrywolfI just dumped the log file, rebooting into bootloader usb now.
00:54:41Mihailupload .rockbox/logf.txt from player
00:56:34furrywolfI take it the log is limited in size? looks like the end of a log, not a whole log.
00:57:16furrywolfI can try plugging and unplugging quicker.
00:57:24Mihailok
00:57:57 Quit funman (Ping timeout: 240 seconds)
00:58:52 Join funman [0] (~fun@chui-pas.net)
01:00
01:00:27furrywolfdoes your client not have working dcc?
01:00:44Mihailno
01:00:51furrywolf... your client sucks. :P
01:01:03Mihailjust web
01:02:12furrywolfblah, my internet connection is really sucking today.
01:02:20furrywolfhttp://fw.bushytails.net/tmp/logf.txt
01:03:52furrywolfwhen 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:08furrywolfwith the dev build before, it would usually show the usb plug screen, then fail.
01:04:56furrywolfthese 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:17Mihaillogf show problem, I need a bit time to think
01:05:40furrywolfare you trying to use the interrupt-based older code, or the non-interrupt newer code?
01:06:19Mihailnon-interrupt
01:06:21furrywolfslightly related: does it charge in bootloader usb mode?
01:06:32Mihailyes
01:06:40furrywolfI like interrupt-driven asynchronous code better. :P
01:06:54 Quit xorly (Ping timeout: 255 seconds)
01:07:37Mihailhave many problems with it and no one can fix it
01:07:49furrywolfwhy can no one fix it?
01:07:54furrywolfalso, at least for me, it has no problems. lol
01:08:10Mihailwe don't have datasheet for i2c2
01:08:48furrywolfthat harms fixing the non-interrupt one too
01:09:35Mihailamsv2 players have bunch of problems with old code - freezeы and panics
01:10:10BilgusI'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:46Bilgusfurrywolf you said you had coding experience feel like doing some dev?
01:11:01furrywolfI generally consider asynchronous i/o with ISRs to be better, just because it's the right way of doing it.
01:11:29furrywolfBilgus: 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:56furrywolfthis started as "I'll just install rockbox, shouldn't take more than 5 minutes..."
01:13:23furrywolfalso, 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:25Mihailgeneral - 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:52Mihail* in general
01:15:34furrywolfit could be worse... you could be bit-banging a gpio pin. :)
01:17:38furrywolfthe old code has a number of error and sanity checks the new code lacks
01:17:49__builtinwoot! SDL compiles!!! (-ish)
01:17:56furrywolflike actually seeing if reads returned anything
01:18:18Mihailit not used
01:18:57__builtinthough I don't have any drivers that actually do anything :P
01:21:47__builtinand I also have a version of SDL from 2014 for some reason
01:22:16furrywolfhrmm, 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:17pamauryfurrywolf: iirc the hardware is not wired for otg
01:24:21pamauryso you can't use it
01:27:21pamauryMihail: you could try to use an intermediate solution use tick_task
01:27:24furrywolfmeh, 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:43furrywolfwhat datasheet was used to write the code? or is it based on dumping stock firmware and reverse-engineering?
01:29:55pamauryprobably reverse engineering
01:31:43pamauryMihail: 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:43pamauryvariable 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:51pamauryMihail: 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:04furrywolfwww.keil.com/dd/docs/datashts/ams/as3525_ds.pdf does seem to cover it a bit, around page 157
01:34:24pamauryfurrywolf: the whole point is that we don't know what changed in amsv2
01:34:37pamauryand the code was broken in amsv2
01:35:30Mihailok, thanks! I try it later. As I already say - furrywolf's case not related to mutex
01:37:57pamaurystill, mutex lock in irq context is no no, this needs to be fixed
01:38:28Mihailsure
01:38:39lebelliumpamaury: 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:41pamauryand jhMikeS says that if an IRQ takes too long it results in weird things
01:39:02pamaurylebellium: are you sure you don't have the hold key on ?
01:39:11lebelliumoh
01:39:12lebellium-_-
01:39:29pamauryI need to add code to provide some HOLD key indicator,
01:39:32lebelliumthat probably means I should have a sleep
01:39:45pamauryto be fair it happened to me at least several times
01:40:53lebelliumis there a way to power it off from the bootloader screen? Or am I obliged to enter walkman?
01:41:56furrywolfthere's a lot of stuff on this chip.
01:42:35pamaurylebellium: no currently you have to go to OF
01:42:56lebelliumok
01:43:07Mihailpamaury: 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:26pamaury2000 what ?
01:43:28lebelliumI'll go to sleep now. I can't believe I didn't notice hold switch was ON ....
01:43:55Mihailint i = 10000; while (I2C2_DACNT != 0 && i−−);
01:44:51 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507])
01:45:54pamaurynot too bad
01:45:55 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net)
01:46:07pamauryso if you busy poll in IRQ it still does not work ?
01:46:26pamaurydid you post the code somewhere ?
01:48:10*pamaury goes to bed
01:48:27Mihailhttp://knk.square7.ch/rb/i2c2.patch
01:50:16furrywolfis the interrupt-based code not working on v2 players due to a change in the SoC, or in external hardware?
01:50:27pamauryisn't that still locking in IRQ ? (I *guess* it will be okay since mutex_lock will always succeed but still)
01:51:46Mihailif we have lock in interrupt - player should freeze, right? but it still work after usb disconnect
01:52:12pamauryI just mean that you are still indirectly calling mutex_lock() is IRQ context
01:52:15pamaurythat's completely undefined
01:53:50pamauryeven if you know that the mutex is not locked
01:54:08*pamaury is tired and goes to bed
01:56:00furrywolfgoogling suggests both v1 and v2 are as3525... did the internals change much?
01:58:42 Quit pamaury (Ping timeout: 255 seconds)
01:59:15Mihailnot much but enough to have problems :)
01:59:30furrywolfwhat doesn't work with v2?
02:00
02:01:13Mihailall works but we don't know how do somethings
02:01:24 Quit ZincAlloy (Quit: Leaving.)
02:03:17furrywolfhrmm.
02:03:26furrywolfhow do you know how to do them in a non-interrupt fashion? lol
02:06:40furrywolfbrb, time to fire up the generator.
02:06:55MihailI looked at old code - early it was non-interrupt
02:07:02jhMikeSif you have to lock out interrupts when the voltage is low you're doing something wrong
02:09:10jhMikeSmy v2 blows up quickly enough though.
02:09:35Mihailit not dependent from voltage value, it freeze as start often read and write to i2c2
02:09:45jhMikeSone problem with blocking in set_cpu_frequency is that it should not be reentered
02:10:06jhMikeSit didn't before introducing the scaling stuff
02:11:25Mihailit freeze not only with scaling, sometime it freeze just at poweroff
02:13:06furrywolfwhy 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:40jhMikeSthere 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:40jhMikeSfurrywolf: I was just messing with it and I'm a bit stumped though I never had issues without scaling enabled
02:16:26Mihailas before i2c2 used rarely
02:17:33jhMikeSI checked a bunch of stuff.
02:18:08Mihailfurrywolf: try http://knk.square7.ch/rb/rockbox-fuzev1-usb-5.zip - I completely remove mutex as pamaury say
02:18:24furrywolfdownloading.
02:19:23jhMikeSinterrupts need to be on though, not masked during every transfer
02:20:31jhMikeSunless you like messing up recordings and such
02:21:05Mihailyes, but it most easy way for test
02:21:46Mihaillater we should fix as pamaury say
02:22:31Mihaildon't call it directly from interrup
02:23:30furrywolfno USB at all. does not respond to plugging, is not identified by pc.
02:23:35jhMikeSMihail: I don't think the old code is "too complicated". It straighforward, though maybe not entirely correct in every way.
02:23:56furrywolfit doesn't freeze, but it doesn't do anything else, either, and the host doesn't detect it being plugged in.
02:24:38Mihailfurrywolf: 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:51MihailjhMikeS: IMHO - old code overkill, as i2c2 quite fast.
02:27:08furrywolfhttp://fw.bushytails.net/tmp/logf.03.txt
02:29:39 Quit skapazzo (Quit: Lost terminal)
02:31:24Mihailhttp://knk.square7.ch/rb/rockbox-fuzev1-usb-6.zip
02:31:31jhMikeSMihail: I disagree 110% with that
02:32:44jhMikeSI don't really care though. I'll stick with what works and meets PCM deadlines without convoluted tick task fuckery
02:33:08Mihaildid you have skip in PCM with new code?
02:35:54jhMikeSYou 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:12MihailI mean current rockbox. As I say - now I disable interrupts just for test
02:41:24furrywolf-6 is back to the previous behavior. freezes while usb cable is connected, unfreezes on removal, doesn't enumerate.
02:41:45furrywolfhttp://fw.bushytails.net/tmp/logf.04.txt
02:43:03furrywolfI dislike the busy loop polling to see if the transfer has finished.
02:43:59***Saving seen data "./dancer.seen"
02:45:25furrywolfso 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:43Mihailyes, but we in this case with i2c2 we polling very low time. Interrupt version even bit slower than non-interrupt.
02:46:48furrywolfwhat does ascodec_endofch do?
02:47:25furrywolfit looks like an isr, but INT_AUDIO does that...
02:47:52furrywolfI'm trying to familiarize myself with your codebase, as I have absolutely no idea how it all works. :)
02:49:06Mihailascodec_endofch will return true if we have "end of charging" event
02:49:26Mihailhttp://knk.square7.ch/rb/rockbox-fuzev1-usb-7.zip
02:49:29jhMikeSfurrywolf: 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:36furrywolfwhy is it wrapped in disable_irq_save?
02:50:32Mihailto prevent corruption if irq try set it
02:51:34furrywolfthen why isn't ascodec_chg_status? :)
02:51:46furrywolfI 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:02BilgusI found a 2s3525 that list revisions AS3525A/B/C (C22O22, C22O23) https://www.mediafire.com/?u3bj8b3b6ulybml
03:00
03:04:37furrywolflooks the same as the one I found, but with a stupidly annoying watermark.
03:05:36Bilgustwo revisions newer
03:05:51Mihailfurrywolf: try http://knk.square7.ch/rb/rockbox-fuzev1-usb-7.zip and I go to sleep
03:08:46Bilgusyours listed AS3525A C21O20 AS3525B C21O20 AS3525B C22O22 this one has C 22023
03:08:55furrywolfdownloading
03:13:40furrywolftypical non-working. (freezes on plug, flashes usb image on unplug)
03:14:10furrywolfhttp://fw.bushytails.net/tmp/logf.05.txt
03:17:18Mihailthanks! I'll try fix it tomorrow
03:18:03 Quit Mihail (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
03:19:03furrywolfcyas
03:20:11furrywolfdoes usb_insert_int() do something that doesn't work if interrupts are disabled?
03:28:04 Quit jhMikeS (Ping timeout: 240 seconds)
03:31:14furrywolfhrmm!
03:32:19furrywolfthe 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:46furrywolfI don't see anything in there that would get poked on usb changes, though. nevermind.
03:34:43furrywolfand I think I read the offsets wrong. What are the extra two bytes the old code is reading?
03:38:44furrywolfyeah, it is reading the other two. but I don't see any usb or charger bits in them.
03:45:24furrywolfother than the RTC interrupt
03:46:32furrywolfand the ADC...
03:46:33furrywolfhrmm
03:57:38furrywolfyou'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:38furrywolfthat I can find, with my very limited understanding of the code.
03:58:10furrywolfblah, I don't want to deal with setting up a whole build environment for this.
03:58:35furrywolfanyone who knows the code better, and isn't asleep, want to comment on if this could in any way be related?
03:59:59furrywolfI guess it won't actually cause any problems... it just generates useless interrupts that don't do anything.
04:00
04:01:05furrywolfbut my arm knowledge is quite limited.
04:04:47furrywolfalso, 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__builtinalright, this is turning out to be more complicated than I expected
05:18:10__builtinSDL 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__builtinwhatever 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:32pamaurylol
12:14:42pamauryactually I was suspecting that
12:20:29jhMikeSmy v2 scales voltage happily but I can't run it as low as 0.875 V or whatever ridiculously low setting
12:21:11jhMikeSpamaury: y u no follow through? *glares disapprovingly* ;)
12:24:07pamauryjhMikeS: 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:48pamauryjhMikeS: 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:53pamauryat least on debug builds
12:29:24 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
12:29:25jhMikeSI 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:15jhMikeSpamaury: 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:26jhMikeSbtw, 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:48jhMikeSI also turned on regulator ramping 42uS
12:32:19jhMikeSnot sure if that matters though since it I was just tweaking stuff and left it there
12:32:44pamauryMihail is the one who lowered voltage on the ams I think
12:33:10jhMikeSrisky
12:33:59jhMikeSthe high is 1.1875 and the low seems to be experimentally tweaked per target
12:35:05jhMikeSit's doubful it
12:35:22jhMikeS'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:19pamauryyeah 0.875 seems really low, I think we should use a safe setting
12:37:28jhMikeSamsv1 is running 1.20/1.10
12:37:39pamauryvoltage is not *that* important to justify running so close to the edge
12:37:54pamauryand that might have unpredictable consequences
12:38:11jhMikeSamsv1 is running 1.1875 and as low as 0.750 V !
12:38:44jhMikeSat the point where it's dependent on a particular chip and maybe even temp is bad
12:41:11pamauryI 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:13jhMikeSsomehow 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:07jhMikeSpamaury: 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:19pamauryyeah clearly this should be reverted
12:52:34pamauryhow does gui boost works ?
12:53:21pamauryI 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:43jhMikeSmost 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:22pamauryI know, that's why we need to do this work on a thread
13:00
13:01:12jhMikeSI 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:02jhMikeSI 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:54dysthese Onkyo DAC-HA300 and TRAC HA-P90SD really scream "port rockbox to me"
13:51:14dysprice is quite steep, but still cheaper than the iRivier jukeboxes when they came out
13:53:49dyss/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:21pamauryAt 600 bucks, that's very steep indeed
14:06:41dys`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:01pamaurywhat soc is it based on ?
14:09:16lebelliumI don't see the point of comparing them with the 2003-2004 iRiver jukeboxes
14:09:38dysthere's a Rockchip RK3188 in there
14:11:22pamauryseriosuly, a quad core Cortex-A9 for a music player is crazy
14:12:00dysbut easy to port to :-)
14:13:09pamaurydepends on what it runs
14:13:43pamauryif it's linux or android kernel + libc then relatively easy. If it's android not really
14:13:47dysthe firmware downloads they provide are about 1.5MB
14:13:51Bilguspamaury: currently button_get() boosts if behind on the queue, Action.c the boost on any return from button_get() with a timeout
14:13:53dysi don't think android fits in there
14:14:14dyspamaury true, but still way better than messing with badly documented DSPs
14:14:20Bilgussorry button.c is where the first boost happens
14:15:45Bilguscurrently *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:01Bilgusthat reads better sorry just woke up
14:17:02pamauryjhMikeS says he has patches
14:17:49dyshmm, the firmware images have very low entropy, but contain legibile strings. maybe just some XORing going on or something
14:18:06dyss/contain/contain no/
14:19:40*dys probably has his puzzle for the weekend
14:20:54BilgusI 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:03pamaurydys: assuming it's XOR, loop for very repetitive patterns
14:24:18BilgusjhMikeS, I think the reason 'someone' used a timeout is because /* most every action takes two rounds through get_action_worker,
14:24:18Bilgus * once for the keypress and once for the key release,
14:24:18Bilgus * actions with pre_button codes take even more to quote myself
14:24:24jhMikeSBilgus: I have my fuzev2 running voltage scaling + interrupt-based I2C and it's been going for hours already
14:25:41jhMikeSFirst item in bucket list is fix button boosting
14:25:51dyslegibile: please don't spoil my excuses for getting one :-)
14:26:02dysi mean lebellium
14:26:12lebelliumaha
14:28:38BilgusI 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:10Bilgusextern struct event_queue button_queue;
14:31:15Bilgushttps://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:11MihailjhMikeS: 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:27MihailI 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:28jhMikeSno, 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:56jhMikeSthe interrupt version technically should too but were not doing that because scalings take too long
14:33:24Mihaildon't understand - rockbox from git already have 0.85v
14:33:36jhMikeSit's not all about AMS. those functions are not reentrant and cannot have interrupts disabled the whole time
14:34:07jhMikeSIf everything doesn't work at a certain voltage, it's too low.
14:34:59jhMikeSI 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:45Mihailwhy you don't report early?
14:37:41Mihailwhich exactly player (name and variant) have?
14:38:02 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net)
14:38:55Mihailwhat mean 'because scalings take too long' ? How long? Are you have skips?
14:40:57jhMikeSit's generally true for any target
14:41:08jhMikeSit takes too long to lock out interrupts
14:41:25jhMikeSPLL relocks can take milliseconds
14:42:33Mihailso why no one reports about skips in this case?
14:42:35jhMikeSthat would destroy interrupt latency since IIS fifos generally have a few microseconds
14:43:59jhMikeSbecause this case is slightly less bad than it was in the first place
14:44:16***Saving seen data "./dancer.seen"
14:56:41Mihailfor 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:28pamauryit may be disabled during very specific parts of it only, the one that really need it (if any)
14:59:11Mihailwhy? If you want I can check how it long
14:59:41BilgusSo I gather the AS3525 is actually using defines from the AS3514?
15:00
15:00:10Mihailyes
15:00:13pamauryBilgus: the AS3525 kinds of includes an AS3514
15:00:26pamauryif my memory serves
15:02:01pamaurywell disabling interrupts for a whole milliseconds is bad, that's asking for trouble
15:02:12pamauryespecially when it is not necessary
15:02:57pamauryjhMikeS: 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:30jhMikeSMihail: it says 32 words for I2SIN
15:07:47jhMikeSI think the actual margin is like 4 words (when a DMA interrupt is asserted)
15:08:26jhMikeSit's the reserve at the time it requests more data that counts, that's your margin
15:09:00jhMikeSor, for recording, when it's about to top out and lose new audio data
15:21:30MihailI 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:46jhMikeSwe don't because we're not going to scale in an ISR
15:41:16jhMikeSbesides, 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:20MihailjhMikeS: 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:20Mihailsolution 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:34Saratoga_We tested voltages for a long while and then set a minimum with a margin above the lowest voltage reported to fail
16:14:48Saratoga_As far as I know we haven't had much trouble since
16:15:02Saratoga_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:33BilgusIIRC fuzev2?
16:26:15Saratoga_Should be raised for that player then
16:26:48Saratoga_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:30johnb3I believe the report was for fuze *v1*. My two fuze v2 work just fine.
16:28:33Saratoga_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:01Saratoga_We didn't change the voltage on amsv1
16:29:21Saratoga_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:47Mihailno, 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:37furrywolfMihail: awake?
17:00
17:00:26pamauryIt'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:57Mihailfurrywolf: yes but bit busy
17:02:12Mihailpamaury: unboosting, why it should be unsafe?
17:02:46furrywolfMihail: 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:05furrywolfI doubt this is related to the USB issue, but it's a bug anyway. :)
17:03:08pamauryas 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:19pamaurygui boosting code has to be fixed
17:03:38Mihailfurrywolf: where it clears AS3514_IRQ_ENRD0?
17:03:47furrywolfreading it clears it
17:04:10furrywolfat least from my understanding of the datasheet
17:04:26Mihailyes, it should
17:04:30furrywolfthe old code reads all three, the new code only reads one
17:05:48furrywolfI can't see it causing the usb problem though.
17:06:04furrywolfunless something only does an adc read while charging
17:06:51Mihailascodec_write(AS3514_IRQ_ENRD2, IRQ_PUSHPULL | IRQ_HIGHACTIVE); - ADC interrupts should be disabled
17:07:38Mihailjust wrong comment string
17:07:48 Join dys [0] (~dys@tmo-112-132.customers.d1-online.com)
17:08:41furrywolfd'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:08furrywolfnever mind, then. :)
17:09:48Bilgusdo you yipe when kicking self?
17:11:00BilgusI'm suprised that the debounce time doesn't get set anywhere
17:11:50furrywolfI've just been trying to spot differences in what the new and old code actually does
17:12:18Mihailaccording to datasheet it should be 512ms be default. I try change it last night - no success.
17:14:21Bilgusyeah 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:31furrywolfthe 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:56chrisjjpamaury, 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:18chrisjjHence my question at https://www.rockbox.org/irc/log-20170120#20:13:22
17:44:41chrisjjRe 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:23pamauryI don't know, if I knew I would solve the problem obviously
17:48:43pamauryone 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:03pamauryI'll send you a new patch to try later, I'm busy right now
17:59:43BilgusSo 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:41Bilgusand I guess the third would be 00:00s 00:10s.. 01:00s
18:01:43 Quit xorly (Ping timeout: 260 seconds)
18:02:27furrywolfdoes it need a label?
18:03:50Mihailpamaury: 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:18Bilgusyes the ranges could be hh:mm:ss.mss or any sequential combination thereof
18:05:14Bilgusthe most common are hh:mm, mm:ss, and ss.mss
18:05:56pamauryMihail: 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:25fs-bluebot_Build Server message: 3New build round started. Revision c6299b2, 255 builds, 12 clients.
18:06:27 Quit Senji (Ping timeout: 245 seconds)
18:07:40pamauryMihail: ^ this commit
18:09:19BilgusI think max unit seems most intuitive
18:10:21jhMikeSoh bloody hell
18:11:24jhMikeSthat 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:59fs-bluebot_Build Server message: 3Build round completed after 1053 seconds.
18:24:00fs-bluebot_Build Server message: 3Revision c6299b2 result: 553 errors 133 warnings
18:24:50jhMikeSwhee
18:27:37 Quit prof_wolfff (Ping timeout: 240 seconds)
18:28:06pamaurylol
18:28:20pamaurywell 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:02fs-bluebot_Build Server message: 3New 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:00Mihailfurrywolf: 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:54fs-bluebot_Build Server message: 3Build round completed after 832 seconds.
18:45:55fs-bluebot_Build Server message: 3Revision 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__builtinuhh, gevaerts: http://forums.rockbox.org/index.php/topic,51640.msg236192/boardseen.html#new
19:16:58__builtinsomething's up with the theme site
19:36:16 Join saratoga_ [0] (47ae84f2@gateway/web/freenode/ip.71.174.132.242)
19:36:52saratoga_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:31saratoga_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:32saratoga_https://www.rockbox.org/tracker/task/13098
19:46:51gevaerts__builtin: that's a full week ago!
19:47:29 Quit furrywolf (Read error: Connection reset by peer)
19:47:45__builtinoh...
19:47:56*__builtin never browses those sections of the forums
19:48:14__builtinso they're all "new" to me :P
19:48:38gevaertsYou could also have verified the claim :)
19:51:43__builtinwell, you did fix it, right?
19:52:13saratoga_has anyone ever looked at all those random SSD mod errors people always report on the forums for the ipod 6g?
19:52:48gevaerts__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:15fs-bluebot_Build Server message: 3New build round started. Revision 3e73866, 255 builds, 13 clients.
20:44:24***Saving seen data "./dancer.seen"
20:46:52fs-bluebot_Build Server message: 3Build round completed after 1177 seconds.
20:46:52fs-bluebot_Build Server message: 3Revision 3e73866 result: 0 errors 283 warnings
20:56:27fs-bluebot_Build Server message: 3New build round started. Revision 28bf763, 255 builds, 13 clients.
21:00
21:10:46__builtinalright, 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__builtinit actually fits in the plugin buffer! :D
21:16:33fs-bluebot_Build Server message: 3Build round completed after 1206 seconds.
21:16:34fs-bluebot_Build Server message: 3Revision 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:53BilgusI'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:32dyshmm, the firmware image doesn't appear to be scrambled at all
22:44:36dyshttp://www.intl.onkyo.com/support/firmware/dacha300_fw/DAC_HA300_b19.zip (3M)
22:44:45dysfile entropy rendered as hilbert space-filling curve: http://ansel.ydns.eu/~andreas/DAC_HA300_b19.png (512k)
22:44:53dysarm-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:01dysI still find it highly disturbing that there are no legible strings _at all_ in it
22:45:13pamaurythere are no strings though, that's suspicious
22:46:00pamaurybut to be fair, a 3MB firmware sounds suspicious too
22:46:20dyssome disassembly snippets make sense, i.e. systematic register use, branches before illegal instructions, etc
22:50:23pamaurydys: had a very quickly look and this doesn't look like valid code to me
22:52:41dysja, regarding the firmware size, it might be worth figuring out what kind of flash chip this: https://vk.com/wall-83451106_16
22:52:56dyss/this/this is/
22:56:17dyshere's an assembly excerpt from 2/3 into the file http://paste.debian.net/909886/
22:57:25dysah, maybe the branches make sense since switching to thumb since there are so few bits for the target…
22:58:28dyshard to make these look outlandish
22:59:39pamaurydys: it's doesn't make sense though, this is thumb code and RK3188 has Cortex A9 which only runs in ARM mode
22:59:52dyspamaury: oooh, i see
23:00
23:00:10pamaurylet me double check
23:00:13pamauryI might be wrong
23:00:38pamauryah no I'm wrong, it has 16-bit and 32-bit thumb mode
23:00:42pamauryso I take it back
23:01:47dysack, just saw that wikipedia advertises Thumb-2 support for the A9
23:03:16pamauryyeah this definitely looks like valid Thumb code
23:04:44pamaurya 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:55dysi 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:09dysI've not found a pic of the back of the pcb yet (at least the adc must be on there)
23:15:52dyss/adc/dac/
23:16:04pamaurywhy on earth would you put a small NOR chip and two big RAMs chip...
23:16:31pamaurybut yeah I guess it makes sense if you put it that way. Doesn't quite explain where are the strings though
23:16:59dysmight 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:35Mihailfurrywolf: 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:08MilardoHi, has there been any progress on Sony NWZ-E350 series-rockbox?
23:37:09furrywolfpong!
23:38:12Mihailfurrywolf: 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:18lebelliumMilardo: not yet
23:39:18Milardoaccording 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:46lebelliumeh
23:40:00lebelliumwork on the linux-based SOny players started later
23:40:45Milardowhats that
23:41:47lebelliumYour E350 appears to be linux-based
23:42:15Milardook
23:42:16lebelliumso it won't be the same kind of port as the E360/E370/E380 already supported
23:42:23Milardooh ok
23:42:38Milardomay i ask whose working on it?
23:42:44lebelliumpamaury is working on it
23:43:53Milardois he/she on the channel now?
23:44:12lebelliumHe is here as you can see in the users lists
23:44:14__builtinMilardo: yes, he is
23:44:21lebelliumhe might be busy or away though
23:44:44Milardook
23:45:24Milardois there a progress log for those players yet?
23:46:28lebelliumHe got a working bootloader and Rockbox running on E460/E470/E580 and A10. But currently there is a sound issue
23:47:07pamauryhi, I've been very busy the past two week, the only progress "log" is g#1481
23:47:08fs-bluebot_3Gerrit review #1481 at http://gerrit.rockbox.org/r/1481 : 3Initial commit for the Sony NWZ linux port and NWZ-E460 (WIP) by Amaury Pouly
23:48:40Milardohi pamaury, do you think that there will be a rockbox build in the near future?
23:49:06Milardofor that series
23:50:42pamaurynot until we sort the sound issue
23:51:48Milardook
23:52:08Milardoso did this work just start this year?
23:52:20Milardosays jan 8 2017
23:52:49pamauryI did some ground work years ago, but recently (like a few monts ago) I resumed it
23:52:58Milardook
23:53:10lebelliumdon't look at the patch date
23:53:13Milardowhich player do you have to work on(physically)
23:53:17lebelliumthere was another patch before :P
23:53:25Milardoi have the nwz e353 us version
23:53:34Mihailpamaury: is it software (alsa driver) or hardware sound isssue?
23:54:32Milardook
23:55:17pamauryI 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:59pamaurysometimes there is no sound at all, sometimes there is sound but it's completely distorted
23:56:12pamauryI think there is a problem with the codec configuration
23:56:30Milardook
23:57:12Mihaildistorted in analog (clipping) or digital (skips)?
23:57:28Milardowell this is good news to hear, from last year it didn't seem a build was viable

Previous day | Next day