| 00:04:24 | | Quit Saijin_Naib (Ping timeout: 258 seconds) |
| 00:07:14 | *** | Saving seen data "./dancer.seen" |
| 00:08:04 | _bilgus | in a coherent fashion? |
| 00:09:15 | braewoods | _bilgus: well |
| 00:09:26 | braewoods | _bilgus: it increases until it hits 0x60 or so then drops back to near 0 |
| 00:09:28 | braewoods | and repeats again |
| 00:09:32 | braewoods | regardless of what i do |
| 00:09:54 | braewoods | it's consistentin this behavior but otherwise still erratic |
| 00:10:19 | braewoods | i had an idea though |
| 00:10:33 | braewoods | would it be a bad idea to create an I2C bus scanner for our debug menu? |
| 00:10:42 | braewoods | it could help with future ports if I2C is involved |
| 00:11:10 | braewoods | might even help with identifying mystery chips |
| 00:17:10 | | Quit pixelma (*.net *.split) |
| 00:17:10 | | Quit Soap_ (*.net *.split) |
| 00:17:10 | | Quit SammysHP (*.net *.split) |
| 00:17:10 | | Quit Natch (*.net *.split) |
| 00:17:10 | | Quit copper (*.net *.split) |
| 00:17:10 | | Quit Xeha (*.net *.split) |
| 00:17:10 | | Quit aevin (*.net *.split) |
| 00:17:10 | | Quit kugel (*.net *.split) |
| 00:17:10 | | Quit kakaka (*.net *.split) |
| 00:17:12 | | Quit rasher (*.net *.split) |
| 00:17:12 | | Quit toruvinn (*.net *.split) |
| 00:17:13 | | Quit blbro[m] (*.net *.split) |
| 00:17:13 | | Quit mud (*.net *.split) |
| 00:17:13 | | Quit APLU (*.net *.split) |
| 00:17:14 | | Quit klock (*.net *.split) |
| 00:17:14 | | Quit lemon_jesus (*.net *.split) |
| 00:17:14 | | Quit trfl (*.net *.split) |
| 00:17:14 | | Quit prg3 (*.net *.split) |
| 00:17:14 | | Quit f1refly (*.net *.split) |
| 00:17:14 | | Quit TheSphinX^ (*.net *.split) |
| 00:17:14 | | Quit JanC (*.net *.split) |
| 00:17:14 | | Quit Acou_Bass (*.net *.split) |
| 00:17:14 | | Quit emacsomancer (*.net *.split) |
| 00:17:14 | | Quit speachy (*.net *.split) |
| 00:17:15 | | Quit Galois (*.net *.split) |
| 00:17:15 | | Quit __builtin (*.net *.split) |
| 00:17:15 | | Quit blucifer22 (*.net *.split) |
| 00:17:15 | | Quit mikroflops (*.net *.split) |
| 00:17:15 | | Quit akaWolf (*.net *.split) |
| 00:17:16 | | Quit Barlow (*.net *.split) |
| 00:17:16 | | Quit Moarc (*.net *.split) |
| 00:17:16 | | Quit Strife89 (*.net *.split) |
| 00:17:16 | | Quit Topy44 (*.net *.split) |
| 00:17:16 | | Quit Romster (*.net *.split) |
| 00:17:16 | | Quit gevaerts (*.net *.split) |
| 00:17:16 | | Quit kirvesAxe (*.net *.split) |
| 00:17:17 | | Quit kadoban (*.net *.split) |
| 00:17:17 | | Quit hook54321 (*.net *.split) |
| 00:17:17 | | Quit edhelas (*.net *.split) |
| 00:17:17 | | Quit michaelni (*.net *.split) |
| 00:17:17 | | Quit shrizza (*.net *.split) |
| 00:17:18 | | Quit ufdm (*.net *.split) |
| 00:17:19 | | Quit fauweh (*.net *.split) |
| 00:17:19 | | Quit jerwin (*.net *.split) |
| 00:17:19 | | Quit alexbobp (*.net *.split) |
| 00:17:19 | | Quit KalBot (*.net *.split) |
| 00:17:19 | | Quit massiveH (*.net *.split) |
| 00:17:19 | | Quit asaba (*.net *.split) |
| 00:17:19 | | Quit fs-bluebot (*.net *.split) |
| 00:17:19 | | Quit ps-auxw (*.net *.split) |
| 00:17:19 | | Quit bertrik (*.net *.split) |
| 00:17:19 | | Quit xcin (*.net *.split) |
| 00:17:20 | | Quit St3ak (*.net *.split) |
| 00:17:20 | | Quit plum (*.net *.split) |
| 00:17:20 | | Quit bluebrother (*.net *.split) |
| 00:17:21 | | Quit Tsesarevich (*.net *.split) |
| 00:17:21 | | Quit vup (*.net *.split) |
| 00:17:21 | | Quit ac_laptop (*.net *.split) |
| 00:17:21 | | Quit Rower (*.net *.split) |
| 00:17:21 | | Quit CR0W (*.net *.split) |
| 00:17:21 | | Quit amiconn (*.net *.split) |
| 00:17:22 | | Quit bzed (*.net *.split) |
| 00:17:22 | | Quit ChanServ (*.net *.split) |
| 00:18:04 | | Join prg3 [0] (~prg@deadcodersociety/prg318) |
| 00:18:04 | | Join f1refly [0] (~f1refly@dynamic-077-003-043-006.77.3.pool.telefonica.de) |
| 00:18:04 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 00:18:04 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 00:18:04 | | Join TheSphinX^ [0] (~briehl@srv001.nosupamu.de) |
| 00:18:04 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
| 00:18:04 | | Join JanC [0] (~janc@lugwv/member/JanC) |
| 00:18:04 | | Join blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-tlbkackcydjojpba) |
| 00:18:04 | | Join kadoban [0] (kadobanemp@gateway/shell/matrix.org/x-zbemkkpthikwihsa) |
| 00:18:04 | | Join mud [0] (kadobanmat@gateway/shell/matrix.org/x-zgbmebmtuhdubutk) |
| 00:18:04 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 00:18:04 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
| 00:18:04 | | Join Xeha [0] (~Xeha@unaffiliated/xeha) |
| 00:18:04 | | Join copper [0] (~copper@unaffiliated/copper) |
| 00:18:04 | | Join Natch [0] (~natch@c-b471e255.014-297-73746f25.bbcust.telenor.se) |
| 00:18:04 | | Join SammysHP [0] (~SammysHP@faol.sammyshp.de) |
| 00:18:04 | | Join Soap_ [0] (~Soap@rockbox/staff/soap) |
| 00:18:04 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 00:18:04 | | Join hook54321 [0] (sid149355@gateway/web/irccloud.com/x-mxonnkmjnhseenax) |
| 00:18:04 | | Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx) |
| 00:18:04 | | Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) |
| 00:18:04 | | Join toruvinn [0] (~toruvinn@77-255-90-179.adsl.inetia.pl) |
| 00:18:04 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 00:18:04 | | Join trfl [0] (~ed@static.59.110.40.188.clients.your-server.de) |
| 00:18:04 | | Join lemon_jesus [0] (~lemon_jes@208.59.79.137) |
| 00:18:04 | | Join klock [0] (~freeklock@unaffiliated/klock) |
| 00:18:04 | | Join APLU [0] (~mulx@2a03:7220:8081:2900::1) |
| 00:18:04 | | Join speachy [0] (~speachy@209.2.65.77) |
| 00:18:04 | | Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) |
| 00:18:04 | | Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 00:18:04 | | Join blucifer22 [0] (~quassel@204.48.30.120) |
| 00:18:04 | | Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) |
| 00:18:04 | | Join __builtin [0] (~quassel@rockbox/developer/builtin) |
| 00:18:04 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 00:18:04 | | Join kirvesAxe [0] (kirvesaxe@aulis.sange.fi) |
| 00:18:04 | | Join gevaerts [0] (~fg@rockbox/developer/gevaerts) |
| 00:18:04 | | Join Romster [0] (~romster@unaffiliated/romster) |
| 00:18:04 | | Join Topy44 [0] (YwgdD0qBv9@bellatrix.uberspace.de) |
| 00:18:04 | | Join Strife89 [0] (~quassel@adsl-74-250-151-186.ags.bellsouth.net) |
| 00:18:04 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 00:18:04 | | Join Barlow [0] (~barlow@unaffiliated/barlow) |
| 00:18:04 | | Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net) |
| 00:18:04 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 00:18:04 | | Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257) |
| 00:18:04 | | Join alexbobp [0] (~alex@meowface.org) |
| 00:18:04 | | Join jerwin [0] (~flippy-fl@unaffiliated/flippy) |
| 00:18:04 | | Join KalBot [0] (~matrixirc@connolly.tech) |
| 00:18:04 | | Join fauweh [0] (~root@ithaqua.unzane.com) |
| 00:18:04 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 00:18:04 | | Join xcin [0] (~x@159.203.132.140) |
| 00:18:04 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 00:18:04 | | Join ps-auxw [0] (~arneb@p548d5577.dip0.t-ipconnect.de) |
| 00:18:04 | | Join fs-bluebot [0] (~fs-bluebo@55d48c6a.access.ecotel.net) |
| 00:18:04 | | Join asaba [0] (~asaba@103.113.159.184) |
| 00:18:04 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 00:18:04 | | Join plum [0] (~plum@unaffiliated/plum) |
| 00:18:04 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
| 00:18:04 | | Join vup [0] (~~~~@46.101.193.235) |
| 00:18:04 | | Join bzed [0] (~bzed@shell.bzed.at) |
| 00:18:04 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 00:18:04 | | Join CR0W [0] (~narf@unaffiliated/em64t) |
| 00:18:04 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 00:18:04 | | Join ChanServ [0] (ChanServ@services.) |
| 00:18:04 | Mode | "#rockbox +o ChanServ " by weber.freenode.net |
| 00:20:04 | | Quit hook54321 (Ping timeout: 252 seconds) |
| 00:20:11 | | Quit Topy44 (Ping timeout: 240 seconds) |
| 00:20:47 | | Quit mud (Ping timeout: 245 seconds) |
| 00:20:48 | | Quit kadoban (Ping timeout: 252 seconds) |
| 00:20:49 | | Quit ccf-100 (Ping timeout: 245 seconds) |
| 00:21:11 | | Quit Tsesarevich (Ping timeout: 245 seconds) |
| 00:21:12 | | Quit blbro[m] (Ping timeout: 245 seconds) |
| 00:21:28 | | Quit danielp3344 (Ping timeout: 258 seconds) |
| 00:21:57 | | Join Topy44 [0] (cwiyZqj6DG@bellatrix.uberspace.de) |
| 00:22:47 | | Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx) |
| 00:23:58 | | Quit Tsesarevich (Excess Flood) |
| 00:24:09 | | Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx) |
| 00:25:34 | | Join hook54321 [0] (sid149355@gateway/web/irccloud.com/x-ooorectxhiwufpta) |
| 00:27:19 | braewoods | speachy: i noticed the DAC3550A has a driver but nothing uses it. Was it an ArchOS only driver? |
| 00:33:18 | | Quit ac_laptop (Ping timeout: 240 seconds) |
| 00:55:07 | _bilgus | you can probably use lua for that |
| 00:55:23 | | Join mud [0] (kadobanmat@gateway/shell/matrix.org/x-wpnmsqvzvkvptipj) |
| 00:55:31 | braewoods | _bilgus: indeed... but is there a platform agnostic set of i2c functions? |
| 00:55:38 | braewoods | i can't find any so far |
| 00:55:46 | braewoods | i2c.h seems to not be implemented by all targets |
| 00:56:04 | _bilgus | of course not |
| 00:56:16 | braewoods | ok. that's what i thought. |
| 00:56:57 | _bilgus | i2c.h hould get it all abstracted though |
| 00:56:57 | braewoods | in any case that means I need to implement the scanner for each platform |
| 00:57:18 | _bilgus | yes the debuf menus are all chock full of device specific code |
| 00:57:29 | braewoods | _bilgus: i know but i2c_read doesn't appear to be implemented on for example PP |
| 00:59:08 | braewoods | anyway thanks for the advice |
| 01:00 |
| 01:01:57 | | Quit massiveH (Quit: Leaving) |
| 01:12:44 | | Join ccf-100 [0] (ccf-100mat@gateway/shell/matrix.org/x-zhthrpugyvbsohxa) |
| 01:12:44 | | Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-mszjopzrirssqien) |
| 01:12:44 | | Join kadoban [0] (kadobanemp@gateway/shell/matrix.org/x-gxlvabnrocccxmxd) |
| 01:12:50 | | Join blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-qdhfayhmwlpdjpwj) |
| 01:38:50 | | Quit pixelma (Quit: .) |
| 01:38:50 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 01:39:03 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 01:39:03 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 01:41:23 | | Quit amiconn (Client Quit) |
| 01:41:23 | | Quit pixelma (Client Quit) |
| 01:43:51 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 01:43:52 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 01:52:04 | braewoods | how strange... there's no I2C ack on PP so there's no way to know if it was received or w/e |
| 02:00 |
| 02:07:18 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:15:55 | braewoods | _bilgus: i had an idea. |
| 03:16:13 | braewoods | other PP targets we support also sometimes have schematics available online if you look hard enough |
| 03:16:33 | braewoods | maybe i can find one where the mystery pin is connected and has a known use |
| 03:17:39 | braewoods | hah go figure... the yh-925gs doesn't use the PWM pins |
| 03:23:29 | braewoods | huh... |
| 03:23:41 | braewoods | yh-820 uses the pwm pins if the schematic is to be believed |
| 04:00 |
| 04:01:06 | | Quit jdarnley (Ping timeout: 240 seconds) |
| 04:07:20 | *** | Saving seen data "./dancer.seen" |
| 04:18:09 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:4532:b8a5:c30b:e1f6) |
| 04:37:09 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 04:52:04 | | Join PimpiN8 [0] (~PimpiN8@178.239.173.176) |
| 04:55:10 | braewoods | interesting |
| 04:55:33 | braewoods | apparently the first few bytes are what amounts to an entry point table |
| 04:55:55 | braewoods | and given how what i'm looking for appears to have an interrupt associated with it |
| 04:56:21 | braewoods | i will probably want to look at the entry point associated with the interrupt handler |
| 04:56:42 | braewoods | that will likely lead to where the data is read from |
| 04:56:55 | braewoods | it may not initialize it but it may give some ideas |
| 05:00 |
| 05:00:06 | | Quit mud (Quit: Idle for 30+ days) |
| 05:05:39 | | Join lebellium_ [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 05:06:11 | | Quit lebellium (Ping timeout: 240 seconds) |
| 05:08:31 | bluebrother | braewoods: iirc there are 2 different OF versions of the Beast. The older one would allow to dualboot, the newer would always run into that exclamation mark screen and restore the whole player when using dualboot. Singleboot is fine on that though. |
| 05:09:09 | | Quit WakiMiko (Ping timeout: 258 seconds) |
| 05:09:23 | bluebrother | could also have been the other way round, but if memory serves me right the old firmware was working with dualboot. |
| 05:10:55 | | Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) |
| 05:14:04 | bluebrother | and iirc you could downgrade your player to the older firmware. You'd need to get the nk.bin and use it with beastpatcher. |
| 05:54:56 | braewoods | bluebrother: i'll figure it out in time |
| 05:54:58 | braewoods | thanks |
| 06:00 |
| 06:07:23 | *** | Saving seen data "./dancer.seen" |
| 06:23:34 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 06:31:23 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 06:37:41 | | Join nihilazo [0] (e33ac355b6@198.108.76.81) |
| 06:38:31 | nihilazo | hi, I'm trying to disable the display on my xduoo x3 running rockbox (I use the audio menus) and I can't figure out how to do it, on my old sansa fuze+ I just set the backlight to 0 but I'm not able to do that on the xduoo. |
| 06:48:08 | braewoods | speachy: one for you ^ |
| 07:00 |
| 07:49:09 | speachy | braewoods: any i2c scanner is going to behighly problematic, as there's no way to guarantee any response from a random i2c device. |
| 07:50:27 | speachy | nihilazo: I don't recall offhand, but that screen doesn't have a backlight. but you could dial the brightness down to 0 instead? |
| 07:51:05 | | Join amachronic [0] (5284b8be@82.132.184.190) |
| 07:54:06 | speachy | dial the backlight setting to "never" and lowest brightness, that's probably the best one can do. Problem is if we disable the display entirely that can render the device unusuable without manually editing thec onfigug on disk. |
| 07:55:58 | _bilgus | it was the same with the clips |
| 07:56:25 | _bilgus | I never understood why we had that but ^thats probably why |
| 07:57:19 | speachy | yeah, an LCD display can at least be seen under sufficiently bright light, but an LED display.. no output means no output. |
| 07:58:12 | amachronic | braewoods, _bilgus: (logs) I did add a platform-independent i2c interface, look for i2c-async. but you'd have to redesign PP's I2C implementation to fit that interface + it's maybe more complex. |
| 07:59:41 | speachy | amachronic: and that's still largely useless for a "scanner" because there isn't any standard probing mechanism for i2c devices. quite the opposite, in fact. |
| 08:00 |
| 08:01:13 | amachronic | yep. but that's the nature of i2c. |
| 08:02:08 | speachy | exactly. a standard API is a good thing, but no non-platform/target code would be able to do anything useful with i2c. |
| 08:03:03 | speachy | (IIRC the new "I3C" stuff does standardize probing. but that's neither here nor there..) |
| 08:07:24 | *** | No seen item changed, no save performed. |
| 08:16:03 | amachronic | speachy: what was your plans for the x1000 USB driver? hoist out the dwc2 ARM code and use same code for all platforms, or just a copypaste and specialize to x1000? |
| 08:16:36 | speachy | pull dwc2 out of ARM, essentially |
| 08:17:07 | Ctcp | Ignored 2 channel CTCP requests in 8 hours and 12 minutes at the last flood |
| 08:17:07 | * | braewoods pulls a dwc2 out of their hat. |
| 08:17:08 | speachy | at this point I don't see why it would need to meaningfully differ. |
| 08:17:31 | speachy | but granted I've barely looked into it yet. too many other fires... |
| 08:19:37 | speachy | IIRC there's not a lot of room for customization in the dwc2 core. Plus it uses its own internal DMA engine. |
| 08:20:13 | speachy | in theory all we should ultimately need to do is point the driver at a new base address in the memory map. |
| 08:20:40 | speachy | but I'm not going to bank on _that_ :) |
| 08:21:00 | amachronic | lol. I was thinking of getting a gdb stub running, so if ever I get around to it, I just wanted to know how to split up the commits. |
| 08:21:53 | amachronic | since dconrad's m3k is behaving strangely I'm hoping gdb might shed light on it, but idk. |
| 08:22:54 | speachy | I did finally extract my m3k, but I keep getting distracted with bugs elsewhere |
| 08:23:12 | speachy | (and the honey-do list..) |
| 08:27:12 | speachy | the dwc driver is already reasonably self-contained. only some platform-specific stubs for init/enable/irq and the instantiation options for the core. |
| 08:27:45 | speachy | so yeah, I'm feeling cautiously optimistic. |
| 08:28:10 | amachronic | I figured as much, but I haven't looked into it yet either |
| 08:31:09 | nihilazo | speachy: thanks, setting backlight to never works |
| 08:31:55 | nihilazo | (I love rockbox's speech options! I'm not sight-impaired but I prefer it as an interface because I don't ever have to actually look at my player. Very convenient) |
| 08:35:34 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-006c-5440-4ecc-d94c.res6.spectrum.com) |
| 08:40:30 | speachy | nihilazo: I'm in the same boat; I find the speech interface invaluable when driving |
| 08:44:33 | nihilazo | I often use my player for podcasts and meditation timers when I'm in bed and it's good to have the speech interface then because I'm too lazy to look over at the display |
| 08:47:39 | | Quit Saijin_Naib (Ping timeout: 258 seconds) |
| 08:48:41 | speachy | too bad I no longer have access to those sweet ellisys bluetooth sniffers. :/ |
| 09:00 |
| 09:24:54 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 09:30:10 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 09:34:08 | dconrad | hey amachronic, I've got a cup of coffee and an m3k, do you want to do some test builds? |
| 09:35:32 | amachronic | yep can you first download https://build.rockbox.org/data/rockbox-fiiom3k.zip (vanilla master build) and extract it to your SD card. |
| 09:36:13 | dconrad | alright, one moment |
| 09:36:32 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-0066-1b2a-1c3a-b4b9.res6.spectrum.com) |
| 09:38:21 | dconrad | got it |
| 09:38:58 | amachronic | cherrypick the latest g#3290 and build the SPL, and do a USB boot with this command: |
| 09:39:00 | fs-bluebot | Gerrit review #3290 at https://gerrit.rockbox.org/r/c/rockbox/+/3290 : (DO NOT MERGE) Debugging a hardware init problem with the FiiO M3K by amachronic |
| 09:39:09 | amachronic | sudo ./usbboot -v -c x1000 -1 ../../build-spl/spl.m3k −−wait 60 -a 0xa2000000 -l 0x100000 -u /tmp/memdump |
| 09:39:29 | dconrad | hm, interesting, ok one moment |
| 09:39:31 | amachronic | just want to make sure first that the RAM is not getting corrupted. |
| 09:39:55 | amachronic | in case your hardware is different, but it's very unlikely to be the problem. |
| 09:40:12 | dconrad | yeah I'm baffled why I seem to be the only one to have this issue |
| 09:41:42 | amachronic | oh forgot to say, do hexdump -C /tmp/memdump after the usbboot finishes. It should be all zeros. |
| 09:47:06 | dconrad | just to clarify, the two hex values are 0xa2000000 (6 zeroes) and 0x100000 (5 zeroes)? |
| 09:47:30 | amachronic | yeah I copy pasted from my own terminal |
| 09:47:52 | dconrad | ok, the lengths just seemed weird |
| 09:47:56 | dconrad | here we go |
| 09:48:31 | dconrad | so this is only doing the first part of the boot, and then dumping something to the computer's disk? |
| 09:49:25 | dconrad | oh, its -a address -l length, probably |
| 09:50:09 | dconrad | all zeroes |
| 09:50:29 | dconrad | uh, I can copy paste it if you would like |
| 09:50:35 | amachronic | no it's fine |
| 09:50:55 | amachronic | the RAM's getting initialized alright, give me a minute & I'll update gerrit with another thing to try |
| 09:56:09 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 09:58:00 | amachronic | pick from gerrit again and boot from USB like this: |
| 09:58:05 | amachronic | sudo ./usbboot -v -c x1000 -1 ../../build-spl/spl.m3k −−wait 1 -2 ../../build-boot/bootloader.bin |
| 09:58:12 | dconrad | ok |
| 09:58:35 | dconrad | do you know if I can do git pull or do I need to do git reset −−hard and then cherrypick it again? |
| 09:59:01 | amachronic | I'm not a git expert myself, so I'd do git reset −−hard to master and cherrypick again |
| 09:59:11 | dconrad | yeah probably safest |
| 10:00 |
| 10:02:06 | amachronic | it should stop just after printing 'Jumping...', then tell me what the addr:xxx data:xxx line says. |
| 10:02:19 | dconrad | alright |
| 10:03:02 | dconrad | address is 8005BA84, data is 40809000 |
| 10:03:15 | dconrad | t is still moving slowly |
| 10:03:18 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 10:03:24 | amachronic | ok, press vol+ |
| 10:03:31 | amachronic | addr should go up to 8005ba88 |
| 10:03:33 | amachronic | what's the data |
| 10:03:50 | | Quit lebellium_ (Ping timeout: 252 seconds) |
| 10:03:54 | dconrad | 40809800 |
| 10:04:21 | amachronic | ok vol+ again |
| 10:05:25 | dconrad | addr 8005ba8c, data 3c020040 |
| 10:06:01 | amachronic | seems like rockbox is getting read off the card so press the power button (just a quick press) |
| 10:06:52 | dconrad | t was changing on occasion, now it's stopped |
| 10:07:27 | *** | Saving seen data "./dancer.seen" |
| 10:07:37 | amachronic | well, control has transfered to Rockbox now, but it is hung somewhere. |
| 10:08:24 | dconrad | hm |
| 10:11:06 | | Quit Saijin_Naib (Read error: Connection reset by peer) |
| 10:12:24 | amachronic | out of curiousity, are you testing with your 2g card or another one? |
| 10:12:32 | dconrad | the 2g one, yeah |
| 10:12:49 | dconrad | do you want me to go get the one out of my good player? |
| 10:13:02 | dconrad | "good" |
| 10:13:07 | amachronic | you can try, see if it has a different result |
| 10:13:13 | dconrad | alright, one moment |
| 10:13:20 | amachronic | but imo it's probably not related |
| 10:13:35 | amachronic | given it didn't work before |
| 10:13:54 | dconrad | might as well |
| 10:14:20 | dconrad | ok, this is a genuine sandisk I bought at walmart like 5 years back, 64 gigs |
| 10:14:45 | dconrad | (I'm still impressed 64 gigs can be so small! and it was only a dollar a gig!) |
| 10:17:33 | dconrad | alright |
| 10:17:50 | dconrad | so it was vol+ twice, then power? |
| 10:17:57 | dconrad | do you want to know any of the values? |
| 10:18:03 | amachronic | no it's probably fine. |
| 10:18:06 | amachronic | just do power. |
| 10:18:30 | dconrad | yeah t just stopped updating |
| 10:18:55 | amachronic | updated gerrit again, retry with that. |
| 10:19:07 | speachy | dconrad: it's worth mentioning that I think you and amachronic might be the _only_ ones who have even tried this stuff. |
| 10:19:48 | amachronic | speachy: there are two people on the forums reporting a successful flash & boot, so idk what's wrong here. |
| 10:20:16 | amachronic | but anyway debugging this crap is like needle in a haystack. ;) |
| 10:20:55 | dconrad | is this just a bootloader/spl change, or should I put a new .rockbox on the card? |
| 10:21:08 | amachronic | oh sorry, you should use the new .rockbox. |
| 10:21:14 | dconrad | ok |
| 10:21:56 | amachronic | this one should start flashing the button lights after you boot it, assuming it gets to Rockbox's main(). |
| 10:24:25 | dconrad | yeah the buttons are flashing |
| 10:24:44 | amachronic | OK. good news. now we're getting somewhere. |
| 10:24:55 | dconrad | woohoo! |
| 10:25:23 | dconrad | so the bootloader is functional? |
| 10:25:25 | fs-bluebot | Build Server message: New build round started. Revision 1303be3437, 298 builds, 10 clients. |
| 10:26:20 | amachronic | well, idk, but whatever is going wrong we have a chance of finding it now. |
| 10:26:44 | dconrad | haha, onwards and downwards |
| 10:27:43 | amachronic | pushed to gerrit, do a rebuild of Rockbox and boot again. |
| 10:27:56 | amachronic | uh sorry don't. |
| 10:28:06 | amachronic | realized I moved code to wrong place |
| 10:28:39 | dconrad | whoops |
| 10:29:03 | amachronic | ok, fixed, try now |
| 10:29:19 | dconrad | alright |
| 10:34:35 | dconrad | should the buttons still be flashing? |
| 10:34:45 | dconrad | they're not |
| 10:34:55 | amachronic | they should flash. |
| 10:34:58 | dconrad | hm |
| 10:35:02 | amachronic | if they're not the bug is in system_init() |
| 10:35:06 | amachronic | so we'll drill down |
| 10:36:41 | fs-bluebot | Build Server message: Build round completed after 676 seconds. |
| 10:36:44 | fs-bluebot | Build Server message: Revision 1303be3437 result: All green |
| 10:39:08 | dconrad | boy this microsd card reader I bought the other day is really a gamechanger though |
| 10:39:18 | dconrad | be a pain in the butt without it |
| 10:39:51 | amachronic | probably faster if you edit locally: go to firmware/target/mips/ingenic_x1000/system-x1000.c, line 120 |
| 10:40:27 | amachronic | add call to DIE() underneath system_init_clk(). recompile Rockbox and try again. |
| 10:40:55 | dconrad | ok, one minute |
| 10:42:29 | dconrad | line 120? |
| 10:42:56 | amachronic | should have comment /* Setup system clocks */ right above the call in question |
| 10:43:06 | amachronic | in function system_init(). |
| 10:43:08 | dconrad | yeah, in system_init() |
| 10:43:10 | dconrad | ok |
| 10:46:23 | dconrad | wait, something went wrong, I didn't get all the debug info in the bootloader |
| 10:46:40 | amachronic | where does it hang? |
| 10:46:58 | amachronic | OH sorry this would affect the bootloader too. |
| 10:47:07 | amachronic | lemme fix this |
| 10:48:03 | amachronic | just reset and pull from gerrit now. |
| 10:48:25 | dconrad | alright |
| 10:50:22 | speachy | ok, g#3317 will probably end the all-green build page. |
| 10:50:24 | fs-bluebot | Gerrit review #3317 at https://gerrit.rockbox.org/r/c/rockbox/+/3317 : misc: Don't include rbpaths.h and string-extra.h in settings.h by Solomon Peachy |
| 10:50:30 | dconrad | oh fun, if I leave that file open in my text editor I can follow along |
| 10:51:04 | speachy | everything I'm locally building is now clean, at least. |
| 10:52:33 | dconrad | one thing I notice, should the file size in the bootloader match the checksum read: line and the load_firmware ret= line? |
| 10:53:02 | dconrad | anyway, no flashing keypad |
| 10:54:15 | dconrad | hm, can I check my process one second? I'll put DIE() (with ifndef) in front of system_init_clk() |
| 10:54:48 | amachronic | made a mistake I was too aggressive and pushed DIE back too early. |
| 10:55:00 | amachronic | it should go after the /* Ungate timers */ block |
| 10:55:36 | amachronic | updated gerrit |
| 10:55:51 | dconrad | ok, one moment |
| 10:56:04 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-0066-1b2a-1c3a-b4b9.res6.spectrum.com) |
| 10:56:12 | amachronic | The sizes reported by the bootloader should differ by 8, one of them includes the header and the other does not. |
| 10:56:17 | amachronic | so no concern there. |
| 10:56:30 | dconrad | oh cool, that's exactly how much the differ |
| 10:57:56 | dconrad | just for my own curiosity, where is the DIE() call now? |
| 10:58:11 | amachronic | still in system_init(), just moved down a few lines. |
| 10:58:23 | amachronic | right below the block ending with jz_set(TCU_STOP, 0x180ff); |
| 10:58:36 | dconrad | oh I see it now |
| 10:58:46 | amachronic | cause without those timers being turned on, the light won't flash anyway. |
| 11:00 |
| 11:00:45 | dconrad | no flashies |
| 11:02:07 | amachronic | ARGH I am being stupid, haven't had to debug like this for a while. |
| 11:02:50 | amachronic | try again from gerrit |
| 11:03:08 | amachronic | this time I actually tested locally, lol |
| 11:03:16 | dconrad | ok, just to forewarn you I think pancakes are about to happen so I might have to step away for a second |
| 11:03:48 | amachronic | haha no problem, if you want to try later or tommorrow it's fine by me. |
| 11:03:56 | amachronic | since this looks like it's going to drag on a while. |
| 11:04:43 | dconrad | I reckon I can probably eat at the computer here, I'll see |
| 11:05:31 | dconrad | I really want to keep going since we have some momentum |
| 11:07:57 | dconrad | still no flashing |
| 11:08:07 | dconrad | one second, I'll be right back |
| 11:10:32 | dconrad | ok back |
| 11:10:39 | dconrad | and with breakfast, yum |
| 11:11:11 | dconrad | give what we know right now, where could I put the die call just to verify that I'm not doing something wrong with my process? |
| 11:11:19 | dconrad | just to double check |
| 11:12:09 | amachronic | put it in main() in apps/main.c, right above CHART(">init") |
| 11:12:20 | amachronic | it worked there before |
| 11:12:27 | amachronic | but due to alignment it may not work there again. |
| 11:12:39 | dconrad | alright, I'll give it a shot |
| 11:12:48 | amachronic | in case my theory of this being a memory corruption problem is true. |
| 11:15:06 | dconrad | you figure something is writing somewhere it shouldn't? |
| 11:15:41 | amachronic | yes, that seems most likely. but it might also be a PLL initialization problem in case PLL never stabilizes we get trapped in an infinite loop |
| 11:16:58 | dconrad | ok, I put it back in main() and get a nice flashing keypad |
| 11:17:06 | dconrad | ok, now I'm satisfied my process works |
| 11:17:20 | amachronic | try again with gerrit, I've updated it. |
| 11:17:26 | dconrad | will do |
| 11:22:20 | dconrad | no flashing this time |
| 11:25:29 | amachronic | try again from gerrit. If it does not flash this time the problem is almost certainly memory corruption |
| 11:26:03 | dconrad | alright, building |
| 11:28:35 | dconrad | ta-da! flashing |
| 11:29:24 | amachronic | hmm. what does grep -A1 text.system_init rockbox.map say? |
| 11:29:50 | amachronic | I'm only interested in the address/size on the left |
| 11:30:40 | dconrad | 0x000000008007f3d0 |
| 11:30:57 | amachronic | and size? should be next to it |
| 11:31:08 | amachronic | 0x18c? |
| 11:31:26 | dconrad | 0x000000008007f3d0 0x18c /..../build-m3k/firmware/libfirmware.a(system-x1000.o) |
| 11:31:49 | amachronic | yep. same as me |
| 11:31:49 | dconrad | sorry, I've got irc open on my laptop and building on my linux box so can't copy/paste |
| 11:41:30 | amachronic | updated gerrit, try it again. |
| 11:42:04 | dconrad | alrighty |
| 11:42:11 | amachronic | this time I padded the area with NOP and jumped over it, assuming it is corrupted, hopefully we'll skip over any corrupted code. |
| 11:42:46 | amachronic | it should get to the logo if all goes well. |
| 11:44:51 | dconrad | so is the assumption that the corruption is due to me having a faulty unit, or an error with rockbox? |
| 11:45:24 | amachronic | I'd assume an error with rockbox, since it's not like my code is very well tested |
| 11:45:41 | dconrad | its just weird it only occurs on one device |
| 11:46:12 | speachy | dconrad: since your player presumably worked fine with the OF, the presumption is that your hardware is ok. though it's certianly possible you have some sort of unknown hw variant |
| 11:46:19 | dconrad | oh whoops, i didn't actually update |
| 11:46:20 | amachronic | exactly |
| 11:46:32 | dconrad | skipped a step, one moment |
| 11:46:48 | speachy | dconrad: your player represents a full quarter of all units this has been tested on |
| 11:47:10 | dconrad | lol |
| 11:47:33 | speachy | (sigh. just got volutnteered to do more shuttling the kiddos around post-game, so my availability this afternoon just evaporated...) |
| 11:49:38 | dconrad | no flashing or boot screen :-\ |
| 11:50:17 | amachronic | bootloader debug still showing right? |
| 11:50:25 | dconrad | yeah |
| 11:50:30 | amachronic | run this again: grep -A1 text.system_init rockbox.map |
| 11:50:38 | amachronic | the address should be the same as last time |
| 11:50:58 | amachronic | it should look like this: |
| 11:51:02 | amachronic | 0x000000008007f3d0 0x4b8 |
| 11:51:54 | dconrad | 0x000000008007f3d0 0x4b8, yep |
| 11:52:20 | amachronic | gimme a minute |
| 11:52:47 | dconrad | boy, even in hex 64 bit means a lot of digits |
| 11:53:11 | speachy | heh, the bit DAP lot is up over $200 now, with nearly 5 days to go. |
| 11:53:18 | speachy | s/bit/big/ |
| 11:54:43 | dconrad | at the risk of getting sidetracked, speachy, that change to the scaling on the eros q is like night and day |
| 11:55:29 | dconrad | I spent an hour yesterday morning listening at various volumes from inaudible to too-loud and heard none of the audio artifacts |
| 11:55:53 | dconrad | though only the bottom half of the range is usable, it gets too loud after that |
| 11:57:35 | dconrad | though it does do some digital noise at the last couple seconds of a track for some reason, and pops between tracks (though some track combinations don't for some reason) |
| 11:57:44 | dconrad | that's different though, if I recall |
| 11:57:46 | speachy | dconrad: that's due to the hot output I presume? |
| 11:58:02 | dconrad | yeah I reckon so |
| 11:58:06 | speachy | the way the math is set up the max volume should be the same befor and after |
| 11:58:28 | dconrad | I don't know, I can't get there without risk to my hearing haha |
| 11:58:42 | dconrad | it's /very/ loud |
| 11:58:44 | speachy | pops between tracks is going to happen if the sample rate changes |
| 11:59:03 | dconrad | ah, maybe that's why it's only sometimes |
| 11:59:14 | amachronic | speachy: I had this issue on the M3K. is there any way to eliminate it? |
| 11:59:24 | amachronic | it gets MUCH worse at high sample rates |
| 12:00 |
| 12:00:01 | amachronic | dconrad: I have another revision to try |
| 12:00:11 | dconrad | aight, I'll go grab it |
| 12:00:17 | amachronic | only a bootloader change, leave the rockbox alone |
| 12:00:22 | dconrad | you got it |
| 12:00:23 | speachy | amachronic: it depends on exactly where the pops are occuring −− traditionally the solution is to mute the analog output when making any DAC config changes |
| 12:00:53 | speachy | also the DAC might have some sort of auto power save feature that turns things off when it gets 0s for some period of time |
| 12:01:12 | amachronic | instead of booting right away this time please wait at the end |
| 12:01:29 | amachronic | I want to figure out if the memory is really getting corrupted |
| 12:01:38 | amachronic | (ie. don't press the power button) |
| 12:01:55 | dconrad | ok, I didn't even build the normal build |
| 12:02:07 | dconrad | you want me to just wait for something to happen? |
| 12:02:33 | amachronic | are you at the end of the boot now? |
| 12:02:51 | amachronic | like on the debug screen with t going up slowly |
| 12:02:53 | dconrad | yeah, t is just doing its thing |
| 12:03:19 | speachy | dconrad: on the erosq (And all of the other hiby targets, grrr) unmuting the analog output is _slow_. |
| 12:03:20 | amachronic | okay now, the data: should be 27bdffe0 |
| 12:03:41 | dconrad | yep |
| 12:03:56 | speachy | so to eliminate the pop we'll end up cutting off the first bit of whatever's playing. not that big of a deal for music but when you're using voiced menus it really sucks |
| 12:03:56 | dconrad | do I have to do anything to get it to refresh the value? |
| 12:04:03 | amachronic | well, the idea now is to compare with this: https://pastebin.com/T3SQf1UE |
| 12:04:09 | amachronic | so vol+ moves the address forward |
| 12:04:11 | amachronic | and vol- moves it back |
| 12:04:16 | dconrad | I see |
| 12:04:22 | amachronic | so the first 4 bytes are okay |
| 12:04:49 | amachronic | if you can step through carefully and report where you find a difference, we may find the culprit |
| 12:05:01 | dconrad | you got it |
| 12:05:24 | amachronic | probably the issue will be somewhere in the 'nop' so you can try holding down vol+ and it should skip through faster |
| 12:05:40 | amachronic | it will be easy to see if that's going on, because it will be a few nonzero values surrounded by zeros (hopefully) |
| 12:06:26 | amachronic | if you get lost then just reboot & try again |
| 12:07:28 | *** | Saving seen data "./dancer.seen" |
| 12:07:36 | dconrad | so far so good, but are the addresses supposed to match? |
| 12:07:52 | amachronic | no the addresses will be offset from the disassembly. |
| 12:08:03 | amachronic | sorry about that |
| 12:08:16 | amachronic | if you're having trouble I can fix that so they match up |
| 12:08:30 | dconrad | ok, because I'm getting 800d6e54 rather than 8007f3d0 |
| 12:08:40 | dconrad | nah its cool, I just wanted to make sure that was expected |
| 12:12:55 | dconrad | phew, just got through the nops |
| 12:13:03 | amachronic | all zero? |
| 12:13:21 | dconrad | let me see what the other side looks like |
| 12:13:26 | dconrad | but yea |
| 12:13:41 | | Quit ac_laptop (Ping timeout: 268 seconds) |
| 12:20:24 | dconrad | so far so good, I'm to 8007f7e4 |
| 12:22:08 | amachronic | you might as well finish it and be sure, but it's looking like not a memory corruption problem. (Phew!) |
| 12:22:54 | amachronic | I guess it must be double-initialization of HW that is the problem. |
| 12:26:30 | dconrad | ok, got to the end, no differences |
| 12:26:48 | dconrad | I think I might scroll back through the nops again though and make sure there's nothing in there but 0's |
| 12:28:19 | amachronic | go ahead if you want to double check... though at this point I would suggest, just build everything from clean master branch, and load Rockbox over USB, like you would when following the wiki install instructions. |
| 12:28:28 | amachronic | because RB should be perfectly usable in that state. |
| 12:28:41 | amachronic | then just try screwing around and playing music, using plugins, and see if you get errors. |
| 12:29:06 | amachronic | because if it was really a corruption problem due to your unit's HW I would expect it to manifest under general usage as well. |
| 12:29:49 | amachronic | in case of a HW double init problem, I will try to sort something out by tonight you can test and see if we can make rockbox boot. |
| 12:30:24 | dconrad | alright, sounds like a plan |
| 12:30:56 | amachronic | thanks a ton for that awful debugging. :D |
| 12:31:58 | dconrad | yeah nothing but zeroes in there |
| 12:32:09 | dconrad | anytime! |
| 12:32:12 | amachronic | going to have to bounce now, so lemme know on the forums if the USB booted rockbox appears stable |
| 12:32:29 | dconrad | will do |
| 12:32:42 | dconrad | thanks |
| 12:32:58 | | Quit amachronic (Quit: Connection closed) |
| 12:51:31 | | Quit berber (Quit: The Lounge - https://thelounge.chat) |
| 12:51:59 | | Join berber [0] (~berber@v2202101107577140883.nicesrv.de) |
| 13:00 |
| 13:04:39 | | Quit pamaury (Ping timeout: 260 seconds) |
| 13:05:31 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 13:20:21 | | Quit dconrad () |
| 13:28:09 | | Quit copper (Remote host closed the connection) |
| 13:28:26 | | Join copper [0] (~copper@unaffiliated/copper) |
| 13:40:24 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 13:42:42 | | Quit copper (Quit: ZNC - http://znc.in) |
| 13:42:49 | | Join copper [0] (~copper@unaffiliated/copper) |
| 13:55:24 | | Quit Galois (*.net *.split) |
| 13:55:24 | | Quit __builtin (*.net *.split) |
| 13:55:24 | | Quit blucifer22 (*.net *.split) |
| 13:55:24 | | Quit mikroflops (*.net *.split) |
| 13:56:22 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 13:56:22 | | Join __builtin [0] (~quassel@rockbox/developer/builtin) |
| 13:56:22 | | Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) |
| 13:56:22 | | Join blucifer22 [0] (~quassel@204.48.30.120) |
| 13:57:24 | | Join lebellium_ [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 13:57:37 | | Quit lebellium (Ping timeout: 252 seconds) |
| 14:00 |
| 14:07:30 | *** | Saving seen data "./dancer.seen" |
| 14:16:45 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 15:00 |
| 15:20:44 | | Quit Saijin_Naib (Read error: Connection reset by peer) |
| 15:32:30 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 15:48:30 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-0066-1b2a-1c3a-b4b9.res6.spectrum.com) |
| 16:00 |
| 16:07:31 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:10:00 | _bilgus | dconrad the lua script rli image demo 'the twist' churns a lot of ram |
| 17:10:23 | _bilgus | it was my memory corruption test through the h10 |
| 17:29:48 | | Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:00 |
| 18:07:34 | *** | Saving seen data "./dancer.seen" |
| 18:53:06 | | Quit lebellium_ (Quit: Leaving) |
| 19:00 |
| 19:14:11 | | Quit pamaury (Ping timeout: 240 seconds) |
| 19:24:16 | speachy | _bilgus: it seems my rocker has returned from its working vacation |
| 19:53:44 | | Quit igitoor (Ping timeout: 245 seconds) |
| 19:54:34 | | Join igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648) |
| 20:00 |
| 20:00:22 | | Quit igitoor (Changing host) |
| 20:00:22 | | Join igitoor [0] (igitur@unaffiliated/contempt) |
| 20:07:35 | *** | Saving seen data "./dancer.seen" |
| 20:08:51 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 20:10:57 | _bilgus | did you like its new box? lol |
| 20:11:47 | | Join chris_s [0] (5fdf48b5@ip-95-223-72-181.hsi16.unitymediagroup.de) |
| 20:12:38 | speachy | yeah, my first thought was "looks like it was hanging out with one of those french girls" |
| 20:15:22 | chris_s | Does g3318 seem sane to you guys? Whenever music was paused or playing (instead of stopped), Rockbox would previously simply return to the main screen from the playlist catalogue after a new item had been selected. |
| 20:15:34 | chris_s | I've successfully tested it at least a bit. Hope I'm not overlooking something – seems like if it was this easy to fix, someone would have already done it sooner... unless I'm the only one annoyed by the current behavior. |
| 20:15:46 | _bilgus | yeah? I'm not sure I get the corollary |
| 20:16:22 | speachy | _bilgus: a riff of "draw me like one of your french girls" from Titanic |
| 20:17:49 | speachy | seems sane to me but I never use the playlist catalog |
| 20:19:09 | _bilgus | chris_s the code looks sane |
| 20:19:34 | _bilgus | I won't really test it till the week though |
| 20:20:23 | chris_s | speachy: well, that might explain it...:D Although the same applies when viewing the contents of playlists (instead of selecting them) from the file browser |
| 20:20:25 | chris_s | _bilgus: thanks, no rush... I may want to test it some more myself |
| 20:20:52 | speachy | is the old behavior explicitly documented in the manual? |
| 20:21:09 | chris_s | I doubt it, but will have to check |
| 20:28:21 | _bilgus | there is a hell of a lot of code that goes into the menu system I've been trying to feed and care for the internal list linedraw a lot more moving pieces than I figured |
| 20:29:44 | _bilgus | I wanted to push data to do+_menu but I've an issue that lua wants to be the pusher and do_menu wants to do it in callbacks |
| 20:35:02 | | Quit ZincAlloy (Quit: Leaving.) |
| 20:43:41 | speachy | ok, the dx50/dx90 work but can't access the external sd card any more due to my hostfs reworking.. I think I know how to fix this but.. working kinda blind here.. |
| 20:44:39 | fs-bluebot | Build Server message: New build round started. Revision bc416ff590, 298 builds, 10 clients. |
| 20:45:12 | speachy | hopefully there won't be any red (or yellow) here. all of my local builds were ok. |
| 21:00 |
| 21:01:42 | braewoods | speachy: this was a fun evening. i was emailing with a senior rockbox user trying to advise them about the dead Clip+ |
| 21:03:09 | braewoods | i'll get around to trying to disassemble the OF this evening |
| 21:03:11 | fs-bluebot | Build Server message: Build round completed after 1112 seconds. |
| 21:03:14 | fs-bluebot | Build Server message: Revision bc416ff590 result: 466 errors 58 warnings |
| 21:03:18 | speachy | egad |
| 21:03:23 | speachy | ok, time to clean up the mess |
| 21:05:13 | braewoods | i recommended the iRiver H120 to him since i thought it was a good fit. |
| 21:05:35 | braewoods | it's very mature and reliable. |
| 21:05:40 | braewoods | etc |
| 21:07:27 | fs-bluebot | Build Server message: New build round started. Revision 6ae2b7140c, 298 builds, 10 clients. |
| 21:07:45 | speachy | should solve all the red. Most of that was due to checkwps. d'oh. |
| 21:22:27 | fs-bluebot | Build Server message: Build round completed after 900 seconds. |
| 21:22:29 | fs-bluebot | Build Server message: Revision 6ae2b7140c result: All green |
| 21:46:11 | | Quit chris_s (Quit: Connection closed) |
| 21:47:05 | _bilgus | I always forget to check check wps |
| 21:47:57 | speachy | and the rest was every m68k with a radio. :/ |
| 22:00 |
| 22:07:38 | *** | Saving seen data "./dancer.seen" |
| 22:19:37 | speachy | there's a lot more header detanglement that could/should be done |
| 22:20:02 | | Quit f1refly (Quit: see ya in hell) |
| 22:21:21 | | Join f1refly [0] (~f1refly@2a01:c22:847c:ae00:f7eb:98d7:1024:6d97) |
| 22:26:40 | | Quit f1refly (Quit: see ya in hell) |
| 22:26:57 | | Join f1refly [0] (~f1refly@2a01:c22:847c:ae00:f7eb:98d7:1024:6d97) |
| 22:36:24 | | Join f1reflyylmao [0] (~f1refly@dynamic-077-008-252-016.77.8.pool.telefonica.de) |
| 22:36:47 | | Quit f1refly (Ping timeout: 260 seconds) |
| 22:36:49 | | Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-077-008-252-016.77.8.pool.telefonica.de) |
| 22:36:49 | speachy | huh, here's an odd one |
| 22:37:32 | speachy | the ID2P macro can generate a null pointer if the ID is LANG_SET_BOOL_YES (== 0) |
| 22:37:41 | speachy | and that's usually statically known at compile time |
| 22:49:40 | | Quit f1refly (Quit: see ya in hell) |
| 22:52:16 | | Join f1refly [0] (~f1refly@2a01:c22:8c93:cd00:79ea:fc8:fff7:1c73) |
| 22:55:46 | | Quit f1refly (Client Quit) |
| 23:00 |
| 23:05:08 | | Join f1refly [0] (~f1refly@dynamic-077-008-252-016.77.8.pool.telefonica.de) |
| 23:06:16 | fs-bluebot | Build Server message: New build round started. Revision e4345f2db8, 298 builds, 10 clients. |
| 23:07:08 | speachy | another set of eyeballs on g#3321 would be appreciated. |
| 23:07:10 | fs-bluebot | Gerrit review #3321 at https://gerrit.rockbox.org/r/c/rockbox/+/3321 : lang: Offset the start of the language VIRT_PTR to avoid a null pointer by Solomon Peachy |
| 23:07:42 | speachy | we have the nullptr check optimizations explicitly disabled due to general wonkiness but this might be one of the causes of that |
| 23:08:13 | | Quit f1refly (Client Quit) |
| 23:08:59 | | Join f1refly [0] (~f1refly@dynamic-077-008-252-016.77.8.pool.telefonica.de) |
| 23:10:38 | speachy | if we ever get anothe target that has "real" memory at addr 0, this will potentially break. |
| 23:14:26 | braewoods | indeed. |
| 23:14:30 | braewoods | the problem with null. |
| 23:14:54 | | Quit f1refly (Quit: see ya in hell) |
| 23:14:59 | braewoods | probably why we should not allocate anything at address 0 outside of something special. |
| 23:15:13 | speachy | this is "something special" |
| 23:15:24 | braewoods | like a reset vector? |
| 23:15:38 | speachy | pointer shenanigans |
| 23:15:43 | braewoods | Oh. |
| 23:15:52 | braewoods | I meant like device or architecture specific memory mappings. |
| 23:16:21 | braewoods | i don't think we should ever try to port RB to anything less than a 32 bit cpu... |
| 23:16:37 | speachy | by treating a range of "invalid" pointers as an index, one can save space in data structures. |
| 23:17:07 | braewoods | let me guess. they have to reconstruct the full pointer before they can use it. |
| 23:17:23 | | Join f1refly [0] (~f1refly@dynamic-077-008-252-016.77.8.pool.telefonica.de) |
| 23:17:36 | braewoods | i've seen people use tagged pointers before. |
| 23:17:41 | speachy | it's used as an index in a table |
| 23:17:45 | braewoods | Oh. |
| 23:17:51 | braewoods | so not a true pointer. |
| 23:17:51 | speachy | (language strings) |
| 23:18:05 | speachy | if it's not in that special range, it is treated as a pointer. |
| 23:18:20 | braewoods | Oh, I see. |
| 23:18:21 | braewoods | A hack. |
| 23:18:33 | braewoods | reminds me of tagged pointers. |
| 23:18:33 | speachy | the key is to ensure that special range is not a valid address for the platform |
| 23:18:48 | speachy | it is, after a fashion |
| 23:18:48 | braewoods | need special processing before you can actually use them |
| 23:19:15 | braewoods | i don't generally recommend it myself since it's not very portable |
| 23:19:18 | speachy | we only have two SoC families supported that have "Real" memory at 0x00 |
| 23:19:27 | speachy | but I know of others |
| 23:19:32 | fs-bluebot | Build Server message: Build round completed after 795 seconds. |
| 23:19:35 | fs-bluebot | Build Server message: Revision e4345f2db8 result: All green |
| 23:19:38 | braewoods | you need to know how the system assigns pointers to know if it's safe to mess with pointers like that |
| 23:19:54 | braewoods | i mean, going around arbitrarily reassigning bits |
| 23:20:15 | braewoods | so i never really used it. didn't feel safe doing so. |
| 23:20:28 | braewoods | i'd rather use more memory to avoid creating new problems. |
| 23:20:30 | braewoods | :D |
| 23:21:01 | braewoods | speachy: i hope we can get -Wpadded in our toolchain eventually |
| 23:21:12 | braewoods | it could be useful for optimizating DS |
| 23:21:17 | braewoods | optimizing |
| 23:21:20 | braewoods | bleh |
| 23:21:31 | speachy | it's going to create a ton of noise |
| 23:21:48 | braewoods | I know, it's not for general use. |
| 23:22:05 | braewoods | but considering how we have a fixed amount of low memory |
| 23:22:05 | speachy | mostly in 3rd-party code (eg codecs, plugins) |
| 23:22:18 | braewoods | it could be useful for optimizing our memory use |
| 23:23:56 | | Quit f1refly (Quit: see ya in hell) |
| 23:24:46 | | Join f1refly [0] (~f1refly@dynamic-077-008-252-016.77.8.pool.telefonica.de) |
| 23:25:06 | speachy | well, it's present in gcc 4.9.4 that we're using, so you can turn it on in your local builds and see how it goes |
| 23:25:52 | braewoods | oh i thought it wasn't |
| 23:25:55 | _bilgus | speachy the virtual pointer doesn't have to be invalid though |
| 23:26:11 | _bilgus | asking not stating |
| 23:26:43 | speachy | the key is that there can't be any chance that the virutal pointer points to a real address that could conceivably have a string in it |
| 23:27:16 | speachy | so the VPTR needs to point at something outside of RAM |
| 23:27:21 | _bilgus | yeah ok so a dead char isn't going to kill us right? |
| 23:27:55 | speachy | just some wonky strings being displayed |
| 23:28:10 | braewoods | do we use memory protection where available? |
| 23:28:21 | speachy | none whatsoever |
| 23:28:29 | _bilgus | no I was saying a char reserved in ram to oint to |
| 23:28:31 | braewoods | wow. so DOS and windows 9x days. |
| 23:29:05 | speachy | even less than that |
| 23:29:23 | speachy | we're bare metal. |
| 23:29:34 | braewoods | i thought DOS was already bare metal |
| 23:30:08 | speachy | DOS is close but thanks to x86 segmentation you actually get some degree of protection |
| 23:30:34 | braewoods | i see, so no MMU for ARM. |
| 23:30:38 | braewoods | ok |
| 23:31:02 | braewoods | if it was an option we'd probably want to use it to help give us some protection |
| 23:31:10 | speachy | some of our SoCs have an MMU, but... why bother? |
| 23:31:20 | speachy | it's a lot of complexity for nearly no gain |
| 23:31:30 | braewoods | we could use it to protect code regions against writes |
| 23:31:34 | braewoods | but that's all I could envision |
| 23:32:20 | braewoods | i guess we don't really need it |
| 23:32:26 | braewoods | we're not a PC |
| 23:32:40 | speachy | we're not running arbitrary 3rd party code |
| 23:33:00 | braewoods | we are when we boot OFs |
| 23:33:02 | braewoods | :D |
| 23:33:07 | braewoods | but yea |
icon identifies that the person is a core developer (has commit access).