On Mon, Jan 14, 2019 at 07:31:26PM +0100, Marek Vasut wrote: > On 1/14/19 5:05 PM, Simon Goldschmidt wrote: > > Hi Dinh, > > Hi, > > > 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. > > We had the same problem with A10, indeed. > > > 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? > > > > Plus: should U-Boot work with older Linux kernels? Because if so, we > > need fallback code in U-Boot to unreset peripherals when running with an > > older kernel... > > Yes, it'd break old broken kernels . The real question is, do we care ?
Yes, we care. Especially since it sounds like we're talking about something that's an LTS and not super-ancient vendor kernel. Off the top of my head I can't recall if we ever fully removed support in sunxi for the vendor kernel in some cases, or just made it, eventually, opt-in as it was a fairly annoying incompatible behavior case. But yes, in general, we do care about old kernels and need to be loud and clear about when we're removing support for them on a given SoC due to it being a PITA to support both ways of doing X and people have had Y years to migrate or correct their kernel. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
