Hi Laurent, [dropped u-boot list] On Tue, Jun 19, 2018 at 2:56 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > Hi Magnus, > > On Tuesday, 19 June 2018 08:43:31 EEST Magnus Damm wrote: >> On Tue, Jun 19, 2018 at 11: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] > >> >>>>>>> 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. >> >> Thanks for the clarification. I wonder how much of the split between >> ATF and "the rest" can be adjusted. It smells like just a software >> architecture policy, my gut feeling is that LIFEC can be programmed to >> adjust the assignment between secure side and "regular". At least it >> can do so for a wide range of bus masters. However if this is the case >> for FCNL remains to be seen. >> >> As a side note, for FCNL I personally would prefer a more dynamic >> solution where we manage physically contiguous ranges from Linux >> during run time instead of relying of statically setup windows. > > So would I, but whether we can be allowed to access those registers from Linux > isn't my decision :-/ I suspect the physical ranges programmed in the DRAM controller for decompression purpose may be ranges in higher memory that are aliases to actual physical memory. So if we would create statically aliased ranges of the entire physical memory for decompression purpose then inside Linux we can simply do a translation to these aliases instead of actual physical memory at map/unmap time. This way you would get both statically setup tables in ATF and dynamic operation inside Linux. Lets discuss this more when we meet tomorrow. Cheers, / magnus
