On 1/14/19 10:05 AM, Simon Goldschmidt wrote: > Hi Dinh, > > Am 14.01.2019 um 16:58 schrieb Dinh Nguyen: >> Hi Simon, >> >> On 1/14/19 9:50 AM, Simon Goldschmidt wrote: >>> 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... >>> >> >> I added an early reset driver for SoCFPGA that should take care of this. >> The patch is in v5.0-rc2[1]. > > OK, it's good to know that this work is already done, I haven't > monitored this close enough. > > But am I correct that my above problem remains even in v5.0 as not all > peripherals in socfpga.dtsi have a "resets" property set (e.g. mmc and > qspi) and would thuse not be taken out of reset by Linux? >
Yes, I see that. I will send a patch for those. Dinh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
