[U-Boot] [PATCH 4/4] ARM: renesas: Configure DRAM size from ATF DT fragment

Eugeniu Rosca erosca at de.adit-jv.com
Thu Apr 4 13:45:54 UTC 2019


Hi Marek,

On Tue, Apr 02, 2019 at 05:45:29AM +0200, Marek Vasut wrote:
> On 3/13/19 4:25 PM, Eugeniu Rosca wrote:
> > On Tue, Mar 12, 2019 at 10:11:21PM +0100, Marek Vasut wrote:
> >> On 3/12/19 8:30 PM, Eugeniu Rosca wrote:
> >>> Hi Marek cc: Michael
> >>
> >> Hi,
> >>
> >>> On Tue, Mar 5, 2019 at 4:37 AM Marek Vasut <marek.vasut at gmail.com> wrote:
> >>>>
> >>>> The ATF can pass additional information via the first four registers,
> >>>> x0...x3. The R-Car Gen3 with mainline ATF, register x1 contains pointer
> >>>> to a device tree with platform information. Parse this device tree and
> >>>> extract DRAM size information from it. This is useful on systems where
> >>>> the DRAM size can vary between configurations.
> >>>
> >>> 1. Do the ATF changes supporting this feature already exist in mainline ATF?
> >>
> >> Yes, for quite some time, see
> >> commit 1d85c4bd5b6291b99feb2409525c96f0c1744328
> >>     plat: rcar: Pass DTB with DRAM layout from BL2 to next stages
> > 
> > That's helpful, but I think such information should go by default into
> > commit description.
> > 
> > [..]
> > 
> > Besides the above, I wonder why this patch duplicates code across three
> > board files? Could this code be relocated to some common area like [1]?
> 
> That's the plan.

I look forward to seeing v2 then, since this would allow us not
duplicating this code over and over again in the board-specific files
of the customer R-Car3 targets.

> 
> > FWIW building the latter could be re-enabled by reverting the Makefile
> > changes from v2018.01-rc1 commit [2].
> 
> I prefer a more progressive approach, that is applying patches, rather
> than reverting.

"reverting" is used here figuratively, suggesting to undo the Makefile
changes added by commit [2], in order to create/restore the R-Car3
common/board-independent space. It doesn't ask creating a revert commit.

> > To differentiate between the boards which expect/require the ATF args
> > and those which don't, I guess that run-time (IS_ENABLED) checking of
> > a newly created Kconfig symbol, e.g. SUPPORTS_ATF_ARGS or similar,
> > selected on per-board basis, could do the job?
> 
> No, the code should auto-detect whether the ATF supports the DT passing
> or not.

Great. Less build-time options the better.

> > Note that we already face the need to have an area for Android features
> > common between all Gen3 boards, so I think reviving [1] is inevitable.
> > 
> > [1] board/renesas/rcar-common/common.c
> > [2] http://git.denx.de/?p=u-boot.git;a=commitdiff;h=e23eb942ad10
> >     ("ARM: rmobile: Stop using rcar-common/common.c on Gen3")
> > 
> > Best regards,
> > Eugeniu.
> > 
> -- 
> Best regards,
> Marek Vasut

I would appreciate being CC-ed in v2, if possible. Thanks!


More information about the U-Boot mailing list