<krichy>
alpernebbi thanks, i'll have a look at that
<Tartarus>
And I'm testing putting that in master right now, fwiw
<alpernebbi>
thanks!
monstr has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
matthias_bgg has quit [Ping timeout: 252 seconds]
lucaceresoli has quit [Quit: Leaving]
vagrantc has joined #u-boot
apritzel has quit [Ping timeout: 252 seconds]
<krichy>
just pulled master branch, and u-boot works as expected on rk3399 based rock-pi-4a
<krichy>
many thanks!
<krichy>
boots from emmc as well from sd
krichy has quit [Quit: Client closed]
<Tartarus>
yay
___nick___ has joined #u-boot
southey2 is now known as foxtrot
apritzel has joined #u-boot
sobkas has joined #u-boot
<Tartarus>
sjg1: Do you have any imx platforms?
<sjg1>
Tartarus: Yes I have an imx6
<Tartarus>
sjg1: Then you should be able to see what Soeren is talking about
<Tartarus>
and what's not generally I think done on imx platforms
<Tartarus>
Unless I missed something and there is a good conversion example to point people at
<sjg1>
I did actually do a bit of mx6 conversion a while back but didn't finish it. Who is the maintainer?
<sjg1>
Tartarus: Re the partitions thing, do you understand with the need for the SPL_PARTITIONS option, now that we have a partition driver?
<Tartarus>
sjg1: Did you see my reply from less than 5 minutes ago?
<Tartarus>
Lets go with that first :)
<sjg1>
Tartarus: Yes but I'm just lost on this. We need to disable the partition driver in SPL, if partitions are not used. What is controversial about that?
<Tartarus>
sjg1: OK, yes, no, I don't object to making it so we can disable something that's been functionally unused in some cases.
<Tartarus>
But I'm worried that we've now gone over the limit on seemingly a bunch of things, just modifying partition infrastructure?
<sjg1>
Tartarus: OK, so can you pick up the SPL_PARTITION patch?
<sjg1>
Tartarus: Yes, adding a partition driver does increase size but only a small amount. It seems well worth it to me
<kettenis>
abstraction layers ave a cost
<kettenis>
have a cost even
<Tartarus>
sjg1: Yes, I'll take that eventually to next, and how much is small?
<Tartarus>
sjg1: And perhaps a good example imx DM_SERIAL conversion is needed then
torez has quit [Remote host closed the connection]
<marex>
Tartarus: which iMX is over the limit now ?
<Tartarus>
marex: None of them are over the limit, but also I think none of them are fully / correctly migrated to DM_SERIAL such that they don't miss console messages nor rely on some ugly non-DM tricks
<Tartarus>
Unless I'm missing the good example(s) to point Soeren at
<marex>
there is a ton of work to be done indeed
___nick___ has quit [Ping timeout: 260 seconds]
sobkas has quit [Quit: sobkas]
<sjg1>
Tartarus: Yes. I have a bad, uncleaned-up series from two years ago. I am not sure when I might get back to it
<Tartarus>
Well, a good example rather than all of them converted, would probably be most helpful
behanw has quit [Quit: Connection closed for inactivity]
<Tartarus>
Because I'd like to have a good answer to what Soeren said on the list now, which I don't think we have, rather than enabled X/Y/Z CONFIG options to remove build warnings, increased the overall size and didn't really make anything else cleaner since the real "ugly" stuff is all still static
prabhakarlad has quit [Quit: Client closed]
<sjg1>
Tartarus: Every SoC is different. For the UART is might need a pinctrl, a clock, or something else. I'll dig out the ugly code in case it helps
<sjg1>
Tartarus: The intent with DM_SERIAL conversion is to do a proper conversion, so something with a missing banner. Having said that, the missing banner is definitely not unheard of
<Tartarus>
pins and clocks are pretty common
<Tartarus>
Yes, there's a little difference between soc families
<Tartarus>
But, a good imx example would probably help a lot
<Tartarus>
I don't know if those are ones that just omit some output. What's the imx you have, and does it do everything right and not miss any output?
<Tartarus>
Because for stuff like this the difference between 6* and 7* isn't all that much
<sjg1>
Tartarus: I have a custom board (not upstream) and it uses SPL, so is not a great example
<Tartarus>
I think I've got a spare cubox around here I can ship you, if it'll help
<marex>
or you can buy the reform laptop ... that's a contemporary mx8m(q)
<Tartarus>
Yeah, but that doesn't quite address the issue of how to nicely convert imx6/7 platforms so it's a net win to use DM_SERIAL
<marex>
hummmm, the SPL size limit will be a problem there
<marex>
Novena uses SPL with all the fancy stuff I think
<marex>
The DH iMX6 should also be reasonably OK
<Tartarus>
Yeah, you can use SPL or not use SPL, but that shouldn't matter for the overall problem
<marex>
what is the "overall problem" ?
<Tartarus>
Since it's how do you have DM handle all of the stuff for a UART early enough to be useful
<Tartarus>
(outside of when yes, DEBUG_SERIAL is the right answer)
<marex>
ugh ... debug serial without debug serial then ?
<Tartarus>
Well in short Soeren is pointing out that yet again, "fixing" the DM migration warning for tbs2910 is increasing the size and not making anything cleaner as there's still manual mux config for uart output
<Tartarus>
or whatever the b4/lei command would be to suck down that message-id
<marex>
ugh
<sjg1>
Tartarus: Can you suggest that Soeren digs in and has a look? It could be a glorious example!
* marex
reads through
<Tartarus>
sjg1: No, that's backwards. What's the 32bit arm golden example for DM_SERIAL to point him at?
<Tartarus>
That gets the mux done early via DM and DM_PINCTRL
<Tartarus>
Even if it's not imx
<marex>
heh, none, I know imx and renesas both do some sort of board-specific pinmux voodoo
<Tartarus>
Or barring 32bit, 64bit that's not relying on TF-A/etc to have done it?
<sjg1>
Tartarus: Actually I have a cubox, I forgot about that. But I'm travelling for some weeks and don't have any hardware, and the MX6 in my lab is not functioning right now
<sjg1>
Tartarus: I think firefly-rk3288 (or any other rk3288 board) is pretty good as a driver model example
<Tartarus>
OK, well, note where / how that's handling all of the mux stuff correctly for UART to work
<Tartarus>
Maybe update doc/develop/driver-model/serial-howto.rst with hints on how to update a board to make the best use of DM_SERIAL and DM_PINCTRL
<marex>
Tartarus: I can see why Soren is so unhappy all right
<sjg1>
Tartarus: arch/arm/dts/rk3288-u-boot.dtsi is most of what is doing on with rockchip. It uses a normal pinctrl driver. I cannot see any special hacks, other than debug_uart_init()
<marex>
sjg1: debug_uart_init() does bind pinctrl driver and UART driver from DT ?
<kettenis>
nope
<marex>
I was under the impression that directly writes into <register area> which is hard-coded in config
<kettenis>
it does
<kettenis>
that is supposed to work really, really early
<marex>
somehow that doesn't seem to be the right answer to the question from Soren then
<marex>
so that means, init IO twice and hack around missing serial console using debug uart ... and then enable serial DM for what reason again, when serial is already working ?
<sjg1>
Tartarus: Re serial-howto, do you mean general comments, like making sure the pinctrl works and adding tags to ensure drivers are bound? Unfortunately there isn't really a general formula. It can be quite tricky
<sjg1>
marex: No, the debug UART is off, in general. The platform uses pinctrl. I'm just pointing out that the debug UART is always a special case
<marex>
sjg1: if you start single-handedly dictating deadlines to people to work on code which has no benefit for them, then yes, you need to provide directions how to do the conversion, ideally including examples
<marex>
telling people "hey, I decided you have a new deadline and you must figure out this hard part of DM by yourself, else we drop your board" ... not great
<Tartarus>
sjg1: I'm saying we should be able to point a developer at https://u-boot.readthedocs.io/en/latest/develop/driver-model/serial-howto.html and between the page itself and links to other relevant and generated documentation, we should be able to get DM_SERIAL conversions that are a benefit to the platform and not just DM_SERIAL is enabled, warning went away, like we get right now, and have gotten I think for a large number of other conversions.
<Tartarus>
Similarly for other conversion deadlines we have or will add in the future
<Tartarus>
It shouldn't just be read the code and try and hunt up someone else doing a conversion that was hopefully good enough
<Tartarus>
We have how to convert the driver, which is good, but also complete now? We don't have convert the board to make good use of the driver
<Tartarus>
As I don't see anything for rk3288 or other rockchip platforms that would be addressing the problem of getting the pinctrl handled early for UART to work at its normal time
<Tartarus>
vs later on
<Tartarus>
I do see arch/arm/include/asm/arch-rockchip/uart.h:void rk_uart_init(void *base); but that's an unused function and should get removed
<Tartarus>
or maybe is, in an outstanding patch
<Tartarus>
And, uh
<Tartarus>
$ make firefly-rk3288_defconfig
<Tartarus>
$ grep DEBUG .config
<Tartarus>
CONFIG_DEBUG_UART_BOARD_INIT=y
<Tartarus>
So, that's where rk3288 UART is init'd, which is not a best practice
<marex>
pff
<Tartarus>
I assume you forgot that was set :)
<Tartarus>
But it's under ARCH_ROCKCHIP with an imply
<Tartarus>
Is turned off on 3 boards tho
<Tartarus>
And ah good, there's Fabio with a patch to do what's being asked for, yay.
<sjg1>
Tartarus: Yes that readme is quite old
<sjg1>
Tartarus: You can turn off CONFIG_DEBUG_UART for rockchip and the UART still works, so it doesn't rely on it
<sjg1>
Tartarus: Re 'addressing the problem of getting the pinctrl early', what is missing? It all works so far as I know, just using the normal pinctrl driver