On Fri, Aug 31, 2018 at 09:27:25AM -0300, Ezequiel Garcia wrote: > On 31 August 2018 at 09:24, Manivannan Sadhasivam > <manivannan.sadhasi...@linaro.org> wrote: > > On Fri, Aug 31, 2018 at 09:08:08AM -0300, Ezequiel Garcia wrote: > >> On 31 August 2018 at 07:56, Peter Robinson <pbrobin...@gmail.com> wrote: > >> >> On Thu, Aug 30, 2018 at 12:44:00AM -0300, Ezequiel Garcia wrote: > >> >> > On 30 August 2018 at 00:00, Manivannan Sadhasivam > >> >> > <manivannan.sadhasi...@linaro.org> wrote: > >> >> > > Hi Ezequiel, > >> >> > > > >> >> > > On Wed, Aug 29, 2018 at 03:11:17AM -0300, Ezequiel Garcia wrote: > >> >> > >> Hi Manivannan, > >> >> > >> > >> >> > >> On 21 August 2018 at 14:09, Manivannan Sadhasivam > >> >> > >> <manivannan.sadhasi...@linaro.org> wrote: > >> >> > >> > This patchset adds board support for Vamrs Limited Rock960, > >> >> > >> > which is one of the 96Boards Consumer Edition platform based > >> >> > >> > on Rockchip RK3399 SoC. > >> >> > >> > > >> >> > >> > >> >> > >> What are the differences between this consumer edition board, > >> >> > >> and the enterprise edition (aka Ficus) Vamrs board? > >> >> > >> > >> >> > > > >> >> > > I asked Vamrs about this and they said the difference is very > >> >> > > minimal. > >> >> > > > >> >> > > >> >> > In that case, you should try to leverage the Linux ficus.dts: > >> >> > > >> >> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts > >> >> > > >> >> > If no differences, using the ficus dts should do. If there are > >> >> > differences, > >> >> > we can create a common rock960.dtsi and then enterprise and consumer > >> >> > edition dts. > >> >> > > >> >> > >> >> Okay. Here are the differences between Ficus and Rock960 CE: > >> >> > >> >> 1. Different host enable GPIO for USB (vcc5v0_host) > >> >> 2. Different power and reset for PCI-E (vcc3v3_pcie, pcie0) > >> >> 3. No Ethernet port on Rock960 (gmac) > >> >> > >> >> So, I would suggest keeping USB, PCI-E and GMAC related nodes on the > >> >> board > >> >> specific devicetree and rest on the rk3399-rock960.dtsi. What do you > >> >> think? > >> >> > >> >> Same applies to Linux also! > >> > > >> > >> Sounds good. If you have some cycles to work on the dts/dtsi split, > >> that would be great. > >> > > > > Sure, will do it for Linux now. Once your u-boot patches gets in, > > will tackle it also. > > > > Well, I think we can tackle u-boot from scratch. No need to > merge my patches if we think they are already wrong :-) >
Makes sense! > >> > Yes, I think a rk3399-rock960.dtsi with the differences in two .dts > >> > would be great, and even better a single U-Boot which can detect the > >> > board and load the right DT, but I do think it should be a separate > >> > config to evb as Mani mentioned. > >> > > > > > Thanks Peter for your thoughts! > > > >> > >> Sounds good too. That'd make board-specific hooks easier. > >> > >> On the other side, the documentation should be > >> merged somewhere. > >> > >> Seems nonsense to have a README per board, > >> with more or less the same instructions each time. > >> > > > > This has other side as well. If we continue to merge board specific > > instructions onto evb-rk3399, it will become messy. So, IMO it's better > > to have it separate. If you have other ideas, please let me know. > > > > Bootloader wise, there is no such thing as board specific instructions, is it? Yeah, but I'm thinking about the overhead of having a common doc for boards which might come in future (like Rock960c have an optional eMMC module). Even in Rock960 CE, we need to specify the load address for u-boot while preparing the uboot.img (not sure why it is required)... I'm kind of skeptical here. Peter, any thoughts? > -- > Ezequiel GarcĂa, VanguardiaSur > www.vanguardiasur.com.ar _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot