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

[Marek Vasut]

On 1/8/19 3:58 PM, Tom Rini wrote:
> 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?).

Sure, but then maybe you do need to remove some of that stuff and
configure the SPL for that one single need you have.

-- 
Best regards,
Marek Vasut