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

[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
>>>> <rayagonda.kokatanur at broadcom.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Wed, May 20, 2020 at 7:50 PM Simon Glass <sjg at chromium.org> wrote:
>>>>>> Hi Rayagonda,
>>>>>>
>>>>>> On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
>>>>>> <rayagonda.kokatanur at broadcom.com> wrote:
>>>>>>> Hi Thomas,
>>>>>>>
>>>>>>> On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons <fitzsim at fitzsim.org> wrote:
>>>>>>>> Rayagonda Kokatanur <rayagonda.kokatanur at broadcom.com> writes:
>>>>>>>>
>>>>>>>>> On Tue, May 19, 2020 at 11:01 PM Tom Rini <trini at 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 at 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?
>>> 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