01:10 <macromorgan> so getting back to my clock thingy earlier... should I A) remove setting the GPU clock in U-boot (this diverges from Linux, but I can use the U-boot specific devicetree to do it), B) rig the clock driver to return 0 for clocks it cannot set and maybe drop a warning, or C) go through the effort of figuring out how to set the clock?

01:11 <macromorgan> the issue is the clock driver is a subset of the Linux one, as a result it can only set a subset of the clocks

01:11 <macromorgan> ideally I'd just figure out how to set the clock, as I have the registers in front of me and the datasheet, but I'm a bit out of my element here...

01:23 <macromorgan> looks like the clk-rk3399.c just returns 0 if it can't get or set the clocks...

09:04 <mwalle> if only more vendors would see NXPs behavior regardings issues, that is rather disable an important feature but debugging it

12:38 <swiftgeek> mwalle: I could only see debug context in your last line, but if it refers to debugging a chipie itself, it's a bit of pain to work with tools like verdi, and at the very least fix programming guide for that ip block

12:39 <mwalle> swiftgeek: wrong nick? ;)

12:40 <swiftgeek> nxp line was yours i think ?

12:44 <mwalle> swiftgeek: ah now I get you, no its not that lowlevel; but caring about upstream fixes outside of their (internal) goals

12:45 <mwalle> i was partly referring to https://lists.denx.de/pipermail/u-boot/2021-July/456371.html, but its not limited to only this

12:46 <swiftgeek> that sounds more like qemu than verdi, strange

12:49 <swiftgeek> I have to deal with debugging logic to which I have no sources, so like compared to that their response feels quite spoiled to me

12:53 <swiftgeek> but maybe just a communication issue, and they just needed to convey that their personally not going to go there, and like it states nothing of NXP position on this issues

12:54 <swiftgeek> *that they are

12:54 <swiftgeek> ie. they bailed without mentioning to whom that issue was handed over :D

12:56 <swiftgeek> mailinglists create a lot potential to get angry ^^

13:01 <mwalle> swiftgeek: not angry, but disappointed

13:06 <milkylainen_> marex: Yes. I did. :)

14:38 <milkylainen_> Hmm. Can I check the value of the serial probe in the cli somehow? Ie, if serial probe fail then stdout + stderr = vidconsole.

15:26 <marex> milkylainen_: see cmd/bind

17:27 <override> boot.scr are scripts run by uboot?

17:41 <marex> it is a boot script, yes

17:46 <override> marex: how does uboot know what script to run at boot up?

17:46 <marex> override: look at bootcmd and then follow that it does

17:46 <marex> printenv bootcmd

17:46 <override> oh, got it thanks!

17:48 <milkylainen_> marex: tnx. A bit unsure how that would work with the probe though?

17:50 <marex> milkylainen_: some extension might be necessary :)

17:50 <marex> milkylainen_: what is it you are trying to achieve ?

17:50 <marex> override: run foo means run script foo, which is part of u-boot env, so you can print it with 'printenv foo'

17:53 <milkylainen_> marex: I'm trying to be a bit flexible with std* on boot. Depending on what's available. My x86 board does not seem to have an UART declared somewhere. A bit unsure if u-boot chokes on that. But I'd like the possibility to say. "Well. If the serial device probe failed, start redirecting everything to vidconsole as out and usbkbd as in f.ex.

17:53 <milkylainen_> marex: I know that u-boot can have multiple targets in stdin/stdout.

17:54 <marex> milkylainen_: maybe you can send the console to all options ?

17:54 <milkylainen_> I think I can. But I suspect a bug somewhere in a serial driver. Not sure yet. Or a behavior.

17:55 <milkylainen_> Seems U-boot does not probe uarts that much. Then it starts talking to them, assuming everything is dandy.

17:55 <milkylainen_> I think there is options for that behavior but it's rather confusing.

17:56 <milkylainen_> CONFIG_SERIAL_SEARCH_ALL and CONFIG_SERIAL_PROBE_ALL

17:57 <milkylainen_> Uploaded file: https://uploads.kiwiirc.com/files/d1ea5096772870a9cd4d5c4dc28c100b/pasted.txt

17:57 <milkylainen_> oops.

17:58 <milkylainen_> The serial subsystem only searches for a single serial device that was instantiated, but does not check whether it was probed correctly.

17:59 <milkylainen_> That part seems rather treacherous.

18:00 <marex> milkylainen_: hm, that might be a bug that should be fixed ?

18:01 <milkylainen_> So what I think happens is that I have ns16550 built and used. Because I do vbox startups for simulation of my "x86 efi". Seems rather doable. x86 is pretty coherent in that way. But my physical board does not contain a UART. I have no UART out and no declarations that Linux can find.

18:01 <milkylainen_> So I suspect U-boot goes. "Oh. Serial.. Thats fine. Bootprompt get_key-> ns16550 uart stuff. IO-explosion. No console.

18:11 <marex> xypron: ^

19:59 <milkylainen_> Seems my console variables are always overwritten if I have mux enabled. So I have a fully working serial and vidconsole. Yet when I specify both builtin, it gets overwritten to just serial. The overwrite function is disabled.

20:02 <mrnuke> our containers for u-boot builds can run on Centos7, right?

20:09 <mrnuke> Tartarus: Thank you for replying to the libressl-2.7 patch. I couldn't have said it better myself

20:55 <milkylainen_> Is there a serial to usb poll rate?

20:55 <milkylainen_> Im running serial and USB now. (finally). But my serial seems abysmally slow

20:57 <milkylainen_> coninfo does not seem to update current console settings.

20:58 <milkylainen_> I have videoconsole and serial running. But coninfo lists everything on serial and nothing on anything else.