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

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

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

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

#rockbox log for 2021-04-01

00:00:15_bilgusbut there is no mirroring I can see
00:00:28_bilgusI bet box those mirrors are COP
00:00:40_bilgusboth*
00:01:13_bilgusprobably the same with the flush base and invalidate base too
00:01:51_bilgusso now my questions are 1. how to init the cache for the other processor
00:02:18_bilguslike can we prime it from our other core then safely?
00:02:25braewoods_bilgus: i may ask for your help with the gigabeat S but after you solve the H10 issues
00:03:00braewoodsin any case i need to trace it
00:03:02***Saving seen data "./dancer.seen"
00:03:05_bilgus2. is this the reason for the myriad issues of alignment and such over the past 10+ years
00:03:09braewoodsi can't assume it's the same thing that killed the H10
00:03:19_bilgus3. will it fix issues with other pp devices
00:03:50_bilgusbraewoods, I don't think anyone ever would have guessed that a lcd update would cause this
00:04:16braewoodswell it did kill the iriver H300 bootloader
00:04:22braewoodsuntil we fixed the issues
00:04:29_bilgusit just happened I think that the fb was no longer static so it got cached
00:05:05braewoodssounds like you need to disable caching or so
00:05:18_bilgusits a good thing
00:05:43_bilgusthe code nbot the address
00:06:06_bilgusthats the cool thing about a instruction cache
00:06:33_bilgusassuming your thing can fit in a cacheline or two
00:07:03braewoodsis it like the cache x86 uses?
00:07:17braewoodsit sounds like IRAM or so
00:07:19_bilgusx86 has aid cache
00:07:24braewoodsRAM really close to the CPU
00:07:51_bilgusI don't think it necessarily has to be close
00:09:25_bilgusIRAM you put the stuff and leave it the cache is LIFO basically
00:09:53_bilgusanything can be there at a given time
00:10:13_bilgusbut then you need to do all the book keeping
00:10:24_bilguswell some of it
00:11:23_bilgusit really makes a noticible difference on this h10
00:11:35braewoodsso how can you fix the issue?
00:11:49_bilguswhat issue?
00:11:55braewoodsa cache is useless if it interferes with reliable operation
00:12:03_bilgusits fixed
00:12:08braewoodsso what was the fix?
00:12:28_bilgus g#3264
00:12:39_bilgusbah bluebotttt
00:13:02braewoodsit's feeling blue
00:13:02_bilguswe were clearing the status of the CPU from both cores
00:14:00braewoodsmeaning the zero flag, etc?
00:14:39braewoodsstrange issue
00:14:44_bilgusno meaning we were wiping out the cache of the CPU with invalidated entries from the other core
00:14:53braewoodsoh
00:15:14braewoodsand of course PP can have race conditions due to having multiple cores
00:15:19_bilgusand on top not even invalidating anything on the COP
00:15:53braewoodsnot that cores are a pre-req to that
00:15:55braewoodsbut
00:16:05braewoodseh
00:16:11braewoodsall depends on how you handle concurrency
00:16:51_bilgusI have to wonder now if we even need to do all this weird invalidation if we just keep in mind that there are two cores but I assume someone already tried the stuff in the wiki
00:17:15_bilgushttp://www.ipodlinux.org/PP5020/
00:18:15_bilgusI still don't know about q1 but I think I'll mess around with it
00:18:50braewoodsok ordered some stuff so i can try some stuff with the gigabeat s
00:18:56braewoodswhile i wait on those parts
00:22:38braewoodsi'll try to sort out the gigabeat S issue
00:33:04braewoodsgood grief
00:33:10braewoodsit seems like it has to build everything
00:35:56braewoods3.15 works no surprise there
00:36:51_bilguswell jump to the commit before the lcd update just to be sure
00:36:54_bilguslol
00:37:40braewoodsi'm going to gradually get there
00:38:19braewoodsi'm probably going to be swapping out my laptop for a ryzen soon
00:44:04 Join chris_s [0] (5fdf48d7@ip-95-223-72-215.hsi16.unitymediagroup.de)
00:44:41chris_sFS #13281 Was able to reproduce this and will investigate it...
00:48:47_bilgusmight be an old bug or your new playback stuff
00:53:02braewoods_bilgus: commit right before the new toolchain checks out
00:53:11braewoodsi'll test right before LCD changes
01:00
01:00:32chris_sbilgus: Well, it definitely happens because of the playlist_resume() call in playlist_modified that I'd added.  Still have to figure out *why* that is creating a problem in that scenario. I think this is probably the same bug that amachronic had described a few days ago.   I almost always use the database instead of the file browser which is why
01:00:32chris_sI hadn't noticed it (it only occurs when playing a folder) "I sometimes had an issue where the song would get loaded but not play, stuck at 0:00"
01:17:17braewoodsspeachy: appears your toolchain broke the gigabeat S port
01:17:31_bilguslooks like 18 devices use the pp5020
01:17:51_bilgusbunch of ipods
01:17:57_bilgusI'm excited
01:18:14_bilguswonder what it fixes/breaks
01:18:17braewoodsor wait
01:19:52 Join fs-bluebot [0] (~fs-bluebo@55d48c6a.access.ecotel.net)
01:20:32 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
01:21:12bluebrotherbraewoods: nice.
01:21:35bluebrotheralso, you volunteered in finishing the port. I don't have much use for it anymore now :)
01:21:47bluebrotherkinda :D
01:21:48braewoodsbluebrother: just hope we can fix the current issue
01:21:55bluebrothersure.
01:22:04braewoodsotherwise not much point "finishing" it
01:22:26 Quit ZincAlloy (Client Quit)
01:22:29bluebrotheralways nice to see things getting fixed. I'd been quite a lot of changes lately.
01:31:41braewoodsi would like to add a tvout driver for it but
01:31:44braewoodsone thing at a time
01:37:01 Quit pixelma (Quit: .)
01:37:02 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
01:38:17braewoodswell one change in the GCC flags...
01:38:27braewoods-Os is enabled for gigabeats where it wasn't before
01:41:18 Join pixelma [0] (~marianne@rockbox/staff/pixelma)
01:41:18 Join amiconn [0] (~jens@rockbox/developer/amiconn)
01:46:17braewoodsfirst thing to try, disable optimizations
01:48:37braewoods...
01:48:39braewoodsThat was it?
01:48:41braewoodsSeriously?
01:49:06braewoodsspeachy: it looks like gigabeats for some reason breaks if optimizations are turned on
01:49:16braewoodsas to why i can't begin to gues
01:49:20braewoodsspeachy: suggestions?
01:52:14braewoodsspeachy: in any case i plan to do some repairs on the unit before i do much else with it
01:52:24braewoodsi would prefer to know why optimizations break it
01:52:28braewoodsbut is that even realistic?
01:52:56braewoodsthe symptoms i observed is it would hang similar to the H10.
01:53:03braewoodsi'd see the rockbox logo and the version at the bottom
01:53:05braewoodsbut it hangs there
01:53:38braewoodsbut optimizations were effectively disabled for gigabeats before the toolchain upgrade
02:00
02:01:16 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net)
02:01:53 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
02:02:13chris_sI've reverted 46085c8 for now, until I have some time to figure out the issue with playlist_resume there just so this is fixed as quickly as possible. ( g#3266). Fix for FS #13281
02:02:15fs-bluebothttps://www.rockbox.org/tracker/task/13281 Problems playing the first song after player turned on (bugs, unconfirmed)
02:02:15fs-bluebotGerrit review #3266 at https://gerrit.rockbox.org/r/c/rockbox/+/3266 : (Fix FS #13281) Revert "Restore playlist state as necessary before checking whether current playlist has been modified" by Christian Soffke
02:02:53 Quit St3ak (Client Quit)
02:03:03***Saving seen data "./dancer.seen"
02:04:39 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
02:05:29 Quit St3ak (Client Quit)
02:05:54braewoodsi'll dig into it more later
02:06:01braewoodsi'll see if -O1 works
02:06:03braewoodsetc
02:06:42 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
02:07:12 Quit St3ak (Client Quit)
02:11:58 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
02:13:23 Quit St3ak (Client Quit)
02:15:49 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
02:16:17 Quit St3ak (Client Quit)
02:17:29 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
02:17:29 Quit St3ak (Remote host closed the connection)
02:17:51 Quit chris_s (Quit: Connection closed)
02:37:49 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
02:37:51 Quit St3ak (Client Quit)
02:41:38 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
02:54:09 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
04:00
04:03:04***Saving seen data "./dancer.seen"
05:00
05:02:02 Quit melmothX (Quit: reboot)
05:35:16 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:58:51fs-bluebotBuild Server message: New build round started. Revision 674c07d654, 298 builds, 10 clients.
06:00
06:01:53speachy_bilgus: so you also forced exceptions to only be handled on the primary CPU?
06:03:08***Saving seen data "./dancer.seen"
06:03:32speachyOr rather, you replaced CURRENT_CORE with IF_COP_CORE(CPU) but that's not the same at all
06:04:14speachyIF_COP_CORE(CPU) is a macro that expands to CPU, so if(IF_COP_CORE(CPU) == CPU) becomes if(CPU == CPU) which becomes if (1)
06:07:19speachy everywhere you changed CURRENT_CORE to IF_COP_CODE seems... suspect.
06:09:37speachyeg now in irq_handler, instead of primary CPU, irqs can now be handled by either.
06:10:15speachyIF_COP_CORE(x) is a macro that
06:11:07speachyso even in the cache_invalidate_special() function you're only ever initializing the primary CPU's cache.
06:13:56fs-bluebotBuild Server message: Build round completed after 905 seconds.
06:13:59speachybraewoods: gigabeat-S hang on startup?
06:14:04fs-bluebotBuild Server message: Revision 674c07d654 result: 5 errors 0 warnings
06:19:14_bilgusspeacy you sure bout that?
06:19:24_bilgusspeachy*
06:19:27_bilgushttps://github.com/Rockbox/rockbox/blob/master/firmware/export/config.h
06:19:52_bilgusor is it redefd somewhere?
06:20:21_bilguslooks like a FB macro to me
06:20:58speachyif !defined(FORCE_SINGLE_CORE) ... #define IF_COP_CORE(core) core
06:21:56_bilgusyeah and just below https://github.com/Rockbox/rockbox/blob/master/firmware/export/config.h#L1161
06:22:13speachythat's wrapped by #ifndef NUM_CORES
06:22:17speachybut NUM_CORES is 2
06:22:33speachy(on the PP, unless FORCE_SINGLE_CORE is set)
06:24:17_bilguswth is the redef then not seeing it
06:26:11speachymy point is it's _not_ getting redefined; using IF_COP_CORE(...) is wrong in this context.
06:26:34_bilgusoh dub
06:26:40_bilgusdamn
06:26:44_bilgusI see it
06:26:48speachyeverywhere you used it you should have used CURRENT_CORE instead
06:27:08_bilgusWhat I was trying to do was get that force single core to work properly
06:30:09speachyI don't think that's necessary with your changes; CURRENT_CORE == CPU in a FORCE_SINGLE_CORE scenario
06:33:51_bilgusWell good thing YOU caught that
06:34:05_bilgusthankfully the player is still fixed :p
06:37:24speachythe compiler will optimize away the CACHE_STATUS_BASE_COP branch in the else in cache_invalidate() as the test becomes if (0 == 0)
06:38:17speachy g#3268
06:38:19fs-bluebotGerrit review #3268 at https://gerrit.rockbox.org/r/c/rockbox/+/3268 : PP: Use CURRENT_CORE instead of IF_COP_CORE(CPU) by Solomon Peachy
06:38:26speachyit compiles therefore it must work!
06:40:52_bilgusI assume its the same as what I just tested but if not ill discover it next round with g#3265
06:40:54fs-bluebotGerrit review #3265 at https://gerrit.rockbox.org/r/c/rockbox/+/3265 : pp5020 −− Initialize COP cache at init_cache by William Wilgus
06:41:40speachy3265 isn't needed
06:41:58speachysystem_init() is called by both cores, and init_cache is unconditionally called at the end of system_init()
06:44:35_bilgusah I was wondering if it was like that or if we just couldn't determine which core would be master
06:45:39speachy(both CPUs call the same reset vector)
06:48:54_bilgusso now my other questions 2. is this the reason for the myriad issues of alignment and such over the past 10+ years 3. will it fix issues with other pp devices
06:49:31_bilgusand now 4. why did daniel think it was mirrored memory
06:49:53_bilguson the e200 or w/e he tested on
06:54:43fs-bluebotBuild Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients.
06:55:25_bilgusI also have to wonder if this is why he couldn't get invalidating ranges to work
06:55:53_bilgusnot that I intend to find out
07:00
07:00:24speachyit might be responsible for our various DMA write corruptions
07:01:08 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
07:02:56_bilgussame 18 players
07:03:03_bilgususing that module
07:03:18_bilguswell same for the other 17
07:15:36fs-bluebotBuild Server message: Build round completed after 1253 seconds.
07:15:38fs-bluebotBuild Server message: Revision 0b20038d87 result: 113 errors 0 warnings
07:17:14speachyum... wtf..
07:17:21speachyI'm going to force a do-over on that round
07:21:23fs-bluebotBuild Server message: New build round started. Revision 0b20038d, 298 builds, 10 clients.
07:46:36 Join MrZeus__ [0] (~MrZeus@2a02:c7f:a0aa:4400:f878:24fa:cc54:429d)
07:51:24fs-bluebotBuild Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients.
07:56:33speachy_bilgus: Should I submit that USE_CURRENT_CORE patch? IMO what's in the build now isn't likely to yield correct results.
08:00
08:02:21 Join amachronic [0] (5284b839@82.132.184.57)
08:03:11***No seen item changed, no save performed.
08:04:20amachronicchris_s: I saw you fixed fs#13281. I'm not sure what's really going on here but it seems interesting the bug was reported on xDuoo X3ii.
08:04:22fs-bluebothttps://www.rockbox.org/tracker/task/13281 Problems playing the first song after player turned on (bugs, closed)
08:05:41amachronicsince it's mips like my fiio m3k. I don't think your changes are the root problem here, since I managed to get the "stuck on 0:00" bug even when NOT on the first song.
08:07:01amachronicsorry forgot to mention: I reverted all your playlist changes for a while when I saw the bug
08:13:13 Join chris_s [0] (5fdf48d7@ip-95-223-72-215.hsi16.unitymediagroup.de)
08:14:06amachronicreading the bug more carefully: "metadata is displayed correctly but cover art isn't loaded". To add to this my music is mostly m4a, and as it turns out, the metadata parser thinks this is "ALAC" which  is what the UI shows when the bug occurs. But when the music loads and plays, it changes to "AAC" which is what it should be.
08:14:27speachy..wtf is going on with the server.. big load spikes, something's causing a ton of disk I/O..
08:15:37 Quit Stanley00 ()
08:25:01chris_samachronic: I guess it's possible my (now reverted) change just *revealed* a deeper problem, but at least the scenario described in the bug report (which was easily reproducible by me on iPods, both on device and in the simulator) should now work correctly again. I have yet to to look into the exact reason for the call to playlist_resume causing a
08:25:01chris_sproblem in that instance but would still like to do so, because I'm not happy with the fact that you now of course, once again, don't get a warning anymore when replacing a modified playlist after restarting the player.
08:26:31speachyjust banned another bot.
08:27:19amachronicchris_s: I haven't managed to reproduce the bug lately, which made me suspect a firmware issue.
08:29:05 Quit cockroach (Quit: leaving)
08:35:14 Join __Bilgus_ph [0] (ac3a6ef3@172.58.110.243)
08:36:07__Bilgus_phSpeachy yes I thought you already committed it, I tested it
08:36:24speachyok, will do
08:36:36speachyneed to finish cleaning up the mess the huge server load did to the buildserver
08:37:20speachy(driven by that bot pounding the wiki... sigh)
08:38:36fs-bluebotBuild Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients.
08:38:51speachyok, let's see if this is clean
08:39:05speachythen I'll merge the PP stuff
08:39:48 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
08:40:56__Bilgus_phRe button remapping I think I have a method that might work, basically add a new button BTN_CUSTOM add it to all button presses when active
08:42:19__Bilgus_phThen when the button map fails have it fall into a lookup buffer when that fails return to the action sys with btn_custom negated
08:44:01speachyhmm, gigbeat-s is a an imx31
08:45:09__Bilgus_phIf match is found it returns new buttons to action sys
08:46:05__Bilgus_phProblem is pre buttons though...
08:46:40__Bilgus_phIirc the gigabeast is very picky
08:46:51__Bilgus_phBbl
08:46:55 Quit __Bilgus_ph (Quit: Connection closed)
08:47:58fs-bluebotBuild Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients.
08:48:29speachyWTF, broke even more spectacularly.
08:48:58speachy...once more, with feeling...
08:52:07amachronicbilgus: I was thinking myself about rejigging the button handling. what do you think about this state machine idea:
08:52:19amachronicuse three states = { RELEASED, PRESSED, HELD } for each button
08:52:26amachronicRELEASED -> PRESSED when BUTTON_X gets set
08:52:31amachronicPRESSED -> RELEASED when BUTTON_X gets unset
08:52:52amachronicPRESSED -> HELD if the PRESSED state persists for a long enough duration
08:53:00amachronicHELD -> RELEASED when BUTTON_X gets unset
08:53:14amachronicand we could attach actions to the transitions.
08:53:52amachronicand if need be the state machine can be made more complex to handle extra behavior
08:55:37speachyamachronic: a normal "press" should only trigger upon release, but "held" should trigger upon entering HELD. and possibly a different behavior upon release..
08:56:11speachyon other words, we want edge detection rather than level. :D fire upon the transitions rather than the states themselves.
08:56:23speachy(gah. scrap the "fire...")
08:56:34amachronicthat's exactly my thinking
08:57:19amachronicNeeds a bit of tweaking to handle the events that come from the scrollwheel, since they don't "release", but overall does this seem like a good idea?
08:58:15speachyit's a ton of work to get there from where we are now though.
08:58:52speachyevery target, every target keymap, and most plugins
08:59:55fs-bluebotBuild Server message: Build round completed after 717 seconds.
08:59:58fs-bluebotBuild Server message: Revision 0b20038d87 result: All green
09:00
09:00:32amachronicyeah I'd be concerned about regressions because so much code would have to be touched.
09:01:02speachyhard to envision a migration path
09:02:41fs-bluebotBuild Server message: New build round started. Revision 9f7f1a841a, 298 builds, 10 clients.
09:02:51speachyok! finally!
09:03:10speachythis round has the PP fixes
09:12:26_bilgusWoo
09:12:54_bilgusthe last rewrite I did of the action engine I pushed it more towards statefulness
09:16:17_bilgusI think the big problem will be that the keymaps are technically translations with individual quirks
09:17:19_bilguslotta ifdefs
09:17:31fs-bluebotBuild Server message: Build round completed after 891 seconds.
09:17:35fs-bluebotBuild Server message: Revision 9f7f1a841a result: All green
09:18:07amachronicwhat if we tag the buttons with intents like "these are directional buttons", "this is an OK button", etc.
09:18:13_bilgusand some players emulate button release events too
09:18:13speachyok, PP fixes in. and lo, the PP targets had their code sizes bump up. :)
09:19:41_bilgusamachronic, yes you could add a field like that but wouldn't it be easier to just remap what goes in
09:20:19_bilgusproblem there if at button level instead of actions you would be limited
09:20:39_bilgusif we do it at the action level then you could be like hold button for action_play
09:22:21amachronicthe intents thing is more of a hack to avoid the need to add tons of #ifdef in places which want to monitor the button level directly
09:22:35amachronicat the action level it isn't really useful
09:24:09_bilgusthat might work for plugins
09:24:26amachronicI'm motivated by the fact some of the plugins in the fiio m3k are hacky, they can only monitor one button when it's better to have 2 or 3 buttons do the same thing.
09:24:46_bilgussometimes some players don't do multiple buttons
09:25:02_bilgusI had to hack that in the .... rocker?
09:25:24speachy_bilgus: you did that on the X3, definitely.
09:25:41_bilgusX3 yeah lol
09:26:44amachronicfor the hosted targets it would be better to bypass the button_read_device() API entirely, since they generally have to translate an event stream back into a "continuous" signal
09:27:19amachronicb/c the state machine I mentioned earlier is just a way to transform a continuous signal to discrete events
09:28:29speachywe still need to map the target-specific "events" to rockbox events.
09:29:18speachyso yeah, a better API will definitely help there, but we can't just wire it up directly. And there are always quirks. sigh.
09:29:24amachronicperhaps the button handling layer should use psuedo-events defined by the target, then use context-dependent mapping to change those into action events.
09:29:33amachronici mean rockbox events
09:29:46_bilgustry to align them all lower but what happens whe you lack a button
09:30:56_bilgusI guess then you could make a 'sticky' button or something
09:31:08speachyamachronic: in a sense that's what we already have though?
09:31:48amachronicsomewhat true, but there's a bunch of special case handling sprinkled all over the place.
09:31:59_bilgusand in a sense its alrady a state machine lol but to get that from compile time to runtime thats a lot of logic that needs to be translated
09:32:00speachyit seems a lot of duplicated work to recreate "raw button bitmap" -> events
09:33:07_bilgusidk i'll keep brewing this one amachronic if you get a wild hair POC is always welcome
09:33:31speachy(for each target I mean)
09:33:54_bilgusI kinda don't want to touch the action system for a bit still kinda sore from the last 50 patch commit it took
09:35:46_bilgusexcuse me 40 not 50
09:38:13_bilgusI think what might help is some kind of scripting in core
09:38:40_bilguswe have it everywhere but with piecemeal fashion
09:38:57_bilgusand its all crypic AF
09:39:29_bilgusmaybe just a central parser engine
09:43:35amachronicis it feasible to push the actions into a queue instead of having the caller "pull" actions by calling a function?
09:49:33_bilgusthe button code has a queue next level down, but you want to insert one for the actions too? I'm not sure how you would do it once you get to the push part??
09:50:49_bilguslike make get_action just chec k the queue and have the action engine running in its own tick task −− its still procedural just hidden lower I suppose
09:51:12amachronicyeah that's the idea −− remove the button tick task and have action engine read the device itself
09:51:33_bilguswe don't have multithreading like that
09:51:54_bilgusit'd still have to be polled in some form or anoter
09:52:20amachronicof course, but instead of queuing the button presses we queue the actions instead
09:52:26_bilgusI think the current is like that because you have more control in regards to when to take the hit
09:54:05_bilgussorta makes sense to me then you can peek the queue and whatnot with handling it but what concrete advantages do we get besides the appearance of 'event based'
09:55:48_bilgusan aside.. a sim bug that crashes when the button queue gets full
09:56:26amachronicI think might be hitting that on my m3k under high loads, but I didn't bother to confirm which queue it was
09:56:49_bilgusit exists
09:57:04_bilguscoded around on players though
09:57:47amachronicit mainly happens on the debug screens, I guess they just don't handle actions "normally" and the queue fills up
09:58:19_bilgusyeah nothing reading it and it overflows
09:58:50_bilguswe could instead do a small bit of the plugin buffer and do some PIC stuff
09:59:05_bilgusa action plugin so to speak
09:59:34_bilgusshould be simple enough to make a plugin that will generate machine code to route the actions
10:00
10:00:34_bilgusit would be of course core but we could generate it at compile time and overwrite it in ram at RT
10:01:01_bilgusthe plugin system has most of the infra for us already
10:01:48amachronicI'm not sure I understand what you mean here.. why would we need to generate code for routing actions??
10:03:12***Saving seen data "./dancer.seen"
10:03:14_bilgusok so right now that keymap is a static representation and the compiler emits machine code that matches that 'map'
10:03:32_bilgusso we instead mark in ram where that is and load it like a plugin
10:03:59_bilgusthen later overwrite that 'map'
10:04:25amachronicyou mean just modifying the keymap table.
10:04:29_bilgusyep
10:04:48amachronicwell we just need to make the mapping of button -> action mutable, no need for anything fancy
10:05:22_bilgusits not fancy its a way to do this without filling core with junk fo it
10:05:29_bilgusfor*
10:05:46amachronicah I see you mean the "compiler" for the table goes in a plugin so it's not in RAM all the time
10:06:18_bilgusyes we can do the logic there
10:06:27_bilgusand just present the map to the core
10:07:36_bilgusstill gonna be hard with all that different ifdef but I think we can cheat and use a default table to get the proper instructions and minkey patch
10:07:46_bilgusmonkey
10:08:29_bilgusthe plugin has a default table that is already compiled that it can exampine for the proper instructions
10:12:07_bilgusI we wanted to get fancy we could then have plugins load a map and lead back to the key setting plugin (since we can call plugins from plugins now)
10:13:05amachronicif we got rid of the pre button stuff, then the tables would simplify because they're no longer dependent on the order of entries.
10:13:22_bilgusI don't know how you copuld
10:13:24amachronicthat would make it easier to dynamically update them without invoking a parser
10:13:47_bilgusproblem is that some actions use two buttons
10:14:38_bilgusit wouldn't be hard to scan the table for prebuttons in the cold path
10:14:54_bilgusjust need a bit o mark it
10:14:57_bilgusto
10:15:15_bilgusI need a click keyboard damnit
10:15:22amachronichow do the 2 button actions work in practice? wouldn't the "modifier" key have to be unused, to avoid wrongly matching it?
10:15:53_bilgusyes but thats why its separaed into different contexts
10:16:06_bilgusso it cuts down on the chance
10:16:42amachronicok, I think the state machine I outlined could be adapted to handle that more reliably and without checking pre buttons.
10:17:30_bilgusits already half way there
10:17:55chris_shuh... on the latest build (since 89acde6 but even on 9f7f1a8) I now seem to be getting digital clicks/pops in the background on an iPod 4G and iPod video when I select "Playing time" while music is playing if there was previously no disk access going on
10:18:31_bilgustheres our ipod :)
10:19:28_bilguschris_s will you be available in about 7 hrs
10:19:55_bilgusor can you compile your own?
10:19:57chris_syeah, sure
10:20:02chris_soh yea, i could
10:20:57_bilgushttps://gerrit.rockbox.org/r/c/rockbox/+/3264/1/apps/plugins/fire.c
10:21:20_bilgusjust copypasta into a convenient plugin
10:23:01_bilgusand try 9f7f and the commit just prior to 89acde6af2 to besure
10:24:59_bilgusoddly the clicks and pop are gone on the h10
10:27:28speachy_bilgus: one more thing about the PP cache fix; when you combine our two patches tehre are only two relevant changes remaining inyour fix
10:28:33speachythe original code only writes 512 first 512 entries, you write 2K. (ie cache_size / 4)
10:30:03speachy(the other being the distinction between CPU and COP)
10:31:10_bilgusyeah the rest is just moving away from magic numbers
10:32:36_bilgusnext questions being what is different in the h10 versus the ipods though
10:32:55 Quit massiveH (Quit: Leaving)
10:33:03speachy2K entries is overkill though; the cache only has 512 entries
10:33:23speachy(ie 8K/16 bytes per row == 512 rows)
10:35:23_bilgus8192 / 16 = 512?
10:35:57_bilgusCACHEALIGN_SIZE = 16
10:36:24_bilgusoh no thats all F-ed up
10:36:39_bilgusi'm stepping 16 * 4 bytes
10:36:57_bilgusgah
10:37:23_bilgusI even made that notation above
10:37:25speachyyou're stepping by 4.
10:37:48speachyCACHEALIGN_BITS = 4
10:38:07speachyyou're just stepping over 8K/4 instead of 2K/4 (from the original code)
10:38:23_bilgusCACHEALIGN_SIZE = 16
10:38:38_bilgusCACHEALIGN_BITS = 4
10:38:47speachyoops, it's a pointer, so yeah, you're stepping by 16.
10:38:53_bilgusI'm stepping by 64 bits
10:39:10speachyp += CACHEALIGN_BITS
10:39:13_bilgusjeesh
10:39:17speachy so p+=4
10:39:38speachy(but p is a pointer, so you're actually stepping by 4*sizeof(*p))
10:39:50_bilguswe are looking at two different places I think
10:40:01_bilgusthats fine up there the math is right
10:40:05_bilgusbut look at init
10:40:15speachyaah, ok, the init
10:40:28speachyI don't think that matters
10:40:28_bilgusYEAH lol
10:40:41_bilgusits not filling the cache all the way
10:40:55speachyI don't see that
10:41:05speachyp is a char* pointer
10:41:07_bilgus8192 / 64 = 128
10:41:21speachyso p+=16 means the pointer goes up by 16
10:41:28speachynot 64
10:41:34_bilgusoh its not a long
10:41:56speachyit's a long in the invalidate code. And I think _that_ is a mistake
10:42:51_bilguswell you are reading a long though and its aligned too
10:43:28speachyfor (i = 0 ; i < 8192 ; i += 16) vs for (i = 0 ; i < 2048 ; p += 16)
10:44:07_bilgusI prefer the firat one
10:45:03speachyso the original code only invalidated 128 entries
10:45:53speachydoes each cache status word really occur four times back-to-back?
10:45:54_bilgusmakes you wonder if there is even a need for it
10:46:09_bilgusnot according to the dumps i've been looking a
10:46:16_bilgusI was puzzling the same
10:46:43_bilgusIve got like 20 if you want to look throught them maybe it does something weird to the addresses
10:47:02_bilguslets see if they increment
10:47:23speachyyeah, we're updating every 4th word. that seems illogical.
10:48:08speachyeww. wait
10:48:11speachywait
10:48:22speachy&STATUS_BASE_CPU + CACHE_SIZE
10:48:33speachystatus_base_cpu is a unsigned long pointer
10:49:00speachyso it's really (i = 0 ; i < 8192*4 ; i+= 16)
10:49:16speachy_that_ can't be right.
10:50:13_bilguslooking at the mem dump i see repeating entries some times never 4 though sometimes 2-3
10:50:14speachyso the old code is actually i < 8192. yours is i < 32768)
10:52:07_bilgusyeah you are right it should be CACHE_SIZE/ bits in that
10:53:15braewoodsspeachy: yes. turning off optimizations fixes it.
10:53:28speachy g#3271
10:53:30fs-bluebotGerrit review #3271 at https://gerrit.rockbox.org/r/c/rockbox/+/3271 : PP: more cache invalidation fixes. by Solomon Peachy
10:53:32braewoodsspeachy: i'll look into seeing if i can trace it.
10:53:47speachyit it a hang-on-boot or what?
10:54:02braewoodshang-on-boot, yes. it never reaches the menu.
10:54:17speachyok, that narrows things down a bit.
10:54:52braewoodsit would be better to fix the real culprit since optimizations shouldn't do this
10:55:06speachyof course
10:55:22braewoodsat least i found a trigger
10:55:34braewoodsi'll try narrowing down what optimizations might be responsible
10:55:41braewoodsthat would help even more
10:56:02braewoodscould be null ptr crap even
10:56:08braewoodsbut no idea yet
10:56:26braewoodsin general that should probably be disabled for freestanding code
10:57:00braewoodsspeachy: i suspect it was also broken for the old toolchain. it was masked by optimizations being disabled on all targets.
10:59:01chris_sg3271 seems to fix it, awesome
10:59:16fs-bluebotBuild Server message: New build round started. Revision 2f785c7797, 298 builds, 10 clients.
10:59:23speachychris_s: good enough for me. :D
10:59:45chris_s:D
11:00
11:01:07_bilgusworks here too
11:01:31_bilgusthink I worked at toyota or something
11:01:41_bilgusBBL
11:02:07speachybraewoods: in system-gigageat-s.c, try getting rid of INIT_ATTR in the system_init() function
11:02:27speachy_bilgus: hey, fumbling towards perfection, eh?
11:04:27speachybraewoods: actually nuke all INIT_ATTR and INITDATA_ATTR in that file
11:14:05fs-bluebotBuild Server message: Build round completed after 889 seconds.
11:14:07fs-bluebotBuild Server message: Revision 2f785c7797 result: All green
11:14:37braewoodsspeachy: ok i'll test from 19d45c9257d1d8d1f59746455cddaeef910b1577
11:16:04speachywhy not current master?
11:16:12speachy(I mean, that's after the point it broke anyway)
11:16:22braewoodsi was tracing it to see if there's more
11:16:29braewoodsremember, bilgus' LCD changes
11:16:49braewoodswe could be dealing with several issues at once
11:16:55braewoodsso i was trying to fix one before moving on
11:17:30speachythere haven't been any substantive changes to imx31 since then
11:25:51speachywell, the gigabeat build isn't adding in an intentional UDF instruction, so it's not the same nullptr issue that bit PP with -Os
11:26:37braewoodsspeachy: UDF
11:26:39braewoods?
11:30:12speachy"undefined instruction" aka "intentionally crash"
11:30:28speachythat isn't to say that there isn't something being optimized away helpfully
11:30:53braewoodsspeachy: i'll dig into it in a bit
11:32:09speachydoes the -S have an LED or something we can blink?
11:32:24speachy(well other than the backlight)
11:37:17 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
11:42:20 Quit RafiX (Remote host closed the connection)
11:42:33 Join RafiX [0] (rafix@junkcc.net)
11:44:20 Quit amachronic (Quit: Connection closed)
12:00
12:03:14***Saving seen data "./dancer.seen"
12:09:52 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
12:10:11 Quit ZincAlloy (Client Quit)
12:10:24 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:d68:907f:d02e:ddf)
12:16:40 Quit chris_s (Quit: Ping timeout (120 seconds))
12:44:30braewoodsspeachy: not to my knowledge
14:00
14:03:15***Saving seen data "./dancer.seen"
14:08:40 Nick dweeber_ is now known as dweeber (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net)
14:25:09braewoodsspeachy: ok. it works on master with optimization disabled.
14:25:34speachythe equivalent of -O0?
14:25:40braewoods-O actually
14:25:45braewoodsbut
14:25:47speachyok, that's -O1
14:25:48braewoods-O is the same more or less
14:25:55braewoodsit is?
14:26:19braewoodshuh it is
14:28:51braewoodsi'll try -O2 just for grins at the moment
14:29:26speachythat's not likely, as it's a superset of -Os
14:29:57speachy(-Os is "everything from -O2 that doesn't increase the binary size")
14:31:20braewoodsyou said i should try disabling those IATTRs in the system code?
14:31:35speachyit was a thought but I doubt that'll matter
14:32:05braewoodsi should try enabling optimizations until i find which one causes issues
14:33:02speachyTry -O2 first, and if that blows up (as I expect) you can turn -Os back on and start selectively diabling the optimizations it enables
14:33:44braewoodsi know one isn't enabled due to gcc 4.9.x changes
14:33:46braewoodswe disaled it
14:34:01speachyremind me please?
14:34:16braewoods-fno-delete-null-pointer-checks
14:34:37speachyah yes
14:35:02braewoodsi found a copy of the old manual so i don't waste my time on stuff not implemented in our current GCC
14:35:32braewoodsthis is a very good player... high end for its day
14:35:41braewoodsstill competitive even
14:35:52braewoodstoo bad it's so rare
14:36:22braewoodsi'll check out what is left to make this a stable port
14:36:51braewoodsi'm probably going to buy another one off ebay to use for comparison with the OF
14:37:39braewoodsspeachy: incidently, the battery reports 0 when i connected to USB
14:37:41speachyfrom the wiki it mostly looks like bootloader issues
14:37:54braewoodsyea, installation of it isn't easy
14:38:03braewoodsthe OF only has MTP
14:38:10 Quit f1refly (Quit: see ya in hell)
14:38:20braewoodsi'll see what it needs
14:38:26 Join f1refly [0] (~f1refly@2a01:c22:909c:d300:ff3d:8a1c:b6c6:f5ff)
14:38:52braewoodsbut tldr, rbutil doesn't work with MTP only devices
14:38:58braewoodsi wonder what our options are
14:42:07braewoodsit would be easiest to use libmtp but not sure how practical that is
14:42:13braewoodsin any case we just need to use it to send a single file
14:51:50speachyTry adding '-fno-gcse -fno-gcse-lm'
14:53:42braewoodsspeachy: what do those normally do?
14:54:26speachyGlobal Common Subexpression Elimination
14:55:12speachythe latter is the more interesting; it tries to pull writes inside a loop out of the loop
14:55:31speachy(ie if you keep overwriting the same variable and nothing tries to read from it, no point in re-writing it each time..)
14:55:32 Quit f1refly (Ping timeout: 258 seconds)
14:55:47speachyit would only be an issue if something wasn't properly marked as volatile.
14:56:36speachy(ie a hardware register, where writing it has "side effects" from C's perspective)
14:58:40speachy-fno-cse-follow-jumps -fno-cse-skip-blocks too
14:59:39 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
15:00
15:01:09speachy-fisolate-erroneous-paths-dereference is what tripped up the PP code but it's not likely an issue here
15:13:52 Join f1refly [0] (~f1refly@dynamic-077-010-167-250.77.10.pool.telefonica.de)
15:16:55 Quit f1refly (Client Quit)
15:17:09 Join f1refly [0] (~f1refly@dynamic-077-010-167-250.77.10.pool.telefonica.de)
15:22:38braewoodsspeachy: i'll try enabling all but those first
15:22:51braewoodssee if it compiles with -O1 with part of -Os enabled
15:22:53braewoodserr
15:22:56braewoodsworks rather
15:23:05speachythe -fno-* selectively disables those features
15:23:13braewoodshm
15:23:21braewoodswell i already wrote it out so. :|
15:26:02braewoodsspeachy: does rockbox automatically use all available cores?
15:26:15speachyfor compiles you mean?
15:26:25braewoodsyea
15:26:40speachynope.
15:26:47braewoodshm
15:26:52braewoodsi'll see if i can improve that
15:27:14speachythat's intentional
15:27:46braewoodsok.
15:27:51braewoodsstrange but ok
15:27:52speachygranted newer make versions can automatically do that for us
15:28:13braewoodsjust how old of a make do we have to support?
15:29:37braewoodsok now adding in the strict optimizations
15:29:45braewoodsthat build worked
15:30:12speachynormally make relies on the -j argument on the cmdline; I think only the newest GNU Make supports overriding that from within a given make invocation
15:30:31braewoodsi was thinking of trying to set makeflags
15:31:12braewoodsthat's how we always enabled it for linux packaging stuff
15:31:25braewoodswe only disable it when it the package didn't support it
15:31:33speachyyes but makeflags has to be set in the environment prior to make being invoked
15:31:43braewoodsoh.
15:32:04speachyit can be set within make and passed to sub-make invocations but we do it all in one go
15:32:24speachyI'm trying to find the release notes for the most recent gnu make
15:32:42braewoodswhich we don't currently do
15:32:52braewoodswe'd have to make a make wrapper really
15:33:00speachyGNU Make 4.3 (released last year) allows -j in MAKEFLAGS
15:34:12speachybut it's not clear that it can overriden from within a given make invocation.
15:34:13speachyso let's see
15:34:46speachyok, that does work
15:37:04braewoodsseems i've narrowed it down to 6
15:37:37 Quit f1refly (Quit: see ya in hell)
15:38:00braewoodsi kinda wish i could disable most of the plugins
15:38:05braewoodsduring these kinds of builds
15:38:06 Join f1refly [0] (~f1refly@dynamic-077-010-167-250.77.10.pool.telefonica.de)
15:38:16braewoodsthere's usually a ton of crap i don't need
15:38:37speachyedit tools/configure, set plugins='' for your target
15:38:51 Quit akaWolf (Remote host closed the connection)
15:38:59braewoodshuh ok
15:45:24speachy(you should be able to say plugins=no but there's a makefile quirk that prevents that from working
15:45:30speachy(fixing it now)
15:47:32fs-bluebotBuild Server message: New build round started. Revision 9e15c19891, 298 builds, 11 clients.
15:48:20 Quit f1refly (Quit: see ya in hell)
15:49:10 Join f1refly [0] (~f1refly@dynamic-077-010-167-250.77.10.pool.telefonica.de)
15:50:05speachylatest master will let you set a value other than 'yes'
15:59:34fs-bluebotBuild Server message: Build round completed after 722 seconds.
15:59:38fs-bluebotBuild Server message: Revision 9e15c19891 result: All green
16:00
16:03:19***Saving seen data "./dancer.seen"
16:21:30braewoodsspeachy: found something. -frerun-cse-after-loop causes a hang.
16:21:37braewoodsi'll test the rest.
16:21:46speachyok..
16:22:03braewoodsstill got 2 flags left
16:22:35speachysend me the .elf from the normal (-Os, failing) and the one with the specific flags removed and I'll dig into the asm to see what's going on.
16:22:49braewoodsi'll work on it after i finish my testing
16:22:58braewoodsi got 2 more left
16:23:11braewoodsgcse and gcse-lm
16:23:35braewoodsi decided to grab the whole set and test them individually
16:23:55braewoodstake me a bit, my server is building something else in the background
16:27:08braewoodsgcse passes
16:27:11braewoodstesting next one
16:27:44braewoodsthe weird part is the one i found wasn't even on your list; i just thought it try it because of the CSE phrase
16:27:47braewoodssounded related
16:28:18braewoodsanywho i'll send you the files one i'm done narrowing it down
16:28:46speachyok, thanks
16:29:04braewoodsi just wanted to be sure it's not multiples at once
16:29:19braewoodssometimes an issue can mask others
16:29:31braewoodsnot likely but it can happen
16:30:06braewoodsspeachy: which files you want specifically?
16:30:14braewoodsi can send you the whole build folder of both if you want
16:32:36braewoodslooks like that's the only flag giving issue
16:35:24braewoodsok building the first one
16:41:14braewoodsnow building with all optimizations
16:45:08 Join PimpiN8 [0] (~PimpiN8@82-75-30-111.cable.dynamic.v4.ziggo.nl)
16:45:33 Quit PimpiN8 (Read error: Connection reset by peer)
16:47:45 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
16:49:16braewoodsuploading now
16:51:00braewoodsspeachy: braewoods.net/rockbox-working.zip">https://braewoods.net/rockbox-working.zip
16:51:04braewoodsspeachy: braewoods.net/rockbox-broken.zip">https://braewoods.net/rockbox-broken.zip
16:51:33speachydone
16:51:43braewoodsit's the entire build directory
16:51:50braewoodsdidn't know what you might need
16:52:06speachyjust needed the two .elf files
16:53:12 Join f1reflyylmao [0] (~f1refly@2a01:c23:8861:7e00:e3b0:7323:c9c5:c2f2)
16:53:33 Join PimpiN8 [0] (~PimpiN8@178.239.173.176)
16:54:11 Quit f1refly (Ping timeout: 240 seconds)
16:54:12 Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c23:8861:7e00:e3b0:7323:c9c5:c2f2)
17:00
17:07:39 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
17:10:30speachybraewoods: any lcd output at all?
17:10:36braewoodsspeachy: yes
17:10:47speachysplash screen then?
17:10:50braewoodsspeachy: it displays the rockbox logo and build version
17:10:53braewoodsand then just stops there
17:11:00speachykk, thanks
17:11:01braewoodsin the working build it makes it to the menu shortly after
17:11:34braewoodsif we must we can disable this one optimization but
17:11:42braewoodsbetter to find out why it's crapping out here
17:14:38braewoodsit's just weird how some units became so rare
17:23:18braewoodsspeachy: once you find something let me know. i can try changing optimizations for specific files once i have some idea where to look.
17:33:22speachybraewoods: please build and try it with this: http://www.shaftnet.org/~pizza/take1.diff
17:33:44speachylet me know if it gets to the logo or not
17:33:45braewoodswhat does this do?
17:34:02speachyjust pushes the logo after a large chunk of the hw init code
17:34:10braewoodsok
17:34:11braewoodsmoment
17:34:21speachystill trying to narrow this down
17:39:04braewoodsspeachy: it now hangs at the bootloader screen
17:40:04 Quit Soap_ (Read error: Connection reset by peer)
17:40:30 Join Soap_ [0] (~Soap@rockbox/staff/soap)
17:43:00speachywell, that narrows things down considerably. let's split the difference
17:43:07speachyhttp://www.shaftnet.org/~pizza/take2.diff
17:44:30braewoodsok
17:44:42speachyso it's in one of: lang_init, rtc_init, adc_init, usb_init, backlight_init, button_init, powermgmt_init, radio_init
17:45:24braewoodsspeachy: apply to fresh git?
17:45:26braewoodsor what?
17:45:29speachyyes please
17:45:53braewoodsok building again
17:47:47braewoodsspeachy: same behavior
17:47:57speachyhuh, we don't have a single target that uses HAVE_RTC_RAM now
17:48:04speachyI guess that was just the archos recorder?
17:48:12braewoodstime to remove it?
17:48:31braewoodsanyway
17:48:38braewoodsspeachy: hangs at bootloader still
17:48:56speachyok, take3.diff is now up
17:49:20speachy(rtc/adc/usb/backlight/button)
17:49:46speachy(oh, and lang too, but I _really_ doubt that as there's no target-specific code in there)
17:50:11braewoodsgood thing this has a way to quickly do a hardware reset
17:50:21braewoodsthis would be a royal PITA if it didn't
17:52:42braewoodsspeachy: logo comes up
17:53:06speachyok, that is purely backlight and button then
17:53:16braewoodsone more to narrow it down more?
17:53:50speachyyep
17:54:05 Join f1reflyylmao [0] (~f1refly@2a01:c22:8c20:5d00:83f5:1076:75da:64b9)
17:54:07 Quit lebellium (Quit: Leaving)
17:54:34 Quit f1refly (Ping timeout: 245 seconds)
17:54:34 Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c22:8c20:5d00:83f5:1076:75da:64b9)
17:55:02speachytake4 is up
17:55:14speachyI'm expecting this to fail.
17:56:18braewoodsonce we have it narrowed down we can try disabling the optimization for those files
17:56:33braewoodstry to isolate what source is impacted
17:58:55braewoodsspeachy: makes it to the logo again
17:59:14speachyhuh. so it's the button init code
18:00
18:00:56 Quit ac_laptop (Quit: WeeChat 3.0)
18:01:01_bilgusI would have guessed the backlight
18:01:16 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
18:02:45braewoodsshall we try disabling the optimization for the code and see what happens?
18:02:55braewoodswe might have multiple parts impacted
18:03:01braewoodsso need to narrow down the scope of the bug
18:03:08speachyok, take5
18:03:22***Saving seen data "./dancer.seen"
18:03:30speachyisolate the "button" from the "headphone" init
18:05:04braewoodsok built
18:06:06braewoodsspeachy: boot logo appears
18:06:27speachyie not bootloader, correct?
18:06:34braewoodsyes, it displays the logo
18:06:38braewoodsnot the text screen of bootloader
18:06:41 Quit ac_laptop (Ping timeout: 240 seconds)
18:07:37speachytake6 is up
18:08:07speachyI expect this to fail.
18:08:40braewoodsbuilding
18:11:46braewoodsspeachy: yep failed
18:11:49braewoodstext screen
18:12:30speachyok, the file in question is firmware/target/arm/imx31/gigabeat-s/headphone-gigabeat-s.c
18:14:23braewoodstry using a pragma to disable the optimization...
18:14:43speachywonder if the inline asm here is the culprit.
18:15:00braewoods-frerun-cse-after-loop
18:15:10braewoodswas the offending optimization
18:15:19speachywell, the only loop here is in the thread body
18:15:21_bilgusdoes gcc optimize hand ASM too?
18:15:30braewoodsin any case we should see if any other files are impacted
18:15:31 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
18:15:37speachyno but the asm can interact ...badly if it's not set up properly
18:15:43braewoodsbefore thinking this is the only one
18:15:54braewoodsif that makes any sense
18:16:05braewoodsi'll try disabling in that one file
18:16:09_bilgusifdef it out
18:19:41braewoodsok now attempting something
18:19:46speachytake7 is up
18:19:53braewoodsoh
18:19:56braewoodsi'll try take7 shortly
18:20:06speachyI honestly don't see how this code can trigger an outright hang directly.
18:21:09braewoodsme either but i've seen weirder hsit
18:21:20speachyhowever, the mc13073 IRQ handling is more likely to be it
18:22:06speachythis code leaves the event disabled so the thread should never trigger.
18:22:38braewoodsbuilding
18:24:09 Join MrZeus_ [0] (~MrZeus@194.37.96.137)
18:24:37braewoodsspeachy: hangs at logo again
18:25:59speachyok, that's fine. take8 up
18:26:12 Join MrZeus [0] (~MrZeus@2a02:c7f:a0aa:4400:f878:24fa:cc54:429d)
18:26:30speachyfixed it
18:26:36speachy(the compile failure I mean)
18:27:33speachytake8 guts the thread's loop.
18:27:52 Quit MrZeus__ (Ping timeout: 246 seconds)
18:28:55 Quit MrZeus_ (Ping timeout: 265 seconds)
18:30:49speachygoing to bounce for a while. programmer needs fuel.
18:40:52braewoodsspeachy: take8 boots fully
18:44:43braewoodsi suspect the problem is in one of the functions the loop clals
18:46:00braewoodstesting if adc_read is OK or not
18:46:09braewoodsoh wait
18:46:11braewoodsdoh
18:51:58braewoodsok inserted the pragma into relevant files
18:52:02braewoodstime to see what happens
19:00
19:01:15 Quit MrZeus (Read error: Connection reset by peer)
19:02:40 Quit ac_laptop (Ping timeout: 268 seconds)
19:02:45 Join MrZeus [0] (~MrZeus@90.200.238.7)
19:05:00speachywe don't care so much about the files, just the callgraph in question
19:06:59 Quit gevaerts (Ping timeout: 252 seconds)
19:07:08 Join gevaerts [0] (~fg@rockbox/developer/gevaerts)
19:18:18 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:18:38 Quit gevaerts (Ping timeout: 240 seconds)
19:18:54 Join gevaerts [0] (~fg@rockbox/developer/gevaerts)
19:24:44speachydc
19:25:19braewoodsspeachy: let me know when you have some idea of what to try next
19:25:23braewoodsi put the unit up for charigng
19:25:25braewoodscharging
19:26:00braewoodsbut it does work with diff8
19:26:21braewoodsbut what part is responsible is unknown to me
19:26:30speachyit's just shrinkinking the disabled area
19:26:54braewoodsplus due to the optimizations we may need to do some clever stuff to keep code from being optimized away
19:27:26speachymore likely, undo something clever. I'm still not inclined to believe the issue lies outside of the imx31 subdir.
19:27:48braewoodsperhaps
19:27:51braewoodsi just meant
19:27:57braewoodsin trying to isolate the problem area
19:28:05speachythere's a take9 now if you wan
19:28:14braewoodsi'll give it a spin; moment
19:28:19braewoodsi think this unit needs a new battery
19:28:22braewoodsseems to run out too readily
19:28:31speachyit's 15 years old, heh
19:28:47braewoodswell i'll work on that next week
19:30:08braewoodsok
19:30:10braewoodsbuilding
19:30:22speachy(take9 enables the adc_read, and a little bit of logic towards the end.
19:32:48braewoodsboots
19:34:09speachytake10
19:35:58speachyI'm betting it's the adc_data_to_button() function, with the inline asm confusing things.
19:36:32_bilgusput the old if then tree
19:37:01_bilgushttps://github.com/Rockbox/rockbox/commit/669fa9a13002835a139b72db80a2a3ee69fa434e
19:39:13_bilgusand thats why people should probably leave the c code in when they do ASM inline
19:40:00braewoodsor not bother with ASM unless you literally cannot do it from C
19:40:17braewoodsASM is a double-edged sword
19:42:01braewoodsspeachy: ok it locks up with that one
19:42:29braewoodsit's only good if you absolutely must have your code generated a certain way
19:42:38speachy...that was unexpected.
19:42:56_bilguswell sometimes speed does matter
19:43:10braewoodsisn't C codegen usually better?
19:43:12 Quit Strife89 (Quit: No Ping reply in 180 seconds.)
19:43:18_bilgusbut I feel lik sometimes esp in this codebase its been taken too far at times
19:43:38braewoodsusing ASM doesn't let us benefit from compiler advances
19:44:06braewoodsmaybe it's only x86 but i've found it hard to beat the compiler for well optimized code
19:44:41 Join Strife89 [0] (~quassel@adsl-74-250-141-224.ags.bellsouth.net)
19:44:44braewoodsmain time i've seen asm used is when you can't get your compiler to generate the code you need or want
19:45:00braewoodse.g., using cpu extensions but that's mainly an x86 thing
19:46:48 Join rogeliodh [0] (~rogeliodh@rogeliodh.dev)
19:47:41 Quit ZincAlloy (Quit: Leaving.)
19:53:16braewoodsspeachy: i was thinking of trying something else
19:53:19braewoodshm
19:54:27speachytake11.
19:57:11speachyI think I see the issue. take11 should work.
19:59:57braewoodsspeachy: ok it boots
20:00
20:00:25braewoodsi had a feeling it was that button get code
20:01:07speachytake12
20:01:27speachyI expect this to work too.
20:02:17braewoodsspeachy: if it does, what's the issue?
20:02:40braewoodsheadphones_detect is a strange one
20:02:42braewoodsbut
20:02:46speachythe headphones_detect variable. it's write-only in one thread context, read-only in the rest
20:03:12braewoodsda fuck
20:03:23***Saving seen data "./dancer.seen"
20:05:27braewoodsit works
20:05:59braewoodsso we need to modify that one variable's storage attributes?
20:06:40speachytake13
20:07:14braewoodsspeachy: why int instead of bool?
20:07:26 Quit MrZeus (Ping timeout: 268 seconds)
20:07:44speachyit's an int's worth of storage anyway, so there's no advantage
20:07:57braewoodsok
20:08:32braewoodsspeachy: why was GCC doing that with this one variable?
20:11:10speachyI don't see any meaningful change in teh asm dump so I'm not confident this fixes anything
20:11:19braewoodsspeachy: it doesn't
20:11:29braewoodsit's still locking up
20:11:29speachyok
20:11:40braewoodsi wonder
20:12:26braewoodsalignment issue?
20:13:02speachy...or stack overflow
20:13:18braewoodsstack overflow?
20:13:25braewoodsthis variable is allocated outside of the normal stack
20:13:33speachyit's immediately adjacent to the stack
20:13:41braewoodsi see.
20:13:46braewoodsso enlarge the stack?
20:13:49speachyyeah
20:14:36speachytake14
20:14:48braewoodsyou naming them takes
20:14:53braewoodssounds like we're filming a movie
20:14:55braewoodsX)
20:15:10speachyI'll bet this is it
20:15:42braewoodsnot much point to being stingy with the stack on this target
20:15:54braewoodsit has 64MB
20:15:58braewoodsmore than most do
20:16:19speachythe old stack size was probably just barely perfect. and with this we oh-so-slightly stepped over it. probably trashing the return value
20:16:25speachyreturn address
20:17:10speachywhen this boots up, go into the debug/thread info screen and it'll report the stack size for the headphoen thread.
20:18:10speachy(remember what I said about this being about undoing cleverness?)
20:18:14 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
20:18:23braewoodsi'll look
20:19:17 Join dconrad [0] (d026e411@208.38.228.17)
20:19:36braewoods91% usage from the headphone one
20:19:58braewoodsthis seems to fix it
20:20:05_bilgusthe issue is the isr knocking you over the top
20:20:12 Quit pamaury (Ping timeout: 246 seconds)
20:20:14speachy91% is 182 bytes
20:20:47braewoodsnext time we should check the stack first?
20:20:49speachya whopping two words over the old size.
20:21:07_bilgus182 bytes? its a 255 byte stack?
20:21:13braewoods200
20:21:15speachyit was 176 bytes
20:21:25_bilgusO_o
20:21:26speachyI bumped it to 200 for this test
20:21:43braewoodsthat was the old value
20:21:47speachythe patch you suggested reverting dropped it from 200 to its 176
20:21:48braewoodsbefore they optimized it
20:22:01_bilguslol
20:22:06speachyso basically it was _perfectly_ sized for the old code+compiler+optimizations
20:22:21braewoodssounds stupid to leave yourself no room for expansion like that
20:22:23speachy(let this be a lesson to everyone...)
20:22:27braewoodsin something that will get forgotten about
20:22:27_bilgushappens
20:22:37_bilgusand probably it was two compilers ago
20:22:56_bilgusjust didn't get caught till now
20:23:20_bilgusbut thats anything like that but I think we should maybe talk about hand optimized ASM
20:23:41speachyit could have bery well been a problem before but the critical value wasn't getting overwritten. or the variable layout was slightly different.
20:23:52_bilguslike the h10
20:27:18fs-bluebotBuild Server message: New build round started. Revision afec380a0d, 298 builds, 11 clients.
20:27:37CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
20:27:37*speachy sticks a fork in it.
20:28:14speachy... I'm beginning to think we shouldn't do a stable realease until we can get at least one report of each target successfully booting.
20:29:30_bilguswe need the tower of rockbox
20:31:39_bilgussaratoga maybe?
20:31:55_bilgushe hasn't been here in a bit hope he comes back
20:32:22braewoodsspeachy: one problem though, some targets are rare
20:32:35braewoodsmpio units? i've never seen one on ebay.
20:32:38braewoodsditto for packard bell.
20:33:02speachywell, we need to test the "stable" targets at least.
20:33:12_bilgusWhat we need to do then is put up a table of tested untested works broken
20:33:16_bilguslike the old days
20:36:54*speachy shudders at the thought of maintainnig that as a wiki page
20:38:10braewoodsspeachy: we should first build up a list of units we have in the developer or contributor area first
20:38:41braewoodsi have iriver h120, h10 (once i get it back from bilgus), the gigabeat S i just received...
20:38:46speachy(it makes sense as a wiki page, but our wiki... ugh)
20:38:48braewoodsphilips gogear hdd1630
20:38:54braewoodshdd6330
20:39:02speachy(after it nearly took down my server again today..)
20:39:25 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
20:39:42fs-bluebotBuild Server message: Build round completed after 744 seconds.
20:39:46fs-bluebotBuild Server message: Revision afec380a0d result: All green
20:42:21braewoodsspeachy: first we need to document what units we have at least one unit of
20:43:40speachyhmm, extend builds.pm to include this info maybe.
20:44:56braewoodsi'll put something on the forums
20:45:03braewoodswe may be able to get some help there
20:46:03braewoods_bilgus: https://forums.rockbox.org/index.php/topic,53611.0.html
20:46:10braewoodsplease archive this thread, it has served its purpose
21:00
21:03:31speachyI'm going to try and hack together a proof of concept of a migrated wiki. foswiki, using a git backend for pages, and have it authenticate against our bug tracker.
21:06:21braewoodsso the wiki would be contained in gerrit somewhere?
21:06:35speachybidirectional, yeah
21:39:53_bilgusbraewoods https://forums.rockbox.org/index.php/topic,53800.0.html
21:40:40braewoods_bilgus: you forgot the H120 and H110
21:40:51braewoodsand yh-820
21:40:59_bilgusI only filled out the ones I have
21:41:08braewoodsOh.
21:41:10_bilgusor you mean in the table
21:41:14braewoodstable
21:41:17_bilgusah
21:41:36braewoodsthere's also gigabeat F series
21:41:41braewoodsit's much more common than the S
21:44:09braewoodsthe X series isn't very common
21:44:17braewoodsbut it shares the same build as the F
21:44:21braewoodsso should be close enough
21:45:20braewoods_bilgus: also the h10 is split into the 20GB and 5/6GB ports
21:45:31braewoodsthough i suspect the 5/6GB is going to be pretty rare
21:45:41_bilgusI have h10 and h10 5gb
21:45:42braewoodsit has no real upgrade potential and its battery is weird
21:45:46braewoodsOh.
21:45:54braewoodsyou had your own H10 before I shipped mine?
21:46:02braewoodso.O
21:46:04_bilgusno I mean in my posession
21:46:06braewoodsoh
21:46:13_bilguslike speachys rocker too
21:46:32_bilgusI tested those devices so I marked them as works
21:46:41braewoodsand the S is from my reports here?
21:46:45_bilgusyep
21:46:48braewoodsok
21:47:00braewoodsi may get a cheap F20 to repair for testing
21:47:13braewoodsthere's quite a few
21:49:13_bilgusok updated
21:49:31_bilgusthat should get us some fill on the more common stuff
21:50:01_bilguseither saratoga or geaverts has the majority of these
21:50:29braewoodssome of these cannot be tested by buying them since they're no longer available
21:51:03_bilguswell we start removing stuff after a few rounds and I bet they come out
21:51:18_bilgusBUT I still have this!!
21:52:29braewoods_bilgus: what port is the creative zen vision m part of?
21:52:34braewoodsi don't recall reading that anywhere
21:54:42_bilguswhat port?
21:54:55braewoods_bilgus: you had it listed
21:55:11 Quit cockroach (Quit: leaving)
21:55:11braewoodsbut i don't recall reading about it anywhere in the docs
21:56:14braewoodsoh
21:56:17_bilgusok I just grepped the build page for the models
21:56:26braewoodshuh
21:56:33braewoodsit's probably an unfinished port with no docs
21:56:43_bilguscould be
21:56:58_bilgusbut I didnt see the giga F/x In there
21:57:19_bilgusthe build one are we no longer building for it or did I miss it
21:57:46braewoodshttps://build.rockbox.org/
21:57:49braewoodsit's right before the S
21:58:19braewoodsvision isn't even built there
21:59:26braewoodsoh found the info
22:00
22:00:02braewoodshttps://www.rockbox.org/wiki/CreativeZVMPort
22:00:05braewoodsyep it's half-finished
22:00:29braewoodswe may end up having to jettison these ports that were never finished
22:00:46braewoodsthat are like over 10 years old and no serious effort to make them useable
22:00:57_bilgusAs we should
22:01:15_bilgusits still in the tree if someone wants to pick it up
22:01:53braewoodsi'll grab an F20 and rebuild it
22:01:56*braewoods has the technology
22:02:07_bilguslol
22:02:22_bilgusat least the techs cheap now
22:03:26***Saving seen data "./dancer.seen"
22:21:29_bilgusamachronic (logs) looks like we can just rejigger cur->get_context_map and inject out own lookup table
22:22:01_bilgusso that part is easy the hard part will be the logic for a plugin
22:24:48_bilgusactually I might do that in lua
22:26:08speachyhmmmm. the dokuwiki git backend is only half-baked. damn..
22:26:34_bilguspotential upgrade path?
22:29:12_bilgusSo I'm thinking we can just make it search for Plugin.btn, wps.btn, etc and have it load them into a predefined table allocated by buflib
22:29:44 Quit dconrad (Quit: Connection closed)
22:30:49_bilgusor just one big table with 4 ints contxt, action, button, pre_btn
22:31:32_bilgusproblem is that order matters in action tables
22:31:39braewoodsspeachy: it's almost like we'd be better off with one of those site generators that works off a git repo
22:32:22speachybraewoods: yeah. the only thing a tradiitonal "wiki" brings us is web-based edits.
22:32:55braewoods_bilgus: i was thinking how we could reduce memory usage a bit with the image files
22:33:12braewoods_bilgus: ICO packs. one contiguous block for all the images
22:33:25braewoodsbut eh just a random idea
22:33:37speachyit seems a bit much to expect folks to grok git/gerrit to modify the "wiki" though.
22:34:28_bilgusthe wiki has terrible syntax
22:34:36speachythis one is ... awful
22:35:07speachymaintaining the history is nigh-impossible if it rquires migrating the syntax too.
22:35:09_bilguslike moreso than currently?
22:35:20speachyI mean the one we have now is awful
22:35:23_bilgus@braewoods
22:35:35speachy_any_ other choice is a massive net improvement. if only because we can use markdown or whatever
22:36:13_bilgusthe images are already stripped per file for icons and such are you saying to put them all together?
22:36:17speachyI'm thinking it may make more sense to just statically save the old site off to the side and nuke it from orbit. :D
22:36:32_bilgusstripe-ed
22:36:34_bilguslol
22:37:02_bilgusspeachy I agree we should archive as it sits and move on
22:39:40_bilgusI wonder if the vector file for the rb logo is smaller than the image probably not after you consider the polyrenderer
22:40:19braewoods_bilgus: well the larger your allocations the less fragmented
22:40:27braewoodsthough it's just an idea
22:40:40braewoodsi observed ICO stores BMPs unmodified that i can tell
22:40:52braewoodsso with some clever addressing hacks you could just load them all into RAM
22:41:06braewoodsas long as the pointers are right, it shouldn't matter
22:41:16braewoodsbut, alignment might be a problem then
22:41:32_bilgusidk only if you use a script to build the ico packs lol
22:41:47braewoodsquite doable, there's even tools to do so.
22:41:57braewoodsICOs can also contain PNGs but we have no means to manipulate those
22:42:05braewoodsand what would be the point?
22:42:10braewoodsrockbox doesn't really benefit
22:43:36_bilgusidk I think separate is better at least then you can unload them
22:45:28 Quit f1refly (Ping timeout: 246 seconds)
22:45:45 Join f1refly [0] (~f1refly@2a01:c23:8c66:bf00:63a3:832f:7359:85c6)
22:45:51_bilgusI wonder how much ram is tied in images
22:46:40braewoods_bilgus: like 256K or less from what i was looking at in the default theme
22:47:14_bilgusi'm saying across the whole of rockbox
22:47:19braewoodsOh.
22:47:31braewoodsultimately if we're just decompressing to the same size regardless
22:47:37braewoodsPNG would only offer some disk saving
22:47:40braewoodsbut pretty moot
22:47:55_bilguslike is it 1 meg of images total
22:48:13_bilgusimage paths are a lot shorter to store
22:49:24_bilgusI think I want to start moving stuff out of core
22:49:33_bilguswe have voices in plugins
22:50:01_bilguswe can move some of the infrequently used stuff out and still have use of it
22:50:15_bilguslike the whole eq menu
22:50:36_bilguscar adapter mode
22:51:05_bilgusthese things can be handled with clever cmd line args to plugins
22:52:01_bilgusget core down to a Fat kernel
22:53:39_bilgushell the settings menus can even be moved out there like the debug menu though it is a bad example since it uses hacks
22:54:36_bilgusbut not the core settins
22:55:55_bilgusshortcuts menu is first on my list
22:57:57speachythe problem with scrapping the existing wiki is that it needs to be replaced with something. and that something is going to take a lot of work to build.
22:58:13speachycontent-wise, I mean
23:00
23:15:57speachyand there are 2275 pages.
23:22:32_bilgusphew
23:23:31 Quit Strife89 (Ping timeout: 268 seconds)
23:37:29braewoodswhat about the official wiki software?
23:37:32braewoodsnot a good fit?
23:37:56speachy"the official" ?
23:39:46braewoodsspeachy: mediawiki i thought?
23:39:56braewoodsit seemed to be what wikipedia uses
23:40:08braewoodsbut no idea
23:40:19braewoodsthere's a ton of wiki clones
23:40:52speachyyep. all of which suffer from the same problem −− getting the data out of our old site is ... lost case comes to mind
23:41:10braewoodsisn't that true of any CMS we use
23:41:25braewoodsthere's not really any standard way of exchanging this kind of data to my knowledge
23:41:33speachyyes and no.. this thing's sytax is ... unique
23:41:56braewoodsdo the newer versions have compatibility
23:42:17braewoodsi know you said you can't easily migrate
23:42:27braewoodsbut does it retain content compatibility?
23:42:50braewoodsmeaning can we just copy it over in some manner and just have it more or less work
23:43:07braewoodsthat's the main issue we face
23:43:07speachysort of. it's essentially a manual migration path
23:43:33braewoodstrue but it's looking like that is going to be involved no matter what
23:43:34speachybut there's no guarantee that the engine will be less of a resource hog
23:43:51speachyand stuff's gonna break.
23:43:52braewoodsdoes the new engine allow for caching?
23:44:00braewoodsthat's true no matter what
23:44:01speachythe old one already does
23:44:12speachyto the point where there's a cache for teh cache
23:44:16speachyand that's what keeps keeling over
23:44:52speachyfrom normal web crawler traffic
23:47:06braewoods._.
23:48:02braewoodsa static site generator CMS would solve most of these problems
23:48:06_bilgusgod the amount of links in that wiki
23:48:17braewoodswe don't edit the wiki all that often
23:48:21speachyyeah. and the migration I'm trying isn't preserving most of 'em.
23:48:28speachy... wtf.
23:49:13speachyand a whole lot of other brokenness too (thie converter was written around the original twiki syntax and is therefore a decade out of date)
23:49:21_bilgusI assume if you cut the link to the wiki from the mainpage the spiders would stop finding it?
23:49:46speachyexcept for all the cached links, sure
23:50:32_bilgusremove it and make it a random link for a few months
23:51:23speachyfoswiki has a 'publish' extension that will generate static html for a page or namespace.
23:52:04_bilgusthat might be a valid way to do it make the editable portion invite only
23:52:31_bilgusthen have a script to gen new content on the build farm
23:52:57_bilgusthen migrate
23:53:58_bilgusthen we can still edit stuff for a bit till it gets closed down and the last static set is the final
23:54:51_bilgusand by migrate I mean a clean new thing no old info

Previous day | Next day