[PATCH v1 00/15] add basic driver support for broadcom NS3 soc

From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc
Date: Mon, 8 Jun 2020 11:12:42 -0600	[thread overview]
Message-ID: <CAPnjgZ2bek9j5GOkrY6uCmbR6wzNHSp3jk_rvtVS5XWBVyjP3w@mail.gmail.com> (raw)
In-Reply-To: <CAHO=5PHC4n8w+-4C4S1wC88sGoS5Zu6W11bRMk_v1C7pdP159Q@mail.gmail.com>

Hi Rayagonda,

On Mon, 8 Jun 2020 at 11:03, Rayagonda Kokatanur
<rayagonda.kokatanur@broadcom.com> wrote:
>
> Hi Simon,
>
> On Thu, Jun 4, 2020 at 8:30 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Rayagonda,
> >
> > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> > <rayagonda.kokatanur@broadcom.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Rayagonda,
> > > >
> > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > > <rayagonda.kokatanur@broadcom.com> wrote:
> > > > >
> > > > > Hi Thomas,
> > > > >
> > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> > > > > >
> > > > > > Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> writes:
> > > > > >
> > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > >>
> > > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> > > > > > >> > Hi Tom,
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini <trini@konsulko.com> wrote:
> > > > > > >> > >
> > > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> > > > > > >> > >
> > > > > > >> > > > This is the second patch set series prepared on top of the
> > > > > > >> > > > first patch set ("add initial support for broadcom NS3 soc").
> > > > > > >> > > >
> > > > > > >> > > > This patch set will add following,
> > > > > > >> > > > -dt nodes and defconfig options for basic device like pinctrl,
> > > > > > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > > > > >> > > > -start wdt service
> > > > > > >> > > > -Enable GPT commands
> > > > > > >> > > > -Enable EXT4 and FAT fs support
> > > > > > >> > >
> > > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either come from
> > > > > > >> > > mainline Linux or at least linux-next and have had some level upstream
> > > > > > >> > > review, right?  Thanks!
> > > > > > >> >
> > > > > > >> > Yes. All the DTS changes are merged in the Linux and are available at
> > > > > > >> > arch/arm64/boot/dts/broadcom/stingray/
> > > > > > >>
> > > > > > >> Great.  Please reference the release you're taking these from as that
> > > > > > >> will make future resyncs easier.  Thanks!
> > > > > > >
> > > > > > > It's Linux v5.6.
> > > > > >
> > > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > > > > > looked at the mainline Linux device trees and I couldn't easily see the
> > > > > > correspondence.  Will the renaming complicate synchronization?
> > > > >
> > > > > Do we need to maintain the same dt file between linux and uboot ?
> > > > > Also in uboot we don't enable all devices,  how do we handle this ?
> > > >
> > > > If there is no U-Boot driver for a particular node then it will be
> > > > ignored. It is easier to keep them in sync if they are the same in
> > > > U-Boot and Linux.
> > > >
> > > > > Please let me know.
> > > >
> > > > That is implied by your question above :-)
> > >
> > > NS3 board is derivative of the existing bcm95874t board
> > > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> > > Hence we have different dt for NS3 in Linux but it is not yet upstremed.
> > >
> > > I compared the dt file size between uboot and Linux.
> > > Uboot dt size = 9K
> > > Linux dt size  = 41K (32K extra)
> > >
> > > In uboot we have 8MB non-volatile SPI flash memory.
> > > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> > > space is allocated to other components
> > > like nitor/bnxt firmware image, DDR shmoo value and for backup image.
> > >
> > > uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> > > will use extra 33K memory of allocated 1.5MB.
> > > This increase in 33K will reduce total memory availability for u-boot
> > > and other features (like ARM trusted firmware, Op-TEE OS) development
> > > in future.
> > > Hence we anticipate qpsi memory shortage going ahead for new features.
> > >
> > > So please let me know your view on maintaining different dt files in uboot.
> >
> > Sounds like you have plenty of memory, actually. Is U-Boot the first
> > thing to load?
> >
> > I think it is important to use the same filename and have the same DT
> > contents where they are present in U-Boot. But if you want to leave
> > out nodes, etc., that seems OK to me. It should be easy enough to meld
> > in the updates later.
> >
> > I wonder if we should add a way to drop unused nodes for U-Boot
> > proper, like we do for SPL?
>
> Thank you for your suggestion.
>
> Right now linux dt files are not upstremed.
> Upstreaming linux dt files first and then using the same in uboot will

U-Boot

> delay these uboot patch merge.
> Hence I am planning to do following,
> 1. Use one sample dt file with just few basic nodes so that uboot can
> be built without any issues.
> 2. Parallely start linux dt file upstream.
> 3. Once the linux dt file gets merged, I will pull them into uboot and
> submit a patch.
>
> Please let me know.

That sounds fine to me.

Regards,
Simon