On Thu, 2019-05-09 at 18:06 +0530, Jagan Teki wrote: > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > <paul.kocialkowski@xxxxxxxxxxx> wrote: > > Hi, > > > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > > Hi Paul, > > > > > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > > > <paul.kocialkowski@xxxxxxxxxxx> wrote: > > > > Hi, > > > > > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > > > > > This is v7 resend patchset for New rk3399 boards support wrt previous > > > > > version[1] > > > > > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > > > orangepi rk3399 changes are merged, so this is rework on top of > > > > > u-boot-rockchip/master. > > > > > > > > > > Overall this series add support below rk3399 boards > > > > > - NanoPI M4 > > > > > - NanoPC T4 > > > > > - NanoPI NEO4 > > > > > - Orangepi RK3399 > > > > > - Rock PI 4 > > > > > - Rockpro64 > > > > > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > > > > > dts(i) from linux-next. > > > > > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > > > > > series [3]. > > > > > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > > > > > booting via Rockchip miniloader as of now. > > > > > > > > Could you send these two boards in a separate series so that we avoid > > > > merging them for now (because SPL support is broken) and then re- > > > > iterate the series later with the DDR bringup? Or maybe find a way to > > > > disable SPL support, but in any case, it's not ok to merge a board with > > > > SPL enabled and broken. > > > > > > I have explained the details about this concern on v2 [1], thought you > > > would comeback on the same line instead here. > > > > Yes, you have already explained the issue, but I don't think it's > > enough a justification to merge broken SPL support. If it was only > > partial or limited, it would be fine, but here it's just broken. > > > > > Anyway, making SPL as an optional is not an idea to go with Mainline > > > as we make many decisions with regards to make SPL is mandatory. > > > > Yes I think making SPL mandatory is a good idea, so that's why I'm > > suggesting that we don't merge the boards until they have SPL support. > > > > > Since the DDR is show stopper here (and it would really need a good > > > amount of time, since it effect the other boards), I can go with TPL > > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > > > booting stages. This way we can avoid skipping SPL usage, and many > > > config changes to make SPL optional. > > > > Honestly I don't really see the point of merging these boards at all if > > they don't have SPL support. People who really want to use them with > > the rockchip blob can cherry-pick the patches from the list in the > > meantime. > > > > It also creates incentive for people to free the DDR init, since that > > becomes a condition to have the board upstream. > > > > What do you think? > > I don't know whether you get my point or not? these boards are not > merged yet. What I'm saying is we are going to support them with > TPL-enabled, that was SPL can make use of these boards which still a > valid boot-chain. moreover this way can avoid touching core files and > no specific change require while supporting ddr dtsi. Ah maybe I missed the point indeed. So what you are suggesting is: rkboot (acts as TPL) -> SPL -> U-Boot? Then I have no problem what that. Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com _______________________________________________ Linux-rockchip mailing list Linux-rockchip@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-rockchip
