| 00:03:04 | speachy | dconrad: check out g#3312 |
| 00:03:06 | fs-bluebot | Gerrit review #3312 at https://gerrit.rockbox.org/r/c/rockbox/+/3312 : erosq: Switch to 32-bit PCM output, and do volume scaling in driver by Solomon Peachy |
| 00:04:19 | dconrad | holy cow that was a fast change |
| 00:04:55 | speachy | I'm thinking it probably makes the most sense to just use the master volume to control both line and hp output due to the overdrive issue |
| 00:05:56 | | Quit kakaka (Remote host closed the connection) |
| 00:05:57 | speachy | since we probably need to cap headphone output too because it's surely overdriving the HP amp in this thing |
| 00:06:30 | | Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) |
| 00:06:45 | *** | Saving seen data "./dancer.seen" |
| 00:07:22 | dconrad | so I should be able to pull and build this? |
| 00:07:35 | speachy | it's not committed yet so you'd need to cherry-pick it out of gerrit |
| 00:07:58 | dconrad | sure |
| 00:08:12 | speachy | I should measure the x3 and x3ii's line out to see what they're like |
| 00:09:53 | speachy | not tonight though |
| 00:15:37 | speachy | let me know how it works for you |
| 00:15:40 | speachy | and now, bed. |
| 00:15:49 | dconrad | haha, thanks for the quick turnaround |
| 00:16:05 | dconrad | ...still building... |
| 00:20:55 | dconrad | I'll have to play with it more tomorrow but holy cow, I think it might be completely fixed? |
| 00:23:36 | dconrad | the numerical scaling is different/off, but the same track at very quiet volumes doesn't have any glitching at all? |
| 00:23:50 | dconrad | (dB number displayed) |
| 00:28:12 | | Quit chris_s (Quit: Ping timeout (120 seconds)) |
| 00:39:42 | | Quit dconrad () |
| 01:00 |
| 01:44:35 | | Quit Rower (Read error: Connection reset by peer) |
| 02:00 |
| 02:06:46 | *** | Saving seen data "./dancer.seen" |
| 02:30:20 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 03:00 |
| 03:40:00 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:793b:87ec:38af:f44a) |
| 04:00 |
| 04:02:17 | | Quit ChanServ (*.net *.split) |
| 04:02:18 | | Quit tomato (*.net *.split) |
| 04:02:18 | | Quit atsampson (*.net *.split) |
| 04:02:18 | | Quit Acou_Bass (*.net *.split) |
| 04:02:18 | | Quit hook54321 (*.net *.split) |
| 04:02:18 | | Quit JanC (*.net *.split) |
| 04:02:18 | | Quit emacsomancer (*.net *.split) |
| 04:02:18 | | Quit speachy (*.net *.split) |
| 04:02:18 | | Quit ZincAlloy (*.net *.split) |
| 04:02:19 | | Quit St3ak (*.net *.split) |
| 04:02:19 | | Quit plum (*.net *.split) |
| 04:02:19 | | Quit bluebrother (*.net *.split) |
| 04:02:19 | | Quit Rower (*.net *.split) |
| 04:02:19 | | Quit CR0W (*.net *.split) |
| 04:02:19 | | Quit amiconn (*.net *.split) |
| 04:02:19 | | Quit bzed (*.net *.split) |
| 04:02:20 | | Quit RafiX (*.net *.split) |
| 04:02:21 | | Quit ccf-100 (*.net *.split) |
| 04:02:21 | | Quit kakaka (*.net *.split) |
| 04:02:22 | | Quit mud (*.net *.split) |
| 04:02:22 | | Quit toruvinn (*.net *.split) |
| 04:02:22 | | Quit rasher (*.net *.split) |
| 04:02:23 | | Quit vup (*.net *.split) |
| 04:02:23 | | Quit edhelas (*.net *.split) |
| 04:02:24 | | Quit blbro[m] (*.net *.split) |
| 04:02:24 | | Quit michaelni (*.net *.split) |
| 04:02:24 | | Quit shrizza (*.net *.split) |
| 04:02:24 | | Quit asaba (*.net *.split) |
| 04:02:25 | | Quit fs-bluebot (*.net *.split) |
| 04:02:25 | | Quit ps-auxw (*.net *.split) |
| 04:02:25 | | Quit bertrik (*.net *.split) |
| 04:02:25 | | Quit xcin (*.net *.split) |
| 04:02:25 | | Quit WakiMiko (*.net *.split) |
| 04:02:25 | | Quit Slasheri (*.net *.split) |
| 04:02:26 | | Quit danielp3344 (*.net *.split) |
| 04:02:26 | | Quit ecs (*.net *.split) |
| 04:02:26 | | Quit TorC (*.net *.split) |
| 04:02:26 | | Quit funman (*.net *.split) |
| 04:02:26 | | Quit advcomp2019 (*.net *.split) |
| 04:02:27 | | Quit rogeliodh (*.net *.split) |
| 04:02:27 | | Quit Huntereb (*.net *.split) |
| 04:02:27 | | Quit tchan (*.net *.split) |
| 04:02:27 | | Quit spectrumanalyst (*.net *.split) |
| 04:02:27 | | Quit gsora (*.net *.split) |
| 04:02:27 | | Quit ParkerR (*.net *.split) |
| 04:02:27 | | Quit benedikt93 (*.net *.split) |
| 04:02:27 | | Quit bleb (*.net *.split) |
| 04:02:27 | | Quit prg3 (*.net *.split) |
| 04:02:27 | | Quit paulk-leonov (*.net *.split) |
| 04:02:27 | | Quit Tsesarevich (*.net *.split) |
| 04:02:28 | | Quit XDjackieXD (*.net *.split) |
| 04:02:28 | | Quit rudi_s (*.net *.split) |
| 04:02:28 | | Quit jschwart (*.net *.split) |
| 04:02:28 | | Quit skrzyp (*.net *.split) |
| 04:02:28 | | Quit galaxy_knuckles (*.net *.split) |
| 04:02:28 | | Quit SovietShaman_ (*.net *.split) |
| 04:02:28 | | Quit ender| (*.net *.split) |
| 04:02:28 | | Quit igitoor (*.net *.split) |
| 04:02:29 | | Quit berber (*.net *.split) |
| 04:02:29 | | Quit Ckat (*.net *.split) |
| 04:02:29 | | Quit daswf852 (*.net *.split) |
| 04:02:29 | | Quit bonfire (*.net *.split) |
| 04:02:29 | | Quit jdarnley (*.net *.split) |
| 04:02:29 | | Quit yosafbridge (*.net *.split) |
| 04:02:29 | | Quit beencubed (*.net *.split) |
| 04:02:29 | | Quit _bilgus (*.net *.split) |
| 04:02:29 | | Quit olspookishmagus (*.net *.split) |
| 04:02:29 | | Quit user890104 (*.net *.split) |
| 04:02:29 | | Quit braewoods (*.net *.split) |
| 04:02:30 | | Quit ArsenArsen (*.net *.split) |
| 04:02:30 | | Quit GeekShadow (*.net *.split) |
| 04:02:30 | | Quit Galois (*.net *.split) |
| 04:02:30 | | Quit __builtin (*.net *.split) |
| 04:02:30 | | Quit mikroflops (*.net *.split) |
| 04:02:30 | | Quit blucifer22 (*.net *.split) |
| 04:02:31 | | Quit pixelma (*.net *.split) |
| 04:02:31 | | Quit Soap_ (*.net *.split) |
| 04:02:31 | | Quit SammysHP (*.net *.split) |
| 04:02:31 | | Quit Natch (*.net *.split) |
| 04:02:31 | | Quit copper (*.net *.split) |
| 04:02:31 | | Quit Xeha (*.net *.split) |
| 04:02:31 | | Quit aevin (*.net *.split) |
| 04:02:31 | | Quit kugel (*.net *.split) |
| 04:02:31 | | Quit kadoban (*.net *.split) |
| 04:02:31 | | Quit APLU (*.net *.split) |
| 04:02:31 | | Quit klock (*.net *.split) |
| 04:02:32 | | Quit lemon_jesus (*.net *.split) |
| 04:02:32 | | Quit trfl (*.net *.split) |
| 04:02:32 | | Quit f1refly (*.net *.split) |
| 04:02:32 | | Quit Barlow (*.net *.split) |
| 04:02:32 | | Quit Moarc (*.net *.split) |
| 04:02:32 | | Quit Strife89 (*.net *.split) |
| 04:02:32 | | Quit Topy44 (*.net *.split) |
| 04:02:32 | | Quit Romster (*.net *.split) |
| 04:02:32 | | Quit gevaerts (*.net *.split) |
| 04:02:32 | | Quit kirvesAxe (*.net *.split) |
| 04:02:33 | | Quit ufdm (*.net *.split) |
| 04:02:33 | | Quit fauweh (*.net *.split) |
| 04:02:33 | | Quit jerwin (*.net *.split) |
| 04:02:33 | | Quit alexbobp (*.net *.split) |
| 04:02:33 | | Quit KalBot (*.net *.split) |
| 04:06:49 | *** | Saving seen data "./dancer.seen" |
| 04:06:57 | | Join trfl [0] (~ed@static.59.110.40.188.clients.your-server.de) |
| 04:06:57 | | Join lemon_jesus [0] (~lemon_jes@208.59.79.137) |
| 04:06:57 | | Join klock [0] (~freeklock@unaffiliated/klock) |
| 04:06:57 | | Join APLU [0] (~mulx@2a03:7220:8081:2900::1) |
| 04:06:57 | | Join speachy [0] (~speachy@209.2.65.77) |
| 04:06:57 | | Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) |
| 04:06:57 | | Join hook54321 [0] (sid149355@gateway/web/irccloud.com/x-yowuzbrikpmmzknf) |
| 04:06:57 | | Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 04:06:57 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 04:06:57 | | Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato) |
| 04:06:57 | | Join blucifer22 [0] (~quassel@204.48.30.120) |
| 04:06:57 | | Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) |
| 04:06:57 | | Join __builtin [0] (~quassel@rockbox/developer/builtin) |
| 04:06:57 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 04:06:57 | | Join ChanServ [0] (ChanServ@services.) |
| 04:06:57 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 04:06:57 | | Join CR0W [0] (~narf@unaffiliated/em64t) |
| 04:06:57 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 04:06:57 | | Join bzed [0] (~bzed@shell.bzed.at) |
| 04:06:57 | | Join vup [0] (~~~~@46.101.193.235) |
| 04:06:57 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:793b:87ec:38af:f44a) |
| 04:06:57 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
| 04:06:57 | | Join plum [0] (~plum@unaffiliated/plum) |
| 04:06:57 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 04:06:57 | | Join asaba [0] (~asaba@103.113.159.184) |
| 04:06:57 | | Join fs-bluebot [0] (~fs-bluebo@55d48c6a.access.ecotel.net) |
| 04:06:57 | | Join ps-auxw [0] (~arneb@p548d5577.dip0.t-ipconnect.de) |
| 04:06:57 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 04:06:57 | | Join xcin [0] (~x@159.203.132.140) |
| 04:06:57 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 04:06:57 | | Join fauweh [0] (~root@ithaqua.unzane.com) |
| 04:06:57 | | Join KalBot [0] (~matrixirc@connolly.tech) |
| 04:06:57 | | Join jerwin [0] (~flippy-fl@unaffiliated/flippy) |
| 04:06:57 | | Join alexbobp [0] (~alex@meowface.org) |
| 04:06:57 | | Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257) |
| 04:06:57 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 04:06:57 | | Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net) |
| 04:06:57 | | Join f1refly [0] (~f1refly@dynamic-077-008-223-115.77.8.pool.telefonica.de) |
| 04:06:57 | | Join Barlow [0] (~barlow@unaffiliated/barlow) |
| 04:06:57 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 04:06:57 | | Join Strife89 [0] (~quassel@adsl-74-250-151-186.ags.bellsouth.net) |
| 04:06:57 | | Join Topy44 [0] (YwgdD0qBv9@bellatrix.uberspace.de) |
| 04:06:57 | | Join Romster [0] (~romster@unaffiliated/romster) |
| 04:06:57 | | Join gevaerts [0] (~fg@rockbox/developer/gevaerts) |
| 04:06:57 | | Join kirvesAxe [0] (kirvesaxe@aulis.sange.fi) |
| 04:06:57 | | Join Slasheri [0] (~miipekk@rockbox/developer/Slasheri) |
| 04:06:57 | Mode | "#rockbox +o ChanServ " by weber.freenode.net |
| 04:06:57 | | Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) |
| 04:06:57 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 04:06:57 | | Join TorC [0] (~Tor@fsf/member/TorC) |
| 04:06:57 | | Join ecs [0] (esawady@sourcehut/interns/ecs) |
| 04:06:57 | | Join GeekShadow [0] (~antoine@unaffiliated/geekshadow) |
| 04:06:57 | | Join ArsenArsen [0] (~Arsen@managarm/dev/ArsenArsen) |
| 04:06:57 | | Join braewoods [0] (~braewoods@learnprogramming/staff/braewoods) |
| 04:06:57 | | Join user890104 [0] (~Venci@freemyipod.org) |
| 04:06:57 | | Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 04:06:57 | | Join _bilgus [0] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com) |
| 04:06:57 | | Join beencubed [0] (~beencubed@209.131.238.248) |
| 04:06:57 | | Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
| 04:06:57 | | Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 04:06:57 | | Join bonfire [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net) |
| 04:06:57 | | Join daswf852 [0] (~daswf852@unaffiliated/dwf) |
| 04:06:57 | | Join RafiX [0] (rafix@junkcc.net) |
| 04:06:57 | | Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) |
| 04:06:57 | | Join igitoor [0] (igitur@unaffiliated/contempt) |
| 04:06:57 | | Join SovietShaman_ [0] (quassel@024-217-039-226.res.spectrum.com) |
| 04:06:57 | | Join galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549) |
| 04:06:57 | | Join skrzyp [0] (~skrzyp@skrzyp.net) |
| 04:06:57 | | Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567) |
| 04:06:57 | | Join rudi_s [0] (~simon@bmi.informatik.uni-erlangen.de) |
| 04:06:57 | | Join XDjackieXD [0] (~jackie@irc.chaosfield.at) |
| 04:06:57 | | Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr) |
| 04:06:57 | | Join prg3 [0] (~prg@deadcodersociety/prg318) |
| 04:06:57 | | Join bleb [0] (~cm@unaffiliated/bleb) |
| 04:06:57 | | Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) |
| 04:06:57 | | Join ParkerR [0] (~ParkerR@unaffiliated/parkerr) |
| 04:06:57 | | Join gsora [0] (~gsora@unaffiliated/gsora) |
| 04:06:57 | | Join spectrumanalyst [0] (~admin@198.46.152.45) |
| 04:06:57 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 04:06:57 | | Join Huntereb [0] (~Huntereb@142-196-011-243.res.spectrum.com) |
| 04:06:57 | | Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) |
| 04:06:57 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
| 04:06:57 | | Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) |
| 04:06:57 | | Join berber [0] (~berber@v2202101107577140883.nicesrv.de) |
| 04:07:06 | | Quit dweeber (Max SendQ exceeded) |
| 04:07:06 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 04:07:06 | | Join toruvinn [0] (~toruvinn@77-255-90-179.adsl.inetia.pl) |
| 04:07:07 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 04:07:34 | | Join dweeber [0] (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net) |
| 04:08:16 | | Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) |
| 04:08:57 | | Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx) |
| 04:09:19 | | Quit paulk-leonov (Ping timeout: 250 seconds) |
| 04:09:43 | | Quit hook54321 (Ping timeout: 260 seconds) |
| 04:09:49 | | Quit Tsesarevich (Excess Flood) |
| 04:10:10 | | Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx) |
| 04:12:22 | | Join hook54321 [0] (sid149355@gateway/web/irccloud.com/session) |
| 04:20:05 | | Quit hook54321 (Changing host) |
| 04:20:05 | | Join hook54321 [0] (sid149355@gateway/web/irccloud.com/x-mxonnkmjnhseenax) |
| 04:23:40 | | Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr) |
| 04:49:08 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 04:49:08 | | Join Soap_ [0] (~Soap@rockbox/staff/soap) |
| 04:49:08 | | Join SammysHP [0] (~SammysHP@faol.sammyshp.de) |
| 04:49:08 | | Join Natch [0] (~natch@c-b471e255.014-297-73746f25.bbcust.telenor.se) |
| 04:49:08 | | Join copper [0] (~copper@unaffiliated/copper) |
| 04:49:08 | | Join Xeha [0] (~Xeha@unaffiliated/xeha) |
| 04:49:08 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
| 04:49:08 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 04:56:41 | | Join ccf-100 [0] (ccf-100mat@gateway/shell/matrix.org/x-iomocwibultsdvpp) |
| 04:56:41 | | Join mud [0] (kadobanmat@gateway/shell/matrix.org/x-zgbmebmtuhdubutk) |
| 04:56:41 | | Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-mvlxwbiddmyjmqzj) |
| 04:56:41 | | Join kadoban [0] (kadobanemp@gateway/shell/matrix.org/x-zbemkkpthikwihsa) |
| 04:56:48 | | Join blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-tlbkackcydjojpba) |
| 05:00 |
| 05:03:29 | | Quit igitoor (Ping timeout: 250 seconds) |
| 05:04:33 | | Join igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648) |
| 05:15:21 | | Quit igitoor (Changing host) |
| 05:15:21 | | Join igitoor [0] (igitur@unaffiliated/contempt) |
| 05:38:58 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 06:00 |
| 06:06:51 | *** | Saving seen data "./dancer.seen" |
| 06:17:07 | | Quit JanC (Ping timeout: 260 seconds) |
| 06:19:09 | speachy | dconrad: I didn't check to see if the unity line out is the same. but yeah, the scale is different. due to how the math works, anything under -43 is effecively muted so there's no point in claiming to go lower than that. |
| 06:21:15 | speachy | the other targets that use this 16->32-bit skullduggery have some control of analog gain so it's possible to be more nuanced but not here. |
| 06:23:17 | | Quit tomato (Read error: Connection reset by peer) |
| 06:23:54 | braewoods | speachy: what xduoos do we support? i just saw an X2 for sale. |
| 06:24:40 | braewoods | https://www.newegg.com/xduoo-x2-mp3-player/p/N82E16855455001 |
| 06:24:43 | braewoods | newegg no less |
| 06:25:10 | speachy | braewoods: check the web page? :D |
| 06:25:27 | speachy | (but x3, x3ii, x20) |
| 06:25:38 | braewoods | oh |
| 06:25:40 | braewoods | not supported |
| 06:25:42 | braewoods | ofc |
| 06:25:59 | braewoods | https://forums.rockbox.org/index.php?topic=50788.0 |
| 06:26:09 | speachy | x2 is a cut-down chip along the lines of the atj212x x2s is about the same. |
| 06:26:14 | speachy | (presumably) |
| 06:26:27 | speachy | d3 is a rknano-D |
| 06:27:40 | braewoods | it's kinda weird seeing as how PP was so high end compared to a lot of modern players |
| 06:27:55 | braewoods | don't even compare in terms of the average ram PP had |
| 06:28:24 | braewoods | too bad rockbox doesn't have a company like gl.inet like openwrt does |
| 06:28:32 | speachy | the funny thing is that the newer SoCs have faster CPUs in them, plus real HW acceleration blocks. where they fall down is system RAM. |
| 06:28:40 | braewoods | gl.inet sells hardware with their own openwrt derivatives |
| 06:29:44 | braewoods | speachy: probably is, an armv7 or newer would probably smoke a PP |
| 06:30:13 | braewoods | which makes me wonder... |
| 06:30:53 | braewoods | would be funny to find a SoC that is just perfect for Rockbox porting |
| 06:31:18 | braewoods | that we could make custom hardware out of |
| 06:31:31 | braewoods | but eh |
| 06:32:16 | | Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato) |
| 06:32:35 | speachy | dconrad: also discovered that how I have the scrollwheel set up it doesn't prevent the disply from going to sleep. oops. |
| 06:33:25 | speachy | the ingenic X1000/X2000 series, and the allwinner V3/V3s are about perfect. (also the FC series, but there's not much point in those unless the price is _very_ right...) |
| 06:33:44 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 06:34:08 | speachy | the V3/FC series also have full upstream uboot/linux support and complete [enough] docs. |
| 06:34:41 | braewoods | and more cores than we can shake a stick at |
| 06:35:01 | braewoods | we're kinda SMP ready due to PP |
| 06:35:03 | speachy | braewoods: they aren't v7s, they're Cortex-M, but clocked high enough to make a real difference. |
| 06:35:05 | braewoods | though how much I can't say |
| 06:35:18 | braewoods | oh, the allwinners lack a FPU? |
| 06:35:33 | speachy | braewoods: I was talking about the cut-down stuff in more modern players |
| 06:35:36 | braewoods | i thought most modern ARM chips had them now |
| 06:35:38 | braewoods | Oh |
| 06:35:40 | speachy | the allwinners are a proper armv7, yes |
| 06:35:57 | speachy | the FC series is an armv6 (ARM11 core IIRC) |
| 06:35:59 | braewoods | we don't need armv8 |
| 06:36:22 | braewoods | if we did have a cpu though we'd have access to 64 bit |
| 06:36:35 | speachy | eh, we dont' need 64-bit but all else being equal the same code on armv8 vs v7 should run faster. |
| 06:37:02 | speachy | (not unlike how x86_64 is faaster than ol' x86) |
| 06:37:12 | braewoods | mostly due to more registers |
| 06:37:29 | speachy | yep. |
| 06:37:30 | braewoods | there were ABIs that were a hybrid of the old and new ABIs |
| 06:37:35 | braewoods | x32 i believe |
| 06:37:48 | braewoods | stayed 32 bit in some ways but leveraged the new 64 bit ISA |
| 06:38:05 | speachy | x32 wasn't "better enough" to warrantt requiring a third binary format |
| 06:38:18 | braewoods | good riddance |
| 06:43:40 | fs-bluebot | Build Server message: New build round started. Revision 1e2a9a651c, 298 builds, 10 clients. |
| 06:46:13 | braewoods | huh. so that's why AMD skybridge never came to be. |
| 06:46:44 | braewoods | i wonder if they'll ever revisit that idea. being able to switch to ARM cores during idle would probably help energy usage. |
| 06:54:42 | fs-bluebot | Build Server message: Build round completed after 662 seconds. |
| 06:54:45 | fs-bluebot | Build Server message: Revision 1e2a9a651c result: All green |
| 06:54:54 | fs-bluebot | Build Server message: New build round started. Revision 54b8e9131c, 298 builds, 10 clients. |
| 06:58:28 | braewoods | speachy: looking for more xduoo x3? i just saw a good condition one up for auction |
| 06:58:40 | braewoods | https://www.ebay.com/itm/XDUOO-X3-DIGITAL-AUDIO-PLAYER/184746255083 |
| 06:58:44 | speachy | I have my beater and a NIB spare |
| 06:58:55 | braewoods | ah. ok. |
| 06:59:10 | speachy | but someone else should buy it so they can enjoy its awesomeness |
| 06:59:22 | braewoods | lol |
| 06:59:49 | braewoods | the gigabeat F felt pretty good when I handled it earlier |
| 06:59:59 | braewoods | it's mostly aluminum shell. |
| 07:00 |
| 07:00:09 | braewoods | may be old but it's well built |
| 07:02:39 | braewoods | well that was a productive night |
| 07:02:53 | braewoods | i spent some time updating ungoogled chromium scripts for submitting stuff to OBS |
| 07:06:41 | braewoods | speachy: what do you use for editting source code these days? |
| 07:06:54 | speachy | emacs |
| 07:06:59 | braewoods | i've grown fond of sublime text myself due to some features i'd never seen in an editor before |
| 07:07:24 | braewoods | sessions mainly, it even remembers stuff i haven't officially saved yet |
| 07:07:31 | braewoods | i was surprised |
| 07:07:37 | braewoods | it has saved me from losing work a few times |
| 07:09:53 | braewoods | i hate vim with a passion, only use it when i have to |
| 07:10:09 | braewoods | it seems far too easy to accidently do the wrong thing and find your whole line replaced with garbage |
| 07:10:12 | braewoods | or something |
| 07:10:33 | speachy | the only vi command one really needs to know is how to quit without saving. :) |
| 07:13:26 | fs-bluebot | Build Server message: Build round completed after 1112 seconds. |
| 07:13:29 | fs-bluebot | Build Server message: Revision 54b8e9131c result: All green |
| 07:13:30 | fs-bluebot | Build Server message: New build round started. Revision 9847f9c85e, 298 builds, 10 clients. |
| 07:28:27 | fs-bluebot | Build Server message: Build round completed after 897 seconds. |
| 07:28:29 | fs-bluebot | Build Server message: Revision 9847f9c85e result: All green |
| 07:28:31 | fs-bluebot | Build Server message: New build round started. Revision 10facef17b, 298 builds, 10 clients. |
| 07:44:57 | fs-bluebot | Build Server message: Build round completed after 987 seconds. |
| 07:44:59 | fs-bluebot | Build Server message: Revision 10facef17b result: All green |
| 07:56:19 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 08:00 |
| 08:04:57 | braewoods | _bilgus: ok so i got a functional hdd6330 now i can test with... |
| 08:05:16 | braewoods | so far i've observed GPIO changes when i connect to the dock |
| 08:05:18 | braewoods | or disconnect |
| 08:05:29 | braewoods | so must be some kind of indication of presence of the dock |
| 08:05:41 | braewoods | but nothing for remote input |
| 08:05:51 | braewoods | hm. |
| 08:06:34 | braewoods | i also noted how the schematic shows that the "cradle remote" pin is connected directly to one of the chip pins labeled as PWM |
| 08:06:43 | braewoods | the other PWM is for the LCD backlight |
| 08:06:52 | braewoods | which i looked into... it's an output pin for sure |
| 08:06:53 | *** | Saving seen data "./dancer.seen" |
| 08:07:01 | braewoods | the code does some stuff with a variable |
| 08:07:21 | braewoods | i'm going to assume that the remote stuff i'm looking for isn't too different from how the backlight is controled |
| 08:07:30 | braewoods | since it's right next to the other PWM pin |
| 08:07:59 | braewoods | question is, how do I enable input on it so I can try to test my theory? |
| 08:09:07 | braewoods | the LCD code uses outl to write to some address I believe. |
| 08:09:36 | braewoods | also does something with GPO32_ENABLE and GPO32_VAL |
| 08:10:15 | braewoods | _bilgus: there's only so many bits i can set so, any advice of what these do? |
| 08:13:08 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-6c7b-cc55-d26f-2c7f.res6.spectrum.com) |
| 08:21:46 | _bilgus | being that the pimns are right next door it should pretty straight forward to enable that GPIO as well |
| 08:22:06 | _bilgus | that PWN signal is also ->out according to the schematic |
| 08:22:50 | _bilgus | my assumption is that they are using the pwm and reading resistor ladders on the acd |
| 08:22:54 | _bilgus | ADC |
| 08:24:51 | _bilgus | doesn't means thats true though −− being that they have an ADC probably not BUT they could even be doing a cap charge on the pwm the buttons bleed it off or even something capacitive but I doubt it |
| 08:25:53 | _bilgus | ALSO IIRC it appears they just piggy back off the inbuilt buttons so in theory you should be able to see them on the adc pin when you press buttons on the player |
| 08:27:12 | _bilgus | if you have a DVM digital being key it should have high enough impedance that you should be able to probe the line |
| 08:31:16 | _bilgus | I think that adc is always enabled so on the pin going back to it I'd just try placing a few resistors like this as a volatage divider between PWM and ground don't choose anything lower than about 1k |
| 08:32:24 | _bilgus | so its going to go like this −−-PWM −−-v^v^v^−−−−-ADC−−−−v^v^v^−−−−−−-GND |
| 08:32:39 | _bilgus | -v^v^v- is a resistor :p |
| 08:33:14 | braewoods | _bilgus: well there's only 2 connected ADC lines. |
| 08:33:26 | braewoods | one is for the battery. the other is a mystery but appears to connect to the FM chip. |
| 08:33:27 | _bilgus | so the one between PWM and ADC would be varied by buttons and would have a fixed one in parallel to hold the line |
| 08:33:58 | _bilgus | it looks to me that the buttons on the player and the player buttons share that one |
| 08:34:12 | _bilgus | but its also been like a week since I looked at it |
| 08:34:24 | braewoods | this isn't the H10, the hdd6330 |
| 08:34:39 | braewoods | i'm just trying to figure out where it's connected in software right now |
| 08:34:45 | braewoods | i thought PWM was an input here |
| 08:34:52 | braewoods | since remote would be an input |
| 08:34:56 | _bilgus | oh you are doing this blind |
| 08:35:01 | braewoods | currently yes |
| 08:35:14 | braewoods | i just thought you might have some ideas |
| 08:35:23 | braewoods | i don't have the fancy hardware probes |
| 08:35:32 | _bilgus | you don't need them |
| 08:35:47 | braewoods | this seems simple enough that i shouldn't need them |
| 08:35:50 | _bilgus | a DMM DVM will do fine unless its high speed stuff |
| 08:36:15 | _bilgus | then even that high impedance can change the circuit |
| 08:36:47 | _bilgus | so first I'd probably see if you can find the gpio triggering for the inbuilt buttons |
| 08:37:01 | braewoods | that's probably easy |
| 08:37:15 | braewoods | i also noted there's an interrupt line for the remote |
| 08:37:20 | braewoods | but probably irrelevant for now |
| 08:37:20 | _bilgus | they would probably do a similar scheme for the remote unless they were constrained |
| 08:37:47 | _bilgus | if you have an interrupt then i'd assume a shift register holding button states |
| 08:37:58 | braewoods | it appears PWM1 and the AIN1 are connected |
| 08:38:13 | braewoods | is that what the red dot means? |
| 08:38:27 | braewoods | err blue dot |
| 08:38:43 | _bilgus | might be shared but IDK |
| 08:39:01 | | Quit akaWolf (Ping timeout: 260 seconds) |
| 08:39:15 | braewoods | the fact it has a separate interrupt makes me think the input is on a different input |
| 08:39:32 | braewoods | otherwise it'd probably use the same interrupt as the regular buttons |
| 08:39:48 | _bilgus | if they are sending an interrupt then there is data stored somewhere |
| 08:40:07 | braewoods | i think GPO32 is a good place to look |
| 08:40:21 | _bilgus | so you do or don't have a remote? |
| 08:40:25 | braewoods | i do |
| 08:40:38 | _bilgus | oh well that makes this much easier start there lol |
| 08:40:48 | braewoods | yea, i wouldn't be talking about it if i didn't |
| 08:41:06 | _bilgus | I figured you were trying to RE it without a remote |
| 08:41:18 | braewoods | why would i bother without the hardware? |
| 08:41:22 | braewoods | i can't test it if i don't have it |
| 08:41:26 | _bilgus | to make a remote |
| 08:41:31 | braewoods | oh |
| 08:41:33 | braewoods | lol |
| 08:41:42 | braewoods | nah |
| 08:41:53 | _bilgus | you need a scope even a $50 will get you somewhere |
| 08:42:06 | braewoods | that still won't tell me where to poke around in software |
| 08:42:25 | braewoods | address wise |
| 08:42:26 | _bilgus | oh sure it will |
| 08:42:31 | _bilgus | no not address |
| 08:42:55 | braewoods | still i find it weird |
| 08:42:58 | _bilgus | once you know the protocol that will narrow down where to look |
| 08:42:58 | braewoods | in this schematic |
| 08:43:06 | braewoods | why is the remote circled? |
| 08:43:11 | braewoods | nothing else is |
| 08:43:33 | _bilgus | but if you have a remote and code running then I'd dump the pin states and do some anaylasis |
| 08:43:44 | _bilgus | analysis |
| 08:43:46 | _bilgus | lol |
| 08:43:49 | braewoods | i tried some of that already |
| 08:44:00 | braewoods | nothing changes when i press buttons in the view i/o ports debug |
| 08:44:06 | braewoods | for the remote |
| 08:44:07 | braewoods | anyway |
| 08:44:19 | braewoods | do i need to enable something? |
| 08:44:28 | braewoods | i'm not used to embedded development |
| 08:44:42 | _bilgus | probably its not looking at the right ones? |
| 08:45:23 | _bilgus | but see if its using the ADC then you won't see GPIO data |
| 08:45:37 | braewoods | the I/O ports also had ADC output |
| 08:45:47 | _bilgus | ADC doesn't output |
| 08:45:50 | braewoods | err |
| 08:45:52 | braewoods | input |
| 08:45:55 | _bilgus | its a GPIO then |
| 08:45:55 | braewoods | it had the inputs |
| 08:46:11 | braewoods | the schematic doesn't suggest it has anything to do with the connected ADC |
| 08:46:13 | _bilgus | ah ok ADC inputs though need to be read |
| 08:46:35 | _bilgus | So first look at the in states in software |
| 08:46:45 | braewoods | truth is _bilgus most of the buttons here are implemented in a touchpad |
| 08:46:45 | _bilgus | they are sometimes 00 01 10 11 |
| 08:46:53 | braewoods | save for the side buttons |
| 08:46:55 | braewoods | which are gpios or so |
| 08:47:07 | _bilgus | PIN states* |
| 08:47:23 | _bilgus | so find the bits controlling the port directions |
| 08:47:44 | _bilgus | and read out that then compare to known pin ststes |
| 08:48:42 | _bilgus | if you have 32 pin states its probably in several INTS |
| 08:49:22 | _bilgus | so one set will be 0 for in 1 for out (or even flipped!) and another set might be special functions |
| 08:50:06 | braewoods | since nothing is happening I need to try flipping unused bits |
| 08:50:30 | _bilgus | the remote is doing something no? |
| 08:50:36 | braewoods | yes, in the OF it works |
| 08:50:41 | _bilgus | ok good |
| 08:50:51 | _bilgus | don't go flipping bits this aint that deep |
| 08:50:51 | braewoods | i wouldn't be trying this without a reference point |
| 08:50:55 | | Quit Saijin_Naib (Ping timeout: 258 seconds) |
| 08:51:14 | braewoods | I thought GPO32 would be a good place to start looking for inputs |
| 08:51:24 | braewoods | where should I look then? |
| 08:51:28 | _bilgus | go into the current button code and see if the adc puts out a different level first if you haven't already |
| 08:51:41 | braewoods | ok i'll try it |
| 08:51:46 | braewoods | actually... |
| 08:51:53 | braewoods | i know for a fact it won't but i'll confirm it |
| 08:52:09 | _bilgus | next i think i'd try finding that interrupt line |
| 08:52:50 | _bilgus | it might be the to signal the adc is ready and I'd watch it in HARDWARE |
| 08:53:40 | _bilgus | or if you can find other interrupt sources then you might be able to flip that bit |
| 08:54:26 | braewoods | the only buttons triggering GPIOs are the physical ones |
| 08:54:32 | braewoods | remote does nothing there |
| 08:54:42 | _bilgus | ah ok I get what you are thinking flip the gpios to input to see if they toggle |
| 08:54:59 | | Quit massiveH (Quit: Leaving) |
| 08:55:06 | braewoods | yes.. try to enable ones that are currently not used to see if anything changes when the remote is used |
| 08:55:24 | braewoods | the ADC doesn't have anything to do with regular input |
| 08:55:29 | braewoods | on this unit |
| 08:55:32 | _bilgus | as long as you don't switch them to output then I think you'll be ok |
| 08:55:46 | braewoods | oh that sounds bad |
| 08:56:48 | _bilgus | fiugure most pins start in input so I don't see why they wouldn't already be enabled |
| 08:57:12 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
| 08:57:38 | _bilgus | unless that remote has > 6 wires my guess would be reading the adc |
| 08:57:52 | _bilgus | so lets enable the adc and do our own read of it |
| 08:58:26 | braewoods | wouldn't the ADC be connected to the remote in some way if it was use? |
| 08:59:07 | _bilgus | now you will have to figure out its input state so maybe you could hook up the remote and boot and read the imnitial memory setup |
| 08:59:25 | _bilgus | well to a pin that the adc can be told to read |
| 09:00 |
| 09:00:05 | _bilgus | if its disconnected though then no way to do that |
| 09:00:26 | braewoods | U16 is connected to the battery ADC |
| 09:00:33 | _bilgus | this is why I said start in the remote and figure out what it does for a button |
| 09:00:33 | braewoods | no way it's used for this |
| 09:00:38 | braewoods | Oh |
| 09:01:53 | braewoods | huh i just had a weird idea |
| 09:02:09 | braewoods | let me check what PM3 is |
| 09:02:35 | _bilgus | so i figure you have several options... a. ADC b. GPIO directly c. processing and sending a packet (I2c, shift register, etc) |
| 09:02:39 | braewoods | no indication |
| 09:02:53 | braewoods | if I2C was used, the manual would probably give me the address for it |
| 09:03:06 | braewoods | it does for the rest of the stuff |
| 09:03:29 | braewoods | i was just thinking though bilgus |
| 09:03:32 | braewoods | what if.. |
| 09:03:37 | braewoods | no wait |
| 09:03:42 | braewoods | the backlight line is an output one |
| 09:03:58 | _bilgus | how many wires go to the remote and what do they connect to in the remote? |
| 09:04:16 | braewoods | _bilgus: well i looked at the dock since that's what is exposed to the player |
| 09:04:47 | _bilgus | if the remote has a processor then it might be sending serial data |
| 09:05:32 | _bilgus | acting as a shift register basically |
| 09:05:58 | _bilgus | its too broad a search area ATM |
| 09:06:14 | braewoods | there's only one remote |
| 09:06:16 | braewoods | pin |
| 09:06:48 | braewoods | _bilgus: what do these arrows mean anyway? |
| 09:06:56 | braewoods | video out points away from the cradle |
| 09:07:00 | braewoods | line out points towards it |
| 09:07:18 | _bilgus | I'd assume the direction of data |
| 09:07:31 | _bilgus | do yu have a pic of this schematic |
| 09:07:38 | braewoods | i showed it to you before |
| 09:07:42 | braewoods | https://www.rockbox.org/wiki/pub/Main/GoGearHDD6330/Philips_HDD6320_HDD6330_Service_Manual.pdf |
| 09:07:53 | braewoods | it's at the back of the service manual |
| 09:08:28 | braewoods | 30 pin cradle connector |
| 09:08:33 | braewoods | i wonder if it's ipod compatible |
| 09:10:16 | _bilgus | REMOTE control power on off |
| 09:10:30 | braewoods | _bilgus: meaning what? |
| 09:10:37 | braewoods | the cradle_remote is something else? |
| 09:10:43 | _bilgus | it shows an opamp that leads to the interrupt pin |
| 09:11:45 | _bilgus | so that tells me at least the power button uses a resistor ladder |
| 09:12:12 | _bilgus | over on the left see the voltage divider |
| 09:12:19 | _bilgus | between 3v3 and gnd |
| 09:12:26 | _bilgus | thats the reference |
| 09:12:42 | braewoods | to trigger an interrupt? |
| 09:12:48 | _bilgus | so that op amp signals an interrupt when those levels differ |
| 09:12:59 | _bilgus | according to the schematic |
| 09:13:12 | braewoods | which happens when there's input on the remote jack or cradle remote |
| 09:13:18 | _bilgus | mioght be REMOTE_INTERNAL |
| 09:13:39 | _bilgus | the lines show that they both connect to this op amp |
| 09:13:52 | braewoods | makes sense if they're related |
| 09:13:53 | _bilgus | but the op amp can't tell you what button was pressed |
| 09:14:09 | braewoods | of course not, since they share the same interrupt |
| 09:14:19 | _bilgus | so it raises an interrupt and someone has to go read it |
| 09:14:19 | braewoods | the rest must be diagnosed from software values |
| 09:14:33 | _bilgus | lets see if we can intuit that |
| 09:14:56 | braewoods | well let's start by seeing what those 2 inputs are connected to |
| 09:15:03 | braewoods | they also need to be connected to the CPU somehow |
| 09:15:33 | braewoods | cradle_remote just goes to a pin labeled as PWM |
| 09:15:38 | braewoods | are PWM inputs a thing? |
| 09:15:45 | braewoods | i thought it was mainly an output |
| 09:17:04 | braewoods | huh |
| 09:17:13 | braewoods | remote_jack is connected to the unknown ADC |
| 09:18:16 | _bilgus | ADC AIN1 |
| 09:18:30 | braewoods | that's an odd one |
| 09:18:36 | braewoods | when it's disconnected from the dock |
| 09:18:37 | _bilgus | that is enough info to do this |
| 09:18:41 | braewoods | or connected even |
| 09:18:59 | _bilgus | so what tou need to do is set up ADC AIN1 for a read |
| 09:19:13 | braewoods | isn't that already happening from the debug menu? |
| 09:19:14 | _bilgus | and instead of waiting for interrupt read it in a loop |
| 09:19:22 | _bilgus | doubtful |
| 09:19:40 | braewoods | adc_read ? |
| 09:19:44 | braewoods | is called from debug_pp.c |
| 09:19:50 | braewoods | debug-pp.c* |
| 09:20:06 | _bilgus | you need to push bits in to set up wait for setup ready (udelay 250 work FN) and trigger it |
| 09:20:19 | _bilgus | possibly but you need to set it up |
| 09:20:35 | _bilgus | and then toggle the trigger bit |
| 09:21:13 | braewoods | so it won't show up in debug then |
| 09:21:45 | _bilgus | copy adc AIN0 (the battery) |
| 09:22:05 | _bilgus | use its code and tweak to the proper ADC |
| 09:22:43 | _bilgus | why would anyone show debug for an unconnected peripheral? |
| 09:23:07 | Ctcp | Ignored 2 channel CTCP requests in 1 day and 7 hours at the last flood |
| 09:23:07 | * | braewoods shrugs |
| 09:26:44 | _bilgus | laer once you get that then you should be able to use the interrupt or just poll it |
| 09:27:57 | braewoods | _bilgus: so how would I "trigger" it? |
| 09:30:27 | braewoods | hm |
| 09:30:34 | braewoods | first thing i'll try... find the interrupt line |
| 09:30:40 | braewoods | that should be pretty harmless |
| 09:32:52 | _bilgus | no just load the bits |
| 09:33:03 | _bilgus | same way the battery loop does it |
| 09:33:26 | braewoods | _bilgus: the debug menu's io ports thing was already triggering reads of ADC1 |
| 09:33:34 | braewoods | so didn't i already do that? |
| 09:33:40 | _bilgus | you just need to send it to the proper register for ADC1 instead of ADC0 |
| 09:34:28 | braewoods | line 177 of debug-pp.c |
| 09:34:30 | _bilgus | is it actually ADC1 and then the question becomes the setup |
| 09:34:40 | braewoods | adc_read(ADC_BATTERY), adc_read(ADC_UNKNOWN_1)); |
| 09:34:49 | _bilgus | so we have an external source |
| 09:35:06 | _bilgus | we probably need to set the bits brb |
| 09:35:11 | braewoods | ok |
| 09:35:28 | braewoods | ADC1 has all the bits turned on (it is 10 bits) |
| 09:35:30 | braewoods | so 0x3ff |
| 09:35:37 | braewoods | thought it will vary a small amunt |
| 09:35:41 | braewoods | regardless of what i do |
| 09:35:48 | braewoods | something 0x3fd or something |
| 09:35:52 | braewoods | let me confirm that |
| 09:37:18 | braewoods | 3ff |
| 09:37:24 | braewoods | 3fe |
| 09:37:30 | braewoods | 3fd |
| 09:40:32 | _bilgus | I don't see adc scan being called |
| 09:40:42 | braewoods | it's just using adc_read |
| 09:40:46 | _bilgus | you are just reading static data presumably |
| 09:40:53 | braewoods | it changes so it is being updated |
| 09:41:07 | _bilgus | looking at the source (hopefully the 5020) |
| 09:41:13 | braewoods | it is a 5020 chip |
| 09:42:00 | braewoods | i just assumed it would be just as good |
| 09:42:09 | braewoods | but.. |
| 09:42:16 | _bilgus | nm it does it in a tick task |
| 09:42:26 | _bilgus | still looking for the cfg bits |
| 09:42:58 | _bilgus | adc_init |
| 09:43:06 | _bilgus | thats where we need to look |
| 09:43:12 | braewoods | ADC1 is connected to 2 things according to the schematic |
| 09:43:49 | braewoods | REMOTE_JACK... what's the 6,7 mean? |
| 09:44:05 | braewoods | and a resistor inline with a 3.3V power supply |
| 09:44:19 | _bilgus | yep |
| 09:44:21 | _bilgus | ADC_STATUS |
| 09:44:29 | _bilgus | play with that register |
| 09:44:35 | _bilgus | under unknown1 |
| 09:44:49 | _bilgus | try 0x20 like the battery try values like the other players |
| 09:45:01 | _bilgus | or guess from similar processors |
| 09:45:24 | _bilgus | but we need to set the threshold and the source |
| 09:45:47 | braewoods | first i need to find input corresponding to the remote events |
| 09:46:05 | braewoods | i should get something even if it doesn't make sense initially |
| 09:47:25 | _bilgus | guessing it needs a thresh of 2.5v by the 10k resistor holding it high |
| 09:48:29 | braewoods | going by the logic in this ADC |
| 09:48:31 | _bilgus | so it may also have internal pull up and down we need that disabled but you should still see stuff |
| 09:48:35 | braewoods | ADC_STATUS must be 8 bits per channel |
| 09:48:58 | braewoods | it shifts over 8 bits for each channel enabled |
| 09:49:02 | _bilgus | no they have 0x200000 inthere right? |
| 09:49:10 | _bilgus | possible |
| 09:49:18 | braewoods | well |
| 09:49:23 | braewoods | the first for battery is |
| 09:49:27 | braewoods | ADC_STATUS |= 0x20; |
| 09:49:32 | braewoods | next one for unknown is |
| 09:49:35 | braewoods | ADC_STATUS |= 0x2000; |
| 09:49:50 | braewoods | it's setting the... |
| 09:49:53 | braewoods | 6th bit? |
| 09:49:57 | _bilgus | Id say your assumption is correct |
| 09:49:59 | braewoods | then the 14th bit |
| 09:50:16 | braewoods | in any case i wonder what the extra bits do |
| 09:50:29 | _bilgus | nope I should have pointed you at init |
| 09:51:07 | _bilgus | OR we are missing the cfg code |
| 09:51:16 | _bilgus | the register rather |
| 09:54:21 | braewoods | i'm getting the feeling the remote_jack indicates the presence of the remote |
| 09:54:26 | braewoods | from the schematic |
| 09:54:46 | braewoods | meaning whether the remote feature is available or not |
| 09:55:05 | braewoods | (or connected to a remote compatible dock) |
| 09:58:48 | _bilgus | try this |
| 09:59:01 | braewoods | ? |
| 09:59:02 | _bilgus | #define ADC_CFG (*(volatile unsigned long*)(0x7000ad0C)) |
| 09:59:19 | _bilgus | then do that same thing they did of writing to the upper |
| 10:00 |
| 10:00:17 | _bilgus | hold on let me math for a moment |
| 10:00:23 | braewoods | Ok |
| 10:01:24 | _bilgus | yeah I think thas right |
| 10:01:31 | _bilgus | 4+ 16 would b 20 |
| 10:01:44 | _bilgus | so thats two 8 bytes registers |
| 10:01:50 | _bilgus | I think cfg is missing |
| 10:02:09 | braewoods | can you give me a patch to try? |
| 10:02:20 | braewoods | at least for this first one |
| 10:02:23 | _bilgus | I can pastebin it |
| 10:02:32 | braewoods | sure |
| 10:02:39 | braewoods | if we still are having trouble... |
| 10:03:22 | braewoods | i can mail you a set of units, i'm going to end up with 2 complete sets anyway |
| 10:03:35 | braewoods | but i want to see if we can find it over the net instead |
| 10:05:55 | _bilgus | https://pastebin.com/fayuaEcY |
| 10:06:25 | _bilgus | we can given enough screwing around |
| 10:06:42 | _bilgus | the next thing to try is to dump the registers from the bootloader |
| 10:06:54 | *** | Saving seen data "./dancer.seen" |
| 10:07:11 | _bilgus | if we can just get the cfg right |
| 10:07:22 | _bilgus | we won't need to |
| 10:08:03 | _bilgus | anyways you see the scheme they are using before I did so there is going to be a bit that seys it to the proper level atm its probably saturated |
| 10:08:42 | _bilgus | so try setting them all might check what the initial values are too |
| 10:08:46 | _bilgus | read that address |
| 10:10:09 | _bilgus | anyways I goota head look forward to progress might also try messing with the battery one to see if you can make it read wrong |
| 10:16:41 | braewoods | _bilgus: that did change the range of random inputs from the ADC1 |
| 10:17:04 | braewoods | but nothing else that i can tell |
| 10:39:23 | braewoods | maybe i should try disassembling the OF |
| 10:40:09 | braewoods | one idea i have |
| 10:40:28 | braewoods | the volume controls are simple enough and appear in both GPIO and the remote control |
| 10:40:42 | braewoods | so in theory they should lead to the same code that causes the volume to chnage |
| 10:40:52 | braewoods | and then backtrace from there |
| 11:00 |
| 11:02:45 | | Quit paulk-leonov (Read error: Connection reset by peer) |
| 11:03:10 | | Join paulk-leonov [0] (~paulk-leo@leonov.paulk.fr) |
| 11:47:56 | braewoods | _bilgus: the hdd1630 and hdd6330 are very similar schematics wise so I thought i'd compare them |
| 11:48:19 | braewoods | _bilgus: pin 17, the cradle remote pin? it's labeled GPIO4 in thhe hdd1630. |
| 11:48:35 | braewoods | _bilgus: and both connect to the same labeled pin on the PP cpu |
| 11:48:46 | braewoods | no idea what the difference is as of ye |
| 11:48:48 | braewoods | yet |
| 11:49:28 | braewoods | ADC_AIN1 is connected to remote jack in this one |
| 11:51:00 | braewoods | so my theory is... |
| 11:51:14 | braewoods | the same method for accessing the remote is the same in both |
| 11:51:16 | braewoods | or close enough |
| 12:00 |
| 12:00:45 | braewoods | i suspect AIN1 is used for some kind of wakeup feature? |
| 12:00:50 | braewoods | hard to say |
| 12:01:09 | braewoods | it appears to basically be a voltage reading of some kind. it's connected to the battery voltage. |
| 12:02:34 | braewoods | yep think that's confirmed |
| 12:02:36 | braewoods | DC-DC_START# |
| 12:02:46 | braewoods | also connected to the power switch |
| 12:06:57 | *** | Saving seen data "./dancer.seen" |
| 12:10:19 | braewoods | _bilgus: though i'm puzzled... why does the cradle even have an I2C connector? |
| 12:10:35 | braewoods | that only makes sense if there's I2C chips inside. |
| 12:10:48 | braewoods | otherwise there's no point to having that. |
| 12:11:12 | braewoods | the remote only sends an IR signal |
| 12:11:27 | braewoods | i wonder if the remote pin is just a red hearing |
| 12:11:37 | braewoods | maybe it only exists to trip the interrupt linee |
| 12:12:02 | braewoods | if so... |
| 12:12:16 | braewoods | the most likely answer is inside the dock |
| 12:12:25 | braewoods | what is on the dock side of the connector? |
| 12:12:33 | braewoods | the I2C bridge exists for a reason |
| 12:12:35 | braewoods | but what? |
| 12:12:52 | braewoods | it might have been for something planned but never used |
| 12:13:01 | braewoods | or it could be for communicating with an IR cihp |
| 12:13:02 | braewoods | chip |
| 12:15:18 | braewoods | most likely explaination why it's there |
| 12:15:56 | braewoods | my theory, the chip sends a GPIO signal of some kind to let it know there's I2C data to read |
| 12:16:10 | braewoods | in any case |
| 12:16:24 | braewoods | i will have to disassemble one of these docks to find out |
| 12:18:12 | braewoods | i'll do it later |
| 12:18:26 | braewoods | disconnected dock from power |
| 12:18:31 | braewoods | i'll let it sit awhile |
| 12:18:33 | braewoods | tired |
| 12:18:35 | braewoods | bbl |
| 12:31:41 | _bilgus | braewoods, I'm 99% sure just getting the proper bits on the ADC will make it work |
| 12:32:15 | _bilgus | I'd just start flipping a bit at a time in a loop |
| 12:32:58 | _bilgus | then pairs |
| 12:34:37 | | Quit ArsenArsen (Quit: bye) |
| 12:34:42 | braewoods | _bilgus: so you think it'd be a waste of time to open up the cradle? |
| 12:34:59 | braewoods | i just don't understand why the cradle has an I2C switch |
| 12:45:06 | _bilgus | /* Enable channel 1 (unknown) */ |
| 12:45:06 | _bilgus | DEV_INIT1 &=~30; |
| 12:45:07 | _bilgus | DEV_INIT1 |=~10; |
| 12:45:07 | DBUG | Enqueued KICK _bilgus |
| 12:45:07 | _bilgus | //DEV_INIT1 |=~20; |
| 12:45:07 | _bilgus | ADC_ADDR |= 0x2000000; |
| 12:45:07 | *** | Alert Mode level 1 |
| 12:45:07 | _bilgus | ADC_STATUS |= 0x2000; |
| 12:45:11 | _bilgus | //ADC_CFG |= 0x2000; //?? |
| 12:45:19 | _bilgus | try that the init of the others sets bits back |
| 12:45:30 | _bilgus | so get rid of the new cfg one for now |
| 12:46:17 | _bilgus | and maybe even |= 0x30 |
| 12:47:36 | _bilgus | hard to say but if its I2c then you should be able to ground the address line through a resistor and stop the remote |
| 12:48:42 | _bilgus | at the very least it shoudl change that adc reading |
| 12:50:24 | _bilgus | still that schematic clearly shows the adc |
| 12:51:34 | braewoods | doesn't |= ~10 turn on a ton of bits? |
| 12:51:44 | _bilgus | sorry no not |
| 12:51:58 | _bilgus | | =10 then try |= 20 then |=30 |
| 12:52:02 | bertrik | braewoods: yes I think so |
| 12:52:06 | _bilgus | it should be 00 01 10 11 |
| 12:52:31 | _bilgus | sorry I missed the tilde |
| 12:52:38 | braewoods | it looked strange |
| 12:52:52 | _bilgus | I couldnt even see it till I got up on the screen lol |
| 12:55:08 | *** | Alert Mode OFF |
| 12:57:37 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 13:00 |
| 13:03:17 | braewoods | nadda with that |
| 13:04:07 | | Join TheSphinX^ [0] (~briehl@srv001.nosupamu.de) |
| 13:04:27 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 13:04:45 | _bilgus | ugh without a datasheet this is annoting |
| 13:04:53 | _bilgus | annoying |
| 13:05:49 | _bilgus | ok so a loop to flip all the uppr bits of those registers? |
| 13:06:43 | _bilgus | the other thing to do is to dump that address range from the bootloader before it starts setting bits |
| 13:07:15 | _bilgus | or disable the init in the bootloader and be first to read on it in the booted FW |
| 13:08:40 | _bilgus | I think it was the clip+ we were doing that with or no clip zip? |
| 13:09:47 | _bilgus | bu ttere we load the OF init so this might be harder for you |
| 13:10:33 | _bilgus | more like run the OF and reset the line and hope it sticks |
| 13:10:42 | braewoods | _bilgus: h320. |
| 13:11:04 | _bilgus | ? |
| 13:11:16 | braewoods | "I think it was the clip+ we were doing that with or no clip zip?" |
| 13:11:29 | _bilgus | no long time ago |
| 13:11:32 | braewoods | oh |
| 13:11:45 | _bilgus | dumping the cfg bits that the OF set |
| 13:12:42 | braewoods | wait a minute... this makes no sense |
| 13:13:01 | braewoods | i think i find a bug in ADC |
| 13:13:28 | _bilgus | in our code? the whole ranging thing? |
| 13:13:55 | braewoods | https://github.com/Rockbox/rockbox/blob/master/firmware/target/arm/pp/adc-pp5020.c#L149 |
| 13:14:00 | braewoods | ~30 |
| 13:14:06 | braewoods | notice there's no hexadecimal PREFIX |
| 13:14:20 | braewoods | it's 30 base 10 |
| 13:14:25 | braewoods | yet the others use hexadecimal |
| 13:14:28 | braewoods | something is amiss here |
| 13:14:56 | braewoods | i'll try changing that |
| 13:15:37 | _bilgus | oh nice catch |
| 13:15:54 | braewoods | i can't imagine that's not a mistake |
| 13:16:08 | braewoods | since everything else is using hexadecimal |
| 13:16:18 | _bilgus | itd set most of the bits in the lower register though? |
| 13:16:47 | _bilgus | so maybe its unintended sideffect is infact setting bits for ADC0 to work |
| 13:17:09 | braewoods | no idea |
| 13:17:29 | _bilgus | you will shortly |
| 13:17:33 | braewoods | actually &= can't turn bits on |
| 13:17:42 | braewoods | only off or leave them as is |
| 13:18:41 | _bilgus | yep still its a mask |
| 13:19:39 | _bilgus | its wiping bit0 out so that first cfg stays the ame |
| 13:19:45 | _bilgus | same the 0x3 |
| 13:19:56 | _bilgus | not(0x3) |
| 13:20:16 | _bilgus | lol |
| 13:21:02 | braewoods | seems to behave the same |
| 13:21:51 | _bilgus | well now try oring 0x10 0x20 0x30 |
| 13:22:11 | braewoods | would it be unwise to do them all at once? |
| 13:22:42 | braewoods | 0x60 |
| 13:22:51 | braewoods | not wait |
| 13:22:53 | braewoods | no wait |
| 13:22:55 | braewoods | that's 0xf0 |
| 13:22:57 | braewoods | LOL |
| 13:23:07 | _bilgus | its not gonna blow up |
| 13:23:14 | _bilgus | it just won't work |
| 13:23:50 | _bilgus | but you might wanna get rid of that ranging thing |
| 13:24:45 | braewoods | ranging thing? |
| 13:25:13 | _bilgus | /* ADC values read low if PLL is enabled */ |
| 13:25:26 | | Quit lebellium (Ping timeout: 240 seconds) |
| 13:25:27 | | Join lebellium_ [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 13:25:52 | braewoods | that doesn't apply to this unit |
| 13:25:55 | braewoods | check the macro |
| 13:26:05 | braewoods | Or? |
| 13:26:12 | braewoods | it's gated by a macro |
| 13:26:27 | _bilgus | oh I see the ! |
| 13:26:43 | _bilgus | nm then I figured that might cover up high readings |
| 13:28:07 | | Join ArsenArsen [0] (~arsen@managarm/dev/ArsenArsen) |
| 13:29:21 | braewoods | this ADC is high under normal circumstances |
| 13:29:36 | braewoods | for it to give anything meaningful it would have to dip low and do consistently |
| 13:30:06 | braewoods | instead it seems to be tied to the fluctations in the power supply |
| 13:30:40 | _bilgus | ok so 0x1000000 is 24 bits |
| 13:30:52 | _bilgus | there are 3 longs for each adc |
| 13:30:57 | _bilgus | in theory |
| 13:32:45 | _bilgus | they step everything by 4 though so that would be 6 shorts |
| 13:34:46 | _bilgus | but since it has 0x80000000 I'd say we assume the former |
| 13:41:58 | _bilgus | something is a bit off here |
| 13:46:56 | braewoods | _bilgus: ya think? |
| 13:46:59 | _bilgus | if 2c is the init and they put 0x8000 0000 at ad2c then that would make it 48 + 52 bytes |
| 13:47:13 | _bilgus | 48 + 8 = 52 bytes |
| 13:47:55 | braewoods | it was just a thought since i don't know what else it would be used fr |
| 13:48:11 | braewoods | if i2c is involved i would have to find the address and datasheet |
| 13:48:30 | braewoods | one way to find out |
| 13:48:41 | braewoods | see if there's any unfamiliar i2c addresses in the OF |
| 13:50:23 | braewoods | i've never heard of an i2c irda chip but they may exist |
| 13:50:30 | braewoods | the dock |
| 13:50:41 | braewoods | the dock's datasheet refers to it as IRDA |
| 13:50:48 | braewoods | so |
| 13:50:59 | braewoods | i'm guessing it has to have an IRDA chip in the dock |
| 13:51:07 | braewoods | but how it sends the data is still a mystery |
| 13:51:16 | braewoods | we still haven't uncovered the entry point for it |
| 13:51:35 | braewoods | i think some hardware level analysis is in order |
| 13:51:47 | braewoods | finding out what's in the dock would probably help |
| 13:52:28 | braewoods | i mean IRDA is a bit involved so it has to have something to translate it to a different kind of signal |
| 13:52:44 | braewoods | unless... |
| 13:59:12 | braewoods | _bilgus: what convinces you that AIN1 has the remote control bits? |
| 13:59:22 | braewoods | it appears to be tied to the remote jack |
| 13:59:32 | braewoods | though not sure what that does exactly other than being tied to power on |
| 14:00 |
| 14:07:00 | *** | Saving seen data "./dancer.seen" |
| 14:09:48 | _bilgus | the schematics pull up resistor |
| 14:10:04 | _bilgus | hope thi shows properly |
| 14:10:10 | _bilgus | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
| 14:10:10 | _bilgus | |__ADDRESS__|________________STATUS_____________________________________________________________|___DATA0___|___DATA1___|________INIT___________| |
| 14:10:15 | _bilgus | yes! |
| 14:10:37 | braewoods | ...? |
| 14:10:41 | braewoods | so what's you find? |
| 14:10:58 | _bilgus | well look at status versus what we set to it |
| 14:11:22 | braewoods | these are... |
| 14:11:27 | braewoods | each 0 is 4 bits? |
| 14:11:40 | braewoods | or? |
| 14:11:44 | braewoods | 1 bit |
| 14:11:52 | braewoods | this is kinda confusing as it is shown on irc |
| 14:12:27 | _bilgus | 80000000 says its 4 bytes |
| 14:12:40 | _bilgus | yes each 0 is a byte |
| 14:12:46 | _bilgus | no 00 is a byte |
| 14:12:55 | _bilgus | laid out like in a hex editor |
| 14:13:25 | _bilgus | sorry lets regroup |
| 14:13:47 | _bilgus | 32 bits or 8 bytes |
| 14:13:49 | braewoods | so apparently we only read the frst 4 bytes |
| 14:13:53 | braewoods | for status |
| 14:14:13 | braewoods | the reminaing 12 are unused |
| 14:14:30 | _bilgus | point being that there is a missing range inthere |
| 14:14:53 | _bilgus | 20 extra bits |
| 14:16:42 | _bilgus | you should set up a loop to fill from that cfg address to the base of data 0 |
| 14:17:14 | _bilgus | and basically go through the init for that adc |
| 14:17:19 | _bilgus | each time |
| 14:17:25 | braewoods | so set them all to 1s |
| 14:17:55 | _bilgus | or all zero and count up |
| 14:18:35 | braewoods | there's also 8 bytes between data and init |
| 14:18:41 | _bilgus | so in your loop all you need to do is write if adc < ad0 or w/e you get and let it do the work |
| 14:18:42 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-110d-8f45-d887-ee78.res6.spectrum.com) |
| 14:18:42 | braewoods | yet we only use the first 4 |
| 14:19:10 | _bilgus | maybe its 12 each chunk |
| 14:19:43 | braewoods | could be unused padding or somethin |
| 14:20:10 | _bilgus | possibly but generally adcs have setup bits and source compare bits |
| 14:20:10 | braewoods | i'm going to take a nap now so tired lol |
| 14:20:22 | _bilgus | ciao |
| 14:20:34 | braewoods | _bilgus: it would help if we had an actual datasheet for the cpu |
| 14:20:37 | braewoods | ._. |
| 14:20:41 | _bilgus | ALWAYS! |
| 14:20:46 | _bilgus | lol |
| 14:20:59 | _bilgus | even a similar one but ?? |
| 14:21:01 | braewoods | can you believe no PP datasheets leaked even though they stopp making chips? |
| 14:21:13 | _bilgus | yes |
| 14:21:19 | braewoods | lol |
| 14:23:19 | _bilgus | ^ that was supposed to be 0x80000000 = 8 bytes 32 bitsd |
| 14:23:39 | _bilgus | so no one thinks I can count in binary lol |
| 14:27:43 | speachy | given who provided most of PP's revenue, and who ultimately acquired them, yes... |
| 14:34:51 | _bilgus | braewoods, https://pastebin.com/nA1LjinE |
| 14:34:59 | _bilgus | that should get you started |
| 14:35:18 | _bilgus | you might not be able to do the splash there either |
| 14:35:31 | _bilgus | depending on when it does its first reads |
| 14:36:08 | _bilgus | so we just go throught and count up and hopefully change those status bits till it changes the adc value |
| 14:36:12 | _bilgus | cfg |
| 14:36:15 | _bilgus | not status |
| 14:37:32 | _bilgus | if that fails we might need to reinit the adc or somethign or maybe block out the 64 bytes I think it encompasses and start randomly flipping bits on and off till it does |
| 15:00 |
| 15:08:24 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 15:28:03 | | Quit Saijin_Naib (Ping timeout: 258 seconds) |
| 15:33:10 | speachy | dconrad: the original X3 has about a 4.3Vpp. A bit on the hot side still |
| 15:40:10 | | Join ats_ [0] (~ats@cartman.offog.org) |
| 15:41:19 | | Quit atsampson (Ping timeout: 260 seconds) |
| 15:55:36 | fs-bluebot | Build Server message: New build round started. Revision cd64aa2b10, 298 builds, 9 clients. |
| 16:00 |
| 16:06:03 | speachy | I'll get to the X3ii eventually. :) |
| 16:07:04 | *** | Saving seen data "./dancer.seen" |
| 16:07:08 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-14ba-5001-4fff-7f89.res6.spectrum.com) |
| 16:07:16 | fs-bluebot | Build Server message: Build round completed after 700 seconds. |
| 16:07:18 | fs-bluebot | Build Server message: Revision cd64aa2b10 result: All green |
| 17:00 |
| 17:21:32 | | Join b0hoon [0] (57cd8bb1@87-205-139-177.adsl.inetia.pl) |
| 17:25:06 | b0hoon | braewoods: Hi. Do you own the YH-925 by accident? |
| 17:32:30 | b0hoon | braewoods: I'm asking because of my radio patch. |
| 17:37:02 | | Quit ZincAlloy (Quit: Leaving.) |
| 17:38:08 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:793b:87ec:38af:f44a) |
| 17:53:12 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 17:57:35 | | Quit ats_ (Ping timeout: 260 seconds) |
| 18:00 |
| 18:00:00 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 18:07:05 | *** | Saving seen data "./dancer.seen" |
| 18:13:05 | | Quit lebellium_ (Quit: Leaving) |
| 18:13:28 | braewoods | b0hoon: i tried to make one work but i never did get it to work. |
| 18:13:34 | braewoods | i no longer have it. |
| 18:13:45 | braewoods | it wouldn't really boot RB or anything |
| 18:13:55 | braewoods | i blame that fickle HDD ribbon cable mysel |
| 18:17:43 | braewoods | practically nothing to keep it from popping out whenever it felt like it |
| 18:21:33 | b0hoon | Oh... It's a pity. Do you know if it had a radio module soldered in? |
| 18:22:32 | b0hoon | I have a patch for the radio, but it's not tested for DAP's without the module. |
| 18:26:22 | b0hoon | braewoods: Regarding the scrollstrip for the HDD6330, you may want to look at this: https://gerrit.rockbox.org/r/c/rockbox/+/786. |
| 18:31:11 | | Quit pamaury (Ping timeout: 260 seconds) |
| 18:36:06 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 18:37:54 | b0hoon | braewoods: and yeah this ribbon cable in this player is very fishy. I have an adapter for CF card inserted, and it's connected for the word. |
| 18:38:58 | braewoods | b0hoon: pretty sure it didn't. |
| 18:39:48 | braewoods | if you can test your radio patch we can probably enable it as a build option for that target |
| 18:40:02 | braewoods | it won't be an official build and will require people to build it themselves but it will be in tree |
| 18:41:54 | braewoods | b0hoon: the funny thing is if they opted for a regular ZIF cable that would have solved most of the issues with it disconnecting |
| 18:42:10 | braewoods | because you can lock the connector down |
| 18:42:32 | b0hoon | it's tested for DAP's with the radio, but it's not a good idea to aply it when we don't know if it can detect lack of it, imo there is no sense to do that |
| 18:43:01 | braewoods | b0hoon: are you familiar with the H120 rtc mod? |
| 18:43:04 | b0hoon | yep, i don't know who designed this thing |
| 18:43:08 | braewoods | that's the kind of thing i was thinking about. |
| 18:43:13 | braewoods | source wise |
| 18:43:34 | braewoods | it's a build option you have to choose for the H120 to even use it |
| 18:44:01 | braewoods | that would be the best option until a way to configure it at runtime can be found. |
| 18:44:19 | braewoods | you can probably pickup a yh-925 on ebay for not much |
| 18:44:30 | b0hoon | no, sorry i never had the h120 |
| 18:44:31 | braewoods | chances are it won't have the chip |
| 18:44:42 | braewoods | i read about it in passing |
| 18:45:29 | braewoods | see tools/configure |
| 18:45:52 | braewoods | have_rtc_alarm |
| 18:45:57 | braewoods | that's where it is enabled |
| 18:46:14 | b0hoon | yeah but the shipping is expensive, twice the price of the DAP for me |
| 18:46:22 | braewoods | oh, you live somewhere remote |
| 18:46:25 | braewoods | ok |
| 18:47:00 | b0hoon | yes, but you have to solder a RTC chip additionally |
| 18:47:06 | braewoods | indeed |
| 18:47:11 | braewoods | but i'm just saying |
| 18:47:16 | braewoods | it's similar to this. |
| 18:47:21 | braewoods | some units have it a lot don't |
| 18:47:21 | b0hoon | there is something on the wiki about it |
| 18:47:43 | b0hoon | didn't know that |
| 18:47:54 | braewoods | if you want to add your patch to current GIT |
| 18:47:57 | braewoods | that's a good way to do it for now |
| 18:48:14 | braewoods | conditionally include it for custom builds that request it |
| 18:48:47 | braewoods | then maybe you can find a way to do it better at runtime so it can be enabled for all units |
| 18:49:34 | braewoods | i think the main reason it never got implemented was lack of any indication of which ones had FM radio and which did not. |
| 18:49:43 | braewoods | it made getting testing units harder |
| 18:50:41 | | Quit pamaury (Ping timeout: 240 seconds) |
| 18:50:53 | b0hoon | i'm not convinced without a full test, well. this patch implements detection. Basically you can see it in the OF |
| 18:51:08 | braewoods | I see. |
| 18:51:16 | braewoods | ask on the forums. I think some people own the unit. |
| 18:51:32 | braewoods | otherwise one of the regulars here might have one. |
| 18:51:35 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 18:52:06 | b0hoon | I think i did it years ago but the main problem is these DAP's are dinosaurs |
| 18:52:36 | braewoods | aren't they all |
| 18:52:40 | | Quit ac_laptop (Ping timeout: 252 seconds) |
| 18:52:55 | braewoods | the bleeding edge ports are still too immature to be all that useful |
| 18:53:08 | braewoods | i think the most feature complete port is the iriver h120 |
| 18:53:10 | b0hoon | yeah PP is relict |
| 18:53:51 | braewoods | i did a major favor to the users of the H100 and H300 series by taking on some risks to update the bootloader |
| 18:53:57 | braewoods | it fixed some really nasty issues |
| 18:54:29 | braewoods | mostly CF card compatibility issues |
| 18:54:36 | b0hoon | i saw that, amazing job! |
| 18:55:00 | braewoods | i also do an overhaul of the H300 bootloader so it could leverage the new H100 features |
| 18:55:04 | braewoods | like boot from ROM |
| 18:55:27 | braewoods | most of the features for that were already implemented in the main firmware |
| 18:55:39 | braewoods | the eeprom settings store at least was 100% complete that i could tell |
| 18:55:49 | braewoods | but they never finished the bootloader redux to use it |
| 18:56:13 | braewoods | probably because they couldn't figure out what broke the bootloader |
| 18:56:37 | braewoods | I found a trick to allow me to flash bad bootloaders until I finally found the culprit |
| 18:56:57 | braewoods | turns out the bootloader's emergency boot into OF mode still worked |
| 18:57:09 | braewoods | so I used the OF to restore the last known good bootloader |
| 18:57:18 | braewoods | lather rinse repeat |
| 18:57:28 | braewoods | i traced it to and LCD optimization that broke the bootloader |
| 18:58:17 | bertrik | wow |
| 18:59:43 | braewoods | i also had to totally refactor the iriver_flash plugin in order to allow flashing stuff from the h300 |
| 19:00 |
| 19:00:04 | braewoods | i broke it down and rebuilt it based on the original but removed bits that were no longer relevant |
| 19:00:25 | braewoods | since i had to understand it in order to extend its support |
| 19:00:51 | braewoods | but now both units can go OF free if they want to |
| 19:01:02 | braewoods | the OF is useless anyway if you perform the CF mod |
| 19:01:12 | braewoods | there's no known way to make it work with CF cards |
| 19:01:31 | braewoods | i tried using one that claimed to be a fixed disk IDE thing |
| 19:01:38 | braewoods | and still didn't work so |
| 19:01:44 | braewoods | i dunno what makes the OF reject CF cards |
| 19:01:51 | braewoods | I just thought maybe it was being too picky |
| 19:02:03 | braewoods | and could work with CF cards that fully emulate a HDD |
| 19:08:39 | braewoods | bertrik: if you're bored, i added code to the disk info in debug menu that reports the 3 bits related to this. |
| 19:08:48 | braewoods | removeable, fixed, and CF compatible bits |
| 19:09:03 | braewoods | only for ATA targets though but i thought it might be helpful for CF modders |
| 19:09:17 | braewoods | in the event some obscure port cares about these bit |
| 19:09:19 | braewoods | we sure don't |
| 19:09:55 | braewoods | but CF cards report different values even in true IDE mode |
| 19:10:10 | braewoods | i had some surprisingly reported fixed disk when i didn't expect it |
| 19:13:49 | braewoods | _bilgus: should we patch the code in the ADC for PP to be 0x30 instead of 30? it's clearly not intended that way |
| 19:15:45 | | Quit Saijin_Naib (Ping timeout: 258 seconds) |
| 19:30:17 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 19:30:42 | braewoods | ugh anyway when i get a chance i need to open up my dock so i can find out what hardware is inside |
| 19:30:51 | braewoods | might shed some light on what I need to do to get remotes to work |
| 19:33:57 | | Join chris_s [0] (5fdf48b5@ip-95-223-72-181.hsi16.unitymediagroup.de) |
| 19:36:14 | | Quit chris_s (Client Quit) |
| 19:37:10 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 19:44:27 | | Quit pamaury (Ping timeout: 260 seconds) |
| 19:49:04 | b0hoon | i have a dock station for HHD's but it's simple passthrough interface with the line out/in and some ir diode connected |
| 19:50:39 | b0hoon | from what i recall hdd6330 has an hardware issue with the i2c interface, so it won't work anyway on dock |
| 19:51:23 | b0hoon | it's more or less described on the wiki |
| 19:52:34 | b0hoon | but you can try to play with it of course |
| 19:57:21 | braewoods | b0hoon: it does work? i can use the remote in the OF |
| 19:57:23 | braewoods | and such |
| 19:57:54 | braewoods | b0hoon: and, IR diode? |
| 19:58:04 | braewoods | i thought it was some IRDA chip |
| 19:58:09 | b0hoon | by remote you mean ir remote? |
| 19:58:12 | braewoods | yes |
| 19:59:09 | b0hoon | yes that may work, probably this is the Cradle_REMOTE pin from the service manual, the OF has some code to interpret it iirc |
| 19:59:37 | braewoods | i know |
| 19:59:49 | braewoods | i wanted to disassemble my dock to see how it's generating said signal |
| 19:59:58 | braewoods | i thought it might give me some clue of where to look |
| 20:00 |
| 20:00:19 | braewoods | i'm starting to think though the cradle remote pin just signals an interrupt line |
| 20:00:47 | b0hoon | i'm afraid you will have to disassemble the OF |
| 20:00:47 | braewoods | but there's 5 possible inputs from the key pad |
| 20:01:18 | braewoods | so there's nothing useful in the dock? |
| 20:01:31 | braewoods | is that what you're telling me? |
| 20:01:33 | braewoods | for the hdd gogears? |
| 20:01:55 | braewoods | so then why does the cradle have an I2C bus switch? |
| 20:02:02 | braewoods | it doesn't make sense to me |
| 20:02:18 | b0hoon | yes |
| 20:02:37 | b0hoon | i may be wrong but the i2c is for something else |
| 20:02:51 | braewoods | it's not specified so i can't be sure |
| 20:02:59 | fs-bluebot | Build Server message: New build round started. Revision 13dbcab6c0, 298 builds, 10 clients. |
| 20:03:12 | braewoods | only logical reason is they expected to interface with external I2C chips |
| 20:03:16 | b0hoon | i can dissaemble my dock again and tell you what's inside if you want |
| 20:03:33 | braewoods | b0hoon: that would help. it's the one with the video out, audio out, dock connector, ? |
| 20:03:48 | braewoods | i also have another version that came with my HDD1635s |
| 20:03:53 | b0hoon | wait a sec i don't remember really :D |
| 20:04:06 | braewoods | it should have 3 ports on the back |
| 20:04:12 | braewoods | including the dock connector in the middle |
| 20:04:14 | braewoods | err |
| 20:04:16 | braewoods | not including |
| 20:04:33 | braewoods | i also noticed the dock consumes 0 power when connected to DC power in the back |
| 20:04:48 | braewoods | so it doesn't get its power from that |
| 20:05:00 | braewoods | must get any power from the docked unit |
| 20:05:37 | braewoods | either that or the dock's power consumption is less than 0.01A |
| 20:05:46 | braewoods | in which case it probably wouldn't register |
| 20:07:08 | *** | Saving seen data "./dancer.seen" |
| 20:07:39 | b0hoon | god...sorry i can't find it. |
| 20:07:54 | braewoods | b0hoon: it's ok |
| 20:08:22 | braewoods | but i need to know for myself how the cradle works to have any hope of knowing where it could possibly be sending the signal |
| 20:08:33 | braewoods | the schematic doesn't tell me much |
| 20:08:57 | braewoods | you know the pin 17 is labeled differently in both HDD schemaics |
| 20:09:03 | braewoods | cradle remote for one |
| 20:09:06 | braewoods | gpio4 for another |
| 20:09:08 | b0hoon | but i'm 99% sure it had nothing but one resistor some ir diode and the rest was just connections of connectors |
| 20:09:09 | braewoods | both connect to same pin |
| 20:09:25 | braewoods | so you think it just sends a pulse signal? |
| 20:09:30 | braewoods | that the diode sends? |
| 20:09:38 | b0hoon | maybe this was a cheap fake |
| 20:09:45 | braewoods | i see |
| 20:09:49 | braewoods | well i'll see what i dig up |
| 20:09:56 | braewoods | i have originals |
| 20:10:02 | braewoods | that i can tell anyway |
| 20:10:10 | braewoods | one came with the gogear i bought |
| 20:10:18 | braewoods | the other is new old stock i haven't received yet |
| 20:10:24 | braewoods | b0hoon: do you remember how it opens? |
| 20:10:29 | braewoods | just need to gently pry it out from above? |
| 20:10:34 | b0hoon | yes, i think it send a pulse signal |
| 20:10:41 | b0hoon | sent |
| 20:10:45 | braewoods | that would explain the PWM |
| 20:10:55 | braewoods | but |
| 20:11:01 | braewoods | it's connected to a pin i don't know how to read |
| 20:11:45 | b0hoon | there were two screws i think from the bottom |
| 20:12:07 | b0hoon | that's why you will have to dig into OF disasm |
| 20:12:10 | b0hoon | :) |
| 20:12:28 | braewoods | any tips? all i got was gibberish |
| 20:12:48 | braewoods | lol |
| 20:14:31 | b0hoon | well no real tips, OF is written with some high level language for sure, 99% c++, so it's really even hard to find what you are looking for |
| 20:15:25 | b0hoon | IDA and fire... |
| 20:16:33 | fs-bluebot | Build Server message: Build round completed after 814 seconds. |
| 20:16:37 | fs-bluebot | Build Server message: Revision 13dbcab6c0 result: All green |
| 20:23:29 | braewoods | that's expensive |
| 20:23:31 | braewoods | IDA |
| 20:23:42 | speachy | go for ghidra |
| 20:24:07 | speachy | can't comment on the relative feature set vs IDA but I've put to good use over the past couple of years |
| 20:24:09 | b0hoon | i can send you my ida file from like 5 years ago, maybe you can find something useful in it |
| 20:24:41 | speachy | https://ghidra-sre.org/ |
| 20:25:51 | braewoods | speachy: if there's a PWM input on a PP how might one read it? |
| 20:26:02 | braewoods | it might help me narrow down what i'm looking for |
| 20:26:07 | braewoods | the OF is like 7MB |
| 20:26:12 | braewoods | that's a fair amount of data to go through |
| 20:26:36 | speachy | I guess it depends on what sort of input wizardry the PP has to offer on those pins |
| 20:26:36 | braewoods | but that's what the schematic appears to be saying |
| 20:26:45 | braewoods | which we have no datasheet for |
| 20:27:00 | braewoods | so there's no way to know what the PWM pin does |
| 20:27:14 | speachy | the naive approach is to use the input to trigger an interrupt on an edge |
| 20:27:38 | speachy | (well, really naive approach is to tightly poll the pin to see what's going on...) |
| 20:27:41 | braewoods | speachy: that seems to be what they do here. the remote control pin is connected to the remote_int line |
| 20:27:56 | braewoods | you want to read the schematic too? |
| 20:28:08 | braewoods | https://www.rockbox.org/wiki/pub/Main/GoGearHDD6330/Philips_HDD6320_HDD6330_Service_Manual.pdf |
| 20:28:11 | braewoods | back of the manual |
| 20:28:30 | speachy | looking at the PWM signal with a logic analyzer would be a good idea |
| 20:29:00 | braewoods | i would need to be able to poke the pins... |
| 20:29:08 | braewoods | which means i'd probably need a unit open to do that |
| 20:29:20 | speachy | c'est la vie |
| 20:29:55 | braewoods | that still won't tell me how to read it from software |
| 20:29:59 | braewoods | but |
| 20:30:09 | braewoods | given that it is connected to PWM |
| 20:30:13 | braewoods | it's probably a pulse |
| 20:30:16 | speachy | one trick I've used in the past is to look for a UI string in the firmware dump, and backtrace from that −− find referencs to that string, and work backwards until you find the code that triggers it. |
| 20:30:30 | braewoods | it probably uses ASCII |
| 20:30:33 | speachy | there's not much point in worrying how to read it until you know what "it" is |
| 20:30:54 | braewoods | the unit has two PWM lines |
| 20:30:58 | speachy | it might be a single pulse. it might be a timed sequence. who knows... |
| 20:31:01 | braewoods | one is already in use to control the LCD backlight |
| 20:31:24 | speachy | PWM output, sure. but _input_ is another matter. |
| 20:31:28 | b0hoon | braewoods: yes, that's a lot of code , i have some functions marked as dock code in it, so if you want let me know |
| 20:31:40 | braewoods | can ghidra even use it? |
| 20:31:44 | braewoods | o.O |
| 20:31:57 | speachy | often one ends up using decidated hw timer peripherals to measure the pulses |
| 20:31:57 | b0hoon | don't know :O |
| 20:32:19 | speachy | if the image is compessed/encrypyed, no. |
| 20:32:32 | braewoods | right, i need to decrypt the raw binary first |
| 20:32:35 | braewoods | i already figured out how to do that |
| 20:32:43 | braewoods | assuming mi4code is the right tool |
| 20:32:51 | braewoods | i found the key in our existing rockbox code |
| 20:33:38 | speachy | but if it's a straight dump of what the CPU would be reading, then sure, ghidra can work with it. you'll need to tell it it's a raw ARMv4T (little endian) image, maybe point at the enry point (reset vector is one of the first words in the image; #2 maybe?) to get things started |
| 20:34:02 | speachy | but this sort of stuff has a _very_ steep learning curve. |
| 20:34:32 | speachy | even with IDA or ghidra one has to know a lot about the low-level architecture |
| 20:35:42 | speachy | but with either you can look for static accesses to certain address ranges (eg gpio control/status) and work back from there.. |
| 20:38:41 | b0hoon | braewoods: the code is so messed up by the compiler that you will probably walk for a beer |
| 20:39:18 | b0hoon | ;) |
| 20:41:16 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 20:42:23 | braewoods | speachy: what would you recommend if i wanted to check the signals? |
| 20:42:56 | braewoods | i could disassembly the cradle and see what it does on the pins |
| 20:43:12 | braewoods | probably easiest way to access the raw pins |
| 20:44:14 | speachy | I mean, there are cheapie logic analyzers to be had |
| 20:45:18 | braewoods | ok.. |
| 20:46:54 | b0hoon | yeah logic analyzer would be the simplest solution. |
| 20:47:39 | braewoods | i'll look into it later, i think i'm going to have to see what it's doing |
| 20:48:02 | braewoods | but yea, I2C would be overkill for something this simple |
| 20:52:00 | speachy | but yeah, you're at the point where you're going to need more specialized tools |
| 20:54:49 | braewoods | i'll looked into it when i get paid again |
| 20:54:52 | braewoods | i'm tapped out for now |
| 20:55:02 | braewoods | until then i see no harm in looking through the OF |
| 20:55:45 | braewoods | objdump seems to do a terrible job for disassembling raw binary |
| 20:55:47 | braewoods | though |
| 20:57:22 | braewoods | i tried that first |
| 20:57:22 | braewoods | speachy: i'll try what bilgus said if my other efforts don't go anywhere |
| 20:57:22 | braewoods | pocket oscilloscope |
| 20:57:22 | DBUG | Enqueued KICK braewoods |
| 20:57:22 | braewoods | but hm |
| 20:57:22 | braewoods | to decode a PWM signal... |
| 20:57:24 | braewoods | yea... the ADC may be involved |
| 20:57:28 | braewoods | but in what way? |
| 20:57:39 | braewoods | a pulse is an analog signal |
| 20:57:57 | | Quit daswf852 (Quit: Ping timeout (120 seconds)) |
| 20:58:27 | braewoods | just didn't seem likely to me originally since the ADC isn't even connected other than to the remote jack line |
| 20:58:40 | braewoods | it's constantly pulled high according to the ADC readout |
| 20:58:43 | braewoods | and schematic |
| 20:59:08 | braewoods | but the ADC1 line has no known use otherwise so |
| 20:59:19 | braewoods | there should be no harm in tinkering with it |
| 20:59:24 | braewoods | i'll investigate ADC first |
| 20:59:32 | braewoods | using the known one we use for battery reding |
| 20:59:40 | braewoods | that one is super simple so it should be easy to find in the OF |
| 20:59:59 | speachy | objdump does disam just fine, but what it won't do is give a stripped raw binary structure |
| 21:00 |
| 21:00:53 | b0hoon | bear in mind that this schematic may be not even the production one, this is leak |
| 21:01:14 | braewoods | indeed but it's better than nothing |
| 21:01:24 | b0hoon | sure |
| 21:02:23 | braewoods | i also plan to look into supporting TV out in rockbox, basically mirroring the LCD like we do for remotes |
| 21:02:35 | braewoods | i have 2 different ports that support it |
| 21:02:39 | braewoods | not ipods even |
| 21:02:40 | speachy | it's also highly doubtable that Philips has this information any more |
| 21:02:55 | braewoods | and even if they did they wouldn't help me i'm sure |
| 21:03:14 | braewoods | so i'm not even going to ask |
| 21:03:26 | speachy | assuming it was actually directly made by a division of Philips instead of just licensing the brand |
| 21:03:35 | speachy | (though I suppose given the age it progbably was) |
| 21:03:49 | speachy | (in any case, that division hasn't existed for a _long_ time) |
| 21:04:00 | b0hoon | i've asked for it once.. or twice... |
| 21:04:24 | braewoods | we generally can't expect help from the people we're trying to reverse engineer |
| 21:04:31 | braewoods | lol |
| 21:06:27 | b0hoon | i've asked NVIDIA for documentation, nicely ... I've received some response even. NOPE |
| 21:06:42 | speachy | (I actually work for Philips now. So I can't really say all that much one way or another. But if anyone has a name I can use as a starting point I can do some internal inquiries) |
| 21:07:12 | speachy | nVidia is infamously awful when it comes to documentation. |
| 21:08:52 | braewoods | speachy: https://gerrit.rockbox.org/r/#/c/rockbox/+/3316/ |
| 21:08:56 | braewoods | can you approve this? |
| 21:09:04 | braewoods | i found a logic error or one that looks awfully like one |
| 21:09:44 | braewoods | i found it earlier when bilgus was trying to help me |
| 21:09:51 | speachy | braewoods: 10d might actually be correct |
| 21:10:11 | braewoods | really? why does the rest of it use 0x? |
| 21:10:30 | speachy | ok, looking at the other context, I see that |
| 21:10:44 | speachy | (I've seen a lot of wierd crap over the years...) |
| 21:10:50 | speachy | (I've been responsible for some of it) |
| 21:10:52 | braewoods | i looked at the pattern of the surrounding code |
| 21:10:57 | braewoods | so i assumed it was a mistake |
| 21:11:12 | braewoods | 0x3 |
| 21:11:14 | braewoods | then 30 |
| 21:11:18 | braewoods | then 0x300 |
| 21:11:20 | braewoods | 0x3000 |
| 21:11:22 | braewoods | so |
| 21:11:25 | braewoods | yea |
| 21:11:28 | braewoods | i assume it works the same |
| 21:11:30 | speachy | so, has this been smoke tested to ensure it doesn't cause a regression? |
| 21:11:43 | braewoods | well i tested it with my hdd6330 |
| 21:11:52 | braewoods | but i honestly can't test them all |
| 21:12:50 | speachy | given that it's unknown it's possible it could trigger a sideeffect somewhere else, etc etc.. but you've shown that it doesn't immediately set your device on fire so that's a good sign. |
| 21:13:06 | braewoods | but if it causes problems it'd probably be with the battery stuff |
| 21:13:16 | fs-bluebot | Build Server message: New build round started. Revision 448f98d9c0, 298 builds, 10 clients. |
| 21:13:24 | braewoods | 30 is... |
| 21:13:38 | braewoods | 0b11110 |
| 21:13:46 | braewoods | 0x1e |
| 21:13:47 | speachy | 0x1e |
| 21:14:00 | braewoods | it overlaps mostly with the battery |
| 21:14:03 | braewoods | and partialy with itself |
| 21:14:17 | speachy | coudl explain some of the wonky battery stuff reported. |
| 21:14:36 | speachy | (that's never really reproducible on known-sane hardware...) |
| 21:14:56 | braewoods | old batteries could cause weird issues too |
| 21:15:02 | braewoods | i've seen it a few times |
| 21:15:41 | braewoods | but if it does cause issues we'll hear complaints about battery reporting |
| 21:15:51 | braewoods | but that's the only thing i can see happening |
| 21:16:03 | braewoods | the old bit pattern only overlapped with the battery low bits |
| 21:20:41 | | Quit ZincAlloy (Quit: Leaving.) |
| 21:21:20 | speachy | I'm more concerned with something different; eg the ADC is suddently "working" and triggering a code path that clearly hasn't ever actually worked before |
| 21:21:55 | braewoods | oh |
| 21:21:59 | braewoods | i see |
| 21:22:07 | braewoods | i'll test it on my H10 once I get it back from bilgus |
| 21:22:34 | speachy | "correct" != "works" |
| 21:22:42 | braewoods | lmao |
| 21:22:50 | braewoods | i know, mostly due to hardware bugs |
| 21:23:07 | braewoods | but we should try the correct way whenever possible |
| 21:23:10 | speachy | or a decade's worth of incorrect assumptions. |
| 21:23:52 | braewoods | in all honestly it looked like it should be this way. if they really meant to use the base 10 bit pattern they shoulda used a different one |
| 21:24:32 | speachy | I agree |
| 21:24:59 | | Part b0hoon |
| 21:25:02 | braewoods | our PP ports work quite well in spite of having no data sheets for the main cpu |
| 21:25:09 | fs-bluebot | Build Server message: Build round completed after 713 seconds. |
| 21:25:11 | fs-bluebot | Build Server message: Revision 448f98d9c0 result: All green |
| 21:25:29 | braewoods | speachy: is there a reason the mi4code utility isn't in our git tree? |
| 21:25:44 | braewoods | i think we should add it to tools so we don't lose it |
| 21:25:54 | braewoods | would you accept it if I added it? |
| 21:26:19 | braewoods | we already have part of it in our code anyway |
| 21:26:22 | braewoods | this is just the complete tool |
| 21:26:28 | speachy | license? |
| 21:27:07 | braewoods | just a copyright notice in the source file... |
| 21:27:09 | braewoods | let me look elsewhere |
| 21:27:25 | braewoods | no license given |
| 21:27:39 | speachy | which means we can't accept it. |
| 21:27:46 | braewoods | https://daniel.haxx.se/sansa/mi4code.c |
| 21:27:50 | braewoods | fair enough |
| 21:27:55 | braewoods | I guess i can just keep a private copy |
| 21:29:57 | speachy | bagder might be able to provide more info on this, but it's ultimately in MrH's hands. |
| 21:30:24 | braewoods | is that Daniel Stenberg? |
| 21:30:29 | braewoods | seems to own the domain |
| 21:31:53 | braewoods | I'll email him and see if he knows anything. |
| 21:31:56 | speachy | yep |
| 21:32:07 | braewoods | I want to ask if we can get an official license so we can include it. |
| 21:32:20 | braewoods | we'd like to archive it in case we need it for something |
| 21:32:35 | braewoods | and maintain it to a lesser degree |
| 21:32:38 | speachy | his whole site should be archived |
| 21:53:30 | braewoods | found something in the strings |
| 21:53:39 | braewoods | startmainui: registerKey: remoteVolUpKey |
| 21:53:48 | braewoods | that seems promising |
| 21:53:52 | braewoods | a debug thing probably |
| 21:54:24 | braewoods | i decided to run strings on the dump first |
| 21:54:29 | braewoods | see if i found anything interesting |
| 22:00 |
| 22:06:03 | braewoods | this reminds me of when i used to dig into linux source code to see if hardware was supported |
| 22:06:31 | | Quit dconrad () |
| 22:07:10 | *** | Saving seen data "./dancer.seen" |
| 22:17:40 | _bilgus | braewoods, did you try that pastebin code that dtps through the unknown bits? |
| 22:18:00 | _bilgus | steps* |
| 22:18:34 | braewoods | _bilgus: erm. that only set it once? |
| 22:18:42 | braewoods | _bilgus: i don't recall you giving me anything else |
| 22:18:48 | _bilgus | oh |
| 22:19:13 | braewoods | in any case i've been trying to examine the decrypted OF |
| 22:19:24 | braewoods | you want a copy? |
| 22:19:34 | _bilgus | https://pastebin.com/nA1LjinE |
| 22:19:56 | _bilgus | the OF won't help yet I want a dump of the memory of those registers |
| 22:20:13 | _bilgus | like when the OF has been working |
| 22:20:54 | braewoods | i see |
| 22:22:03 | _bilgus | actually with some careful sleuthing you can intuit some things watching the registers switch, I see it has a jtag on that schema |
| 22:22:36 | braewoods | indeed but i have no way to access it |
| 22:23:09 | _bilgus | opening the device will get you closer |
| 22:23:38 | _bilgus | at least then you might narrow down the mechanism |
| 22:24:43 | braewoods | https://dpaste.com/8E9Z7XES4 |
| 22:27:17 | _bilgus | just add ; |
| 22:28:13 | _bilgus | the splash might be too early to not crash the player |
| 22:28:28 | _bilgus | in that case i'll re-work it a bit |
| 22:29:57 | _bilgus | hmm I wonder if those PWM pins are actually the other two ADCs the other devices have |
| 22:30:06 | _bilgus | maybe we are chasing the wrong ones |
| 22:30:47 | _bilgus | doesn't seem like theyd multiplex those two functions on a single pin path |
| 22:31:12 | braewoods | one problem with that theory |
| 22:31:25 | braewoods | one of them is connected to the LCD backlight which we do have code for |
| 22:31:29 | braewoods | but it's an output |
| 22:31:42 | braewoods | aren't ADCs always inputs? |
| 22:31:48 | _bilgus | well you have the address so go up or down 32 bits |
| 22:32:10 | _bilgus | and PWMs are *almost* always outs |
| 22:32:46 | _bilgus | I can't see why you'd do some weird stuff with reading PWM levels when you can just use an adc |
| 22:33:09 | braewoods | anyway i'll run the code you asked me to |
| 22:33:23 | _bilgus | and I'm not sure its even possible I've never seen one that wasn't std gpio when an input |
| 22:33:41 | _bilgus | but... |
| 22:35:24 | | Join f1reflyylmao [0] (~f1refly@dynamic-077-003-043-006.77.3.pool.telefonica.de) |
| 22:36:09 | braewoods | btw you used splash instead of splashf |
| 22:36:45 | braewoods | anyway |
| 22:36:52 | braewoods | time to run this |
| 22:37:41 | | Quit f1refly (Ping timeout: 240 seconds) |
| 22:37:42 | | Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-077-003-043-006.77.3.pool.telefonica.de) |
| 22:43:56 | braewoods | _bilgus: nothing that i can tell |
| 22:45:08 | braewoods | 80000000? |
| 22:45:17 | braewoods | was it meant to be 0x80000000? |
| 22:49:59 | _bilgus | it stops at 0x8000000 |
| 22:50:04 | _bilgus | did it splash |
| 22:50:07 | braewoods | no |
| 22:50:30 | _bilgus | then the adc never changed i assume you went to the debug menu |
| 22:50:36 | braewoods | yea |
| 22:50:40 | braewoods | i waited a bit |
| 22:50:45 | braewoods | it changed but stayed about 3f0 |
| 22:51:03 | _bilgus | oh you need to hold the remote button |
| 22:51:11 | braewoods | i just tapped it |
| 22:51:13 | _bilgus | like the vol up something that repeats |
| 22:51:14 | braewoods | is that the problem? |
| 22:51:32 | braewoods | ok i'll try that instead |
| 22:51:36 | _bilgus | yeah just hold it incase you miss it while it scans |
| 22:54:18 | braewoods | i held the button but nothing |
| 22:54:25 | _bilgus | and probably from the time it boots it will take a bit like probably 1 minute |
| 22:54:45 | braewoods | you want me to boot it up again and wait longer? |
| 22:54:49 | _bilgus | oh well I'm out of ideas then |
| 22:55:01 | _bilgus | maybe its something weird |
| 22:55:55 | braewoods | i'll wait a bit then |
| 22:56:50 | _bilgus | idk I think a pocket oscope would probably do ya some good like 50-100 mhz is ok.. |
| 23:00 |
| 23:02:03 | _bilgus | mine is a 'portable' from 1980ish |
| 23:02:18 | _bilgus | it weighs 35 lbs so its portable lol |
| 23:02:55 | _bilgus | its 100 MHZ and I can count maybe 2x that it wasn't adequate |
| 23:03:12 | _bilgus | though it is a 4 chan scope |
| 23:03:47 | _bilgus | but i've been eyeing those pocket scopes itd come in handy in the garage |
| 23:04:59 | _bilgus | like the missing shielding on a CPS sensor causing spurious signals lol I caught that one with the scope strapped to the hood with a power inverter |
| 23:26:10 | | Join daswf852 [0] (~daswf852@unaffiliated/dwf) |
| 23:30:59 | braewoods | _bilgus: i decided to try enabling all the AIN lines |
| 23:31:02 | braewoods | interesting results |
| 23:31:07 | braewoods | the 4th channel is always 0 |
| 23:31:14 | braewoods | the 3rd channel is jumping around |
| 23:36:18 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-14ba-5001-4fff-7f89.res6.spectrum.com) |
| 23:56:33 | | Quit prg3 (Quit: ZNC 1.8.2 - https://znc.in) |
icon identifies that the person is a core developer (has commit access).