> On 12.06.2019, at 17:30, Jagan Teki <ja...@amarulasolutions.com> wrote: > > On Tue, Jun 11, 2019 at 8:36 PM Philipp Tomsich > <philipp.toms...@theobroma-systems.com > <mailto:philipp.toms...@theobroma-systems.com>> wrote: >> >> >> >>> On 11.06.2019, at 17:03, Jagan Teki <ja...@amarulasolutions.com> wrote: >>> >>> On Tue, Jun 11, 2019 at 8:23 PM Philipp Tomsich >>> <philipp.toms...@theobroma-systems.com> wrote: >>>> >>>> >>>> >>>>> On 11.06.2019, at 16:50, Jagan Teki <ja...@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?
We aren’t talking about a single MW here, given that summer is starting to eat up some of my resources… Thanks, Phil. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot