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 | braewoods | _bilgus: i may ask for your help with the gigabeat S but after you solve the H10 issues |
00:03:00 | braewoods | 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 | braewoods | 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 | braewoods | well it did kill the iriver H300 bootloader |
00:04:22 | braewoods | 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 | braewoods | 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 | braewoods | is it like the cache x86 uses? |
00:07:17 | braewoods | it sounds like IRAM or so |
00:07:19 | _bilgus | x86 has aid cache |
00:07:24 | braewoods | 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 | braewoods | so how can you fix the issue? |
00:11:49 | _bilgus | what issue? |
00:11:55 | braewoods | a cache is useless if it interferes with reliable operation |
00:12:03 | _bilgus | its fixed |
00:12:08 | braewoods | so what was the fix? |
00:12:28 | _bilgus | g#3264 |
00:12:39 | _bilgus | bah bluebotttt |
00:13:02 | braewoods | it's feeling blue |
00:13:02 | _bilgus | we were clearing the status of the CPU from both cores |
00:14:00 | braewoods | meaning the zero flag, etc? |
00:14:39 | braewoods | 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 | braewoods | oh |
00:15:14 | braewoods | 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 | braewoods | not that cores are a pre-req to that |
00:15:55 | braewoods | but |
00:16:05 | braewoods | eh |
00:16:11 | braewoods | 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 | braewoods | ok ordered some stuff so i can try some stuff with the gigabeat s |
00:18:56 | braewoods | while i wait on those parts |
00:22:38 | braewoods | i'll try to sort out the gigabeat S issue |
00:33:04 | braewoods | good grief |
00:33:10 | braewoods | it seems like it has to build everything |
00:35:56 | braewoods | 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 | braewoods | i'm going to gradually get there |
00:38:19 | braewoods | 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 | chris_s | 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 | braewoods | _bilgus: commit right before the new toolchain checks out |
00:53:11 | braewoods | i'll test right before LCD changes |
01:00 |
01:00:32 | chris_s | 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 | chris_s | 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 | braewoods | 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 | braewoods | 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 | bluebrother | braewoods: nice. |
01:21:35 | bluebrother | also, you volunteered in finishing the port. I don't have much use for it anymore now :) |
01:21:47 | bluebrother | kinda :D |
01:21:48 | braewoods | bluebrother: just hope we can fix the current issue |
01:21:55 | bluebrother | sure. |
01:22:04 | braewoods | otherwise not much point "finishing" it |
01:22:26 | | Quit ZincAlloy (Client Quit) |
01:22:29 | bluebrother | always nice to see things getting fixed. I'd been quite a lot of changes lately. |
01:31:41 | braewoods | i would like to add a tvout driver for it but |
01:31:44 | braewoods | 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 | braewoods | well one change in the GCC flags... |
01:38:27 | braewoods | -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 | braewoods | first thing to try, disable optimizations |
01:48:37 | braewoods | ... |
01:48:39 | braewoods | That was it? |
01:48:41 | braewoods | Seriously? |
01:49:06 | braewoods | speachy: it looks like gigabeats for some reason breaks if optimizations are turned on |
01:49:16 | braewoods | as to why i can't begin to gues |
01:49:20 | braewoods | speachy: suggestions? |
01:52:14 | braewoods | speachy: in any case i plan to do some repairs on the unit before i do much else with it |
01:52:24 | braewoods | i would prefer to know why optimizations break it |
01:52:28 | braewoods | but is that even realistic? |
01:52:56 | braewoods | the symptoms i observed is it would hang similar to the H10. |
01:53:03 | braewoods | i'd see the rockbox logo and the version at the bottom |
01:53:05 | braewoods | but it hangs there |
01:53:38 | braewoods | but 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:13 | chris_s | 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 | fs-bluebot | https://www.rockbox.org/tracker/task/13281 Problems playing the first song after player turned on (bugs, unconfirmed) |
02:02:15 | fs-bluebot | 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 | braewoods | i'll dig into it more later |
02:06:01 | braewoods | i'll see if -O1 works |
02:06:03 | braewoods | 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: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:51 | fs-bluebot | Build Server message: New build round started. Revision 674c07d654, 298 builds, 10 clients. |
06:00 |
06:01:53 | speachy | _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 | speachy | Or rather, you replaced CURRENT_CORE with IF_COP_CORE(CPU) but that's not the same at all |
06:04:14 | speachy | 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 | speachy | everywhere you changed CURRENT_CORE to IF_COP_CODE seems... suspect. |
06:09:37 | speachy | eg now in irq_handler, instead of primary CPU, irqs can now be handled by either. |
06:10:15 | speachy | IF_COP_CORE(x) is a macro that |
06:11:07 | speachy | so even in the cache_invalidate_special() function you're only ever initializing the primary CPU's cache. |
06:13:56 | fs-bluebot | Build Server message: Build round completed after 905 seconds. |
06:13:59 | speachy | braewoods: gigabeat-S hang on startup? |
06:14:04 | fs-bluebot | 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 | speachy | 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 | speachy | that's wrapped by #ifndef NUM_CORES |
06:22:17 | speachy | but NUM_CORES is 2 |
06:22:33 | speachy | (on the PP, unless FORCE_SINGLE_CORE is set) |
06:24:17 | _bilgus | wth is the redef then not seeing it |
06:26:11 | speachy | 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 | speachy | 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 | speachy | 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 | speachy | 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 | speachy | g#3268 |
06:38:19 | fs-bluebot | 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 | speachy | 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 | fs-bluebot | 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 | speachy | 3265 isn't needed |
06:41:58 | speachy | 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 | speachy | (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 | fs-bluebot | 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 |
07:00:24 | speachy | 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 | fs-bluebot | Build Server message: Build round completed after 1253 seconds. |
07:15:38 | fs-bluebot | Build Server message: Revision 0b20038d87 result: 113 errors 0 warnings |
07:17:14 | speachy | um... wtf.. |
07:17:21 | speachy | I'm going to force a do-over on that round |
07:21:23 | fs-bluebot | 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 | fs-bluebot | Build Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients. |
07:56:33 | speachy | _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:20 | amachronic | 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 | fs-bluebot | https://www.rockbox.org/tracker/task/13281 Problems playing the first song after player turned on (bugs, closed) |
08:05:41 | amachronic | 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 | amachronic | 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 | amachronic | 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 | speachy | ..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 | chris_s | 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 | chris_s | 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 | speachy | just banned another bot. |
08:27:19 | amachronic | 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 | speachy | ok, will do |
08:36:36 | speachy | need to finish cleaning up the mess the huge server load did to the buildserver |
08:37:20 | speachy | (driven by that bot pounding the wiki... sigh) |
08:38:36 | fs-bluebot | Build Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients. |
08:38:51 | speachy | ok, let's see if this is clean |
08:39:05 | speachy | 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 | speachy | 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 | fs-bluebot | Build Server message: New build round started. Revision 0b20038d87, 298 builds, 10 clients. |
08:48:29 | speachy | WTF, broke even more spectacularly. |
08:48:58 | speachy | ...once more, with feeling... |
08:52:07 | amachronic | bilgus: I was thinking myself about rejigging the button handling. what do you think about this state machine idea: |
08:52:19 | amachronic | use three states = { RELEASED, PRESSED, HELD } for each button |
08:52:26 | amachronic | RELEASED -> PRESSED when BUTTON_X gets set |
08:52:31 | amachronic | PRESSED -> RELEASED when BUTTON_X gets unset |
08:52:52 | amachronic | PRESSED -> HELD if the PRESSED state persists for a long enough duration |
08:53:00 | amachronic | HELD -> RELEASED when BUTTON_X gets unset |
08:53:14 | amachronic | and we could attach actions to the transitions. |
08:53:52 | amachronic | and if need be the state machine can be made more complex to handle extra behavior |
08:55:37 | speachy | 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 | speachy | on other words, we want edge detection rather than level. :D fire upon the transitions rather than the states themselves. |
08:56:23 | speachy | (gah. scrap the "fire...") |
08:56:34 | amachronic | that's exactly my thinking |
08:57:19 | amachronic | 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 | speachy | it's a ton of work to get there from where we are now though. |
08:58:52 | speachy | every target, every target keymap, and most plugins |
08:59:55 | fs-bluebot | Build Server message: Build round completed after 717 seconds. |
08:59:58 | fs-bluebot | Build Server message: Revision 0b20038d87 result: All green |
09:00 |
09:00:32 | amachronic | yeah I'd be concerned about regressions because so much code would have to be touched. |
09:01:02 | speachy | hard to envision a migration path |
09:02:41 | fs-bluebot | Build Server message: New build round started. Revision 9f7f1a841a, 298 builds, 10 clients. |
09:02:51 | speachy | ok! finally! |
09:03:10 | speachy | 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 | fs-bluebot | Build Server message: Build round completed after 891 seconds. |
09:17:35 | fs-bluebot | Build Server message: Revision 9f7f1a841a result: All green |
09:18:07 | amachronic | 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 | speachy | 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 | amachronic | 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 | amachronic | at the action level it isn't really useful |
09:24:09 | _bilgus | that might work for plugins |
09:24:26 | amachronic | 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 | speachy | _bilgus: you did that on the X3, definitely. |
09:25:41 | _bilgus | X3 yeah lol |
09:26:44 | amachronic | 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 | amachronic | b/c the state machine I mentioned earlier is just a way to transform a continuous signal to discrete events |
09:28:29 | speachy | we still need to map the target-specific "events" to rockbox events. |
09:29:18 | speachy | 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 | amachronic | 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 | amachronic | 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 | speachy | amachronic: in a sense that's what we already have though? |
09:31:48 | amachronic | 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 | speachy | 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 | speachy | (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 | amachronic | 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 | amachronic | 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 | amachronic | 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 | amachronic | 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 | amachronic | 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 |
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 | amachronic | 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 | amachronic | you mean just modifying the keymap table. |
10:04:29 | _bilgus | yep |
10:04:48 | amachronic | 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 | amachronic | 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 | amachronic | 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 | amachronic | 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 | amachronic | 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 | amachronic | 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 | chris_s | 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 | chris_s | yeah, sure |
10:20:02 | chris_s | 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 | speachy | _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 | speachy | the original code only writes 512 first 512 entries, you write 2K. (ie cache_size / 4) |
10:30:03 | speachy | (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 | speachy | 2K entries is overkill though; the cache only has 512 entries |
10:33:23 | speachy | (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 | speachy | you're stepping by 4. |
10:37:48 | speachy | CACHEALIGN_BITS = 4 |
10:38:07 | speachy | 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 | speachy | 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 | speachy | p += CACHEALIGN_BITS |
10:39:13 | _bilgus | jeesh |
10:39:17 | speachy | so p+=4 |
10:39:38 | speachy | (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 | speachy | aah, ok, the init |
10:40:28 | speachy | 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 | speachy | I don't see that |
10:41:05 | speachy | p is a char* pointer |
10:41:07 | _bilgus | 8192 / 64 = 128 |
10:41:21 | speachy | so p+=16 means the pointer goes up by 16 |
10:41:28 | speachy | not 64 |
10:41:34 | _bilgus | oh its not a long |
10:41:56 | speachy | 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 | speachy | 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 | speachy | so the original code only invalidated 128 entries |
10:45:53 | speachy | 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 | speachy | yeah, we're updating every 4th word. that seems illogical. |
10:48:08 | speachy | eww. wait |
10:48:11 | speachy | wait |
10:48:22 | speachy | &STATUS_BASE_CPU + CACHE_SIZE |
10:48:33 | speachy | status_base_cpu is a unsigned long pointer |
10:49:00 | speachy | so it's really (i = 0 ; i < 8192*4 ; i+= 16) |
10:49:16 | speachy | _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 | speachy | 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 | braewoods | speachy: yes. turning off optimizations fixes it. |
10:53:28 | speachy | g#3271 |
10:53:30 | fs-bluebot | Gerrit review #3271 at https://gerrit.rockbox.org/r/c/rockbox/+/3271 : PP: more cache invalidation fixes. by Solomon Peachy |
10:53:32 | braewoods | speachy: i'll look into seeing if i can trace it. |
10:53:47 | speachy | it it a hang-on-boot or what? |
10:54:02 | braewoods | hang-on-boot, yes. it never reaches the menu. |
10:54:17 | speachy | ok, that narrows things down a bit. |
10:54:52 | braewoods | it would be better to fix the real culprit since optimizations shouldn't do this |
10:55:06 | speachy | of course |
10:55:22 | braewoods | at least i found a trigger |
10:55:34 | braewoods | i'll try narrowing down what optimizations might be responsible |
10:55:41 | braewoods | that would help even more |
10:56:02 | braewoods | could be null ptr crap even |
10:56:08 | braewoods | but no idea yet |
10:56:26 | braewoods | in general that should probably be disabled for freestanding code |
10:57:00 | braewoods | speachy: i suspect it was also broken for the old toolchain. it was masked by optimizations being disabled on all targets. |
10:59:01 | chris_s | g3271 seems to fix it, awesome |
10:59:16 | fs-bluebot | Build Server message: New build round started. Revision 2f785c7797, 298 builds, 10 clients. |
10:59:23 | speachy | chris_s: good enough for me. :D |
10:59:45 | chris_s | :D |
11:00 |
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 | speachy | braewoods: in system-gigageat-s.c, try getting rid of INIT_ATTR in the system_init() function |
11:02:27 | speachy | _bilgus: hey, fumbling towards perfection, eh? |
11:04:27 | speachy | braewoods: actually nuke all INIT_ATTR and INITDATA_ATTR in that file |
11:14:05 | fs-bluebot | Build Server message: Build round completed after 889 seconds. |
11:14:07 | fs-bluebot | Build Server message: Revision 2f785c7797 result: All green |
11:14:37 | braewoods | speachy: ok i'll test from 19d45c9257d1d8d1f59746455cddaeef910b1577 |
11:16:04 | speachy | why not current master? |
11:16:12 | speachy | (I mean, that's after the point it broke anyway) |
11:16:22 | braewoods | i was tracing it to see if there's more |
11:16:29 | braewoods | remember, bilgus' LCD changes |
11:16:49 | braewoods | we could be dealing with several issues at once |
11:16:55 | braewoods | so i was trying to fix one before moving on |
11:17:30 | speachy | there haven't been any substantive changes to imx31 since then |
11:25:51 | speachy | 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 | braewoods | speachy: UDF |
11:26:39 | braewoods | ? |
11:30:12 | speachy | "undefined instruction" aka "intentionally crash" |
11:30:28 | speachy | that isn't to say that there isn't something being optimized away helpfully |
11:30:53 | braewoods | speachy: i'll dig into it in a bit |
11:32:09 | speachy | does the -S have an LED or something we can blink? |
11:32:24 | speachy | (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:30 | braewoods | speachy: 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:09 | braewoods | speachy: ok. it works on master with optimization disabled. |
14:25:34 | speachy | the equivalent of -O0? |
14:25:40 | braewoods | -O actually |
14:25:45 | braewoods | but |
14:25:47 | speachy | ok, that's -O1 |
14:25:48 | braewoods | -O is the same more or less |
14:25:55 | braewoods | it is? |
14:26:19 | braewoods | huh it is |
14:28:51 | braewoods | i'll try -O2 just for grins at the moment |
14:29:26 | speachy | that's not likely, as it's a superset of -Os |
14:29:57 | speachy | (-Os is "everything from -O2 that doesn't increase the binary size") |
14:31:20 | braewoods | you said i should try disabling those IATTRs in the system code? |
14:31:35 | speachy | it was a thought but I doubt that'll matter |
14:32:05 | braewoods | i should try enabling optimizations until i find which one causes issues |
14:33:02 | speachy | 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 | braewoods | i know one isn't enabled due to gcc 4.9.x changes |
14:33:46 | braewoods | we disaled it |
14:34:01 | speachy | remind me please? |
14:34:16 | braewoods | -fno-delete-null-pointer-checks |
14:34:37 | speachy | ah yes |
14:35:02 | braewoods | 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 | braewoods | this is a very good player... high end for its day |
14:35:41 | braewoods | still competitive even |
14:35:52 | braewoods | too bad it's so rare |
14:36:22 | braewoods | i'll check out what is left to make this a stable port |
14:36:51 | braewoods | i'm probably going to buy another one off ebay to use for comparison with the OF |
14:37:39 | braewoods | speachy: incidently, the battery reports 0 when i connected to USB |
14:37:41 | speachy | from the wiki it mostly looks like bootloader issues |
14:37:54 | braewoods | yea, installation of it isn't easy |
14:38:03 | braewoods | the OF only has MTP |
14:38:10 | | Quit f1refly (Quit: see ya in hell) |
14:38:20 | braewoods | i'll see what it needs |
14:38:26 | | Join f1refly [0] (~f1refly@2a01:c22:909c:d300:ff3d:8a1c:b6c6:f5ff) |
14:38:52 | braewoods | but tldr, rbutil doesn't work with MTP only devices |
14:38:58 | braewoods | i wonder what our options are |
14:42:07 | braewoods | it would be easiest to use libmtp but not sure how practical that is |
14:42:13 | braewoods | in any case we just need to use it to send a single file |
14:51:50 | speachy | Try adding '-fno-gcse -fno-gcse-lm' |
14:53:42 | braewoods | speachy: what do those normally do? |
14:54:26 | speachy | Global Common Subexpression Elimination |
14:55:12 | speachy | the latter is the more interesting; it tries to pull writes inside a loop out of the loop |
14:55:31 | speachy | (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 | speachy | it would only be an issue if something wasn't properly marked as volatile. |
14:56:36 | speachy | (ie a hardware register, where writing it has "side effects" from C's perspective) |
14:58:40 | speachy | -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:09 | speachy | -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 | braewoods | speachy: i'll try enabling all but those first |
15:22:51 | braewoods | see if it compiles with -O1 with part of -Os enabled |
15:22:53 | braewoods | err |
15:22:56 | braewoods | works rather |
15:23:05 | speachy | the -fno-* selectively disables those features |
15:23:13 | braewoods | hm |
15:23:21 | braewoods | well i already wrote it out so. :| |
15:26:02 | braewoods | speachy: does rockbox automatically use all available cores? |
15:26:15 | speachy | for compiles you mean? |
15:26:25 | braewoods | yea |
15:26:40 | speachy | nope. |
15:26:47 | braewoods | hm |
15:26:52 | braewoods | i'll see if i can improve that |
15:27:14 | speachy | that's intentional |
15:27:46 | braewoods | ok. |
15:27:51 | braewoods | strange but ok |
15:27:52 | speachy | granted newer make versions can automatically do that for us |
15:28:13 | braewoods | just how old of a make do we have to support? |
15:29:37 | braewoods | ok now adding in the strict optimizations |
15:29:45 | braewoods | that build worked |
15:30:12 | speachy | 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 | braewoods | i was thinking of trying to set makeflags |
15:31:12 | braewoods | that's how we always enabled it for linux packaging stuff |
15:31:25 | braewoods | we only disable it when it the package didn't support it |
15:31:33 | speachy | yes but makeflags has to be set in the environment prior to make being invoked |
15:31:43 | braewoods | oh. |
15:32:04 | speachy | it can be set within make and passed to sub-make invocations but we do it all in one go |
15:32:24 | speachy | I'm trying to find the release notes for the most recent gnu make |
15:32:42 | braewoods | which we don't currently do |
15:32:52 | braewoods | we'd have to make a make wrapper really |
15:33:00 | speachy | GNU Make 4.3 (released last year) allows -j in MAKEFLAGS |
15:34:12 | speachy | but it's not clear that it can overriden from within a given make invocation. |
15:34:13 | speachy | so let's see |
15:34:46 | speachy | ok, that does work |
15:37:04 | braewoods | seems i've narrowed it down to 6 |
15:37:37 | | Quit f1refly (Quit: see ya in hell) |
15:38:00 | braewoods | i kinda wish i could disable most of the plugins |
15:38:05 | braewoods | 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 | braewoods | there's usually a ton of crap i don't need |
15:38:37 | speachy | edit tools/configure, set plugins='' for your target |
15:38:51 | | Quit akaWolf (Remote host closed the connection) |
15:38:59 | braewoods | huh ok |
15:45:24 | speachy | (you should be able to say plugins=no but there's a makefile quirk that prevents that from working |
15:45:30 | speachy | (fixing it now) |
15:47:32 | fs-bluebot | 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 | speachy | latest master will let you set a value other than 'yes' |
15:59:34 | fs-bluebot | Build Server message: Build round completed after 722 seconds. |
15:59:38 | fs-bluebot | Build Server message: Revision 9e15c19891 result: All green |
16:00 |
16:03:19 | *** | Saving seen data "./dancer.seen" |
16:21:30 | braewoods | speachy: found something. -frerun-cse-after-loop causes a hang. |
16:21:37 | braewoods | i'll test the rest. |
16:21:46 | speachy | ok.. |
16:22:03 | braewoods | still got 2 flags left |
16:22:35 | speachy | 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 | braewoods | i'll work on it after i finish my testing |
16:22:58 | braewoods | i got 2 more left |
16:23:11 | braewoods | gcse and gcse-lm |
16:23:35 | braewoods | i decided to grab the whole set and test them individually |
16:23:55 | braewoods | take me a bit, my server is building something else in the background |
16:27:08 | braewoods | gcse passes |
16:27:11 | braewoods | testing next one |
16:27:44 | braewoods | 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 | braewoods | sounded related |
16:28:18 | braewoods | anywho i'll send you the files one i'm done narrowing it down |
16:28:46 | speachy | ok, thanks |
16:29:04 | braewoods | i just wanted to be sure it's not multiples at once |
16:29:19 | braewoods | sometimes an issue can mask others |
16:29:31 | braewoods | not likely but it can happen |
16:30:06 | braewoods | speachy: which files you want specifically? |
16:30:14 | braewoods | i can send you the whole build folder of both if you want |
16:32:36 | braewoods | looks like that's the only flag giving issue |
16:35:24 | braewoods | ok building the first one |
16:41:14 | braewoods | 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 | braewoods | uploading now |
16:51:00 | braewoods | speachy: braewoods.net/rockbox-working.zip">https://braewoods.net/rockbox-working.zip |
16:51:04 | braewoods | speachy: braewoods.net/rockbox-broken.zip">https://braewoods.net/rockbox-broken.zip |
16:51:33 | speachy | done |
16:51:43 | braewoods | it's the entire build directory |
16:51:50 | braewoods | didn't know what you might need |
16:52:06 | speachy | 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:00 |
17:07:39 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
17:10:30 | speachy | braewoods: any lcd output at all? |
17:10:36 | braewoods | speachy: yes |
17:10:47 | speachy | splash screen then? |
17:10:50 | braewoods | speachy: it displays the rockbox logo and build version |
17:10:53 | braewoods | and then just stops there |
17:11:00 | speachy | kk, thanks |
17:11:01 | braewoods | in the working build it makes it to the menu shortly after |
17:11:34 | braewoods | if we must we can disable this one optimization but |
17:11:42 | braewoods | better to find out why it's crapping out here |
17:14:38 | braewoods | it's just weird how some units became so rare |
17:23:18 | braewoods | 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 | speachy | braewoods: please build and try it with this: http://www.shaftnet.org/~pizza/take1.diff |
17:33:44 | speachy | let me know if it gets to the logo or not |
17:33:45 | braewoods | what does this do? |
17:34:02 | speachy | just pushes the logo after a large chunk of the hw init code |
17:34:10 | braewoods | ok |
17:34:11 | braewoods | moment |
17:34:21 | speachy | still trying to narrow this down |
17:39:04 | braewoods | 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 | speachy | well, that narrows things down considerably. let's split the difference |
17:43:07 | speachy | http://www.shaftnet.org/~pizza/take2.diff |
17:44:30 | braewoods | ok |
17:44:42 | speachy | 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 | braewoods | speachy: apply to fresh git? |
17:45:26 | braewoods | or what? |
17:45:29 | speachy | yes please |
17:45:53 | braewoods | ok building again |
17:47:47 | braewoods | speachy: same behavior |
17:47:57 | speachy | huh, we don't have a single target that uses HAVE_RTC_RAM now |
17:48:04 | speachy | I guess that was just the archos recorder? |
17:48:12 | braewoods | time to remove it? |
17:48:31 | braewoods | anyway |
17:48:38 | braewoods | speachy: hangs at bootloader still |
17:48:56 | speachy | ok, take3.diff is now up |
17:49:20 | speachy | (rtc/adc/usb/backlight/button) |
17:49:46 | speachy | (oh, and lang too, but I _really_ doubt that as there's no target-specific code in there) |
17:50:11 | braewoods | good thing this has a way to quickly do a hardware reset |
17:50:21 | braewoods | this would be a royal PITA if it didn't |
17:52:42 | braewoods | speachy: logo comes up |
17:53:06 | speachy | ok, that is purely backlight and button then |
17:53:16 | braewoods | one more to narrow it down more? |
17:53:50 | speachy | yep |
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:02 | speachy | take4 is up |
17:55:14 | speachy | I'm expecting this to fail. |
17:56:18 | braewoods | once we have it narrowed down we can try disabling the optimization for those files |
17:56:33 | braewoods | try to isolate what source is impacted |
17:58:55 | braewoods | speachy: makes it to the logo again |
17:59:14 | speachy | huh. so it's the button init code |
18:00 |
18:00:56 | | Quit ac_laptop (Quit: WeeChat 3.0) |
18:01:01 | _bilgus | I would have guessed the backlight |
18:01:16 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
18:02:45 | braewoods | shall we try disabling the optimization for the code and see what happens? |
18:02:55 | braewoods | we might have multiple parts impacted |
18:03:01 | braewoods | so need to narrow down the scope of the bug |
18:03:08 | speachy | ok, take5 |
18:03:22 | *** | Saving seen data "./dancer.seen" |
18:03:30 | speachy | isolate the "button" from the "headphone" init |
18:05:04 | braewoods | ok built |
18:06:06 | braewoods | speachy: boot logo appears |
18:06:27 | speachy | ie not bootloader, correct? |
18:06:34 | braewoods | yes, it displays the logo |
18:06:38 | braewoods | not the text screen of bootloader |
18:06:41 | | Quit ac_laptop (Ping timeout: 240 seconds) |
18:07:37 | speachy | take6 is up |
18:08:07 | speachy | I expect this to fail. |
18:08:40 | braewoods | building |
18:11:46 | braewoods | speachy: yep failed |
18:11:49 | braewoods | text screen |
18:12:30 | speachy | ok, the file in question is firmware/target/arm/imx31/gigabeat-s/headphone-gigabeat-s.c |
18:14:23 | braewoods | try using a pragma to disable the optimization... |
18:14:43 | speachy | wonder if the inline asm here is the culprit. |
18:15:00 | braewoods | -frerun-cse-after-loop |
18:15:10 | braewoods | was the offending optimization |
18:15:19 | speachy | well, the only loop here is in the thread body |
18:15:21 | _bilgus | does gcc optimize hand ASM too? |
18:15:30 | braewoods | in 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:37 | speachy | no but the asm can interact ...badly if it's not set up properly |
18:15:43 | braewoods | before thinking this is the only one |
18:15:54 | braewoods | if that makes any sense |
18:16:05 | braewoods | i'll try disabling in that one file |
18:16:09 | _bilgus | ifdef it out |
18:19:41 | braewoods | ok now attempting something |
18:19:46 | speachy | take7 is up |
18:19:53 | braewoods | oh |
18:19:56 | braewoods | i'll try take7 shortly |
18:20:06 | speachy | I honestly don't see how this code can trigger an outright hang directly. |
18:21:09 | braewoods | me either but i've seen weirder hsit |
18:21:20 | speachy | however, the mc13073 IRQ handling is more likely to be it |
18:22:06 | speachy | this code leaves the event disabled so the thread should never trigger. |
18:22:38 | braewoods | building |
18:24:09 | | Join MrZeus_ [0] (~MrZeus@194.37.96.137) |
18:24:37 | braewoods | speachy: hangs at logo again |
18:25:59 | speachy | ok, that's fine. take8 up |
18:26:12 | | Join MrZeus [0] (~MrZeus@2a02:c7f:a0aa:4400:f878:24fa:cc54:429d) |
18:26:30 | speachy | fixed it |
18:26:36 | speachy | (the compile failure I mean) |
18:27:33 | speachy | take8 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:49 | speachy | going to bounce for a while. programmer needs fuel. |
18:40:52 | braewoods | speachy: take8 boots fully |
18:44:43 | braewoods | i suspect the problem is in one of the functions the loop clals |
18:46:00 | braewoods | testing if adc_read is OK or not |
18:46:09 | braewoods | oh wait |
18:46:11 | braewoods | doh |
18:51:58 | braewoods | ok inserted the pragma into relevant files |
18:52:02 | braewoods | time 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:00 | speachy | we 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:44 | speachy | dc |
19:25:19 | braewoods | speachy: let me know when you have some idea of what to try next |
19:25:23 | braewoods | i put the unit up for charigng |
19:25:25 | braewoods | charging |
19:26:00 | braewoods | but it does work with diff8 |
19:26:21 | braewoods | but what part is responsible is unknown to me |
19:26:30 | speachy | it's just shrinkinking the disabled area |
19:26:54 | braewoods | plus due to the optimizations we may need to do some clever stuff to keep code from being optimized away |
19:27:26 | speachy | more likely, undo something clever. I'm still not inclined to believe the issue lies outside of the imx31 subdir. |
19:27:48 | braewoods | perhaps |
19:27:51 | braewoods | i just meant |
19:27:57 | braewoods | in trying to isolate the problem area |
19:28:05 | speachy | there's a take9 now if you wan |
19:28:14 | braewoods | i'll give it a spin; moment |
19:28:19 | braewoods | i think this unit needs a new battery |
19:28:22 | braewoods | seems to run out too readily |
19:28:31 | speachy | it's 15 years old, heh |
19:28:47 | braewoods | well i'll work on that next week |
19:30:08 | braewoods | ok |
19:30:10 | braewoods | building |
19:30:22 | speachy | (take9 enables the adc_read, and a little bit of logic towards the end. |
19:32:48 | braewoods | boots |
19:34:09 | speachy | take10 |
19:35:58 | speachy | I'm betting it's the adc_data_to_button() function, with the inline asm confusing things. |
19:36:32 | _bilgus | put the old if then tree |
19:37:01 | _bilgus | https://github.com/Rockbox/rockbox/commit/669fa9a13002835a139b72db80a2a3ee69fa434e |
19:39:13 | _bilgus | and thats why people should probably leave the c code in when they do ASM inline |
19:40:00 | braewoods | or not bother with ASM unless you literally cannot do it from C |
19:40:17 | braewoods | ASM is a double-edged sword |
19:42:01 | braewoods | speachy: ok it locks up with that one |
19:42:29 | braewoods | it's only good if you absolutely must have your code generated a certain way |
19:42:38 | speachy | ...that was unexpected. |
19:42:56 | _bilgus | well sometimes speed does matter |
19:43:10 | braewoods | isn't C codegen usually better? |
19:43:12 | | Quit Strife89 (Quit: No Ping reply in 180 seconds.) |
19:43:18 | _bilgus | but I feel lik sometimes esp in this codebase its been taken too far at times |
19:43:38 | braewoods | using ASM doesn't let us benefit from compiler advances |
19:44:06 | braewoods | maybe 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:44 | braewoods | main time i've seen asm used is when you can't get your compiler to generate the code you need or want |
19:45:00 | braewoods | e.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:16 | braewoods | speachy: i was thinking of trying something else |
19:53:19 | braewoods | hm |
19:54:27 | speachy | take11. |
19:57:11 | speachy | I think I see the issue. take11 should work. |
19:59:57 | braewoods | speachy: ok it boots |
20:00 |
20:00:25 | braewoods | i had a feeling it was that button get code |
20:01:07 | speachy | take12 |
20:01:27 | speachy | I expect this to work too. |
20:02:17 | braewoods | speachy: if it does, what's the issue? |
20:02:40 | braewoods | headphones_detect is a strange one |
20:02:42 | braewoods | but |
20:02:46 | speachy | the headphones_detect variable. it's write-only in one thread context, read-only in the rest |
20:03:12 | braewoods | da fuck |
20:03:23 | *** | Saving seen data "./dancer.seen" |
20:05:27 | braewoods | it works |
20:05:59 | braewoods | so we need to modify that one variable's storage attributes? |
20:06:40 | speachy | take13 |
20:07:14 | braewoods | speachy: why int instead of bool? |
20:07:26 | | Quit MrZeus (Ping timeout: 268 seconds) |
20:07:44 | speachy | it's an int's worth of storage anyway, so there's no advantage |
20:07:57 | braewoods | ok |
20:08:32 | braewoods | speachy: why was GCC doing that with this one variable? |
20:11:10 | speachy | I don't see any meaningful change in teh asm dump so I'm not confident this fixes anything |
20:11:19 | braewoods | speachy: it doesn't |
20:11:29 | braewoods | it's still locking up |
20:11:29 | speachy | ok |
20:11:40 | braewoods | i wonder |
20:12:26 | braewoods | alignment issue? |
20:13:02 | speachy | ...or stack overflow |
20:13:18 | braewoods | stack overflow? |
20:13:25 | braewoods | this variable is allocated outside of the normal stack |
20:13:33 | speachy | it's immediately adjacent to the stack |
20:13:41 | braewoods | i see. |
20:13:46 | braewoods | so enlarge the stack? |
20:13:49 | speachy | yeah |
20:14:36 | speachy | take14 |
20:14:48 | braewoods | you naming them takes |
20:14:53 | braewoods | sounds like we're filming a movie |
20:14:55 | braewoods | X) |
20:15:10 | speachy | I'll bet this is it |
20:15:42 | braewoods | not much point to being stingy with the stack on this target |
20:15:54 | braewoods | it has 64MB |
20:15:58 | braewoods | more than most do |
20:16:19 | speachy | the 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:25 | speachy | return address |
20:17:10 | speachy | when this boots up, go into the debug/thread info screen and it'll report the stack size for the headphoen thread. |
20:18:10 | speachy | (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:23 | braewoods | i'll look |
20:19:17 | | Join dconrad [0] (d026e411@208.38.228.17) |
20:19:36 | braewoods | 91% usage from the headphone one |
20:19:58 | braewoods | this seems to fix it |
20:20:05 | _bilgus | the issue is the isr knocking you over the top |
20:20:12 | | Quit pamaury (Ping timeout: 246 seconds) |
20:20:14 | speachy | 91% is 182 bytes |
20:20:47 | braewoods | next time we should check the stack first? |
20:20:49 | speachy | a whopping two words over the old size. |
20:21:07 | _bilgus | 182 bytes? its a 255 byte stack? |
20:21:13 | braewoods | 200 |
20:21:15 | speachy | it was 176 bytes |
20:21:25 | _bilgus | O_o |
20:21:26 | speachy | I bumped it to 200 for this test |
20:21:43 | braewoods | that was the old value |
20:21:47 | speachy | the patch you suggested reverting dropped it from 200 to its 176 |
20:21:48 | braewoods | before they optimized it |
20:22:01 | _bilgus | lol |
20:22:06 | speachy | so basically it was _perfectly_ sized for the old code+compiler+optimizations |
20:22:21 | braewoods | sounds stupid to leave yourself no room for expansion like that |
20:22:23 | speachy | (let this be a lesson to everyone...) |
20:22:27 | braewoods | in something that will get forgotten about |
20:22:27 | _bilgus | happens |
20:22:37 | _bilgus | and probably it was two compilers ago |
20:22:56 | _bilgus | just didn't get caught till now |
20:23:20 | _bilgus | but thats anything like that but I think we should maybe talk about hand optimized ASM |
20:23:41 | speachy | it 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 | _bilgus | like the h10 |
20:27:18 | fs-bluebot | Build Server message: New build round started. Revision afec380a0d, 298 builds, 11 clients. |
20:27:37 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
20:27:37 | * | speachy sticks a fork in it. |
20:28:14 | speachy | ... 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 | _bilgus | we need the tower of rockbox |
20:31:39 | _bilgus | saratoga maybe? |
20:31:55 | _bilgus | he hasn't been here in a bit hope he comes back |
20:32:22 | braewoods | speachy: one problem though, some targets are rare |
20:32:35 | braewoods | mpio units? i've never seen one on ebay. |
20:32:38 | braewoods | ditto for packard bell. |
20:33:02 | speachy | well, we need to test the "stable" targets at least. |
20:33:12 | _bilgus | What we need to do then is put up a table of tested untested works broken |
20:33:16 | _bilgus | like the old days |
20:36:54 | * | speachy shudders at the thought of maintainnig that as a wiki page |
20:38:10 | braewoods | speachy: we should first build up a list of units we have in the developer or contributor area first |
20:38:41 | braewoods | i have iriver h120, h10 (once i get it back from bilgus), the gigabeat S i just received... |
20:38:46 | speachy | (it makes sense as a wiki page, but our wiki... ugh) |
20:38:48 | braewoods | philips gogear hdd1630 |
20:38:54 | braewoods | hdd6330 |
20:39:02 | speachy | (after it nearly took down my server again today..) |
20:39:25 | | Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) |
20:39:42 | fs-bluebot | Build Server message: Build round completed after 744 seconds. |
20:39:46 | fs-bluebot | Build Server message: Revision afec380a0d result: All green |
20:42:21 | braewoods | speachy: first we need to document what units we have at least one unit of |
20:43:40 | speachy | hmm, extend builds.pm to include this info maybe. |
20:44:56 | braewoods | i'll put something on the forums |
20:45:03 | braewoods | we may be able to get some help there |
20:46:03 | braewoods | _bilgus: https://forums.rockbox.org/index.php/topic,53611.0.html |
20:46:10 | braewoods | please archive this thread, it has served its purpose |
21:00 |
21:03:31 | speachy | I'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:21 | braewoods | so the wiki would be contained in gerrit somewhere? |
21:06:35 | speachy | bidirectional, yeah |
21:39:53 | _bilgus | braewoods https://forums.rockbox.org/index.php/topic,53800.0.html |
21:40:40 | braewoods | _bilgus: you forgot the H120 and H110 |
21:40:51 | braewoods | and yh-820 |
21:40:59 | _bilgus | I only filled out the ones I have |
21:41:08 | braewoods | Oh. |
21:41:10 | _bilgus | or you mean in the table |
21:41:14 | braewoods | table |
21:41:17 | _bilgus | ah |
21:41:36 | braewoods | there's also gigabeat F series |
21:41:41 | braewoods | it's much more common than the S |
21:44:09 | braewoods | the X series isn't very common |
21:44:17 | braewoods | but it shares the same build as the F |
21:44:21 | braewoods | so should be close enough |
21:45:20 | braewoods | _bilgus: also the h10 is split into the 20GB and 5/6GB ports |
21:45:31 | braewoods | though i suspect the 5/6GB is going to be pretty rare |
21:45:41 | _bilgus | I have h10 and h10 5gb |
21:45:42 | braewoods | it has no real upgrade potential and its battery is weird |
21:45:46 | braewoods | Oh. |
21:45:54 | braewoods | you had your own H10 before I shipped mine? |
21:46:02 | braewoods | o.O |
21:46:04 | _bilgus | no I mean in my posession |
21:46:06 | braewoods | oh |
21:46:13 | _bilgus | like speachys rocker too |
21:46:32 | _bilgus | I tested those devices so I marked them as works |
21:46:41 | braewoods | and the S is from my reports here? |
21:46:45 | _bilgus | yep |
21:46:48 | braewoods | ok |
21:47:00 | braewoods | i may get a cheap F20 to repair for testing |
21:47:13 | braewoods | there's quite a few |
21:49:13 | _bilgus | ok updated |
21:49:31 | _bilgus | that should get us some fill on the more common stuff |
21:50:01 | _bilgus | either saratoga or geaverts has the majority of these |
21:50:29 | braewoods | some of these cannot be tested by buying them since they're no longer available |
21:51:03 | _bilgus | well we start removing stuff after a few rounds and I bet they come out |
21:51:18 | _bilgus | BUT I still have this!! |
21:52:29 | braewoods | _bilgus: what port is the creative zen vision m part of? |
21:52:34 | braewoods | i don't recall reading that anywhere |
21:54:42 | _bilgus | what port? |
21:54:55 | braewoods | _bilgus: you had it listed |
21:55:11 | | Quit cockroach (Quit: leaving) |
21:55:11 | braewoods | but i don't recall reading about it anywhere in the docs |
21:56:14 | braewoods | oh |
21:56:17 | _bilgus | ok I just grepped the build page for the models |
21:56:26 | braewoods | huh |
21:56:33 | braewoods | it's probably an unfinished port with no docs |
21:56:43 | _bilgus | could be |
21:56:58 | _bilgus | but I didnt see the giga F/x In there |
21:57:19 | _bilgus | the build one are we no longer building for it or did I miss it |
21:57:46 | braewoods | https://build.rockbox.org/ |
21:57:49 | braewoods | it's right before the S |
21:58:19 | braewoods | vision isn't even built there |
21:59:26 | braewoods | oh found the info |
22:00 |
22:00:02 | braewoods | https://www.rockbox.org/wiki/CreativeZVMPort |
22:00:05 | braewoods | yep it's half-finished |
22:00:29 | braewoods | we may end up having to jettison these ports that were never finished |
22:00:46 | braewoods | that are like over 10 years old and no serious effort to make them useable |
22:00:57 | _bilgus | As we should |
22:01:15 | _bilgus | its still in the tree if someone wants to pick it up |
22:01:53 | braewoods | i'll grab an F20 and rebuild it |
22:01:56 | * | braewoods has the technology |
22:02:07 | _bilgus | lol |
22:02:22 | _bilgus | at least the techs cheap now |
22:03:26 | *** | Saving seen data "./dancer.seen" |
22:21:29 | _bilgus | amachronic (logs) looks like we can just rejigger cur->get_context_map and inject out own lookup table |
22:22:01 | _bilgus | so that part is easy the hard part will be the logic for a plugin |
22:24:48 | _bilgus | actually I might do that in lua |
22:26:08 | speachy | hmmmm. the dokuwiki git backend is only half-baked. damn.. |
22:26:34 | _bilgus | potential upgrade path? |
22:29:12 | _bilgus | So 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 | _bilgus | or just one big table with 4 ints contxt, action, button, pre_btn |
22:31:32 | _bilgus | problem is that order matters in action tables |
22:31:39 | braewoods | speachy: it's almost like we'd be better off with one of those site generators that works off a git repo |
22:32:22 | speachy | braewoods: yeah. the only thing a tradiitonal "wiki" brings us is web-based edits. |
22:32:55 | braewoods | _bilgus: i was thinking how we could reduce memory usage a bit with the image files |
22:33:12 | braewoods | _bilgus: ICO packs. one contiguous block for all the images |
22:33:25 | braewoods | but eh just a random idea |
22:33:37 | speachy | it seems a bit much to expect folks to grok git/gerrit to modify the "wiki" though. |
22:34:28 | _bilgus | the wiki has terrible syntax |
22:34:36 | speachy | this one is ... awful |
22:35:07 | speachy | maintaining the history is nigh-impossible if it rquires migrating the syntax too. |
22:35:09 | _bilgus | like moreso than currently? |
22:35:20 | speachy | I mean the one we have now is awful |
22:35:23 | _bilgus | @braewoods |
22:35:35 | speachy | _any_ other choice is a massive net improvement. if only because we can use markdown or whatever |
22:36:13 | _bilgus | the images are already stripped per file for icons and such are you saying to put them all together? |
22:36:17 | speachy | I'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 | _bilgus | stripe-ed |
22:36:34 | _bilgus | lol |
22:37:02 | _bilgus | speachy I agree we should archive as it sits and move on |
22:39:40 | _bilgus | I wonder if the vector file for the rb logo is smaller than the image probably not after you consider the polyrenderer |
22:40:19 | braewoods | _bilgus: well the larger your allocations the less fragmented |
22:40:27 | braewoods | though it's just an idea |
22:40:40 | braewoods | i observed ICO stores BMPs unmodified that i can tell |
22:40:52 | braewoods | so with some clever addressing hacks you could just load them all into RAM |
22:41:06 | braewoods | as long as the pointers are right, it shouldn't matter |
22:41:16 | braewoods | but, alignment might be a problem then |
22:41:32 | _bilgus | idk only if you use a script to build the ico packs lol |
22:41:47 | braewoods | quite doable, there's even tools to do so. |
22:41:57 | braewoods | ICOs can also contain PNGs but we have no means to manipulate those |
22:42:05 | braewoods | and what would be the point? |
22:42:10 | braewoods | rockbox doesn't really benefit |
22:43:36 | _bilgus | idk 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 | _bilgus | I wonder how much ram is tied in images |
22:46:40 | braewoods | _bilgus: like 256K or less from what i was looking at in the default theme |
22:47:14 | _bilgus | i'm saying across the whole of rockbox |
22:47:19 | braewoods | Oh. |
22:47:31 | braewoods | ultimately if we're just decompressing to the same size regardless |
22:47:37 | braewoods | PNG would only offer some disk saving |
22:47:40 | braewoods | but pretty moot |
22:47:55 | _bilgus | like is it 1 meg of images total |
22:48:13 | _bilgus | image paths are a lot shorter to store |
22:49:24 | _bilgus | I think I want to start moving stuff out of core |
22:49:33 | _bilgus | we have voices in plugins |
22:50:01 | _bilgus | we can move some of the infrequently used stuff out and still have use of it |
22:50:15 | _bilgus | like the whole eq menu |
22:50:36 | _bilgus | car adapter mode |
22:51:05 | _bilgus | these things can be handled with clever cmd line args to plugins |
22:52:01 | _bilgus | get core down to a Fat kernel |
22:53:39 | _bilgus | hell 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 | _bilgus | but not the core settins |
22:55:55 | _bilgus | shortcuts menu is first on my list |
22:57:57 | speachy | the 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:13 | speachy | content-wise, I mean |
23:00 |
23:15:57 | speachy | and there are 2275 pages. |
23:22:32 | _bilgus | phew |
23:23:31 | | Quit Strife89 (Ping timeout: 268 seconds) |
23:37:29 | braewoods | what about the official wiki software? |
23:37:32 | braewoods | not a good fit? |
23:37:56 | speachy | "the official" ? |
23:39:46 | braewoods | speachy: mediawiki i thought? |
23:39:56 | braewoods | it seemed to be what wikipedia uses |
23:40:08 | braewoods | but no idea |
23:40:19 | braewoods | there's a ton of wiki clones |
23:40:52 | speachy | yep. all of which suffer from the same problem −− getting the data out of our old site is ... lost case comes to mind |
23:41:10 | braewoods | isn't that true of any CMS we use |
23:41:25 | braewoods | there's not really any standard way of exchanging this kind of data to my knowledge |
23:41:33 | speachy | yes and no.. this thing's sytax is ... unique |
23:41:56 | braewoods | do the newer versions have compatibility |
23:42:17 | braewoods | i know you said you can't easily migrate |
23:42:27 | braewoods | but does it retain content compatibility? |
23:42:50 | braewoods | meaning can we just copy it over in some manner and just have it more or less work |
23:43:07 | braewoods | that's the main issue we face |
23:43:07 | speachy | sort of. it's essentially a manual migration path |
23:43:33 | braewoods | true but it's looking like that is going to be involved no matter what |
23:43:34 | speachy | but there's no guarantee that the engine will be less of a resource hog |
23:43:51 | speachy | and stuff's gonna break. |
23:43:52 | braewoods | does the new engine allow for caching? |
23:44:00 | braewoods | that's true no matter what |
23:44:01 | speachy | the old one already does |
23:44:12 | speachy | to the point where there's a cache for teh cache |
23:44:16 | speachy | and that's what keeps keeling over |
23:44:52 | speachy | from normal web crawler traffic |
23:47:06 | braewoods | ._. |
23:48:02 | braewoods | a static site generator CMS would solve most of these problems |
23:48:06 | _bilgus | god the amount of links in that wiki |
23:48:17 | braewoods | we don't edit the wiki all that often |
23:48:21 | speachy | yeah. and the migration I'm trying isn't preserving most of 'em. |
23:48:28 | speachy | ... wtf. |
23:49:13 | speachy | and 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 | _bilgus | I assume if you cut the link to the wiki from the mainpage the spiders would stop finding it? |
23:49:46 | speachy | except for all the cached links, sure |
23:50:32 | _bilgus | remove it and make it a random link for a few months |
23:51:23 | speachy | foswiki has a 'publish' extension that will generate static html for a page or namespace. |
23:52:04 | _bilgus | that might be a valid way to do it make the editable portion invite only |
23:52:31 | _bilgus | then have a script to gen new content on the build farm |
23:52:57 | _bilgus | then migrate |
23:53:58 | _bilgus | then we can still edit stuff for a bit till it gets closed down and the last static set is the final |
23:54:51 | _bilgus | and by migrate I mean a clean new thing no old info |