[U-Boot] [PATCH 1/3] dm: dts: ls2085a: Bring in ls2085a dts files from linux kernel

Albert ARIBAUD albert.u.boot at aribaud.net
Wed Jul 8 11:19:33 CEST 2015


Hello Sharma,

On Wed, 8 Jul 2015 07:31:47 +0000, Sharma Bhupesh
<bhupesh.sharma at freescale.com> wrote:
> > -----Original Message-----
> > From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Wang
> > Haikun
> > On 7/8/2015 3:13 PM, Bin Meng wrote:
> > > Hi,
> > >
> > > On Wed, Jul 8, 2015 at 2:51 PM, Wang Haikun <Haikun.Wang at freescale.com>
> > wrote:
> > >> On 6/26/2015 7:53 PM, Haikun Wang wrote:
> > >>> From: Haikun Wang <Haikun.Wang at freescale.com>
> > >>>
> > >>> Bring in required device tree files for ls2085a from Linux.
> > >>> These are initially unchanged and have a number of pieces not needed
> > by U-Boot.
> > >> Hi Simon,
> > >>
> > >> I got below comment when review this patch internal.
> > >> Please help me confirm.
> > >>
> > >> "For new platforms like ARM64, it was discussed to not duplicate the
> > >> DTS in u-boot and Linux, simply because that will break compatibility
> > >> with other bootloaders like Linaro's BootMonitor and UEFI bootloader,
> > >> which do not place the DTS in the bootloader. Also in near future,
> > >> with DTS being replaced by ACPI gradually for ARM64 platforms, it was
> > >> discussed that in a longer run it would be beneficial to move DTS out
> > >> of both u-boot and Linux and maintain it as a separate tree."
> > >>
> > >
> > > I think UEFI + ACPI is only required for ARMv8 servers, not for all
> > > ARMv8 processors. Is ls2085a a processor targeting the server market?
> > No, at least it's not our major market.
> > I want to know whether we have made a conclusion that u-boot will not add
> > Arm64 dts files?
> 
> Adding Russell and Mark for their thoughts.
> 
> AFAIK there were discussions to generate common DTS files for PPC and ARM platforms,
> where it was discussed that in a longer run it would be beneficial to move DTS out
> of both u-boot and Linux and maintain it as a separate tree.

This might be what happens in the long term (and I pretty much agree
with having DTS common to, and separate from, any project that uses
them even though that means yet one more configuration item to manage
at the full project delivery level), but precisely because it is a
long term goal, it is not what's going on right now.

In the interim, and AFAIAC, I'm fine with DTS files living in U-Boot.
And I'd be finer yet with a simple way to specify where the DTS files
can be searched for at build time, using e.g. an env var, something
like:

  DTC_PATH = "/home/dev/linux/arch/arm/boot/dtc" tools/buildman/...

I believe this would be quite easy to implement in both U-Boot and
Linux with dtc_cpp_flags, by passing DTC_PATH as a -I option.

One could even specify a set of paths, which would produce several -I
options, for instance making dtc search first in U-Boot's own repo,
then in the standalone DTS files projects repo (once a standalone
DTS files project exists, that is). Looking in U-Boot first would allow
using U-boot as a staging area for new DTS files until the standalone
DTS project picks them up.

> Regards,
> Bhupesh

Amicalement,
-- 
Albert.


More information about the U-Boot mailing list