--- Log for 29.03.121 Server: weber.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 10 hours ago 00.01.24 *** Saving seen data "./dancer.seen" 00.11.24 # <_bilgus_> braewoods, speachy h10 update -- after determining that disabling the cache seems to solve the issue I started looking through the FS I think boris had mentioned they tried pointing to a 2kb buffer first but pointing past the 'end' of ram seemed to work, well I went ahead and set up a 2kb trash buffer and it works unaligned addresses on the lcd cur vp and everything 00.12.14 # <_bilgus_> so I think it might just be corrupting where it is dumping those invalid entries 00.17.37 # <_bilgus_> looking throught the code and calculating the address it is 32 * 0x100000 >> 11 | 0x 800000 and I get 0x840000 whic is way below ram so I'm not sure how it relates yet 00.18.38 Quit ac_laptop (Ping timeout: 240 seconds) 00.18.53 # <_bilgus_> I wonder if GCC might decide to change that behind our backs? IDK don't understand it well enough I suppose 00.26.32 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 00.43.40 Quit _bilgus_ (Remote host closed the connection) 00.44.14 Join _bilgus_ [0] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com) 01.12.37 Quit ac_laptop (Ping timeout: 265 seconds) 01.16.45 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 01.21.00 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:90d7:81a6:29f3:6d53) 01.25.27 Quit ZincAlloy (Ping timeout: 246 seconds) 01.30.55 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:90d7:81a6:29f3:6d53) 01.35.55 Quit ZincAlloy (Ping timeout: 276 seconds) 01.53.05 Nick hook54321 is now known as hook5432 (sid149355@gateway/web/irccloud.com/x-dmzuiftnmzcwraep) 01.53.27 Nick hook5432 is now known as hook54321 (sid149355@gateway/web/irccloud.com/x-dmzuiftnmzcwraep) 01.54.25 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 01.58.44 Quit ZincAlloy (Ping timeout: 246 seconds) 02.01.27 *** Saving seen data "./dancer.seen" 02.53.33 Join petur [0] (~petur@rockbox/developer/petur) 03.07.57 Quit kakaka (Ping timeout: 240 seconds) 03.27.27 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 03.51.46 Quit fs-bluebot (Ping timeout: 240 seconds) 03.52.51 Quit bluebrother^ (Ping timeout: 245 seconds) 03.55.59 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 04.01.28 *** Saving seen data "./dancer.seen" 04.21.59 Quit kakaka (Remote host closed the connection) 04.22.28 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 04.56.16 Quit Guest13329 (Quit: All for nothing) 04.56.55 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 05.18.06 Quit kakaka (Remote host closed the connection) 05.34.30 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 05.52.18 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 06.01.30 *** Saving seen data "./dancer.seen" 06.23.21 # _bilgus_: so some sort of linker wonkiness? when I did the toolchian bump I ran into something similar with the PP-based iPods. 06.24.55 # _bilgus_: look at 5bd86eb4b4 06.25.18 # speaking of cache initialization 06.42.39 # and cd990684 06.47.58 # I _think_ the ncdata section is overlapping the start of the stack 06.50.00 # more accurately it's in the middle of the stack space 06.52.05 # no, too many digits. sigh. too early in the morning for this stuff. 06.59.53 # a lot of the _init() code overlaps with the codec buffer 07.01.40 # but I'm pretty sure that's deliberate. but if those functions are called after audiobuf is set up/used/whatever... 07.02.19 # I mean codecbuf 08.01.32 *** No seen item changed, no save performed. 08.21.50 # <_bilgus_> speachy 5bd86eb4b4 i don't see where the range is shifted back is everything up to 0x1000 mapped back to 0? 08.23.27 # the point was to initialize the cache -- gcc helpfully optimized away the loop due to NULL 08.23.56 # <_bilgus_> ah ok got ya get valid data in it 08.24.27 # or rather, just faulted for us. whoops, need to re-read my comments 08.28.42 # <_bilgus_> hmm yeah this (cd990684) sounds like an interesting issue maybe I should try going back to the old toolchain on my other system and get it to build \ 08.32.58 # it seems to be linking okay to my eyes, or at least close enough to the ipods as to not matter 08.33.29 # (You could also try going from -Os to -O1 instead at the top level) 08.34.54 Quit pamaury (Ping timeout: 246 seconds) 08.35.30 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 08.41.36 # <_bilgus_> I'm still not fully sure what is going on here I mean ram end is realllllyyyy close to the LCD_CVP pointer like its literally the last thing but when I put a buffer there and check integrity it was intact 08.43.03 # <_bilgus_> so I started playing around with pushing the cache further past the 'end' of memory and at 32 bytes it booted mostly ok 08.43.13 # <_bilgus_> further up and it refused to boot 08.43.40 # 32B is the cacheline IIRC 08.43.43 # <_bilgus_> further back and still crashed ocassionall 08.43.50 # <_bilgus_> yeah thats why I picked it 08.44.09 # <_bilgus_> but it still crashed some boots with that 08.44.21 # <_bilgus_> just 1 in 20 instead of 1 in 2 08.44.50 # <_bilgus_> remapped cache to trash buffer and smooth as butter and no crash yet 08.45.09 # <_bilgus_> and it could still be an alignment thing happening to fix it 08.45.21 # one thing that comes to mind -- we have native asm code for some lcd paths on the H10 08.45.27 # <_bilgus_> now I need to do some other stuff and see if it pops back up again 08.45.48 Quit kakaka (Remote host closed the connection) 08.45.53 # <_bilgus_> mm you think stack clobber 08.45.57 # would be worth disabling them. 08.46.16 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 08.47.18 # and switching to pure C? 08.47.22 # the native pp asm threading/locking asm was completely b0rked on the newer toolchain; to the point of "I don't see how this technically ever ran previously" 08.47.23 # <_bilgus_> yeah I'll keep playing around with it, Its in several iPods too I wonder if they have different revisions 08.47.41 # the lcd code I have in mind is unique to the h10 series 08.47.53 # (which would explain why the ipods apparently work ok) 08.48.22 # <_bilgus_> assuming they still do 08.48.22 # it's too bad i only sent bilgus the 20GB unit 08.48.31 # not that the 5GB is very usable today 08.48.43 # it's capped a 5/6 GB and hard to repair compared to the 20GB 08.49.00 # <_bilgus_> you can test a 5G unit too but originally they had issues with the 20 08.49.06 # well, the mini2g was good as of about a week ago, and I know others using the 4g grey and 4g color models with current builds 08.49.16 # <_bilgus_> so that might be a valid difference between the targets 08.49.48 # <_bilgus_> the greys are the most likely to suffer if something is wrong with memory 08.49.52 # it sounds like sendng it to you was the right choice ultimately 08.50.05 # i don't know ARM ASM at all 08.50.30 # <_bilgus_> I'm ok at it just need a cheat sheet 08.50.42 # i mostly write C and almost no ASM to date 08.50.47 # mostly just some random x86 08.50.50 # for shits and grins 08.51.30 # i did manage to do some minor patching of the coldfire ASM 08.51.39 # when i worked on the bootloader 08.52.01 # but ppc is a lot closer to x86 than early arm is 08.52.05 # just wow is arm 08.52.15 # arm seems to take a lot more work to do anything 08.52.25 # at least the version we use 08.53.05 # from what i gathered loading from RAM into a register requires separate instructions every single time 08.53.38 # braewoods: that's a RISC thing. x86 and m68k were the last bastions of heavyweight CISC. 08.53.43 # while in x86 some instructions can do that automatically as part of the instructions 08.54.02 # i see 08.54.03 # <_bilgus_> hmm other targets have the YUv420 thing wonder if any are pp 08.55.11 # speachy: ok, just used to x86 where you can multiply a register by the contents of a ram address 08.55.17 # you don't need to load into a register first 08.55.21 # for both 08.55.30 # consider that x86 is also extremely register limited 08.55.36 # indeed 08.55.44 # x86_64 does a lot to address that 08.55.48 # adds a ton of new register 08.55.58 # even some that aren't even given a special name 08.56.01 # just numbered 08.56.52 # all i can say now is i don't miss the 16 bit x86 addressing model 08.56.53 # <_bilgus_> I typically just look through the generated ASM looking for weird bottlenecks 08.57.01 # it must have made memory management a nightmare 08.57.26 # <_bilgus_> generally with some kind of unit test in hand 08.57.35 # having to flip pages so to speak and not having access to more than 16 bits at a time 08.57.50 # the flat model simplifies access a lot 08.58.52 # 32 bit x86 was a big deal until they exhausted the RAM limits 08.59.00 # 4GB must have seemed massive back in the day 09.00.08 Quit speachy (Quit: WeeChat 3.0.1) 09.06.12 Quit petur (Quit: Connection reset by beer) 09.23.53 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.32.14 # <_bilgus_> gotta love source versioning found the reference yuv code luckily 09.50.25 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-8cf1-46e2-d458-1f45.res6.spectrum.com) 09.58.15 # <_bilgus_> Speachy, No dice still same crash with C yuv routines 09.58.43 Join MrZeus [0] (~MrZeus@194.37.96.151) 10.01.33 *** Saving seen data "./dancer.seen" 10.09.41 # <_bilgus_> item of note https://gerrit.rockbox.org/r/c/rockbox/+/3264/4/firmware/target/arm/pp/system-pp502x.c#237 10.10.19 # <_bilgus_> when I tried to do the addresses and math in the for loop gcc messed it up and i'm not totally sure why 10.10.51 # <_bilgus_> ie m= 0;m<0x1800 m+=0x800UL 10.40.12 Quit massiveH (Quit: Leaving) 11.20.42 Quit kakaka (Remote host closed the connection) 11.21.07 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 11.41.16 Quit kakaka (Remote host closed the connection) 11.41.45 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 12.01.36 *** Saving seen data "./dancer.seen" 12.05.33 Quit paulk-leonov (Ping timeout: 258 seconds) 12.15.47 Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr) 12.21.31 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 12.21.48 Quit ZincAlloy (Client Quit) 12.21.57 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:a5ac:21ca:9113:49de) 13.22.30 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 14.01.39 *** Saving seen data "./dancer.seen" 14.19.13 Quit _bilgus_ (Read error: Connection reset by peer) 14.20.16 Join _bilgus_ [0] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com) 14.20.53 Join eevan [0] (~eevan@176.205.87.33) 15.25.12 Join speachy [0] (~speachy@209.2.65.77) 15.43.44 Quit Natch (Remote host closed the connection) 15.59.52 Part eevan ("Leaving") 16.01.33 Join PimpiN8 [0] (~PimpiN8@178.239.173.176) 16.01.41 *** Saving seen data "./dancer.seen" 16.21.18 Join Natch [0] (~natch@c-b471e255.014-297-73746f25.bbcust.telenor.se) 16.27.13 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 16.50.01 Quit Saijin_Naib (Remote host closed the connection) 16.50.08 Quit Natch (Read error: Connection reset by peer) 16.53.43 Join Natch [0] (~natch@c-b471e255.014-297-73746f25.bbcust.telenor.se) 17.00.57 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 17.01.43 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 17.02.43 Quit St3ak (Client Quit) 17.05.45 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-3dc3-7fa3-f8ad-b3a3.res6.spectrum.com) 17.23.08 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 17.23.23 Quit St3ak (Client Quit) 17.24.59 Quit Saijin_Naib (Disconnected by services) 17.25.03 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-3dc3-7fa3-f8ad-b3a3.res6.spectrum.com) 17.43.56 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 17.44.09 Quit kakaka (Remote host closed the connection) 17.44.36 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) 17.46.02 Quit lebellium (Quit: Leaving) 17.53.53 Quit Saijin-Naib (Ping timeout: 250 seconds) 18.01.42 *** Saving seen data "./dancer.seen" 18.04.30 Quit ZincAlloy (Quit: Leaving.) 18.24.36 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 18.40.42 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 19.04.58 Quit pamaury (Ping timeout: 240 seconds) 19.10.09 Quit atsampson (Ping timeout: 250 seconds) 19.10.38 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 19.11.22 Join atsampson [0] (~ats@2001:8b0:83b:b53f:42b0:76ff:fea4:87b) 19.21.00 Quit pamaury (Ping timeout: 246 seconds) 19.29.04 Quit atsampson (Ping timeout: 276 seconds) 19.30.33 Join atsampson [0] (~ats@2001:8b0:83b:b53f:42b0:76ff:fea4:87b) 20.01.46 *** Saving seen data "./dancer.seen" 20.45.17 Quit MrZeus (Ping timeout: 268 seconds) 20.52.00 Quit ac_laptop (Ping timeout: 246 seconds) 21.29.58 # speachy: that was disappointing 21.30.17 # seems the yh-925 doesn't actually need fixed disks but it does have trouble keeping the HDD connected 21.30.24 # it uses such an easily disconnected adapter 21.30.27 # baffling 21.30.49 # it snaps in place normally but the slightest movement can dislodge it 21.30.54 # what a stupid design choice 22.01.47 *** Saving seen data "./dancer.seen" 22.04.28 Join bonfire [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net) 22.09.51 Quit cockroach (Quit: leaving) 22.22.20 # <_bilgus_> speachy you around? 22.23.26 # <_bilgus_> https://pastebin.com/Bz8AM8VY 22.23.39 # <_bilgus_> Pretty self explanatory what this is ^ 22.26.44 # <_bilgus_> removing 0x800000 makes this device run perfectly fine looking at the diff of the asm I see that it is clearly using an immediate in the 0x0 version versus loading in the 0x8 version I suspect that is the desired result (0x8) but this device clearly doesn't like it 22.27.47 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 22.32.16 Join f1reflyylmao [0] (~f1refly@2a01:c22:8839:c00:d92a:d8d3:4569:1c3b) 22.35.03 Quit f1refly (Ping timeout: 268 seconds) 22.35.04 Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c22:8839:c00:d92a:d8d3:4569:1c3b) 23.08.16 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 23.11.33 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-884c-8dd3-f69e-d12c.res6.spectrum.com) 23.36.55 # <_bilgus_> and the plot thickens the cache is returning bad data with 0x0 so it is needed but still no clue why that makes it work 23.37.54 Quit ac_laptop (Ping timeout: 246 seconds)