[U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select
Simon Goldschmidt
simon.k.r.goldschmidt at gmail.com
Mon Jan 14 15:50:47 UTC 2019
Am 11.01.2019 um 23:02 schrieb Marek Vasut:
> On 1/11/19 9:39 PM, Simon Goldschmidt wrote:
>> Am 07.01.2019 um 23:53 schrieb Marek Vasut:
>>> 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 ?
>>
>> I found that out just now: there's the function
>> 'reset_deassert_peripherals_handoff()' in spl_gen5.c that should
>> "De-assert reset for peripherals and bridges based on handoff". However,
>> at least for Gen5, it just writes a 0 to rstmgr->permodrst. By doing
>> that, it enables *ALL* peripherals on the SoC (except for some DMA
>> channels that aren't really used) :-)
>>
>> I guess that needs some cleaning up as well ;-)
>
> Yes
>
>> I think the proper thing to do here would be to remove this function and
>> convert all drivers to provide appropriate 'resets' properties in the dts?
>
> Indeed
So I just did that and it works nice for SPL and U-Boot: By adding some
"resets" properties the the main dtsi and adding reset bulk code to the
cadence_qspi, denali_dt nand and drivers, I can nearly remove the reset
code from arch/mach_socfpga.
The problem would be that now Linux cannot use peripherals that aren't
enabled by U-Boot because it relies on them being enabled. How are such
dependencies solved? Because even if I would add reset support in the
corresponding Linux drivers, we probably could not bootolder Kernels
(e.g. the Debian 9 kernel - v4.9.x) with a new U-Boot...
Regards,
Simon
More information about the U-Boot
mailing list