Hi Paul, On 06/18/2019 05:03 PM, Paul Kocialkowski wrote: > Hi, > > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote: >> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski >> <paul.kocialkowski@xxxxxxxxxxx> wrote: >>> Hi, >>> >>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick@xxxxxxxxx wrote: >>>> From: Nick Xie <nick@xxxxxxxxxx> >>> Was this tested with SPL support? I don't see DRAM configuration here >>> so it seems that it relies on the non-free rockchip loader. >>> >>> If that is the case, could you please indicate that in the commit >>> message? >>> >>> To maintainers: please do not merge this series before DRAM init and >>> SPL support is available for these boards. >>> >>> It seems that other RK3399 boards were merged without SPL support and >>> sofar, I have the feeling that nobody cared to explain how we got into >>> this broken situation. Please don't merge any more such board. >> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged >> with TPL-enabled (which was discussed on the threads, if you remember) >> with below boot chain. >> >> rkbin (TPL) -> SPL -> U-Boot proper >> >> Same case for this board as well. > Here is a quote from Philipp Tomsich on the thread we discussed this: > > " On some boards, there will be no TPL and only a SPL stage that will > initialise DRAM (as the move to having TPL on the RK3399 is optional). > > I agree with Paul that the DRAM init should be part of U-Boot whenever > we add new boards and make an open DRAM init a prerequisite. " > > So even if I frequently confuse SPL and TPL, it doesn't change the fact > that no board should be merged without proper DRAM init. > > Please stop pushing for merging these boards. I'm not sure what we > should do about the boards that were merged already without DRAM init, > but maybe they should be reverted. I don't think we have to have full DRAM init source code for each board before we can merge it, I believe most of the board on U-Boot mainline need to removed due to this rule. There are so many boards from different vendor need a binary loader before U-Boot, and I can see only very few drivers for dram at driver/ram/, and I believe rockchip is already the most open vendor on this area. I won't use this rule to stop developers contribute there source code, for a board support, we only need the board to have the full documentation about how to setup and boot with upstream U-Boot. and I think the most of people cares more about features in U-Boot proper. Everything before U-Boot proper, you can use TPL/SPL or alternative to use binary from vendor, as you can see all over the U-Boot mainline now, although we encourage people to use full open source TPL/SPL. Specifically for U-Boot Rockchip platform, I would like people to support not only U-Boot proper, but also for full SPL(ATF, OP-TEE support, itb image and other features) support. And for DRAM init, - if this belongs to SPL for this board, you must implement it or else SPL won't work; - if this does not belong to SPL for this board, you need implement full function SPL; and you can either to have full function TPL with DRAM init(which is prefered) or alternatively use binary loader from vendor. I'm not sure if you have write a new dram driver for a board, but I know even the board vendor may not have the capability to write the DRAM driver, so this should not stop developers contribute to all other 99% features on U-Boot. Thanks, - Kever > > Cheers, > > Paul > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-rockchip
