[Ksummit-discuss] Devicetree Workshop at Kernel Summit Prague (26 Oct 2017)

Wed Oct 18 16:20:44 UTC 2017

Hi Andre,

On Wed, 2017-10-18 at 17:05 +0100, Andre Przywara wrote:
> Hi,
> 
> On 18/10/17 16:32, Rob Herring wrote:
> > On Wed, Oct 18, 2017 at 9:28 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> >> Hi,
> >>
> >> On 18/10/17 15:04, Michal Simek wrote:
> >>> On 16.10.2017 16:11, Rob Herring wrote:
> >>>> On Mon, Oct 16, 2017 at 12:36 AM, Michal Simek <monstr at monstr.eu> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 9.10.2017 22:39, Grant Likely wrote:
> >>>>>> Kernel Summit is now just over 2 weeks away and it is time to pull
> >>>>>> together the schedule for the Devicetree workshop. Originally I
> >>>>>> planned on just an afternoon, but I've got the room for the whole day,
> >>>>>> so I've got a lot of flexibility on the schedule. Unscheduled time can
> >>>>>> be used for hacking.
> >>>>>>
> >>>>>> Date: 26 Oct 2017
> >>>>>> Time: 9:00am-5:30pm (Lunch from 12:30-2:30)
> >>>>>> Location: Athens room - Hilton Prague
> >>>>>>
> >>>>>> If you plan to attend, make sure you update your OSSunmitE/ELCE
> >>>>>> registration to include the DT Workshop (log in to access and modify
> >>>>>> your registration):
> >>>>>>
> >>>>>> https://www.regonline.com/register/login.aspx?eventID=1883377&MethodId=0&EventsessionId=&Email_Address=&membershipID=
> >>>>>>
> >>>>>> Here is my current list of topics in no particular order, including
> >>>>>> the topic moderator:
> >>>>>>
> >>>>>> Runtime memory consumption (Rob Herring)
> >>>>>> Overlay maintenance plan (TBC)
> >>>>>> Stable ABI for devicetree (TBC)
> >>>>>> DT YAML encoding (Pantelis Antoniou)
> >>>>>> DT Schema format - option 1 (Pantelis Antoniou)
> >>>>>> DT Schema format - option 2 (Grant Likely)
> >>>>>> Sharing Generic bindings (TBC)
> >>>>>> devicetree.org update (Grant)
> >>>>>>
> >>>>>> Reply to this email if you want to propose another topic.
> >>>>>>
> >>>>>> Reply privately if there is a particular topic you want to attend but
> >>>>>> you are unable to be there in the morning or afternoon. I'll put the
> >>>>>> actual agenda together a week out from the event.
> >>>>>
> >>>>> I would like to talk how to add support for AArch32 based on arm64 dts file.
> >>>>
> >>>> We already have that for RPi3, but it's a bit hacky in that you have
> >>>> to include files from one arch to the other. What I'd like to see
> >>>> ideally is no dependency on $ARCH to build dts files. You can't build
> >>>> dts files for an arch without a cross-compiler installed which is an
> >>>> artificial dependency. The dtb should be independent of whether you're
> >>>> building for 32 or 64 bit.
> >>>
> >>> I wasn't aware about RPI3 but yes - I have seen the same for ZynqMP.
> >>>
> >>>>
> >>>> There's the other aspect of being able to do armv8 32-bit builds as
> >>>> there's no explicit support for v8 in arch/arm/. But that's not a DT
> >>>> issue.
> >>>
> >>> Yep including Kconfig.platforms is required.
> >>>
> >>>>
> >>>>> And next topic is discuss criteria for adding new DTS board files to
> >>>>> kernel for supporting custom boards especially for arm32 which can end
> >>>>> up with a lot of dts files in this folder.
> >>>>
> >>>> We really should move the arm32 files into subdirs for each SoC vendor
> >>>> IMO, but I think armsoc maintainers have been against that churn.
> >>>
> >>> As you said above maybe we should consider to move all DTS files out of
> >>> arch folder and sorted them based on SoC vendor. It sounds like a good
> >>> topic to discuss.
> > 
> > That is 2 separate topics really. For the latter, you need to come up
> > with reasons to justify the churn.
> > 
> >>>>> If make sense to permit only boards with something new or just enable
> >>>>> reference boards to go in.
> >>>>
> >>>> The board dts files are generally pretty minimal. What's the issue
> >>>> here? Just lots of files in arch/arm/boot/dts?
> >>>
> >>> yep. A lot of files there.
> > 
> > Are we approaching the limits of # of files in one directory? Is
> > Arnd/Olof or Linus complaining about there being too many files to
> > maintain? Do sub-arch maintainers not know which files are theirs?
> > What problem are we trying to solve here?
> > 
> > If we're talking about moving bindings and dts files out of the
> > kernel, then call it that. Otherwise, let's not mix the topics. Unless
> > you want nothing to happen then tie it to moving to a separate
> > repository.
> > 
> >> I was wondering whether we should really stop providing .dts files for
> >> *boards* in the *kernel* tree. In my impression this was more a stop-gap
> >> measure to bridge the transition from board files to DT.
> > 
> > Not really. A stop-gap would be a couple of kernel cycles in my mind.
> > PPC dts files have been there forever practically.
> > 
> >> Given that the particular board files are rather boring anyway, wouldn't
> >> it be sufficient to just include the SoC .dtsi plus one (or two) example
> >> .dts, for instance for the official evaluation board?
> > 
> > That sounds horrible to manage. You are assuming the split between
> > board and SoC specifics are done perfectly from the start. I haven't
> > checked the history, but I'm going to guess that has not been the
> > case. That would effectively make the split be an ABI. Folks have
> > enough issues with the entire dtb being an ABI.
> 
> I agree that we should not create an ABI between the SoC's .dtsi the
> board's .dts files. But eventually people would put *.dtbs* on their
> boards, so we don't really care, as long as they are created from the
> right combination of both.
> At the end of the day a vendor actually doesn't really need to provide a
> DT matching exactly the kernel version, as long as it does not violate
> any bindings.
> 
> > However, there is a coming issue with Android project Treble which
> > does say all board specifics are an overlay (or multiple overlays) to
> > a common SoC base dtb which does make the split an ABI. For mainline
> > to handle this, we'd need to start making the board files overlays.
> 
> That does not sound good ...
> 
> > And to not break everything, we'd need to apply those overlays at
> > build time to produce a single board dtb. OTOH, phones aren't really
> > supported in mainline and vendors will do it wrong before mainline
> > gets around to it.
> > 
> >> This could be used as a template for creating specific board DTs.
> >> Ideally vendors could put those on their boards: into some flash or
> >> integrated into the firmware (as part of U-Boot, for instance).
> > 
> > That's really a separate problem from where are dts files maintained.
> > 
> > Does u-boot support using the same dtb to configure itself and to pass
> > to the kernel yet? That was a foreign concept though I think it was
> > being worked on.
> 
> That works already for some platforms or SoCs, as long as someone cares
> to keep the U-Boot copy up-to-date with the kernel version [1].
> I boot the Pine64 with $fdtcontroladdr (which points to U-Boot's .dtb)
> these days, without the need to load any .dtb. And on some boards U-Boot
> lives in SPI flash, so the .dtb is really tied to the board. Like on
> Highbank/Midway ;-)
> 
> Also this is the default address which the bootuefi command takes when
> there is nothing more specific provided.
> 
> But this is purely platform specific, and for some of them the DT used
> in U-Boot is quite different from the kernel version. Although this can
> be fixed, as the U-Boot drivers can be changed and don't adhere to some ABI.
> 
> >> And having a source for the .dtsi should make it easier to get a
> >> readable de-compilation of a given .dtb.
> > 
> > If such a tool existed to add back the annotations. YAML will solve
> > that, I'm sure.
> 
> Yes, but you need some extra JSON to recover the formatting ;-)
> 

YAML output preserves references and anchors. But still would not
be the same as the original sources since we're now heavily using
macros and the preprocessor.

Close, but no cigar.

> >> We could collect .dts files for boards somewhere else. It's already the
> >> case that we have some boards with a specific SoC "supported by the
> >> kernel" and some not, for no technical reason at all, actually. It's
> >> just whether there is someone willing to post (and push through) a .dts
> >> file.
> > 
> > We could start accepting (but not requiring) patches against the
> > devicetree-rebasing.git tree if that solves the problem of "kernel
> > bindings" and "kernel dts files". We can mechanically convert their
> > paths back to kernel paths and apply them. I've got no issue signing
> > up to that because I fully expect that to be only a trickle.
> 
> But that would mean that they would still live in the kernel, right?
> 
> Cheers,
> Andre.
> 
> [1]
> http://git.denx.de/?p=u-boot.git;a=commit;h=f98852bfa9a99d7258eb06e4849e5c3d075f44cf
> > 
> > Rob
> > 