[U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Tom Rini]

On Tue, Jan 08, 2019 at 04:04:12PM +0100, Simon Goldschmidt wrote:
> Am 08.01.2019 um 15:58 schrieb Tom Rini:
> >On Tue, Jan 08, 2019 at 03:50:48PM +0100, Marek Vasut wrote:
> >>On 1/8/19 3:48 PM, Tom Rini wrote:
> >>>On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:
> >>>>On 1/8/19 1:46 PM, Simon Goldschmidt wrote:
> >>>>>On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut <marex at denx.de> wrote:
> >>>>>>
> >>>>>>On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
> >>>>>>>On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut <marex at denx.de> wrote:
> >>>>>>>>
> >>>>>>>>On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
> >>>>>>>>>On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut <marex at denx.de> wrote:
> >>>>>>>>>>
> >>>>>>>>>>On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> >>>>>>>>>>>In order to build a smaller SPL, let's imply SPL_DM_RESET and
> >>>>>>>>>>>SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled
> >>>>>>>>>>>via defconfig.
> >>>>>>>>>>>
> >>>>>>>>>>>This also seems to be required to use OF_PLATDATA, as the reset drivers
> >>>>>>>>>>>don't seem to work with it.
> >>>>>>>>>>
> >>>>>>>>>>How do you un-reset IP blocks if you disable the reset controller ?
> >>>>>>>>>
> >>>>>>>>>Here again, socfpga seems to be another bad example. Taking
> >>>>>>>>>peripherals out of reset
> >>>>>>>>>is cluttered throughout the mach-socfpga code at least in SPL. By now
> >>>>>>>>>I know socfpga is
> >>>>>>>>>lacking support for clock and reset management via devicetree. And
> >>>>>>>>>this is bad, I know,
> >>>>>>>>>but can we keep this a seperate issue from OF_PLATDATA?
> >>>>>>>>>
> >>>>>>>>>That being said, drivers/reset/reset-uclass.c fails to compile with
> >>>>>>>>>OF_PLATDATA, so I
> >>>>>>>>>guess this has not been used with OF_PLATDATA before. And given that I
> >>>>>>>>>don't seem
> >>>>>>>>>to need it for socfpga either, I don't think this would be the right
> >>>>>>>>>series to fix that.
> >>>>>>>>
> >>>>>>>>Don't you need it to unreset at least the DWMMC or CQSPI ?
> >>>>>>>
> >>>>>>>Reading the code, it seems like that's taken care of through another hack in
> >>>>>>>spl_boot_device() ;-)
> >>>>>>
> >>>>>>Sigh.
> >>>>>>
> >>>>>>>>Anyway, I'd much prefer to start cleaning up the horrorshow that
> >>>>>>>>arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
> >>>>>>>>Would that be possible ?
> >>>>>>>
> >>>>>>>I would be best, yes. I don't know when I will find the time to do that, though.
> >>>>>>>I don't know how much effort that would be, either. Is there maybe a patch
> >>>>>>>where A10 got converted from "as bad as gen5" to its current state? That
> >>>>>>>would help me to see if I can do it...
> >>>>>>
> >>>>>>A10 got switched to reset framework recently (in last 6 months or so),
> >>>>>>the reset driver is the same for Gen5 and A10 too, so it should be easy
> >>>>>>to recycle.
> >>>>>
> >>>>>Hmm, ok, let me check that... it would indeed be nice to port this to gen5.
> >>>>>
> >>>>>Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
> >>>>>to continue on this? I mean, I thought I heard people here saying "use
> >>>>>OF_PLATDATA" if you're running out of space in SPL. After using it, I'm not too
> >>>>>keen on using it, either, but it does seem to give me some code space back...
> >>>>
> >>>>OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
> >>>>This platform has a massive 60k of SRAM for SPL, so if we're running out
> >>>>of space, we're doing something wrong.
> >>>
> >>>It's not for "30k or below" but "needs more space to enable all desired
> >>>features inside of SPL".
> >>
> >>Which the SoCFPGA should have with 60k of SRAM. If U-Boot SPL became so
> >>bloated that even platform with so much space has issues, how can we
> >>even cater for the rest of platforms with much more limited SPL ? And if
> >>that is the case, we have a much bigger problem ...
> >
> >It depends, greatly, on what features you want within a single binary.
> >I'm not saying SoCFPGA can't fit what it wants, including verified boot,
> >inside of 60k.  But what I am saying is we don't have a hard-and-fast
> >limit on when you must not use OF_PLATDATA since it's always been easy
> >to make SPL too big, once you start including all of the possible
> >kitchen sink options (lets do falcon mode, and boot count and usb gadget
> >and usb host and regular ethernet and mmc and nand and oh crap, where
> >did all of my space go?).
> 
> I'm not saying this was directed to me (I'm sure it wasn't). Just to clarify
> my point: I'm really just trying to get the most basic SPL to work that
> loads U-Boot as FIT from spi-flash and verifies it. It might well be that
> it's this verified FIT offset that could be reduced...

Oh no, I'm just listing the worst case of am335x, which is my fault, and
goes well over the generous 100k+ that we have available there.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190108/22b242a0/attachment.sig>