From mboxrd@z Thu Jan 1 00:00:00 1970 From: Walter Lozano Date: Fri, 5 Jun 2020 12:47:10 -0300 Subject: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc In-Reply-To: <20200605150555.GG32287@bill-the-cat> References: <20200519173143.GO14425@bill-the-cat> <20200604031624.GC32287@bill-the-cat> <20200605150555.GG32287@bill-the-cat> Message-ID: <362a0176-c2da-3210-8272-49da31a793a4@collabora.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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