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

[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
>>>>>> <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?
> 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 hardware in a
> machine readable format.
>
> While this is more appropriate to the RFC thread about tiny-DM or some
> other idea, what keeps popping to my mind is that we have few cases
> where the device tree we work from is being passed to us from some
> outside source.  Most of the time we're being told at build time the
> device tree, or sometimes trees, that will ever be used on a platform at
> run time.  How can we use that information to discard never-will-be-used
> information?  If we've turned the device trees to C, then we can <do
> something I haven't figured out the details on> and have the linker
> discard things.


I totally agree with you. From what I see there are several things we 
could do. Let's continue the discussion on the RFC thread about tiny-DM

Regards,

Walter