From mboxrd@z Thu Jan 1 00:00:00 1970 From: Soeren Moch Date: Fri, 5 Jun 2020 11:36:57 +0200 Subject: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc In-Reply-To: <20200604031624.GC32287@bill-the-cat> References: <20200517081945.21282-1-rayagonda.kokatanur@broadcom.com> <20200518191622.GH14425@bill-the-cat> <20200519173143.GO14425@bill-the-cat> <20200604031624.GC32287@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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