10:31 <kcxt> how do we feel about folks using LLMs on the mailing list? I just got this reply to my patch review which smells a lot like chatgpt https://lore.kernel.org/u-boot/9b43ff3f-f675-4438-bad0-84d002b1a9cb@oss.qualcomm.com/

11:07 <marex> kcxt: I had a few replies to review feedback from LLMs, but this one is hard to tell

11:08 <marex> kcxt: that said, I really dislike the use of LLMs, I had people generate commit messages with those which was awful (basically missed the whole point of writing that commit message and reasoning about the content of the patch in it before sending it to the actual reviewer), and also had people generate entire code for patches using LLM iteratively in each patch revision (that was just awful)

11:09 <marex> kcxt: and I also dislike the mass deployment of LLMs which massively cripple productivity

11:10 <kcxt> marex: yeah im fully in agreement

11:11 <f_> hello this is funderscoreAI™ talking here, what do you need help with today?

11:12 <f_> </joke> that said I think maybe an LLM policy would help

11:14 <marex> kcxt: I think I need to get more coffee, grumb

11:30 <kcxt> lol

11:36 <f_> I sometimes just have quite a bit of fun with LLMs

11:36 <f_> like the time when I asked gpt to count how many "r"s are in "strawberry" it said there are 0 of them

12:30 <any1> marex: Here it is: https://github.com/Joshua-Riek/u-boot-rockchip/blob/rk3576/board/rockchip/evb_rk3576/evb_rk3576.c

12:30 <any1> They do a manual clock reset

12:33 <any1> rk3576.dtsi has that same reset referenced under usb_drd0_dwc3 as "resets = <&cru SRST_A_USB3OTG0>;"

12:33 <any1> I'll see if the dwc3 driver does anything with that node

13:48 <marex> any1: good

13:50 <any1> Looks like it's used by UCLASS_RESET

14:20 <any1> I didn't have the phy driver enabled. Need to add .compatible = "rockchip,rk3576-usbdp-phy" though

14:24 <any1> N.b. I also added rk3576 to dwc_glue_ids[], hoping that it would just work. :)

14:38 <marex> any1: use 'dm tree' to print currently bound and with [*] also probed drivers

14:43 <any1> The problem now is that I need to create a rockchip_udphy_cfg that works for rk3576

14:56 <marex> maybe that's something you can pull from the downstream stuff, esp. if its only register configuration or tuning settings

15:08 <any1> Hooray! It works

15:13 <any1> marex: Thanks for helping to figure this out!

15:15 <any1> I can send a patch, but I really haven't the foggiest idea about what the numbers in grfcfg mean

15:17 <any1> https://paste.sr.ht/~andri/043b43aa007d4f7aa262030347eab7038f452d24

15:20 <any1> Ahh, they're here, of course: https://github.com/Joshua-Riek/u-boot-rockchip/blob/rk3576/drivers/phy/phy-rockchip-usbdp.c#L1360

15:21 <any1> Why it works at all with the wrong numbers, is a mystery. :p

15:46 <Kwiboo> any1: the usb nodes was not added to the rk3576 board I had when rk3576 support was initially added, so I only did limited usb otg testing and as you noticed it resulted in ep timeout without full support for usb3.0

15:57 <any1> Kwiboo: Well, I have it working now. :)

18:50 <any1> Kwiboo: Did you get op-tee working in rk3576?

18:51 <any1> The bl32 file from rkbin is a binary, not an elf, and it looks like binman doesn't like that.

19:04 <Kwiboo> any1: no, I see no benefit in trying to get vendor optee blob working with mainline u-boot, as it mainly only provide feature for bsp u-boot, bsp kernel and bsp android

19:06 <any1> how about non-vendor optee then? :)

19:31 <marex> any1: does the optee-os binary provide any services for u-boot/linux , like psci/scmi/... ?

19:31 <marex> any1: if not, do you need it at all ?

19:34 <any1> marex: To be honest, I don't need any of that. I just wanted to enable it in case we need it in the future. The smarter thing to do would be to make sure that I can upgrade the bootloader in the future in a fail-safe manner, probably some kind of A/B partitioning

19:35 <marex> or start optee-os from fitImage , together with tfa bl31 and kernel

19:37 <any1> things are in a fit image, although the kernel on the file system

19:39 <any1> rockchip socs are a little bit annoying in that they don't offer any kind of a/b partitioning for the bootloader. I remember on i.MX6, I could use mmcblkboot[01] and switch between them

19:43 <any1> I suppose I could implement this in SPL

20:01 <marex> r-car v4h boots tfa bl31 and linux from one fitImage, from u-boot

20:02 <marex> this way it avoids bootloader updates when tfa needs to be updated