[U-Boot] [PATCH 00/92] ram: rk3399: Add LPDDR4 support

[Jagan Teki]

On Tue, Jun 11, 2019 at 8:36 PM Philipp Tomsich
<philipp.tomsich at theobroma-systems.com> wrote:
>
>
>
> > On 11.06.2019, at 17:03, Jagan Teki <jagan at amarulasolutions.com> wrote:
> >
> > On Tue, Jun 11, 2019 at 8:23 PM Philipp Tomsich
> > <philipp.tomsich at theobroma-systems.com> wrote:
> >>
> >>
> >>
> >>> On 11.06.2019, at 16:50, Jagan Teki <jagan at amarulasolutions.com> wrote:
> >>>
> >>> Yes, it can be possible to break this series into multiple sub series
> >>> but idea here is to mark all the required changes to support LPDDR4
> >>> in rk3399 in one set. if required we can break it from next versions.
> >>>
> >>> This is the initial set for supporting LPDDR4 with associated
> >>> features.
> >>>
> >>> Thanks to
> >>> - YouMin Chen
> >>> - Akash Gajjar
> >>> - Kever Yang
> >>> for supporting all the help on this work.
> >>>
> >>> On summary this series support
> >>> - Code warning and fixes
> >>> - rank detection, this would required to probe single channel
> >>> sdram configured in NanoPI-NEO4
> >>> - LPDDR4 support, tested in Rockpro64 and Rock-PI-4
> >>>
> >>> patch 0001 - 0033: fix code warnings, prints, new macros
> >>>
> >>> patch 0034 - 0051: rank detection, sdram debug code
> >>>
> >>> patch 0052: Use DDR3-1800 on NanoPI-NEO4
> >>>
> >>> patch 0053 - 0089: lpddr4 support
> >>>
> >>> patch 0090: LPDDR4-100 timings
> >>>
> >>> patch 0091: Use LPDDR4-100 on Rockpro64
> >>>
> >>> patch 0092: Use LPDDR4-100 on Rock-PI 4
> >>>
> >>> Note: Puma rk3399 has SPL size overflow, better to enable TPL
> >>> for this board.
> >>
> >> We need to keep Puma on a SPL-only configuration for the time being.
> >> Please make sure that the LPDDR4 code is an optional feature that does not
> >> increase the DRAM-driver size for boards that don’t need/want it.
> >
> > We have few boards do have TPL-runnable, would be any technical issue
> > to switch puma to TPL? because we have lpddr4 code part of existing
> > driver itself and it require extra ifdef to consider which indeed look
> > awful from code point-of-view.
>
> Our secure boot process (i.e. signing tools) currently depends on this and
> the changeover won’t be quick…

Not so quick, we have time till MW. isn't it possible? enabling secure
tools in both TPL and SPL or TPL-alone would be meaningful trail. what
do you think?