| Message ID | 20190508054151.21762-1-jagan@amarulasolutions.com |
|---|---|
| Headers |
Return-Path: <linux-amarula+bncBD7MFH7A7EEBBLGYZHTAKGQEPASI6KI@amarulasolutions.com> X-Original-To: linux-amarula@patchwork.amarulasolutions.com Delivered-To: linux-amarula@patchwork.amarulasolutions.com Received: from mail-it1-f199.google.com (mail-it1-f199.google.com [209.85.166.199]) by ganimede.amarulasolutions.com (Postfix) with ESMTPS id 75CC83F069 for <linux-amarula@patchwork.amarulasolutions.com>; Wed, 8 May 2019 07:42:06 +0200 (CEST) Received: by mail-it1-f199.google.com with SMTP id v7sf1268539itf.8 for <linux-amarula@patchwork.amarulasolutions.com>; Tue, 07 May 2019 22:42:06 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1557294125; cv=pass; d=google.com; s=arc-20160816; b=HNA/10fmcXR0Uh29k8xwEoNC80I/6vRJgNcIk//rlVhE64s1RoDryrIwQJ05ZlwXc5 VefVxKZqWyIl0pBNvrTGXQqk+j1wv4uYdDH1DjmjA8sainQ/rQBj8VWeztkdV91TG5ug rjPeVcxGSUdVQ/qElsZT2sNaMcg3tKTjHFaZdG8how3WKcaNhpiXIn6KhmiwuHCO1b1t 9RXodXfmxOPjStjaEgPxocYQFWse0z+PE3FQrxBiU4aq3mT+cCPnvm2vu33GVjaGI8J0 sZALUfW4IjeSEaMXYLqIapzNQDyVm3o/kr9jRyFm05TB3/BIhMIIKzDomV0Db3nOhMON rP8A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-archive:list-help:list-post:list-id :mailing-list:precedence:mime-version:message-id:date:subject:cc:to :from:dkim-signature; bh=npIeC7rdcVnNtfhzBqjt4bak6a+KyF1Ob8sgkrSzakM=; b=tf5ZoYEB9227Jvz+dNlCikdFk2gdTAFKVLbNpP+yL/tiQMCikgRyWBt4+78nyl+ZQC UPKMYpSpdND9fJiDV60dl/4WP4zF5RqdM75BNbRZ16Q+N9x3PkwNz/vAcwzjs/itxPlF gk4zZrIuG+1KLV+3GrgcOalosr9z1f5iAFVB+OHS4NISe7ymtZW553ukiMkBe3jl6I8w 2WtcjqXgdV3oIiNkCkknuzxK9lt9LCYaksH9213m9OuvQZYP+7UrSomM89arWUg4kRa9 RSoEYrEF+ChN49unlDyr9wryuIDlFfiYvZZ3hswIcXi0+BYOt060wKwBGWR7sDst7dWB skYw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b="ldyn6//L"; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=from:to:cc:subject:date:message-id:mime-version:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-unsubscribe; bh=npIeC7rdcVnNtfhzBqjt4bak6a+KyF1Ob8sgkrSzakM=; b=JLXowitJvOVmanTYdch/xTsQmfA5mRZLO/cITQnMZ22U/NgzlMyLmKq/wnKOPeeVeK R0xGdmb32fKEikIEg/ks6tG6qcpNmjp60A1FUlRb2LfreVzDNPgJJr7Bp9/vSH4BYNg2 S1wwaX3zSu1T8QsDzzJia9NruDNvkeMgE16TQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :x-original-sender:x-original-authentication-results:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-unsubscribe; bh=npIeC7rdcVnNtfhzBqjt4bak6a+KyF1Ob8sgkrSzakM=; b=hKKxCgxhxTDt/9V3atQiegLLNVIebKFbtVYZ5dYUlQZ3LCiKpYCyekdbnT4WURCbG+ cBkVUDPsUFy74I1sV74VAQEAe71imuFrQ/C8rutpn0Ojo9NxP0C+UZKmEdSZp3w2buSO 38L/yo5yN6cqhxlkZ666n2lZDrsx6D8Uo9Gtls16GJzrCfkoishIto/uWIw5zPDOH3DL 783gXwj1SCrXTluJmbX+0CVpY+/BXf3pCXJO1KY4GEgvHd4i2Znrq2qQQ55NegQWOjqR SlRZ8xeNkFxVScUQLLUBA1y2uQobVQdGy/ZC3ij1KRqyYep81mvR+gAuS9kGjH0dJ3Pk et5g== X-Gm-Message-State: APjAAAUadGtaEPdmGa9OZTL+nGaFKwucYYHDfQr0Xyt5VV5TP2P8+xRs ErWZsVo2Sj80HZ8bicCAGR0BkvjJ X-Google-Smtp-Source: APXvYqzyvBl9BGgSfN29DAMhMfdZ8udu7vIiugOkyuygTB4YcIPpY/PChMNtLEK3EZcP30tIaXw30Q== X-Received: by 2002:a24:eecf:: with SMTP id b198mr2178026iti.47.1557294124663; Tue, 07 May 2019 22:42:04 -0700 (PDT) X-BeenThere: linux-amarula@amarulasolutions.com Received: by 2002:a02:c6d8:: with SMTP id r24ls1606179jan.1.gmail; Tue, 07 May 2019 22:42:04 -0700 (PDT) X-Received: by 2002:a02:62ce:: with SMTP id d197mr26399917jac.91.1557294124121; Tue, 07 May 2019 22:42:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557294124; cv=none; d=google.com; s=arc-20160816; b=FJr6zFPx6nWEJi5/H8kOmCgMEqcjrVfqg5aGnoP4TBvl6UFvtvXDvOa8stzEi4hYnD 8inzsDIQlfN2Jjots+HlQ0zeSCbj7K0SLDJ1M4ZX0esi0ocliII8z9zYHvP3VHgCNz/3 ULo+e3JFFQk/yXZF2/t/POQPVraiNgwuiZ88hW/G7nbJJiP1lJJekdAn/lcGIp9qcQcO awE+Gz1QTosyYe4ulwOIQKbi+NPj3MVyxiXNmdFphpB6HYZbMi23Wpg5EU9vpYmGRtsd kuLXkWU2YGfNXfLyKDePN1ohh2f2FhR2cNd/ucom5WKEf/L+40xsDpXEkGqVtkBi3ZVG s4rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:dkim-signature; bh=ESk1Nic+SQTtbzkbO4ctb5tA7ij0E48GBmc6W9QxJDs=; b=LaySWwxN918CvI/mKxEjMjPsrRXLhwMAyDq/ib3jGWGgdUeuzOLwEh8la2zx9jfYry BKhyNsYlHFzeZD4FxSCVKLfH+J8kZXSpqpMCiIba4kX0KaQBM5VKaORBPzvROWKLoGL1 fmVKwfNtp2iX6/ICHQbjJT51gFqNe0P42Ru3u2HSMZLaZL+Lwx81xadSm+fIT9IQfg7S nRcE55rrJQpCx0Aq3x9z8yeb0xjjpa1VPR4+N8k6Gw3k7EN21s+Wzz8nbAe8sBDz0S/+ ccDuyGn72thtPWe8Tvl07dRIJlMR7n69HVbMjQi+podYtTcOfLsxCHojn1hOczJgOGIi 0leg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b="ldyn6//L"; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id a11sor1591380itg.31.2019.05.07.22.42.03 for <linux-amarula@amarulasolutions.com> (Google Transport Security); Tue, 07 May 2019 22:42:03 -0700 (PDT) Received-SPF: pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a17:902:567:: with SMTP id 94mr44019986plf.120.1557294122444; Tue, 07 May 2019 22:42:02 -0700 (PDT) Received: from localhost.localdomain ([115.97.185.144]) by smtp.gmail.com with ESMTPSA id p67sm33864394pfi.123.2019.05.07.22.41.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 22:42:01 -0700 (PDT) From: Jagan Teki <jagan@amarulasolutions.com> To: Simon Glass <sjg@chromium.org>, Philipp Tomsich <philipp.tomsich@theobroma-systems.com>, Kever Yang <kever.yang@rock-chips.com>, Akash Gajjar <akash@openedev.com> Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>, linux-rockchip@lists.infradead.org, linux-amarula@amarulasolutions.com, u-boot@lists.denx.de, Jagan Teki <jagan@amarulasolutions.com> Subject: [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards Date: Wed, 8 May 2019 11:11:40 +0530 Message-Id: <20190508054151.21762-1-jagan@amarulasolutions.com> X-Mailer: git-send-email 2.18.0.321.gffc6fa0e3 MIME-Version: 1.0 X-Original-Sender: jagan@amarulasolutions.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b="ldyn6//L"; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com Content-Type: text/plain; charset="UTF-8" Precedence: list Mailing-list: list linux-amarula@amarulasolutions.com; contact linux-amarula+owners@amarulasolutions.com List-ID: <linux-amarula.amarulasolutions.com> X-Spam-Checked-In-Group: linux-amarula@amarulasolutions.com X-Google-Group-Id: 476853432473 List-Post: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/post>, <mailto:linux-amarula@amarulasolutions.com> List-Help: <https://support.google.com/a/amarulasolutions.com/bin/topic.py?topic=25838>, <mailto:linux-amarula+help@amarulasolutions.com> List-Archive: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/> List-Unsubscribe: <mailto:googlegroups-manage+476853432473+unsubscribe@googlegroups.com>, <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/subscribe> |
| Series |
rockchip: Add new rk3399 boards
|
|
Message
Jagan Teki
May 8, 2019, 5:41 a.m. UTC
(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. For booting the same with SPL NEO4 would require dynamic dram timing detection and rest require LPDDR4 code. There is WIP[2] for these dependencies and this would require big chunk of changes will effect all the rk3399 boards, so I'm planning to mark it for next MW. Changes for v7: - rebase on top of u-boot-rockchip/master - add SPL_TEXT_BASE on each board defconfig - rebase on required changes Changes for v6: - Include Nanopc T4 support patch - drop rk3399-u-boot.dtsi patch since it is send separately. Changes for v5: - Make all changes related to move sdmmc, spi1 u-boot,dm-pre-reloc properties into all rk3399 dts(i) files. Changes for v4: - don't include existing dts(i) sdmmc, u-boot,dm-pre-reloc into rk3399-u-boot.dtsi Changes for v3: - drop NanoPC T4 for now, since board is yet to receive. - add Rock PI-4 board. - add separate -u-boot.dtsi file for nanopi4 sdram changes. - collect Paul, Philipp and Kever Reviewed-by tags Travis-CI: https://travis-ci.org/openedev/u-boot-amarula/builds/529284236 [1] https://patchwork.ozlabs.org/cover/1096473/ [2] https://github.com/amarula/u-boot-amarula/tree/rockdev-lpddr4 [3] https://patchwork.ozlabs.org/cover/1091909/ Any inputs? Jagan. Jagan Teki (11): rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2 Kconfig: Add default SPL_FIT_GENERATOR for rockchip arm: rockchip: rk3399: Move common configs in Kconfig rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux rockchip: dts: rk3399: nanopi4: Use CD pin as RK_FUNC_1 rockchip: rk3399: Add Nanopi M4 board support rockchip: rk3399: Add Nanopc T4 board support rockchip: rk3399: Add Nanopi NEO4 board support rockchip: rk3399: Add Rockpro64 board support rockchip: rk3399: Add Rock PI 4 support doc: rockchip: Add global doc for rk3399 build/flash Kconfig | 1 + arch/arm/dts/Makefile | 5 + arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi | 7 + arch/arm/dts/rk3399-nanopc-t4.dts | 91 +++ arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi | 7 + arch/arm/dts/rk3399-nanopi-m4.dts | 66 ++ arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi | 6 + arch/arm/dts/rk3399-nanopi-neo4.dts | 50 ++ arch/arm/dts/rk3399-nanopi4-u-boot.dtsi | 11 + arch/arm/dts/rk3399-nanopi4.dtsi | 703 +++++++++++++++++++ arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi | 6 + arch/arm/dts/rk3399-rock-pi-4.dts | 606 +++++++++++++++++ arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 6 + arch/arm/dts/rk3399-rockpro64.dts | 712 ++++++++++++++++++++ arch/arm/dts/rk3399.dtsi | 5 + arch/arm/mach-rockchip/Kconfig | 16 + board/rockchip/evb_rk3399/MAINTAINERS | 32 + configs/chromebook_bob_defconfig | 17 - configs/evb-rk3399_defconfig | 17 - configs/ficus-rk3399_defconfig | 17 - configs/firefly-rk3399_defconfig | 17 - configs/nanopc-t4-rk3399_defconfig | 59 ++ configs/nanopi-m4-rk3399_defconfig | 59 ++ configs/nanopi-neo4-rk3399_defconfig | 59 ++ configs/orangepi-rk3399_defconfig | 17 - configs/puma-rk3399_defconfig | 16 - configs/rock-pi-4-rk3399_defconfig | 59 ++ configs/rock960-rk3399_defconfig | 17 - configs/rockpro64-rk3399_defconfig | 59 ++ doc/README.rockchip | 233 ++++++- 30 files changed, 2857 insertions(+), 119 deletions(-) create mode 100644 arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi create mode 100644 arch/arm/dts/rk3399-nanopc-t4.dts create mode 100644 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi create mode 100644 arch/arm/dts/rk3399-nanopi-m4.dts create mode 100644 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi create mode 100644 arch/arm/dts/rk3399-nanopi-neo4.dts create mode 100644 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi create mode 100644 arch/arm/dts/rk3399-nanopi4.dtsi create mode 100644 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi create mode 100644 arch/arm/dts/rk3399-rock-pi-4.dts create mode 100644 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi create mode 100644 arch/arm/dts/rk3399-rockpro64.dts create mode 100644 configs/nanopc-t4-rk3399_defconfig create mode 100644 configs/nanopi-m4-rk3399_defconfig create mode 100644 configs/nanopi-neo4-rk3399_defconfig create mode 100644 configs/rock-pi-4-rk3399_defconfig create mode 100644 configs/rockpro64-rk3399_defconfig
Comments
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. Cheers, Paul > For booting the same with SPL NEO4 would require dynamic dram timing > detection and rest require LPDDR4 code. There is WIP[2] for these > dependencies and this would require big chunk of changes will effect > all the rk3399 boards, so I'm planning to mark it for next MW. > > Changes for v7: > - rebase on top of u-boot-rockchip/master > - add SPL_TEXT_BASE on each board defconfig > - rebase on required changes > Changes for v6: > - Include Nanopc T4 support patch > - drop rk3399-u-boot.dtsi patch since it is send separately. > Changes for v5: > - Make all changes related to move sdmmc, spi1 u-boot,dm-pre-reloc > properties into all rk3399 dts(i) files. > Changes for v4: > - don't include existing dts(i) sdmmc, u-boot,dm-pre-reloc into > rk3399-u-boot.dtsi > Changes for v3: > - drop NanoPC T4 for now, since board is yet to receive. > - add Rock PI-4 board. > - add separate -u-boot.dtsi file for nanopi4 sdram changes. > - collect Paul, Philipp and Kever Reviewed-by tags > > Travis-CI: > https://travis-ci.org/openedev/u-boot-amarula/builds/529284236 > > [1] https://patchwork.ozlabs.org/cover/1096473/ > [2] https://github.com/amarula/u-boot-amarula/tree/rockdev-lpddr4 > [3] https://patchwork.ozlabs.org/cover/1091909/ > > Any inputs? > Jagan. > > Jagan Teki (11): > rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2 > Kconfig: Add default SPL_FIT_GENERATOR for rockchip > arm: rockchip: rk3399: Move common configs in Kconfig > rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux > rockchip: dts: rk3399: nanopi4: Use CD pin as RK_FUNC_1 > rockchip: rk3399: Add Nanopi M4 board support > rockchip: rk3399: Add Nanopc T4 board support > rockchip: rk3399: Add Nanopi NEO4 board support > rockchip: rk3399: Add Rockpro64 board support > rockchip: rk3399: Add Rock PI 4 support > doc: rockchip: Add global doc for rk3399 build/flash > > Kconfig | 1 + > arch/arm/dts/Makefile | 5 + > arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi | 7 + > arch/arm/dts/rk3399-nanopc-t4.dts | 91 +++ > arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi | 7 + > arch/arm/dts/rk3399-nanopi-m4.dts | 66 ++ > arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi | 6 + > arch/arm/dts/rk3399-nanopi-neo4.dts | 50 ++ > arch/arm/dts/rk3399-nanopi4-u-boot.dtsi | 11 + > arch/arm/dts/rk3399-nanopi4.dtsi | 703 +++++++++++++++++++ > arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi | 6 + > arch/arm/dts/rk3399-rock-pi-4.dts | 606 +++++++++++++++++ > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 6 + > arch/arm/dts/rk3399-rockpro64.dts | 712 ++++++++++++++++++++ > arch/arm/dts/rk3399.dtsi | 5 + > arch/arm/mach-rockchip/Kconfig | 16 + > board/rockchip/evb_rk3399/MAINTAINERS | 32 + > configs/chromebook_bob_defconfig | 17 - > configs/evb-rk3399_defconfig | 17 - > configs/ficus-rk3399_defconfig | 17 - > configs/firefly-rk3399_defconfig | 17 - > configs/nanopc-t4-rk3399_defconfig | 59 ++ > configs/nanopi-m4-rk3399_defconfig | 59 ++ > configs/nanopi-neo4-rk3399_defconfig | 59 ++ > configs/orangepi-rk3399_defconfig | 17 - > configs/puma-rk3399_defconfig | 16 - > configs/rock-pi-4-rk3399_defconfig | 59 ++ > configs/rock960-rk3399_defconfig | 17 - > configs/rockpro64-rk3399_defconfig | 59 ++ > doc/README.rockchip | 233 ++++++- > 30 files changed, 2857 insertions(+), 119 deletions(-) > create mode 100644 arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3399-nanopc-t4.dts > create mode 100644 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3399-nanopi-m4.dts > create mode 100644 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3399-nanopi-neo4.dts > create mode 100644 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3399-nanopi4.dtsi > create mode 100644 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3399-rock-pi-4.dts > create mode 100644 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3399-rockpro64.dts > create mode 100644 configs/nanopc-t4-rk3399_defconfig > create mode 100644 configs/nanopi-m4-rk3399_defconfig > create mode 100644 configs/nanopi-neo4-rk3399_defconfig > create mode 100644 configs/rock-pi-4-rk3399_defconfig > create mode 100644 configs/rockpro64-rk3399_defconfig >
Hi Paul, On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski <paul.kocialkowski@bootlin.com> 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. 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. 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. [1] https://patchwork.ozlabs.org/cover/1086213/
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@bootlin.com> 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? Cheers, Paul
On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski <paul.kocialkowski@bootlin.com> 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@bootlin.com> 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. Jagan.
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@bootlin.com> 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@bootlin.com> 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
Jagan, > On 09.05.2019, at 14:36, Jagan Teki <jagan@amarulasolutions.com> wrote: > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > <paul.kocialkowski@bootlin.com <mailto:paul.kocialkowski@bootlin.com>> 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@bootlin.com> 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. 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. Thanks, Philipp.
On Thu, May 9, 2019 at 6:09 PM Paul Kocialkowski <paul.kocialkowski@bootlin.com> wrote: > > 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@bootlin.com> 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@bootlin.com> 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? Exactly, to make it confirm. Here is boot-chain on NEO4: ------------------------------------ DDR Version 1.20 20190314 In Channel 0: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB no stride ch 0 ddrconfig = 0x101, ddrsize = 0x20 pmugrf_os_reg[2] = 0x10006281, stride = 0x17 OUT U-Boot SPL 2019.07-rc1-00243-gbd57cc7444 (May 09 2019 - 18:10:25 +0530) Trying to boot from MMC1 U-Boot 2019.07-rc1-00243-gbd57cc7444 (May 09 2019 - 18:12:59 +0530) Model: FriendlyARM NanoPi NEO4
Hi, On Thu, 2019-05-09 at 14:40 +0200, Philipp Tomsich wrote: > Jagan, > > > On 09.05.2019, at 14:36, Jagan Teki <jagan@amarulasolutions.com> wrote: > > > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > > <paul.kocialkowski@bootlin.com> 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@bootlin.com> 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. > > 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. Well, my initial point was to forbid merging broken SPL support, but I am totally in favor of requiring free DRAM init for merging new boards. Sadly it's hard to enforce this as a general rule in U-Boot since some platforms are plagued by non-free first-stage bootloaders because of signature checks, and that's where DRAM init happens. But for RK3399, we can totally have that rule, which directly creates incentive to free the blobs. Cheers, Paul
Hi Philipp, On Thu, May 9, 2019 at 6:10 PM Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote: > > Jagan, > > On 09.05.2019, at 14:36, Jagan Teki <jagan@amarulasolutions.com> wrote: > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > <paul.kocialkowski@bootlin.com> 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@bootlin.com> 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. > > > 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). True, my suggestion here the same. SPL is mandatory. > > 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. True, I agree this point. Since we have an option of having DRAM init at TPL I'm proposing this boot-chain (along with commitment on dram work).