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.kokata...@broadcom.com> wrote:
> >>>
> >>> Hi Simon,
> >>>
> >>> On Wed, May 20, 2020 at 7:50 PM Simon Glass <s...@chromium.org> wrote:
> >>>>
> >>>> Hi Rayagonda,
> >>>>
> >>>> On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> >>>> <rayagonda.kokata...@broadcom.com> wrote:
> >>>>>
> >>>>> Hi Thomas,
> >>>>>
> >>>>> On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons
> >>>>> <fitz...@fitzsim.org> wrote:
> >>>>>>
> >>>>>> Rayagonda Kokatanur <rayagonda.kokata...@broadcom.com> writes:
> >>>>>>
> >>>>>>> On Tue, May 19, 2020 at 11:01 PM Tom Rini <tr...@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 <tr...@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. -- Tom
signature.asc
Description: PGP signature
