[U-Boot] [RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer

[Laurent Pinchart]

Hi Geert,

On Tuesday, 19 June 2018 09:58:59 EEST Geert Uytterhoeven wrote:
> On Tue, Jun 19, 2018 at 4:15 AM Laurent Pinchart wrote:
> > On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote:
> >> On 06/16/2018 05:44 PM, Laurent Pinchart wrote:
> >>> On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote:
> >>>> On 06/16/2018 01:21 AM, Laurent Pinchart wrote:
> >>>>> On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
> >>>>>> On 06/15/2018 01:43 PM, Marek Vasut wrote:

[snip]

> >>>>>>>>> Obvious design question is -- since you're adding new SMC call
> >>>>>>>>> anyway, can't the call just return the memory layout table
> >>>>>>>>> itself, so that it won't be duplicated both in U-Boot and ATF ?
> >>>>>>>> 
> >>>>>>>> My gut feeling was to go with the smallest interface possible.
> >>>>>>> 
> >>>>>>> But this doesn't scale. The API here uses some ad-hoc constants to
> >>>>>>> identify memory layout tables which have to be encoded both in ATF
> >>>>>>> and U-Boot, both of which must be kept in sync.
> >>>>>>> 
> >>>>>>> The ATF already has those memory layout tables, it's only a matter
> >>>>>>> of passing them to U-Boot. If you do just that, the ad-hoc
> >>>>>>> constants and encoding of tables into U-Boot goes away and in fact
> >>>>>>> simplifies the design.
> >>>>>>> 
> >>>>>>> Yet, I have to wonder if ATF doesn't already contain some sort of
> >>>>>>> standard SMC call to get memory topology. It surprises me that it
> >>>>>>> wouldn't.
> >>>>>> 
> >>>>>> In fact, Laurent (CCed) was solving some similar issue with lossy
> >>>>>> decomp and I think this involved some passing of memory layout
> >>>>>> information from ATF to U-Boot too, or am I mistaken ?
> >>>>> 
> >>>>> That's correct, ATF stores information about the memory layout at a
> >>>>> fixed address in system memory, and U-Boot can read it.
> >>>> 
> >>>> Well, that sounds good ! Maybe we can avoid adding SMC call
> >>>> altogether then? :)
> >>> 
> >>> I'd prefer that, yes.
> >>> 
> >>> Let's not duplicate the mechanism used to pass FCNL information from
> >>> ATF to U- Boot, but instead create a data table format that can store
> >>> all the information we need, in an easily extensible way.
> >>> 
> >>> To see how the mechanism is implemented for FCNL, search for 47FD7000
> >>> in the Renesas ATF sources
> >>> (git://github.com/renesas-rcar/arm-trusted-firmware.git).
> >> 
> >> For everyone involved, can you explain what FCNL is ? ;-)
> > 
> > FCNL is Frame Compression Near Lossless. It's a way to reduce memory
> > bandwidth by transparent compression and decompression of video frames.
> > Compression is handled by an IP core called FCP, and decompression is
> > handled by the DRAM controller. ATF programs the DRAM controller with
> > ranges of memory addresses that will be dynamically decompressed. The
> > registers containing those ranges are accessible in secure mode only, so
> > neither U-Boot nor Linux can read them. That's why ATF has to pass the
> > information to U-Boot, in order to add the ranges as reserved memory in
> > DT.
> > 
> >> Any yes, I agree this sounds good. I had a discussion on the U-Boot IRC
> >> about passing the memory configuration around and the result is
> >> basically the same -- pass a table from ATF to U-Boot. If there's
> >> already something, great.
> 
> Pass a "table"? Or an FDT containing the /memory nodes?
> The latter allows for easier future extension.

ATF passes a table to U-Boot, and U-Boot then updates the FDT accordingly 
before starting Linux.

-- 
Regards,

Laurent Pinchart