--- Log for 01.04.121 Server: weber.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 10 hours ago 00.00.15 # <_bilgus> but there is no mirroring I can see 00.00.28 # <_bilgus> I bet box those mirrors are COP 00.00.40 # <_bilgus> both* 00.01.13 # <_bilgus> probably the same with the flush base and invalidate base too 00.01.51 # <_bilgus> so now my questions are 1. how to init the cache for the other processor 00.02.18 # <_bilgus> like can we prime it from our other core then safely? 00.02.25 # _bilgus: i may ask for your help with the gigabeat S but after you solve the H10 issues 00.03.00 # in any case i need to trace it 00.03.02 *** Saving seen data "./dancer.seen" 00.03.05 # <_bilgus> 2. is this the reason for the myriad issues of alignment and such over the past 10+ years 00.03.09 # i can't assume it's the same thing that killed the H10 00.03.19 # <_bilgus> 3. will it fix issues with other pp devices 00.03.50 # <_bilgus> braewoods, I don't think anyone ever would have guessed that a lcd update would cause this 00.04.16 # well it did kill the iriver H300 bootloader 00.04.22 # until we fixed the issues 00.04.29 # <_bilgus> it just happened I think that the fb was no longer static so it got cached 00.05.05 # sounds like you need to disable caching or so 00.05.18 # <_bilgus> its a good thing 00.05.43 # <_bilgus> the code nbot the address 00.06.06 # <_bilgus> thats the cool thing about a instruction cache 00.06.33 # <_bilgus> assuming your thing can fit in a cacheline or two 00.07.03 # is it like the cache x86 uses? 00.07.17 # it sounds like IRAM or so 00.07.19 # <_bilgus> x86 has aid cache 00.07.24 # RAM really close to the CPU 00.07.51 # <_bilgus> I don't think it necessarily has to be close 00.09.25 # <_bilgus> IRAM you put the stuff and leave it the cache is LIFO basically 00.09.53 # <_bilgus> anything can be there at a given time 00.10.13 # <_bilgus> but then you need to do all the book keeping 00.10.24 # <_bilgus> well some of it 00.11.23 # <_bilgus> it really makes a noticible difference on this h10 00.11.35 # so how can you fix the issue? 00.11.49 # <_bilgus> what issue? 00.11.55 # a cache is useless if it interferes with reliable operation 00.12.03 # <_bilgus> its fixed 00.12.08 # so what was the fix? 00.12.28 # <_bilgus> g#3264 00.12.39 # <_bilgus> bah bluebotttt 00.13.02 # it's feeling blue 00.13.02 # <_bilgus> we were clearing the status of the CPU from both cores 00.14.00 # meaning the zero flag, etc? 00.14.39 # strange issue 00.14.44 # <_bilgus> no meaning we were wiping out the cache of the CPU with invalidated entries from the other core 00.14.53 # oh 00.15.14 # and of course PP can have race conditions due to having multiple cores 00.15.19 # <_bilgus> and on top not even invalidating anything on the COP 00.15.53 # not that cores are a pre-req to that 00.15.55 # but 00.16.05 # eh 00.16.11 # all depends on how you handle concurrency 00.16.51 # <_bilgus> I 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 # <_bilgus> http://www.ipodlinux.org/PP5020/ 00.18.15 # <_bilgus> I still don't know about q1 but I think I'll mess around with it 00.18.50 # ok ordered some stuff so i can try some stuff with the gigabeat s 00.18.56 # while i wait on those parts 00.22.38 # i'll try to sort out the gigabeat S issue 00.33.04 # good grief 00.33.10 # it seems like it has to build everything 00.35.56 # 3.15 works no surprise there 00.36.51 # <_bilgus> well jump to the commit before the lcd update just to be sure 00.36.54 # <_bilgus> lol 00.37.40 # i'm going to gradually get there 00.38.19 # i'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.41 # FS#13281 Was able to reproduce this and will investigate it... 00.48.47 # <_bilgus> might be an old bug or your new playback stuff 00.53.02 # _bilgus: commit right before the new toolchain checks out 00.53.11 # i'll test right before LCD changes 01.00.32 # bilgus: 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.32 # I 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.17 # speachy: appears your toolchain broke the gigabeat S port 01.17.31 # <_bilgus> looks like 18 devices use the pp5020 01.17.51 # <_bilgus> bunch of ipods 01.17.57 # <_bilgus> I'm excited 01.18.14 # <_bilgus> wonder what it fixes/breaks 01.18.17 # or 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.12 # braewoods: nice. 01.21.35 # also, you volunteered in finishing the port. I don't have much use for it anymore now :) 01.21.47 # kinda :D 01.21.48 # bluebrother: just hope we can fix the current issue 01.21.55 # sure. 01.22.04 # otherwise not much point "finishing" it 01.22.26 Quit ZincAlloy (Client Quit) 01.22.29 # always nice to see things getting fixed. I'd been quite a lot of changes lately. 01.31.41 # i would like to add a tvout driver for it but 01.31.44 # one 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.17 # well one change in the GCC flags... 01.38.27 # -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.17 # first thing to try, disable optimizations 01.48.37 # ... 01.48.39 # That was it? 01.48.41 # Seriously? 01.49.06 # speachy: it looks like gigabeats for some reason breaks if optimizations are turned on 01.49.16 # as to why i can't begin to gues 01.49.20 # speachy: suggestions? 01.52.14 # speachy: in any case i plan to do some repairs on the unit before i do much else with it 01.52.24 # i would prefer to know why optimizations break it 01.52.28 # but is that even realistic? 01.52.56 # the symptoms i observed is it would hang similar to the H10. 01.53.03 # i'd see the rockbox logo and the version at the bottom 01.53.05 # but it hangs there 01.53.38 # but optimizations were effectively disabled for gigabeats before the toolchain upgrade 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.13 # I'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.15 # https://www.rockbox.org/tracker/task/13281 Problems playing the first song after player turned on (bugs, unconfirmed) 02.02.15 # Gerrit 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.54 # i'll dig into it more later 02.06.01 # i'll see if -O1 works 02.06.03 # etc 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.03.04 *** Saving seen data "./dancer.seen" 05.02.02 Quit melmothX (Quit: reboot) 05.35.16 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 05.58.51 # Build Server message: New build round started. Revision 674c07d654, 298 builds, 10 clients. 06.01.53 # _bilgus: so you also forced exceptions to only be handled on the primary CPU? 06.03.08 *** Saving seen data "./dancer.seen" 06.03.32 # Or rather, you replaced CURRENT_CORE with IF_COP_CORE(CPU) but that's not the same at all 06.04.14 # IF_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.19 # everywhere you changed CURRENT_CORE to IF_COP_CODE seems... suspect. 06.09.37 # eg now in irq_handler, instead of primary CPU, irqs can now be handled by either. 06.10.15 # IF_COP_CORE(x) is a macro that 06.11.07 # so even in the cache_invalidate_special() function you're only ever initializing the primary CPU's cache. 06.13.56 # Build Server message: Build round completed after 905 seconds. 06.13.59 # braewoods: gigabeat-S hang on startup? 06.14.04 # Build Server message: Revision 674c07d654 result: 5 errors 0 warnings 06.19.14 # <_bilgus> speacy you sure bout that? 06.19.24 # <_bilgus> speachy* 06.19.27 # <_bilgus> https://github.com/Rockbox/rockbox/blob/master/firmware/export/config.h 06.19.52 # <_bilgus> or is it redefd somewhere? 06.20.21 # <_bilgus> looks like a FB macro to me 06.20.58 # if !defined(FORCE_SINGLE_CORE) ... #define IF_COP_CORE(core) core 06.21.56 # <_bilgus> yeah and just below https://github.com/Rockbox/rockbox/blob/master/firmware/export/config.h#L1161 06.22.13 # that's wrapped by #ifndef NUM_CORES 06.22.17 # but NUM_CORES is 2 06.22.33 # (on the PP, unless FORCE_SINGLE_CORE is set) 06.24.17 # <_bilgus> wth is the redef then not seeing it 06.26.11 # my point is it's _not_ getting redefined; using IF_COP_CORE(...) is wrong in this context. 06.26.34 # <_bilgus> oh dub 06.26.40 # <_bilgus> damn 06.26.44 # <_bilgus> I see it 06.26.48 # everywhere you used it you should have used CURRENT_CORE instead 06.27.08 # <_bilgus> What I was trying to do was get that force single core to work properly 06.30.09 # I don't think that's necessary with your changes; CURRENT_CORE == CPU in a FORCE_SINGLE_CORE scenario 06.33.51 # <_bilgus> Well good thing YOU caught that 06.34.05 # <_bilgus> thankfully the player is still fixed :p 06.37.24 # the 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.17 # g#3268 06.38.19 # Gerrit 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.26 # it compiles therefore it must work! 06.40.52 # <_bilgus> I assume its the same as what I just tested but if not ill discover it next round with g#3265 06.40.54 # Gerrit review #3265 at https://gerrit.rockbox.org/r/c/rockbox/+/3265 : pp5020 -- Initialize COP cache at init_cache by William Wilgus 06.41.40 # 3265 isn't needed 06.41.58 # system_init() is called by both cores, and init_cache is unconditionally called at the end of system_init() 06.44.35 # <_bilgus> ah I was wondering if it was like that or if we just couldn't determine which core would be master 06.45.39 # (both CPUs call the same reset vector) 06.48.54 # <_bilgus> so 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 # <_bilgus> and now 4. why did daniel think it was mirrored memory 06.49.53 # <_bilgus> on the e200 or w/e he tested on 06.54.43 # Build Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients. 06.55.25 # <_bilgus> I also have to wonder if this is why he couldn't get invalidating ranges to work 06.55.53 # <_bilgus> not that I intend to find out 07.00.24 # it might be responsible for our various DMA write corruptions 07.01.08 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 07.02.56 # <_bilgus> same 18 players 07.03.03 # <_bilgus> using that module 07.03.18 # <_bilgus> well same for the other 17 07.15.36 # Build Server message: Build round completed after 1253 seconds. 07.15.38 # Build Server message: Revision 0b20038d87 result: 113 errors 0 warnings 07.17.14 # um... wtf.. 07.17.21 # I'm going to force a do-over on that round 07.21.23 # Build 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.24 # Build Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients. 07.56.33 # _bilgus: Should I submit that USE_CURRENT_CORE patch? IMO what's in the build now isn't likely to yield correct results. 08.02.21 Join amachronic [0] (5284b839@82.132.184.57) 08.03.11 *** No seen item changed, no save performed. 08.04.20 # chris_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.22 # https://www.rockbox.org/tracker/task/13281 Problems playing the first song after player turned on (bugs, closed) 08.05.41 # since 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.01 # sorry 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.06 # reading 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.27 # ..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.01 # amachronic: 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.01 # problem 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.31 # just banned another bot. 08.27.19 # chris_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_ph> Speachy yes I thought you already committed it, I tested it 08.36.24 # ok, will do 08.36.36 # need to finish cleaning up the mess the huge server load did to the buildserver 08.37.20 # (driven by that bot pounding the wiki... sigh) 08.38.36 # Build Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients. 08.38.51 # ok, let's see if this is clean 08.39.05 # then I'll merge the PP stuff 08.39.48 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 08.40.56 # <__Bilgus_ph> Re 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_ph> Then 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.01 # hmm, gigbeat-s is a an imx31 08.45.09 # <__Bilgus_ph> If match is found it returns new buttons to action sys 08.46.05 # <__Bilgus_ph> Problem is pre buttons though... 08.46.40 # <__Bilgus_ph> Iirc the gigabeast is very picky 08.46.51 # <__Bilgus_ph> Bbl 08.46.55 Quit __Bilgus_ph (Quit: Connection closed) 08.47.58 # Build Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients. 08.48.29 # WTF, broke even more spectacularly. 08.48.58 # ...once more, with feeling... 08.52.07 # bilgus: I was thinking myself about rejigging the button handling. what do you think about this state machine idea: 08.52.19 # use three states = { RELEASED, PRESSED, HELD } for each button 08.52.26 # RELEASED -> PRESSED when BUTTON_X gets set 08.52.31 # PRESSED -> RELEASED when BUTTON_X gets unset 08.52.52 # PRESSED -> HELD if the PRESSED state persists for a long enough duration 08.53.00 # HELD -> RELEASED when BUTTON_X gets unset 08.53.14 # and we could attach actions to the transitions. 08.53.52 # and if need be the state machine can be made more complex to handle extra behavior 08.55.37 # amachronic: a normal "press" should only trigger upon release, but "held" should trigger upon entering HELD. and possibly a different behavior upon release.. 08.56.11 # on other words, we want edge detection rather than level. :D fire upon the transitions rather than the states themselves. 08.56.23 # (gah. scrap the "fire...") 08.56.34 # that's exactly my thinking 08.57.19 # Needs 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.15 # it's a ton of work to get there from where we are now though. 08.58.52 # every target, every target keymap, and most plugins 08.59.55 # Build Server message: Build round completed after 717 seconds. 08.59.58 # Build Server message: Revision 0b20038d87 result: All green 09.00.32 # yeah I'd be concerned about regressions because so much code would have to be touched. 09.01.02 # hard to envision a migration path 09.02.41 # Build Server message: New build round started. Revision 9f7f1a841a, 298 builds, 10 clients. 09.02.51 # ok! finally! 09.03.10 # this round has the PP fixes 09.12.26 # <_bilgus> Woo 09.12.54 # <_bilgus> the last rewrite I did of the action engine I pushed it more towards statefulness 09.16.17 # <_bilgus> I think the big problem will be that the keymaps are technically translations with individual quirks 09.17.19 # <_bilgus> lotta ifdefs 09.17.31 # Build Server message: Build round completed after 891 seconds. 09.17.35 # Build Server message: Revision 9f7f1a841a result: All green 09.18.07 # what if we tag the buttons with intents like "these are directional buttons", "this is an OK button", etc. 09.18.13 # <_bilgus> and some players emulate button release events too 09.18.13 # ok, PP fixes in. and lo, the PP targets had their code sizes bump up. :) 09.19.41 # <_bilgus> amachronic, yes you could add a field like that but wouldn't it be easier to just remap what goes in 09.20.19 # <_bilgus> problem there if at button level instead of actions you would be limited 09.20.39 # <_bilgus> if we do it at the action level then you could be like hold button for action_play 09.22.21 # the 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.35 # at the action level it isn't really useful 09.24.09 # <_bilgus> that might work for plugins 09.24.26 # I'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 # <_bilgus> sometimes some players don't do multiple buttons 09.25.02 # <_bilgus> I had to hack that in the .... rocker? 09.25.24 # _bilgus: you did that on the X3, definitely. 09.25.41 # <_bilgus> X3 yeah lol 09.26.44 # for 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.19 # b/c the state machine I mentioned earlier is just a way to transform a continuous signal to discrete events 09.28.29 # we still need to map the target-specific "events" to rockbox events. 09.29.18 # so 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.24 # perhaps 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.33 # i mean rockbox events 09.29.46 # <_bilgus> try to align them all lower but what happens whe you lack a button 09.30.56 # <_bilgus> I guess then you could make a 'sticky' button or something 09.31.08 # amachronic: in a sense that's what we already have though? 09.31.48 # somewhat true, but there's a bunch of special case handling sprinkled all over the place. 09.31.59 # <_bilgus> and 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.00 # it seems a lot of duplicated work to recreate "raw button bitmap" -> events 09.33.07 # <_bilgus> idk i'll keep brewing this one amachronic if you get a wild hair POC is always welcome 09.33.31 # (for each target I mean) 09.33.54 # <_bilgus> I 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 # <_bilgus> excuse me 40 not 50 09.38.13 # <_bilgus> I think what might help is some kind of scripting in core 09.38.40 # <_bilgus> we have it everywhere but with piecemeal fashion 09.38.57 # <_bilgus> and its all crypic AF 09.39.29 # <_bilgus> maybe just a central parser engine 09.43.35 # is it feasible to push the actions into a queue instead of having the caller "pull" actions by calling a function? 09.49.33 # <_bilgus> the 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 # <_bilgus> like 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.12 # yeah that's the idea -- remove the button tick task and have action engine read the device itself 09.51.33 # <_bilgus> we don't have multithreading like that 09.51.54 # <_bilgus> it'd still have to be polled in some form or anoter 09.52.20 # of course, but instead of queuing the button presses we queue the actions instead 09.52.26 # <_bilgus> I think the current is like that because you have more control in regards to when to take the hit 09.54.05 # <_bilgus> sorta 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 # <_bilgus> an aside.. a sim bug that crashes when the button queue gets full 09.56.26 # I 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 # <_bilgus> it exists 09.57.04 # <_bilgus> coded around on players though 09.57.47 # it mainly happens on the debug screens, I guess they just don't handle actions "normally" and the queue fills up 09.58.19 # <_bilgus> yeah nothing reading it and it overflows 09.58.50 # <_bilgus> we could instead do a small bit of the plugin buffer and do some PIC stuff 09.59.05 # <_bilgus> a action plugin so to speak 09.59.34 # <_bilgus> should be simple enough to make a plugin that will generate machine code to route the actions 10.00.34 # <_bilgus> it would be of course core but we could generate it at compile time and overwrite it in ram at RT 10.01.01 # <_bilgus> the plugin system has most of the infra for us already 10.01.48 # I'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 # <_bilgus> ok so right now that keymap is a static representation and the compiler emits machine code that matches that 'map' 10.03.32 # <_bilgus> so we instead mark in ram where that is and load it like a plugin 10.03.59 # <_bilgus> then later overwrite that 'map' 10.04.25 # you mean just modifying the keymap table. 10.04.29 # <_bilgus> yep 10.04.48 # well we just need to make the mapping of button -> action mutable, no need for anything fancy 10.05.22 # <_bilgus> its not fancy its a way to do this without filling core with junk fo it 10.05.29 # <_bilgus> for* 10.05.46 # ah 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 # <_bilgus> yes we can do the logic there 10.06.27 # <_bilgus> and just present the map to the core 10.07.36 # <_bilgus> still 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 # <_bilgus> monkey 10.08.29 # <_bilgus> the plugin has a default table that is already compiled that it can exampine for the proper instructions 10.12.07 # <_bilgus> I 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.05 # if 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 # <_bilgus> I don't know how you copuld 10.13.24 # that would make it easier to dynamically update them without invoking a parser 10.13.47 # <_bilgus> problem is that some actions use two buttons 10.14.38 # <_bilgus> it wouldn't be hard to scan the table for prebuttons in the cold path 10.14.54 # <_bilgus> just need a bit o mark it 10.14.57 # <_bilgus> to 10.15.15 # <_bilgus> I need a click keyboard damnit 10.15.22 # how 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 # <_bilgus> yes but thats why its separaed into different contexts 10.16.06 # <_bilgus> so it cuts down on the chance 10.16.42 # ok, I think the state machine I outlined could be adapted to handle that more reliably and without checking pre buttons. 10.17.30 # <_bilgus> its already half way there 10.17.55 # huh... 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 # <_bilgus> theres our ipod :) 10.19.28 # <_bilgus> chris_s will you be available in about 7 hrs 10.19.55 # <_bilgus> or can you compile your own? 10.19.57 # yeah, sure 10.20.02 # oh yea, i could 10.20.57 # <_bilgus> https://gerrit.rockbox.org/r/c/rockbox/+/3264/1/apps/plugins/fire.c 10.21.20 # <_bilgus> just copypasta into a convenient plugin 10.23.01 # <_bilgus> and try 9f7f and the commit just prior to 89acde6af2 to besure 10.24.59 # <_bilgus> oddly the clicks and pop are gone on the h10 10.27.28 # _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.33 # the original code only writes 512 first 512 entries, you write 2K. (ie cache_size / 4) 10.30.03 # (the other being the distinction between CPU and COP) 10.31.10 # <_bilgus> yeah the rest is just moving away from magic numbers 10.32.36 # <_bilgus> next questions being what is different in the h10 versus the ipods though 10.32.55 Quit massiveH (Quit: Leaving) 10.33.03 # 2K entries is overkill though; the cache only has 512 entries 10.33.23 # (ie 8K/16 bytes per row == 512 rows) 10.35.23 # <_bilgus> 8192 / 16 = 512? 10.35.57 # <_bilgus> CACHEALIGN_SIZE = 16 10.36.24 # <_bilgus> oh no thats all F-ed up 10.36.39 # <_bilgus> i'm stepping 16 * 4 bytes 10.36.57 # <_bilgus> gah 10.37.23 # <_bilgus> I even made that notation above 10.37.25 # you're stepping by 4. 10.37.48 # CACHEALIGN_BITS = 4 10.38.07 # you're just stepping over 8K/4 instead of 2K/4 (from the original code) 10.38.23 # <_bilgus> CACHEALIGN_SIZE = 16 10.38.38 # <_bilgus> CACHEALIGN_BITS = 4 10.38.47 # oops, it's a pointer, so yeah, you're stepping by 16. 10.38.53 # <_bilgus> I'm stepping by 64 bits 10.39.10 # p += CACHEALIGN_BITS 10.39.13 # <_bilgus> jeesh 10.39.17 # so p+=4 10.39.38 # (but p is a pointer, so you're actually stepping by 4*sizeof(*p)) 10.39.50 # <_bilgus> we are looking at two different places I think 10.40.01 # <_bilgus> thats fine up there the math is right 10.40.05 # <_bilgus> but look at init 10.40.15 # aah, ok, the init 10.40.28 # I don't think that matters 10.40.28 # <_bilgus> YEAH lol 10.40.41 # <_bilgus> its not filling the cache all the way 10.40.55 # I don't see that 10.41.05 # p is a char* pointer 10.41.07 # <_bilgus> 8192 / 64 = 128 10.41.21 # so p+=16 means the pointer goes up by 16 10.41.28 # not 64 10.41.34 # <_bilgus> oh its not a long 10.41.56 # it's a long in the invalidate code. And I think _that_ is a mistake 10.42.51 # <_bilgus> well you are reading a long though and its aligned too 10.43.28 # for (i = 0 ; i < 8192 ; i += 16) vs for (i = 0 ; i < 2048 ; p += 16) 10.44.07 # <_bilgus> I prefer the firat one 10.45.03 # so the original code only invalidated 128 entries 10.45.53 # does each cache status word really occur four times back-to-back? 10.45.54 # <_bilgus> makes you wonder if there is even a need for it 10.46.09 # <_bilgus> not according to the dumps i've been looking a 10.46.16 # <_bilgus> I was puzzling the same 10.46.43 # <_bilgus> Ive got like 20 if you want to look throught them maybe it does something weird to the addresses 10.47.02 # <_bilgus> lets see if they increment 10.47.23 # yeah, we're updating every 4th word. that seems illogical. 10.48.08 # eww. wait 10.48.11 # wait 10.48.22 # &STATUS_BASE_CPU + CACHE_SIZE 10.48.33 # status_base_cpu is a unsigned long pointer 10.49.00 # so it's really (i = 0 ; i < 8192*4 ; i+= 16) 10.49.16 # _that_ can't be right. 10.50.13 # <_bilgus> looking at the mem dump i see repeating entries some times never 4 though sometimes 2-3 10.50.14 # so the old code is actually i < 8192. yours is i < 32768) 10.52.07 # <_bilgus> yeah you are right it should be CACHE_SIZE/ bits in that 10.53.15 # speachy: yes. turning off optimizations fixes it. 10.53.28 # g#3271 10.53.30 # Gerrit review #3271 at https://gerrit.rockbox.org/r/c/rockbox/+/3271 : PP: more cache invalidation fixes. by Solomon Peachy 10.53.32 # speachy: i'll look into seeing if i can trace it. 10.53.47 # it it a hang-on-boot or what? 10.54.02 # hang-on-boot, yes. it never reaches the menu. 10.54.17 # ok, that narrows things down a bit. 10.54.52 # it would be better to fix the real culprit since optimizations shouldn't do this 10.55.06 # of course 10.55.22 # at least i found a trigger 10.55.34 # i'll try narrowing down what optimizations might be responsible 10.55.41 # that would help even more 10.56.02 # could be null ptr crap even 10.56.08 # but no idea yet 10.56.26 # in general that should probably be disabled for freestanding code 10.57.00 # speachy: i suspect it was also broken for the old toolchain. it was masked by optimizations being disabled on all targets. 10.59.01 # g3271 seems to fix it, awesome 10.59.16 # Build Server message: New build round started. Revision 2f785c7797, 298 builds, 10 clients. 10.59.23 # chris_s: good enough for me. :D 10.59.45 # :D 11.01.07 # <_bilgus> works here too 11.01.31 # <_bilgus> think I worked at toyota or something 11.01.41 # <_bilgus> BBL 11.02.07 # braewoods: in system-gigageat-s.c, try getting rid of INIT_ATTR in the system_init() function 11.02.27 # _bilgus: hey, fumbling towards perfection, eh? 11.04.27 # braewoods: actually nuke all INIT_ATTR and INITDATA_ATTR in that file 11.14.05 # Build Server message: Build round completed after 889 seconds. 11.14.07 # Build Server message: Revision 2f785c7797 result: All green 11.14.37 # speachy: ok i'll test from 19d45c9257d1d8d1f59746455cddaeef910b1577 11.16.04 # why not current master? 11.16.12 # (I mean, that's after the point it broke anyway) 11.16.22 # i was tracing it to see if there's more 11.16.29 # remember, bilgus' LCD changes 11.16.49 # we could be dealing with several issues at once 11.16.55 # so i was trying to fix one before moving on 11.17.30 # there haven't been any substantive changes to imx31 since then 11.25.51 # well, 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.37 # speachy: UDF 11.26.39 # ? 11.30.12 # "undefined instruction" aka "intentionally crash" 11.30.28 # that isn't to say that there isn't something being optimized away helpfully 11.30.53 # speachy: i'll dig into it in a bit 11.32.09 # does the -S have an LED or something we can blink? 11.32.24 # (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.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.30 # speachy: not to my knowledge 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.09 # speachy: ok. it works on master with optimization disabled. 14.25.34 # the equivalent of -O0? 14.25.40 # -O actually 14.25.45 # but 14.25.47 # ok, that's -O1 14.25.48 # -O is the same more or less 14.25.55 # it is? 14.26.19 # huh it is 14.28.51 # i'll try -O2 just for grins at the moment 14.29.26 # that's not likely, as it's a superset of -Os 14.29.57 # (-Os is "everything from -O2 that doesn't increase the binary size") 14.31.20 # you said i should try disabling those IATTRs in the system code? 14.31.35 # it was a thought but I doubt that'll matter 14.32.05 # i should try enabling optimizations until i find which one causes issues 14.33.02 # Try -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.44 # i know one isn't enabled due to gcc 4.9.x changes 14.33.46 # we disaled it 14.34.01 # remind me please? 14.34.16 # -fno-delete-null-pointer-checks 14.34.37 # ah yes 14.35.02 # i found a copy of the old manual so i don't waste my time on stuff not implemented in our current GCC 14.35.32 # this is a very good player... high end for its day 14.35.41 # still competitive even 14.35.52 # too bad it's so rare 14.36.22 # i'll check out what is left to make this a stable port 14.36.51 # i'm probably going to buy another one off ebay to use for comparison with the OF 14.37.39 # speachy: incidently, the battery reports 0 when i connected to USB 14.37.41 # from the wiki it mostly looks like bootloader issues 14.37.54 # yea, installation of it isn't easy 14.38.03 # the OF only has MTP 14.38.10 Quit f1refly (Quit: see ya in hell) 14.38.20 # i'll see what it needs 14.38.26 Join f1refly [0] (~f1refly@2a01:c22:909c:d300:ff3d:8a1c:b6c6:f5ff) 14.38.52 # but tldr, rbutil doesn't work with MTP only devices 14.38.58 # i wonder what our options are 14.42.07 # it would be easiest to use libmtp but not sure how practical that is 14.42.13 # in any case we just need to use it to send a single file 14.51.50 # Try adding '-fno-gcse -fno-gcse-lm' 14.53.42 # speachy: what do those normally do? 14.54.26 # Global Common Subexpression Elimination 14.55.12 # the latter is the more interesting; it tries to pull writes inside a loop out of the loop 14.55.31 # (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.47 # it would only be an issue if something wasn't properly marked as volatile. 14.56.36 # (ie a hardware register, where writing it has "side effects" from C's perspective) 14.58.40 # -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.01.09 # -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.38 # speachy: i'll try enabling all but those first 15.22.51 # see if it compiles with -O1 with part of -Os enabled 15.22.53 # err 15.22.56 # works rather 15.23.05 # the -fno-* selectively disables those features 15.23.13 # hm 15.23.21 # well i already wrote it out so. :| 15.26.02 # speachy: does rockbox automatically use all available cores? 15.26.15 # for compiles you mean? 15.26.25 # yea 15.26.40 # nope. 15.26.47 # hm 15.26.52 # i'll see if i can improve that 15.27.14 # that's intentional 15.27.46 # ok. 15.27.51 # strange but ok 15.27.52 # granted newer make versions can automatically do that for us 15.28.13 # just how old of a make do we have to support? 15.29.37 # ok now adding in the strict optimizations 15.29.45 # that build worked 15.30.12 # normally 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.31 # i was thinking of trying to set makeflags 15.31.12 # that's how we always enabled it for linux packaging stuff 15.31.25 # we only disable it when it the package didn't support it 15.31.33 # yes but makeflags has to be set in the environment prior to make being invoked 15.31.43 # oh. 15.32.04 # it can be set within make and passed to sub-make invocations but we do it all in one go 15.32.24 # I'm trying to find the release notes for the most recent gnu make 15.32.42 # which we don't currently do 15.32.52 # we'd have to make a make wrapper really 15.33.00 # GNU Make 4.3 (released last year) allows -j in MAKEFLAGS 15.34.12 # but it's not clear that it can overriden from within a given make invocation. 15.34.13 # so let's see 15.34.46 # ok, that does work 15.37.04 # seems i've narrowed it down to 6 15.37.37 Quit f1refly (Quit: see ya in hell) 15.38.00 # i kinda wish i could disable most of the plugins 15.38.05 # during these kinds of builds 15.38.06 Join f1refly [0] (~f1refly@dynamic-077-010-167-250.77.10.pool.telefonica.de) 15.38.16 # there's usually a ton of crap i don't need 15.38.37 # edit tools/configure, set plugins='' for your target 15.38.51 Quit akaWolf (Remote host closed the connection) 15.38.59 # huh ok 15.45.24 # (you should be able to say plugins=no but there's a makefile quirk that prevents that from working 15.45.30 # (fixing it now) 15.47.32 # Build 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.05 # latest master will let you set a value other than 'yes' 15.59.34 # Build Server message: Build round completed after 722 seconds. 15.59.38 # Build Server message: Revision 9e15c19891 result: All green 16.03.19 *** Saving seen data "./dancer.seen" 16.21.30 # speachy: found something. -frerun-cse-after-loop causes a hang. 16.21.37 # i'll test the rest. 16.21.46 # ok.. 16.22.03 # still got 2 flags left 16.22.35 # send 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.49 # i'll work on it after i finish my testing 16.22.58 # i got 2 more left 16.23.11 # gcse and gcse-lm 16.23.35 # i decided to grab the whole set and test them individually 16.23.55 # take me a bit, my server is building something else in the background 16.27.08 # gcse passes 16.27.11 # testing next one 16.27.44 # the 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.47 # sounded related 16.28.18 # anywho i'll send you the files one i'm done narrowing it down 16.28.46 # ok, thanks 16.29.04 # i just wanted to be sure it's not multiples at once 16.29.19 # sometimes an issue can mask others 16.29.31 # not likely but it can happen 16.30.06 # speachy: which files you want specifically? 16.30.14 # i can send you the whole build folder of both if you want 16.32.36 # looks like that's the only flag giving issue 16.35.24 # ok building the first one 16.41.14 # now 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.16 # uploading now 16.51.00 # speachy: https://braewoods.net/rockbox-working.zip 16.51.04 # speachy: https://braewoods.net/rockbox-broken.zip 16.51.33 # done 16.51.43 # it's the entire build directory 16.51.50 # didn't know what you might need 16.52.06 # just 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.07.39 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 17.10.30 # braewoods: any lcd output at all? 17.10.36 # speachy: yes 17.10.47 # splash screen then? 17.10.50 # speachy: it displays the rockbox logo and build version 17.10.53 # and then just stops there 17.11.00 # kk, thanks 17.11.01 # in the working build it makes it to the menu shortly after 17.11.34 # if we must we can disable this one optimization but 17.11.42 # better to find out why it's crapping out here 17.14.38 # it's just weird how some units became so rare 17.23.18 # speachy: 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.22 # braewoods: please build and try it with this: http://www.shaftnet.org/~pizza/take1.diff 17.33.44 # let me know if it gets to the logo or not 17.33.45 # what does this do? 17.34.02 # just pushes the logo after a large chunk of the hw init code 17.34.10 # ok 17.34.11 # moment 17.34.21 # still trying to narrow this down 17.39.04 # speachy: 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.00 # well, that narrows things down considerably. let's split the difference 17.43.07 # http://www.shaftnet.org/~pizza/take2.diff 17.44.30 # ok 17.44.42 # so it's in one of: lang_init, rtc_init, adc_init, usb_init, backlight_init, button_init, powermgmt_init, radio_init 17.45.24 # speachy: apply to fresh git? 17.45.26 # or what? 17.45.29 # yes please 17.45.53 # ok building again 17.47.47 # speachy: same behavior 17.47.57 # huh, we don't have a single target that uses HAVE_RTC_RAM now 17.48.04 #