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

2020-06-08 Thread Rayagonda Kokatanur
On Mon, Jun 8, 2020 at 10:43 PM Simon Glass  wrote:
>
> Hi Rayagonda,
>
> On Mon, 8 Jun 2020 at 11:03, Rayagonda Kokatanur
>  wrote:
> >
> > Hi Simon,
> >
> > On Thu, Jun 4, 2020 at 8:30 AM Simon Glass  wrote:
> > >
> > > Hi Rayagonda,
> > >
> > > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> > >  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:
> > > > >
> > > > > Hi Rayagonda,
> > > > >
> > > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > > >  wrote:
> > > > > >
> > > > > > Hi Thomas,
> > > > > >
> > > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons 
> > > > > >  wrote:
> > > > > > >
> > > > > > > Rayagonda Kokatanur  writes:
> > > > > > >
> > > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini  
> > > > > > > > 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 
> > > > > > > >> >  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.
> > 

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

2020-06-08 Thread Simon Glass
Hi Rayagonda,

On Mon, 8 Jun 2020 at 11:03, Rayagonda Kokatanur
 wrote:
>
> Hi Simon,
>
> On Thu, Jun 4, 2020 at 8:30 AM Simon Glass  wrote:
> >
> > Hi Rayagonda,
> >
> > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> >  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:
> > > >
> > > > Hi Rayagonda,
> > > >
> > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > >  wrote:
> > > > >
> > > > > Hi Thomas,
> > > > >
> > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons 
> > > > >  wrote:
> > > > > >
> > > > > > Rayagonda Kokatanur  writes:
> > > > > >
> > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini  
> > > > > > > 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  
> > > > > > >> > 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 

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

2020-06-08 Thread Rayagonda Kokatanur
Hi Simon,

On Thu, Jun 4, 2020 at 8:30 AM Simon Glass  wrote:
>
> Hi Rayagonda,
>
> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
>  wrote:
> >
> > Hi Simon,
> >
> > On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:
> > >
> > > Hi Rayagonda,
> > >
> > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > >  wrote:
> > > >
> > > > Hi Thomas,
> > > >
> > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons 
> > > >  wrote:
> > > > >
> > > > > Rayagonda Kokatanur  writes:
> > > > >
> > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini  
> > > > > > 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  
> > > > > >> > 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
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.

Best regards,
Rayagonda


>
> Regards,
> Simon


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

2020-06-07 Thread dphadke
USB host node is missing from this patch series.

Driver was previously added here -
https://lists.denx.de/pipermail/u-boot/2020-April/405764.html

Linux arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi

Regards,
Dhananjay




--
Sent from: http://u-boot.10912.n7.nabble.com/


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

2020-06-05 Thread Walter Lozano

Hi Tom.

On 5/6/20 15:22, Tom Rini wrote:

On Fri, Jun 05, 2020 at 12:47:10PM -0300, Walter Lozano wrote:

Hi Tom,

On 5/6/20 12:05, Tom Rini wrote:

On Fri, Jun 05, 2020 at 11:36:57AM +0200, Soeren Moch wrote:

On 04.06.20 05:16, Tom Rini wrote:

On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:

Hi Rayagonda,

On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
 wrote:

Hi Simon,

On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:

Hi Rayagonda,

On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
 wrote:

Hi Thomas,

On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons  wrote:

Rayagonda Kokatanur  writes:


On Tue, May 19, 2020 at 11:01 PM Tom Rini  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  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?

We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
trim things down for tbs2910.


For tbs2910 we remove some properties, not whole nodes, from the dtb. Is
it possible to also remove complete nodes? This would help even more for
size reduction, I think.

Ah, that I think not.  Another idea to keep in mind for the dtoc
enhancements perhaps?  There is very much a use case of having a dtb (or
set of dtbs) and a U-Boot (full or SPL) and not needing/wanting to pass
our DTB on to the OS so both discarding things from the DTB and from
U-Boot based on this knowledge would be great.


This enhancement sounds more to extend the current u-boot.dtsi feature, to
include just specific nodes in the dtb, which currently works for SPL. A
first step towards this direction could be to add a configuration option to
use the same DTB forĀ  both SPL and U-Boot, which would be a reduced version
if the proper u-boot.dtsi is found.

What do you think?

I think there's another RFC patch that dropped a ton of not-needed nodes
via the -u-boot.dtsi file but that's also less than ideal since it's
manual.

I see, thanks for clarifying.

Regarding dtoc, currently is used to parse dtb and to convert this info to C
structures, which doesn't seems to be the desired goal here.

So, what made me think of dtoc is that we aren't so much tied to device
trees because we want device trees, but rather we're tied to device
trees because that's the common format for describing 

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

2020-06-05 Thread Tom Rini
On Fri, Jun 05, 2020 at 12:47:10PM -0300, Walter Lozano wrote:
> Hi Tom,
> 
> On 5/6/20 12:05, Tom Rini wrote:
> > On Fri, Jun 05, 2020 at 11:36:57AM +0200, Soeren Moch wrote:
> > > On 04.06.20 05:16, Tom Rini wrote:
> > > > On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:
> > > > > Hi Rayagonda,
> > > > > 
> > > > > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> > > > >  wrote:
> > > > > > Hi Simon,
> > > > > > 
> > > > > > On Wed, May 20, 2020 at 7:50 PM Simon Glass  
> > > > > > wrote:
> > > > > > > Hi Rayagonda,
> > > > > > > 
> > > > > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > > > > >  wrote:
> > > > > > > > Hi Thomas,
> > > > > > > > 
> > > > > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons 
> > > > > > > >  wrote:
> > > > > > > > > Rayagonda Kokatanur  writes:
> > > > > > > > > 
> > > > > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini 
> > > > > > > > > >  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 
> > > > > > > > > > > >  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 

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

2020-06-05 Thread Walter Lozano

Hi Tom,

On 5/6/20 12:05, Tom Rini wrote:

On Fri, Jun 05, 2020 at 11:36:57AM +0200, Soeren Moch wrote:

On 04.06.20 05:16, Tom Rini wrote:

On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:

Hi Rayagonda,

On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
 wrote:

Hi Simon,

On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:

Hi Rayagonda,

On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
 wrote:

Hi Thomas,

On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons  wrote:

Rayagonda Kokatanur  writes:


On Tue, May 19, 2020 at 11:01 PM Tom Rini  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  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?

We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
trim things down for tbs2910.


For tbs2910 we remove some properties, not whole nodes, from the dtb. Is
it possible to also remove complete nodes? This would help even more for
size reduction, I think.

Ah, that I think not.  Another idea to keep in mind for the dtoc
enhancements perhaps?  There is very much a use case of having a dtb (or
set of dtbs) and a U-Boot (full or SPL) and not needing/wanting to pass
our DTB on to the OS so both discarding things from the DTB and from
U-Boot based on this knowledge would be great.

This enhancement sounds more to extend the current u-boot.dtsi feature, 
to include just specific nodes in the dtb, which currently works for 
SPL. A first step towards this direction could be to add a configuration 
option to use the same DTB forĀ  both SPL and U-Boot, which would be a 
reduced version if the proper u-boot.dtsi is found.


What do you think?

Regarding dtoc, currently is used to parse dtb and to convert this info 
to C structures, which doesn't seems to be the desired goal here.


Regards,

Walter



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

2020-06-05 Thread Tom Rini
On Fri, Jun 05, 2020 at 11:36:57AM +0200, Soeren Moch wrote:
> On 04.06.20 05:16, Tom Rini wrote:
> > On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:
> >> Hi Rayagonda,
> >>
> >> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> >>  wrote:
> >>>
> >>> Hi Simon,
> >>>
> >>> On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:
> 
>  Hi Rayagonda,
> 
>  On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
>   wrote:
> >
> > Hi Thomas,
> >
> > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons 
> >  wrote:
> >>
> >> Rayagonda Kokatanur  writes:
> >>
> >>> On Tue, May 19, 2020 at 11:01 PM Tom Rini  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  
> > 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?
> >
> > We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
> > trim things down for tbs2910.
> >
> For tbs2910 we remove some properties, not whole nodes, from the dtb. Is
> it possible to also remove complete nodes? This would help even more for
> size reduction, I think.

Ah, that I think not.  Another idea to keep in mind for the dtoc
enhancements perhaps?  There is very much a use case of having a dtb (or
set of dtbs) and a U-Boot (full or SPL) and not needing/wanting to pass
our DTB on to the OS so both discarding things from the DTB and from
U-Boot based on this knowledge would be great.

-- 
Tom


signature.asc
Description: PGP signature


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

2020-06-05 Thread Soeren Moch
On 04.06.20 05:16, Tom Rini wrote:
> On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:
>> Hi Rayagonda,
>>
>> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
>>  wrote:
>>>
>>> Hi Simon,
>>>
>>> On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:

 Hi Rayagonda,

 On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
  wrote:
>
> Hi Thomas,
>
> On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons  
> wrote:
>>
>> Rayagonda Kokatanur  writes:
>>
>>> On Tue, May 19, 2020 at 11:01 PM Tom Rini  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  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?
>
> We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
> trim things down for tbs2910.
>
For tbs2910 we remove some properties, not whole nodes, from the dtb. Is
it possible to also remove complete nodes? This would help even more for
size reduction, I think.

Soeren


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

2020-06-03 Thread Tom Rini
On Wed, Jun 03, 2020 at 08:59:58PM -0600, Simon Glass wrote:
> Hi Rayagonda,
> 
> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
>  wrote:
> >
> > Hi Simon,
> >
> > On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:
> > >
> > > Hi Rayagonda,
> > >
> > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > >  wrote:
> > > >
> > > > Hi Thomas,
> > > >
> > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons 
> > > >  wrote:
> > > > >
> > > > > Rayagonda Kokatanur  writes:
> > > > >
> > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini  
> > > > > > 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  
> > > > > >> > 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?

We have that for a little while now, OF_DTB_PROPS_REMOVE, from trying to
trim things down for tbs2910.

-- 
Tom


signature.asc
Description: PGP signature


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

2020-06-03 Thread Simon Glass
Hi Rayagonda,

On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
 wrote:
>
> Hi Simon,
>
> On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:
> >
> > Hi Rayagonda,
> >
> > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> >  wrote:
> > >
> > > Hi Thomas,
> > >
> > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons  
> > > wrote:
> > > >
> > > > Rayagonda Kokatanur  writes:
> > > >
> > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini  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  
> > > > >> > 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?

Regards,
Simon


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

2020-06-03 Thread Rayagonda Kokatanur
Hi Simon,

On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:
>
> Hi Rayagonda,
>
> On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
>  wrote:
> >
> > Hi Thomas,
> >
> > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons  
> > wrote:
> > >
> > > Rayagonda Kokatanur  writes:
> > >
> > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini  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  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.

Best regards,
Rayagonda


>
> Regards,
> SImon


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

2020-05-20 Thread Simon Glass
Hi Rayagonda,

On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
 wrote:
>
> Hi Thomas,
>
> On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons  
> wrote:
> >
> > Rayagonda Kokatanur  writes:
> >
> > > On Tue, May 19, 2020 at 11:01 PM Tom Rini  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  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 :-)

Regards,
SImon


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

2020-05-19 Thread Rayagonda Kokatanur
Hi Thomas,

On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons  wrote:
>
> Rayagonda Kokatanur  writes:
>
> > On Tue, May 19, 2020 at 11:01 PM Tom Rini  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  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 ?
Please let me know.

Best regards,
Rayagonda

>
> Thomas


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

2020-05-19 Thread Thomas Fitzsimmons
Rayagonda Kokatanur  writes:

> On Tue, May 19, 2020 at 11:01 PM Tom Rini  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  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?

Thomas


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

2020-05-19 Thread Rayagonda Kokatanur
On Tue, May 19, 2020 at 11:01 PM Tom Rini  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  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.

Best regards,
Rayagonda

>
>
> --
> Tom


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

2020-05-19 Thread Tom Rini
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  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!

-- 
Tom


signature.asc
Description: PGP signature


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

2020-05-19 Thread Rayagonda Kokatanur
Hi Tom,


On Tue, May 19, 2020 at 12:46 AM Tom Rini  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/

Best regards,
Rayagonda

>
> --
> Tom


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

2020-05-18 Thread Tom Rini
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!

-- 
Tom


signature.asc
Description: PGP signature


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

2020-05-17 Thread Rayagonda Kokatanur
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

Pramod Kumar (2):
  arm: dts: ns3: add emmc node
  arm: dts: ns3: add sp805 watchdog node

Rayagonda Kokatanur (12):
  configs: ns3: enable pinctrl driver
  dt-bindings: pinctrl: add ns3 pads definition
  arm: dts: ns3: add pinctrl node
  arm: dts: ns3: add gpio node
  configs: ns3: enable BCM IPROC mmc driver
  configs: ns3: enable mmc commands
  arm: dts: ns3: add qspi node
  arm: dts: ns3: add i2c node
  configs: ns3: enable gpt commands
  configs: ns3: enable EXT4 and FAT fs support
  configs: ns3: enable sp805 watchdog driver
  board: ns3: start sp805 watchdog service

Srinath Mannam (1):
  arm: dts: ns3: add PAXB PCIe host and phy node

 arch/arm/dts/ns3-board.dts|  58 
 arch/arm/dts/ns3-pinctrl.dtsi | 321 ++
 arch/arm/dts/ns3.dtsi | 224 
 board/broadcom/bcmns3/ns3.c   |  56 +++
 configs/bcm_ns3_defconfig |  19 ++
 .../dt-bindings/pinctrl/brcm,pinctrl-ns3.h|  41 +++
 6 files changed, 719 insertions(+)
 create mode 100644 arch/arm/dts/ns3-pinctrl.dtsi
 create mode 100644 include/dt-bindings/pinctrl/brcm,pinctrl-ns3.h

-- 
2.17.1