15:32 <samcday> Anyone know the history of the REBOOT_MODE uclass? I wrote a driver for it and manually kludged "dm_reboot_mode_update" into my "board_late_init" and it works nicely, but it seems like it isn't used anywhere. Should that "dm_reboot_mode_update" be called somewhere automatically when "DM_REBOOT_MODE=y"?

15:41 <marex> I never used that one

15:41 <marex> seems sandbox specific ... sjg1 ^ ?

15:57 <samcday> My gut feeling is it was intended to properly codify something that was done elsewhere (such as "sniper" board), but after the groundwork was laid no actual consumers were integrated because life do be like that sometimes

15:58 <samcday> I'd be surprised if it was just for sandbox since the original author implemented actual drivers for GPIO and nvram

16:02 <marex> oh, you're right

16:07 <samcday> Also, interestingly, the uclass code is making use of a "mode-" property convention on the DT node to map the reboot codes to strings, and the device I chose to write a reboot mode for (PM8916) already has those properties in the upstream .dtsi ... So that's why I'm really confused as to why all this great stuff already exists (since 2021!) but isn't in use anywhere o.O

16:11 <Hammdist> hello. I am interested in building a custom u-boot for orange pi 5 that would utilize a smaller baud rate than the default, because my serial port adapater does not support 1500000. is this possible?

16:13 <samcday> Hammdist: should be, there's already a u-boot DT tweak for that board: https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi

16:14 <samcday> So I think it might be as easy as dropping a "stdout-path = "serial2:<your new buad>n8";" into the "/chosen" of that file, and then rebuild

16:16 <sjg1> samcday: The reason for the sandbox support is that we have to have sandbox tests for each uclass. I'm not sure why no one has upstreamed actual use of this feature to U-Boot

16:21 <samcday> sjg1: Cool, that makes sense. Do you have any tips for how "dm_reboot_mode_update" should be "properly" plumbed in, or is that something that should just be left up to the boards? I did this: https://github.com/samcday/u-boot/commit/76a16de7a2cfe818880c80b285688a6a264401ff

16:23 <samcday> I was thinking maybe it'd make sense to do as a uclass ".child_post_probe" or something, but the problem with that is "env_set" doesn't work until somewhere later like "board_late_init"

18:35 <sjg1> samcday: You could perhaps create a sysinfo driver for the board and do it there. You could have a phandle from the sysinfo node pointing to the reboot-mode device.

18:42 <marex> Hammdist: setenv baudrate number ; saveenv

18:42 <marex> Hammdist: you can reconfigure baudrate by setting that variable in your U-Boot env, no need to rebuild anything

21:16 <marex> Tartarus: did that hash md5 test go all weird ?

22:13 <Tartarus> marex: well, there's something up yes, no, no one knows why

22:13 <Tartarus> Removing or skipping the test papers over the problem, and the problem only shows up when the test was added

22:13 <marex> Tartarus: is it always md5sum test ?

22:14 <marex> test/cmd/hash.c:22, dm_test_cmd_hash_md5(): 0 == run_command("hash md5 $loadaddr 0", 0): Expected 0x0 (0), got 0x1 (1)

22:14 <Tartarus> Yes, it's only that test that randomly fails for unknown reasons (the dm_rtc test fails sometimes because it took too long)

22:14 <marex> maybe $loadaddr is not always set ?

22:14 <marex> it did, after all, print a help message

22:15 <Tartarus> Sure, but how could that happen?

22:15 <marex> Tartarus: broken sandbox or broken CI server ?

22:16 <Tartarus> If you loop a commit that failed once about 50 times it will fail again, but not every time

22:16 <Tartarus> And it doesn't matter what the host machine is

22:45 <marex> Tartarus: https://source.denx.de/u-boot/custodians/u-boot-sh/-/jobs/1006238#L299

22:56 <marex> Tartarus: I wonder if the wget test which is mucking around with loadaddr might be responsible

23:04 <marex> Tartarus: https://source.denx.de/u-boot/custodians/u-boot-sh/-/jobs/1006241#L302 wow

23:25 <marex> Tartarus: ah ... I think I know what it is , it is really the wget test which does env_set loadaddr as string I think

23:58 <marex> Tartarus: https://lists.denx.de/pipermail/u-boot/2025-January/578604.html