<Kwiboo>
it just cleans up some Kconfig that should not be needed, work-in-progress for v2 of the external/rockchip-tpl series
<CounterPillow>
Hmmm, still no luck. I think I'll wait until some of this stuff has settled into upstream to work on it further.
<Kwiboo>
I have been using the evb-rk3568 config for my rk356x testing so far, and only cared to see if sd+emmc works, I just want u-boot to load linux :-)
<naoki>
Kwiboo: did you try CONFIG_OF_LIBFDT_OVERLAY=y?
<CounterPillow>
I assume that means they didn't try that :P
<naoki>
I want to try few more things, but my build PC was crashed some minutes ago...
kevery has joined #linux-rockchip
<Kwiboo>
I can now confirm that I was able to start linux on my rock-3a+c with CONFIG_OF_LIBFDT_OVERLAY=y and CONFIG_TOOLS_FIT_SIGNATURE=y
<CounterPillow>
My current hypothesis is that turning on overlays makes u-boot compile the dts with node names, which increases the size of the dts, which stomps on something else
<CounterPillow>
But I'll try the remove props
<CounterPillow>
hmmm, remove props didn't work. something weird is going on. I wish I knew where exactly it was hanging but I don't have an expensive debug probe
<CounterPillow>
hmmm, u-boot.itb isn't much larger with overlay support (929280 vs. 908288 bytes), so I don't think my hypothesis holds any water
<Kwiboo>
you can allways add "#debug LOG_DEBUG" to include/log.h and see lots and lots of debug messages on your serial console
<Kwiboo>
#define LOG_DEBUG
<CounterPillow>
.itb of size 923648 works, one of size 928256 doesn't work. Time to throw out stuff to find the precise change that triggers it and then see if it's specific to that node or just the size
<Kwiboo>
it could be some size limit/memory overlap, lookin at the fdt_addr_r=0x0a100000 and ramdisk_addr_r=0x0a200000, possible other ranges only are 1MiB until they overlap?
<CounterPillow>
925696 doesn't work, 924672 doesn't work, 924160 doesn't work, 923136 works as expected, 923648 works as expected with a different set of nodes, so it seems to really just be the size
<CounterPillow>
There seems to be a fdt_size_r used in like 3 places, but I don't see where that is actually read
<CounterPillow>
and increasing it with changing the ranges so they wouldn't overlap didn't work :(
naoki has joined #linux-rockchip
<naoki>
interesting...
<CounterPillow>
can't seem to find the right config value to set fdt size
<Kwiboo>
CounterPillow: could you try with CONFIG_SPL_FIT_SIGNATURE=y, I wrote TOOLS earlier but should have been SPL, then SPL will verify hash of the data loaded from the FIT
<CounterPillow>
Will try, thanks for the hint
<CounterPillow>
Do I need to somehow also generate a hash?
<CounterPillow>
## Checking hash(es) for config config-1 ... fit_config_verify_required_keys: No signature node found: FDT_ERR_NOTFOUND
<CounterPillow>
OK
<Kwiboo>
hash should be added by the mkimage call, but not for the config, that is only added with full signing
<CounterPillow>
it hangs at the same point, so if hash verification failing triggers a board reset it's not happening
<Kwiboo>
okay, then is is probably passing the hash test on rest or the loadables, it probably prinst sha256 +OK mixed with the rest of the debug text
<CounterPillow>
Yeah, I see some sha256 +OK in the output
<CounterPillow>
so I guess my hypothesis of this being related to the size is wrong then, unless something other than SPL is running into issues
<CounterPillow>
CONFIG_SPL_LOAD_FIT_ADDRESS is 0x0, is that bad?
<Kwiboo>
at least reading the external data into dst= is not a problem, strange issue, your u-boot seems to be ~700kb (size=ad030) and dtb ~68kb (size=10d00), does not seem to overlap with other addresses
<CounterPillow>
the last message is that it's jumping to 0xa00000, which is the text base. I guess if something overwrote what's there then that could be an issue but it's apparently not the dtb doing it from what I gather
<Kwiboo>
SPL_LOAD_FIT_ADDRESS seem to be used for loading FIT from ram, so should not be used here
<CounterPillow>
Alright
<CounterPillow>
I'll try CONFIG_SPL_FIT_FULL_CHECK to see if that shows anything interesting
<Kwiboo>
exactly, u-boot proper is loaded to 0xa00000, fdt directly after that, and atf to 0x40000 and some sram locations, SPL is read in by bootrom to 0x0
<CounterPillow>
oh god what if my SPL is simply too chonky? But then jumping to atf wouldn't succeed
<Kwiboo>
SPL is usually pretty small, and it can be up to ~256kb, only job of SPL is to read FIT from storage, load content to dram, then jump to atf/u-boot proper
<CounterPillow>
ok with the full check enabled it just bootloops, interesting!