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

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

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

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

#rockbox log for 2021-03-29

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@
00:43:40 Quit _bilgus_ (Remote host closed the connection)
00:44:14 Join _bilgus_ [0] (
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/
01:53:27 Nick hook5432 is now known as hook54321 (sid149355@gateway/web/
01:54:25 Join ZincAlloy [0] (
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] (
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:21speachy_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:55speachy_bilgus_: look at 5bd86eb4b4
06:25:18speachyspeaking of cache initialization
06:42:39speachyand cd990684
06:47:58speachyI _think_ the ncdata section is overlapping the start of the stack
06:50:00speachymore accurately it's in the middle of the stack space
06:52:05speachyno, too many digits. sigh. too early in the morning for this stuff.
06:59:53speachya lot of the _init() code overlaps with the codec buffer
07:01:40speachybut I'm pretty sure that's deliberate. but if those functions are called after audiobuf is set up/used/whatever...
07:02:19speachyI 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:27speachythe 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:27speachyor 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:58speachyit seems to be linking okay to my eyes, or at least close enough to the ipods as to not matter
08:33:29speachy(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:40speachy32B 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:21speachyone 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:57speachywould be worth disabling them.
08:46:16 Join kakaka [0] (~koniu@gateway/tor-sasl/koniu)
08:47:18braewoodsand switching to pure C?
08:47:22speachythe 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:41speachythe lcd code I have in mind is unique to the h10 series
08:47:53speachy(which would explain why the ipods apparently work ok)
08:48:22_bilgus_assuming they still do
08:48:22braewoodsit's too bad i only sent bilgus the 20GB unit
08:48:31braewoodsnot that the 5GB is very usable today
08:48:43braewoodsit'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:06speachywell, 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:52braewoodsit sounds like sendng it to you was the right choice ultimately
08:50:05braewoodsi don't know ARM ASM at all
08:50:30_bilgus_I'm ok at it just need a cheat sheet
08:50:42braewoodsi mostly write C and almost no ASM to date
08:50:47braewoodsmostly just some random x86
08:50:50braewoodsfor shits and grins
08:51:30braewoodsi did manage to do some minor patching of the coldfire ASM
08:51:39braewoodswhen i worked on the bootloader
08:52:01braewoodsbut ppc is a lot closer to x86 than early arm is
08:52:05braewoodsjust wow is arm
08:52:15braewoodsarm seems to take a lot more work to do anything
08:52:25braewoodsat least the version we use
08:53:05braewoodsfrom what i gathered loading from RAM into a register requires separate instructions every single time
08:53:38speachybraewoods: that's a RISC thing. x86 and m68k were the last bastions of heavyweight CISC.
08:53:43braewoodswhile in x86 some instructions can do that automatically as part of the instructions
08:54:02braewoodsi see
08:54:03_bilgus_hmm other targets have the YUv420 thing wonder if any are pp
08:55:11braewoodsspeachy: ok, just used to x86 where you can multiply a register by the contents of a ram address
08:55:17braewoodsyou don't need to load into a register first
08:55:21braewoodsfor both
08:55:30speachyconsider that x86 is also extremely register limited
08:55:44braewoodsx86_64 does a lot to address that
08:55:48braewoodsadds a ton of new register
08:55:58braewoodseven some that aren't even given a special name
08:56:01braewoodsjust numbered
08:56:52braewoodsall 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:01braewoodsit must have made memory management a nightmare
08:57:26_bilgus_generally with some kind of unit test in hand
08:57:35braewoodshaving to flip pages so to speak and not having access to more than 16 bits at a time
08:57:50braewoodsthe flat model simplifies access a lot
08:58:52braewoods32 bit x86 was a big deal until they exhausted the RAM limits
08:59:00braewoods4GB 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] (
09:32:14_bilgus_gotta love source versioning found the reference yuv code luckily
09:50:25 Join Saijin_Naib [0] (
09:58:15_bilgus_Speachy, No dice still same crash with C yuv routines
09:58:43 Join MrZeus [0] (~MrZeus@
10:01:33***Saving seen data "./dancer.seen"
10:09:41_bilgus_item of note
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] (
12:21:31 Join ZincAlloy [0] (
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] (
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] (
14:20:53 Join eevan [0] (~eevan@
15:25:12 Join speachy [0] (~speachy@
15:43:44 Quit Natch (Remote host closed the connection)
15:59:52 Part eevan ("Leaving")
16:01:33 Join PimpiN8 [0] (~PimpiN8@
16:01:41***Saving seen data "./dancer.seen"
16:21:18 Join Natch [0] (
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] (
17:00:57 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC:
17:01:43 Join St3ak [0] (
17:02:43 Quit St3ak (Client Quit)
17:05:45 Join Saijin_Naib [0] (
17:23:08 Join St3ak [0] (
17:23:23 Quit St3ak (Client Quit)
17:24:59 Quit Saijin_Naib (Disconnected by services)
17:25:03 Join Saijin-Naib [0] (
17:43:56 Join St3ak [0] (
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@
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:58braewoodsspeachy: that was disappointing
21:30:17braewoodsseems the yh-925 doesn't actually need fixed disks but it does have trouble keeping the HDD connected
21:30:24braewoodsit uses such an easily disconnected adapter
21:30:49braewoodsit snaps in place normally but the slightest movement can dislodge it
21:30:54braewoodswhat a stupid design choice
22:01:47***Saving seen data "./dancer.seen"
22:04:28 Join bonfire [0] (
22:09:51 Quit cockroach (Quit: leaving)
22:22:20_bilgus_speachy you around?
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@
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] (
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)

Previous day | Next day