22 Feb
2019
22 Feb
'19
8:36 p.m.
On 2/22/19 8:12 PM, Simon Goldschmidt wrote:
Am Fr., 22. Feb. 2019, 18:34 hat Marek Vasut <marex@denx.de mailto:marex@denx.de> geschrieben:
On 2/22/19 7:20 AM, Simon Goldschmidt wrote: > On Thu, Feb 21, 2019 at 11:13 PM Marek Vasut <marex@denx.de <mailto:marex@denx.de>> wrote: >> >> On 2/21/19 11:11 PM, Simon Goldschmidt wrote: >>> >>> >>> Am Do., 21. Feb. 2019, 23:05 hat Marek Vasut <marex@denx.de <mailto:marex@denx.de> >>> <mailto:marex@denx.de <mailto:marex@denx.de>>> geschrieben: >>> >>> On 2/21/19 11:03 PM, Simon Goldschmidt wrote: >>> > >>> > >>> > Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut <marex@denx.de <mailto:marex@denx.de> >>> <mailto:marex@denx.de <mailto:marex@denx.de>> >>> > <mailto:marex@denx.de <mailto:marex@denx.de> <mailto:marex@denx.de <mailto:marex@denx.de>>>> geschrieben: >>> > >>> > On 2/21/19 10:43 PM, Simon Goldschmidt wrote: >>> > > The SPL for socfpga gen5 currently takes all peripherals out >>> of reset >>> > > unconditionally. To implement proper reset handling for >>> peripherals, >>> > > the reset node has to be provided with the SPL dts. >>> > > >>> > > In preparation to move the DDR driver to DM, the sdr node is >>> required >>> > > in SPL, too. >>> > > >>> > > This patch adds "u-boot,dm-pre-reloc" to U-Boot specific >>> dtsi addon >>> > > files so that the reset manager and SDR driver correctly >>> probe in SPL. >>> > > >>> > > Signed-off-by: Simon Goldschmidt >>> <simon.k.r.goldschmidt@gmail.com <mailto:simon.k.r.goldschmidt@gmail.com> >>> <mailto:simon.k.r.goldschmidt@gmail.com <mailto:simon.k.r.goldschmidt@gmail.com>> >>> > <mailto:simon.k.r.goldschmidt@gmail.com <mailto:simon.k.r.goldschmidt@gmail.com> >>> <mailto:simon.k.r.goldschmidt@gmail.com <mailto:simon.k.r.goldschmidt@gmail.com>>>> >>> > > --- >>> > > >>> > > Changes in v2: None >>> > > >>> > > arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi | 8 >>> ++++++++ >>> > > arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts | 8 >>> ++++++++ >>> > > arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 8 >>> ++++++++ >>> > > arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 8 >>> ++++++++ >>> > > arch/arm/dts/socfpga_cyclone5_de1_soc.dts | 8 >>> ++++++++ >>> > > arch/arm/dts/socfpga_cyclone5_is1.dts | 8 >>> ++++++++ >>> > > arch/arm/dts/socfpga_cyclone5_socdk-u-boot.dtsi | 8 >>> ++++++++ >>> > > arch/arm/dts/socfpga_cyclone5_sockit-u-boot.dtsi | 8 >>> ++++++++ >>> > > arch/arm/dts/socfpga_cyclone5_socrates-u-boot.dtsi | 8 >>> ++++++++ >>> > > arch/arm/dts/socfpga_cyclone5_sr1500.dts | 8 >>> ++++++++ >>> > > arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi | 8 >>> ++++++++ >>> > > 11 files changed, 88 insertions(+) >>> > > >>> > > diff --git a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi >>> > b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi >>> > > index c44d1ee2fa..8aaec56285 100644 >>> > > --- a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi >>> > > +++ b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi >>> > > @@ -17,6 +17,14 @@ >>> > > }; >>> > > }; >>> > > >>> > > +&rst { >>> > > + u-boot,dm-pre-reloc; >>> > > +}; >>> > > + >>> > > +&sdr { >>> > > + u-boot,dm-pre-reloc; >>> > > +}; >>> > >>> > What about some socfpga-common-u-boot.dtsi to avoid duplication ? >>> > >>> > >>> > Right. I tested with 'socfpga-u-boot.dtsi' but the hot included for >>> > gen10 as well. >>> >>> hot included ? I don't think I understand. >>> >>> >>> Argh. I'm writing from my mobile... >> >> It can wait till tomorrow ... >> >>> What I meant was that file got included by the automatism so I couldn't >>> use it. >> Errr, which file ? What automatism ? Really, wait till tomorrow with a >> reply, please. > > Let me try again: I started this patch with trying to centralize the > "u-boot,dm-pre-reloc" > lines in one file named "socfpga-u-boot.dtsi" since it is valid for > all gen5 devices > and including it automatically would be OK. > > However, the automatism to search for a "-u-boot.dtsi" file caught > that file also for > a10 and even s10 due to the lack of a more specific match. > > In the end I dropped that idea and added it to all board dtsi files. > > However, by using a name that doesn't match the automatism rules, I > can centralize > these settings. I'll do that for V3. I think applying it on A10 would be fine too, dunno about S10.S10 is where it failed compiling for me. A10 compiled OK but i could not test it. I guess going the safe way and applying for Gen5 only would be better.
Chee can test A10 for you.
What's the problem with S10 ?
--
Best regards,
Marek Vasut