From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dalon L Westergreen Date: Tue, 08 Oct 2019 10:08:50 -0700 Subject: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include In-Reply-To: References: <20191004223043.18127-1-dalon.westergreen@linux.intel.com> <20191004223043.18127-5-dalon.westergreen@linux.intel.com> <125a5772-1357-d5ee-c3ed-6e2c859c0015@denx.de> <6323f4381558a754bdf790e77ba2003919708137.camel@linux.intel.com> <5f982476-610e-cde3-391e-c7ad1f1990f0@gmail.com> <0683984be3f4f8ac6c5e9ac94e3f110663803a26.camel@linux.intel.com> Message-ID: <8a9b796fede21161007c6a77111482ba917c0f4b.camel@linux.intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, 2019-10-07 at 16:45 +0200, Simon Goldschmidt wrote: > There's something wrong with your mailer: indentation of replies doesn't > seemto work. It gets kind of hard to read who wrote what... > On Mon, Oct 7, 2019 at 4:34 PM Dalon L Westergreen< > dalon.westergreen at linux.intel.com> wrote: > > On Sun, 2019-10-06 at 20:05 +0200, Simon Goldschmidt wrote: > > Am 06.10.2019 um 19:44 schrieb Dalon L Westergreen: > > On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote: > > On 10/6/19 1:19 AM, Dalon L Westergreen wrote: > > On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote: > > On 10/5/19 12:30 AM, Dalon Westergreen wrote: > > From: Dalon Westergreen < > > dalon.westergreen at intel.com > > > > > > > dalon.westergreen at intel.com > > > > > > Generic handoff devicetree include uses a header generated bythe qts-filter- > > a10.sh script in mach-socfpga. The scriptcreates the header based on design > > specific implementationsfor clock and pinmux configurations. > > > > [...] > > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi > > b/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi > > > > [...] > > - clock_manager at 0xffd04000 {+ clkmgr at 0xffd04000 {+ compatible = > > "altr,socfpga-a10-clk-init";+ reg = <0xffd04000 0x00000200>;+ > > reg-names = "soc_clock_manager_OCP_SLV"; u-boot,dm-pre- > > reloc; mainpll {+ vco0-psrc = > > ;+ vco1-denom = > > ;+ vco1-numer = > > ; > > > > But these bits are board-specific , they shouldn't be in common DT. > > > > This common dtsi requires that the top level u-boot.dtsi include the board > > specific header. The format > > and #define names are in fact common. > > > > OK, I now see what you're doing here. Can you explain that in a bit more > > detail in the commit message ? > > > > Basically socfpga_board.h is included socfpga_board.dts , and then the > > preprocessor correctly expands the values from socfpga_board.h in the > > socfpga_board.dts , so this works for multiple boards too ? > > > > Exactly. Will add more detail in the commit message, and slim down the > > included clocks in > > the u-boot.dtsi > > > > I'm (still) working on a series to bring gen5 completely to devicetree, > > so that the 'qts' directories can be removed. I chose a different > > approach however, in that I generated everything into a '-handoff.dtsi' > > file (*). I'd be happy if we could find a common mechanism for all > > socfpga sub-archs. How does S10/Agilex handle this? > > > > (*): Gen5 has the downside that we're low on memory in SPL (regarding > > DM), and as we require large binary arrays there, I chose to encode the > > binary blob arrays in host byte order so that they could be used > > in-place instead of copying them from BE (dtb) to LE (stack/heap). Maybe > > that doesn't fit A10/S10/Agilex anyway? > > > > Can you share your patch set with me, privately or otherwise, just so we can > > take a similarapproach in the devicetree? > > Give me a week max. and I'll send the series as RFC. > > Also, have you looked at the bsp-editor python source that generates the > > "generated" filesfrom the bsp-editor? > > 19.1std/647/linux64/ip/altera/preloader/scripts > > No, I mainly focused on the U-Boot part for now. I just wrote a C programthat > did the conversion from 'official generated' files to DTS... > > I am hoping to replace these with a script included in the u-boot source. > > iocsr.py doesa bunch of binary parsing. > > Right, a direct conversion from compilation output to U-Boot would be > better.However, that would require Intel to keep that output consistent! It should be consistent at this point. i would not worry about that. > Regards,Simon > > --dalon > > > > Regards, > > Simon