[PATCH v1 00/15] add basic driver support for broadcom NS3 soc
Soeren Moch
smoch at web.de
Fri Jun 5 11:36:57 CEST 2020
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.
Soeren
More information about the U-Boot
mailing list