<marex>
peterm6881: upgrade to newer U-Boot version, please
<marex>
peterm6881: also, this is a BR problem, better ask BR developers
Stat_headcrabed has quit [Quit: Stat_headcrabed]
enok has joined #u-boot
gsz has quit [Ping timeout: 264 seconds]
Leopold has quit [Ping timeout: 260 seconds]
Leopold has joined #u-boot
___nick___ has quit [Ping timeout: 268 seconds]
Leopold has quit [Remote host closed the connection]
Leopold has joined #u-boot
Leopold has quit [Remote host closed the connection]
Leopold has joined #u-boot
naoki has joined #u-boot
naoki has quit [Client Quit]
enok has quit [Ping timeout: 245 seconds]
Leopold has quit [Ping timeout: 260 seconds]
Leopold has joined #u-boot
Leopold has quit [Excess Flood]
Leopold has joined #u-boot
vagrantc has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
Leopold has quit [Ping timeout: 260 seconds]
Leopold has joined #u-boot
Leopold has quit [Ping timeout: 260 seconds]
mmu_man has joined #u-boot
Leopold has joined #u-boot
<abws>
I try to add debug output to script/dtc/libfdt/fdt_ro.c to sort out why fdtdec_get_chosen_prop(blob, "stdout-path") returns a NULL string while stdout-path is defined in u-boot dtb fro the board (I checked with dtc)
<marex>
abws: that will dump the chosen node from u-boot control DT
<abws>
to do so I try to add "fprintf(stderr" to fdt_ro.c. u-boot main built fine, but u-boot-spl and u-boot-tpl failed because fprintf definition is taken from common/console.c but this definition calls vscnprintf which is defined in lib/vsprintf.c (built into u-boot main) but not in lib/tiny-printf.c (u-boot-spl/-tpl)
<marex>
#if !defined(CONFIG_SPL_BUILD)
<abws>
so I copied the definition vscnprintf from lib/vsprintf.c to lib/tiny-printf.c and rebuild. The rebuild then went fine but thenI get a hang running u-boot. I only get "U-Boot TPL 2023.10-armbian (Mar 23 2024 - 19:26:45)"
<abws>
is there a known issue with "chosen > stdout-path" read from fdt by serial-uclass.c ?
<marex>
not that I am aware of
<marex>
what is the real problem here ?
<abws>
marex: I cannot u-boot panic
<marex>
does it work with upstream u-boot, not a downstream fork ?
<abws>
this is upstream
<marex>
2023.10-armbian ... is not really upstream, is it ?
<abws>
with a few lines not yet upstream (the vendor closed door)
<marex>
upstream is 2024.04-rc4 or so btw
<abws>
well for this board there are no armbian patches out of the code not yet upstreamed for this board (the other patches have not been ported to v2023.10). So it is build with armbian but with no armbian patches
<abws>
I tried v2024.04-rc3 a few days ago, but as it failed I tried to step down a bit. Ie I got v2023.01 booting, then I try v2023.10
<abws>
I am not on latest master yet (that is the aim but I believe it is easier to up by steps)
<abws>
I found a few weird behaviors
<abws>
in lib/tiny-printf.c I have code enclosed by "#if CONFIG_IS_ENABLED(LOG=)" that is not build even though I have CONFIG_LOG=y in u-boot .config. Is it expected ?
<abws>
I mean I add random characters inside the preprocessor "if" and the build goes fine. If I put the garbage out of the "if" it does not build
<abws>
does the .config values applies to the tpl/ and spl/ builds?
<marex>
CONFIG_SPL_ values apply to SPL builds
<marex>
CONFIG_TPL_ ... TPL builds
<marex>
CONFIG_IS_ENABLED(FOO) expands per stage , i.e. if you have CONFIG_SPL_FOO=y , the section will build for SPL , if you have # CONFIG_FOO is not set, the section will NOT build for U-Boot proper
<abws>
also I tried to only add my code to lib/tiny-printf.c to the the SPL build by guarding it by "#if defined(CONFIG_SPL_BUILD)" but then it is is also defined in the tpl/lib/builtin-in.so
<marex>
abws: is CONFIG_TPL_BUILD defined in one and not in the other ?
<abws>
thanks for the confirmation of the expected behavior by the way
<abws>
marex: how to see if it is defined (do you mean if there is an "if defined(CONFIG_TPL_BUILD)""?)
<marex>
abws: #if defined(FOO) #error here #endif
<marex>
or gcc -E if you want to experiment with this
Leopold has quit [Ping timeout: 260 seconds]
<abws>
thanks, I usually add an invalid instruction (garbage characters) inside the guard and see if I get a syntax error). I forgot to check for the CONFIG_SPL_BUILD guard, will do
Leopold has joined #u-boot
<marex>
I wish you success
<abws>
ok #if defined(CONFIG_SPL_BUILD)\n #if defined(CONFIG_TPL_BUILD)\n #error "test" \n#endif\n#endif" and the error triggered for the tpl/ build
<abws>
that seems weird, isn"t it either SPL or TPL not both at the same time?
slobodan has quit [Ping timeout: 256 seconds]
naoki has joined #u-boot
<abws>
for now I use "#if !defined(CONFIG_TPL_BUILD)"
<marex>
abws: that is a bit odd
<marex>
SPL and TPL are different things and should have different set of symbols
<marex>
I have to admit, I havent used TPL is ... a very long time
<marex>
I think there are very few platforms which do use it, rockchip I think is one of them
<abws>
indeed this is rockchip rk3399 :-)
<abws>
I try newer u-boot because I have issues at least with upstream TPL and memory stability (this memory issue vanish when I switch to rockchip binary DDR blob, still the board is unstable, ie various crashes random kernel oops
<abws>
this might be a bug (and even be fixed in newer u-boot tags).
Leopold has quit [Ping timeout: 260 seconds]
<marex>
abws: there are a few people here working with that, qschulz maybe ? narmstrong ?
<marex>
they might be asleep or something
Leopold has joined #u-boot
<marex>
Jonas I think too, I am not sure what the nick is
<abws>
I am just trying to understand more about u-boot build system to add debug to fdt_path_offset (I have been able to add debug to fdtdec_get_chosen_prop but the output I get is an error code instead of a node for "stdout-path" in chosen node
<marex>
abws: what are you trying to debug again ?
<marex>
(sorry, I might be a bit distracted)
Leopold has quit [Remote host closed the connection]
Leopold has joined #u-boot
<abws>
u-boot pani with a "no serial driver found". I debugged it to the fact drivers/serial/serial-uclass.c serial_check_stdout fdtdec_get_chosen_prop fails to read "stdout-path" from the dtb "chosen " node even though my dtb has "chosen { stdout-path = "serial2:1500000n8";" defined
<abws>
you are not distracted I believe, I ask too many question at once :)
<marex>
abws: errr ... aren't you missing some ... bootph ... somewhere in the DT for serial console node ?
<marex>
abws: I am digging in something else, really
<marex>
abws: the bootph stuff is also used to retain nodes in SPL/TPL which would otherwise be removed
<marex>
so you must have that for the serial node, else it will be removed from that reduced SPL/TPL DT
<abws>
I blieve the bootph is fine, it is defined in the common rk3399.dtsi. But the fact is "fdtdec_get_chosen_prop(blob, "stdout-path")" returns an empty string instead of the value of the node. Then the code fallback to try serial0 (but on rk3399 this is serial2) so fails
<marex>
abws: is the chosen node actually in the SPL/TPL DT ?
<abws>
I added debug around the code attempting to get stdout-path, it returns a null string, then the debug code show u-boot-spl attempt the uclass_get_device_by_seq for UCLASS_SERIAL with index 1 (instea of 2 but u-boot cannot know as it has to read stdout-path to know the indx to raed is 2 but it fails to read stdout-path
<abws>
maybe not
<abws>
where is the SPL/TPL dtb?
<marex>
abws: errr, check /alias node and see what serial0 points to
<marex>
in the build directory, try find . -name \*dtb
<marex>
there will be some \*spl\*dtb
<abws>
the chosen node is in ts/dt.dtb and arch/arm/dts/rk3399-kobol-helios64.dtb
<abws>
thanks I believe I found it , I have spl/dts/dt-spl.dtb
<marex>
that looks about right
<abws>
yes it is there (with the stdout-path value)
<abws>
the error code out of fdt_path_offset(blob, "/chosen"); in fdtdec_get_chosen_prop is "-11"
<marex>
is this of_alias_scan you are looking at ?
<abws>
sorry? the callchain is serial_find_console_or_panic > serial_check_stdout > fdtdec_get_chosen_prop > fdt_path_offset(blob, "/chosen")
<abws>
from drivers/serial/serial-uclass.c
<marex>
oh
<abws>
also about TPL hanging at boot when I add "fprintf(stderr," to the script/dts/libfdt/fdt_or.c, could it be one cannot print to stderr in TPL?