On 1/14/19 10:53 PM, Simon Goldschmidt wrote: > > > Am Mo., 14. Jan. 2019, 22:50 hat Tom Rini <tr...@konsulko.com > <mailto:tr...@konsulko.com>> geschrieben: > > On Mon, Jan 14, 2019 at 10:30:36PM +0100, Marek Vasut wrote: > > On 1/14/19 10:28 PM, Tom Rini wrote: > > > 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. > > > > Then we have to add some fallback mechanism, possibly the env variable > > to tell reset controller to unreset everything. > > Alright, so the prior art in question is: > commit accc9e446be6c3bd129315a0c5830bddccfa16da > Author: Hans de Goede <hdego...@redhat.com <mailto:hdego...@redhat.com>> > Date: Wed Oct 22 14:56:36 2014 +0200 > > sunxi: Add CONFIG_OLD_SUNXI_KERNEL_COMPAT Kconfig option > > And is about supporting the sunxi 3.4 vendor kernel tree, and something > we have still (and a single enabler of). So, what's the range of broken > / not broken kernels here? > > > I haven't yet tested but my idea is that it is still broken (some of the > devices won't come out of reset in some scenarios). > > So I guess such a Kconfig option would even need to be enabled by > default for some time...
Well, if you had a variable to configure that at runtime, you won't need another ad-hoc Kconfig option . -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
