17:46 <smaeul> mripard: jernej: thanks for the hints! LCD_RB_SWAP made the tint red instead of blue. and even with all layers disabled, the blender background color was affected. BLD_BK_COLOR=0xffff7f was full white. (changing any of the other bits did have an effect)

17:46 <smaeul> so the problem was between the blender and the TCON FIFO... or in other words, the TCON TOP

17:48 <smaeul> the problem was DE_PORT_SELECT_REG having both mixers mapped to TCON_LCD (value == 0)

17:48 <smaeul> R40 manual has the note: "If TCON_LCD0 selects DE0 and DE1 as source at the same time, then DE0 will be used for the source of TCON_LCD0."

17:49 <smaeul> so theoretically it should be fine, but it causes both the 1 pixel offset/wraparound and the incorrect colors

19:16 <machinehum> I'm assuming some people here have used Ghidra, is there a way to check to see which section of the program has accessed this memory? https://imgur.com/a/GoEHiLc

19:17 <machinehum> Other data blocks have labels, like this https://imgur.com/a/9hW5K8v and I can search for them

19:17 <machinehum> But I'm not sure how to find which section of the program is using this string

19:27 <jernej> smaeul: interesting, good to know

19:30 <smaeul> machinehum: 1) make sure you have the right base address, so absolute address references work 2) split the memory region between .text/.rodata and .data/bss, and mark the .text/.rodata region as read-only. This allows the analysis to "dereference" through constant pools

19:36 <machinehum> Right of course, yeah it's a relative

19:37 <machinehum> all

19:40 <jernej> smaeul: second point explains the annoyance I have with ghidra when analyzing binaries.

20:00 <smaeul> another trick for dynamically-initialized (yet still constant) pointers is telling Ghidra to assume the initialized value