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@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.
- 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!