09:16 <clamor> sjg1: are you free? Spl test fail of ofnode graph test is related to device tree size as well

10:42 <Daanct12> clamor: i think you're the one working on video bridge patch?

10:42 <clamor> Yes

10:43 <clamor> Daanct12: yes

10:43 <Daanct12> i tested your patch on my device and it works as expected

10:46 <clamor> Daanct12: I am glad to hear that. You may respond tested-by (preferably with the device name you tested on) to the patch if you wish.

10:48 <Daanct12> clamor: will do later when i have access to my mailbox. at the same time i'll also submit v2 of my rockchip display support

10:49 <clamor> Daanct12: nice. You may include me in cc or to if you wish so

10:49 <Daanct12> do you have a rk3568 device?

10:49 <Daanct12> would be nice if you can test them :)

10:50 <Daanct12> i have already tested it on my pinetab 2 and that's the only rk3566 device i had

10:51 <clamor> Unfortunately I don't have rockchip, I am a tegra owner ;) but I still can take a look.

10:54 <Daanct12> i still want the jetson orin :(

10:54 <Daanct12> such a costly device

10:57 <clamor> I don't have tegra newer than tk1 so yeah, expensive

14:52 <sjg1> clamor: OK...I'm not sure what is going on, but it is something to do with bloblist, right?

15:38 <clamor> sjg1: it seems to be related directly to size of tree

15:39 <clamor> If I add my bindings and comment node of similar size, my tests pass

16:47 <sjg1> clamor: OK, but I'm not sure what is going on, sorry. If it is bloblist, I was hoping to look at it this weekend, but I might not get time. You could try your patches on my tree if you like and I don't see any reason not to post them, since the bug seems unrelated to your code

16:48 <clamor> sjg1: is it possible that tree is overlaping global data?

16:48 <clamor> Load address of gd is fixed, correct?

16:48 <clamor> *start address

17:25 <sjg1> clamor: Yes, that is possible if something is horribly wrong. You could check that the bloblist is being relocated properly?

17:25 <clamor> sjg1: how?

17:28 <sjg1> clamor: You can use the 'meminfo' command to see where things are, assuming you can get to the cmdline. The function is reloc_bloblist(). But that is just a blind guess as do what it might be. I'm really not sure

17:30 <clamor> sjg1: I cannot check with complete tree since uboot just fails, I will try to find out what is going on.

17:30 <sjg1> clamor: OK, good luck

17:34 <clamor> sjg1: thank you

17:45 <clamor> sjg1: https://pastebin.com/vnK97rWw

17:46 <clamor> Plain, then with test tree, then with test tree trimmed

17:47 <clamor> Just informing

18:57 <sjg1> clamor: OK

23:14 <shadow> sjg1: board_fit_config_name_match() callback decides a "winner", do we know from U-Boot main payload what that is?

23:16 <shadow> I'm looking at duplicated EEPROM checking board/starfive/visionfive2/starfive_visionfive2.c to re-discover what the fdtfile search path should be set to, which is now heavily redundant but I'm not aware how we know what the winning result from board_fit_config_name_match() was

23:18 <sjg1> shadow: We should not be using that function. You can enable CONFIG_FIT_BEST_MATCH and do it that way. The fdtfile thing is not needed with FIT

23:18 <shadow> ah. Interesting.

23:20 <shadow> I'll adjust my review message to instead simply raise the question then. I did not like the clever string pointer math and this gets me looking at what could instead be deleted or simplified without trying to be clever and save a few bytes at the expense of code readability

23:24 <shadow> yeah I think this logic used to make some kind of sense and now it's just the wrong way around in board/starfive/visionfive2/spl.c