[U-Boot] [PATCH v3 2/4] rockchip: rk3399: Add common Rock960 family from Vamrs

[Manivannan Sadhasivam]

On Wed, Oct 03, 2018 at 09:41:25PM +0200, Philipp Tomsich wrote:
> 
> 
> > On 03.10.2018, at 21:36, Ezequiel Garcia <ezequiel at collabora.com> wrote:
> > 
> > On Wed, 2018-10-03 at 21:34 +0200, Philipp Tomsich wrote:
> >>> On 02.10.2018, at 16:01, Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org> wrote:
> >>> 
> >>> Hi Simon,
> >>> 
> >>> On Tue, Oct 02, 2018 at 04:21:38AM -0700, Simon Glass wrote:
> >>>> On 27 September 2018 at 12:02, Manivannan Sadhasivam
> >>>> <manivannan.sadhasivam at linaro.org> wrote:
> >>>>> Rock960 is a family of boards based on Rockchip RK3399 SoC from Vamrs.
> >>>>> It consists of Rock960 (Consumer Edition) and Ficus (Enterprise Edition)
> >>>>> 96Boards.
> >>>>> 
> >>>>> Below are some of the key differences between both Rock960 and Ficus
> >>>>> boards:
> >>>>> 
> >>>>> 1. Different host enable GPIO for USB
> >>>>> 2. Different power and reset GPIO for PCI-E
> >>>>> 3. No Ethernet port on Rock960
> >>>>> 
> >>>>> The common board support will be utilized by both boards. The device
> >>>>> tree has been organized in such a way that only the properties which
> >>>>> differ between both boards are placed in the board specific dts and
> >>>>> the reset of the nodes are placed in common dtsi file.
> >>>>> 
> >>>>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
> >>>>> [Added instructions for SD card boot]
> >>>>> Signed-off-by: Ezequiel Garcia <ezequiel at collabora.com>
> >>>>> ---
> >>>>> 
> >>>>> Changes in v3: Added instruction for copying prebuilt bl31.elf for SPL
> >>>>> 
> >>>>> Changes in v2: None
> >>>>> 
> >>>>> arch/arm/dts/rk3399-rock960.dtsi            | 506 ++++++++++++++++++++
> >>>>> arch/arm/mach-rockchip/rk3399/Kconfig       |  26 +
> >>>>> board/vamrs/rock960_rk3399/Kconfig          |  15 +
> >>>>> board/vamrs/rock960_rk3399/MAINTAINERS      |   6 +
> >>>>> board/vamrs/rock960_rk3399/Makefile         |   6 +
> >>>>> board/vamrs/rock960_rk3399/README           | 152 ++++++
> >>>>> board/vamrs/rock960_rk3399/rock960-rk3399.c |  50 ++
> >>>>> include/configs/rock960_rk3399.h            |  15 +
> >>>>> 8 files changed, 776 insertions(+)
> >>>>> create mode 100644 arch/arm/dts/rk3399-rock960.dtsi
> >>>>> create mode 100644 board/vamrs/rock960_rk3399/Kconfig
> >>>>> create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS
> >>>>> create mode 100644 board/vamrs/rock960_rk3399/Makefile
> >>>>> create mode 100644 board/vamrs/rock960_rk3399/README
> >>>>> create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c
> >>>>> create mode 100644 include/configs/rock960_rk3399.h
> >>>> 
> >>>> Reviewed-by: Simon Glass <sjg at chromium.org>
> >>>> 
> >>>> Could you also add a note to README.rockchip? Some of your docs seem
> >>>> to duplicate what is there.
> >>> 
> >>> Thanks for your review!
> >>> 
> >>> You mean, I should skip the duplicate instructions and add a pointer to
> >>> relevant sections in Rockchip README?
> >> 
> >> I also had had a similar comment on an earlier series: we should avoid just copying these
> >> instructions verbatim into every new board: if these are indeed identical to Rockchip’s EVB
> >> (i.e. if the board-vendor completely relies on the chip-vendor's tools), they should reference
> >> back to the EVB’s README instead of duplicating the content.
> >> 
> > 
> > Yes, I agree here. The instructions are almost 100% SoC-specific, not board specific.
> > Having a doc per SoC is the way to go, IMO.
> 
> That’s not entirely true: on the RK3399-Q7 we have very different instructions, as we have
> our own tooling and maintain a number of components specifically for the board.
> In other words: many boards will want to reference back to the EVB’s instructions, but not
> all of them … and the instructions are not entirely SoC specific, but most vendors choose
> to do things exactly the same as for the EVB.
>

Agree! Even we are working on customizing the instructions for Rock960
family boards. The current instructions in README is just an intial
reference to get the board up and running. But I admit that it is a dup
of EVB mostly. 

> > Philipp: do you think it's acceptable that this is done as follow-up patches?
> 
> Just rewrite the README to point it to the one in the EVB-directory and this can go in with the
> next batch of patches...

Cool. Then I will modify the instructions and push out as an incremental
patchset once this series gets in.

Thanks,
Mani

> 
> > Thanks!
> > Eze
>