[U-Boot] ARM CONFIG_OF_CONTROL status
Michal Simek
monstr at monstr.eu
Wed Jul 4 08:13:14 CEST 2012
On 07/04/2012 03:48 AM, Simon Glass wrote:
> Hi,
>
> On Tue, Jul 3, 2012 at 1:22 PM, Stephan Linz <linz at li-pro.net <mailto:linz at li-pro.net>> wrote:
>
> Am Dienstag, den 03.07.2012, 12:21 -0700 schrieb Simon Glass:
> > Hi,
> >
> > On Sun, Jul 1, 2012 at 10:43 PM, Michal Simek <monstr at monstr.eu <mailto:monstr at monstr.eu>> wrote:
> >
> > > 2012/6/29 Stephan Linz <linz at li-pro.net <mailto:linz at li-pro.net>>:
> > > > Am Freitag, den 29.06.2012, 10:18 +0200 schrieb Michal Simek:
> > > >> On 06/29/2012 04:32 AM, Simon Glass wrote:
> > > >> > Hi,
> > > >> >
> > > >> > --snip--
> > > >>
> > > >> I have sent support for Microblaze. Currently without dts because I
> > > want to clear this part a little bit.
> > > >
> > > > Hi Michal,
> > > >
> > > > looks good, I've been waiting a long time on the FDT support in U-Boot
> > > > for Microblaze -- great -- PS: see my comment on patch 5 ...
> > > >
> > > >>
> > > >> Tegra is using ./arch/arm/dts/tegra20.dtsi and
> > > board/nvidia/dts/tegra2-seaboard.dts
> > > >> and they are composed together in dts/Makefile by calling preprocessor.
> > > >> Microblaze will be totally different case because every Microblaze hw
> > > design is different.
> > > >
> > > > Yes, that's right. We will never be in the position to define a skeleton
> > > > or a basic platform configuration.
> > > >
> > > >> We can use two main buses (little and big endian) and cpu is also
> > > configurable.
> > > >> Based on this for Microblaze is the best solution directly to use dts.
> > > >> (DTS for Microblaze is also generated directly from design tool).
> > > >
> > > > ... directly in the context of a board, not arch/cpu, right?
> > >
> > > yes.
> > >
> > > >
> > > >>
> > > >>
> > > >> Anyway - here is the bug message I am getting if I use full dts in
> > > board/<name>/dts/microblaze.dts
> > > >> and empty arch/microblaze/dts/microblaze.dtsi
> > > >>
> > > >> <stdin>:34:3: error: invalid preprocessing directive #address
> > > >> <stdin>:35:3: error: invalid preprocessing directive #size
> > > >> <stdin>:52:4: error: invalid preprocessing directive #address
> > > >> <stdin>:53:4: error: invalid preprocessing directive #cpus
> > > >> <stdin>:54:4: error: invalid preprocessing directive #size
> > > >> <stdin>:155:4: error: invalid preprocessing directive #address
> > > >> <stdin>:156:4: error: invalid preprocessing directive #size
> > > >> <stdin>:160:5: error: invalid preprocessing directive #gpio
> > > >> <stdin>:192:5: error: invalid preprocessing directive #gpio
> > > >> <stdin>:209:5: error: invalid preprocessing directive #gpio
> > > >> <stdin>:241:5: error: invalid preprocessing directive #gpio
> > > >> <stdin>:267:5: error: invalid preprocessing directive #address
> > > >> <stdin>:268:5: error: invalid preprocessing directive #size
> > > >> <stdin>:394:5: error: invalid preprocessing directive #interrupt
> > > >>
> > > >> This is error for opposite case - empty microblaze.dts and full
> > > microblaze.dtsi.
> > > >
> > > > That are CPP errors, because the auto generated xilinx.dts is full of
> > > > CPP pragma like syntax (#something) that are wrong (invalid).
> > >
> > > I know what it is.
> > >
> > > >
> > > >>
> > > >> make[1]: Entering directory `/mnt/projects/u-boot/dts'
> > > >> rc=$( cat /mnt/projects/u-boot/board/petalogix/dts/microblaze.dts |
> > > microblaze-unknown-linux-gnu-gcc -E
> > > >> -P
> > > -DARCH_CPU_DTS=\"/mnt/projects/u-boot/arch/microblaze/dts/microblaze.dtsi\"
> > > - | { { dtc -R 4 -p 0x1000
> > > >> -O dtb -o dt.dtb - 2>&1 ; echo $? >&3 ; } | grep -v '^DTC: dts->dtb on
> > > file' ; } 3>&1 ) ; \
> > > >> exit $rc
> > > >> /bin/sh: line 1: exit: too many arguments
> > > >> make[1]: *** [dt.dtb] Error 1
> > > >> make[1]: Leaving directory `/mnt/projects/u-boot/dts'
> > > >>
> > > >>
> > > >> I have just tried to fix it by introducing new CONFIG option for
> > > skipping that preprocessor
> > > >> part.
> > > >
> > > > Instead of disable / skipp the CPP step you can hide the auto generated
> > > > xilinx.dts with a second include stage, for example:
> > > >
> > > > board/microblaze/dts/microblaze.dts looks like:
> > > >
> > > > /include/ ARCH_CPU_DTS
> > > > /include/ BOARD_DTS
> > > >
> > > >
> > > > Right, only two lines. The arch/microblaze/dts/microblaze.dtsi remains
> > > > empty as you have said above. Just new is BOARD_DTS -- with the attached
> > > > patch for dts/Makefile you can copy the auto generated xilinx.dts into
> > > > the specific board directory and the CPP step substitute the right place
> > > > to board/microblaze/microblaze-generic/dts/microblaze.dts
> > > >
> > > > I think there are no side effects with other ports like the tegra2.
> > > >
> > > > If you want you can omit the ARCH_CPU_DTS inclusion. The architectural
> > > > microblaze.dtsi file is empty and (!!) have to be empty, because the DTC
> > > > will break with an error on multiple "/dts-v1/;" lines!
> > > >
> > > > Here is the patch:
> > > >
> > > > diff --git a/dts/Makefile b/dts/Makefile
> > > > index 914e479..b1f47a1 100644
> > > > --- a/dts/Makefile
> > > > +++ b/dts/Makefile
> > > > @@ -36,7 +36,8 @@ $(error Your architecture does not have device tree
> > > > support enabled. \
> > > > Please define CONFIG_ARCH_DEVICE_TREE))
> > > >
> > > > # We preprocess the device tree file provide a useful define
> > > > -DTS_CPPFLAGS := -DARCH_CPU_DTS=
> > > > \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\"
> > > > +DTS_CPPFLAGS := -DARCH_CPU_DTS=
> > > > \"$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\" \
> > > > + -DBOARD_DTS=
> > > > \"$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\"
> > > >
> > > > all: $(obj).depend $(LIB)
> > >
> > > Not sure if using another dts file will be the best approach.
> > > From my point of view will be the best to support only one dts file
> > > (without dtsi)
> > > because it is much cleaner then using 3 dts files.
> > >
> >
> > Well there is no inherent problem with having multiple include files,
> > except that it is hard to support with the old dtc when there are in
> > different subdirs.
> >
> > As a workaround, how about putting the include files in the
> > board/vendor/dts subdir as well for now?
>
> Hi,
>
> good idea -- but they cannot be used directly. The substitution variable
> ARCH_CPU_DTS is already reserved for dtsi in arch/cpu. The Microblaze
> architecture needs a board specific dts onyl. That's why I think the new
> substitution variable BOARD_DTS can be a option to solve the CPP problem
> today and handle the dtc -i in the future.
>
> BOARD_DTS can point to anything below board/vendor and perhaps with a
> new configuration option similar to CONFIG_DEFAULT_DEVICE_TREE the
> substitution could be affected with freely selectable file name instead
> of DEVICE_TREE only.
>
>
> Just in case there is any confusion here...
>
> The device tree file is not necessarily intended to be built with/by the U-Boot Makefile.
Yes it is convenient to do that, but where you have multiple board variants it is actually best to have
the Makefile build U-Boot without a device tree, i.e. no need to select the particular board variant.
>
> Then, in a separate step:
>
> for board in ${list_of_available_boards}; do
> dtc ... ${board}.dts
> cat u-boot.bin ${board}.dtb >u-boot-${board}.bin
> done
>
> I mention this because if we make U-Boot build the particular board variant,
then have we actually achieved the goal of a single U-Boot image that supports multiple boards?
>
> So IMO the infrastructure to support the post-processing of U-Boot binaries and device trees
may not in fact belong in the U-Boot Makefile. It is convenient to be able to specify a device tree
for U-Boot to pick up and build, but I don't think it should come from the boards.cfg file -
after all the whole point is that we support a number of build variants.
The board name in boards.cfg will be something generic, like microblaze-dt, or similar.
>
> I hope that makes sense.
Yes, I am aware about it and make sense.
I am not sure if we can use only one u-boot binary for Microblaze with different device tree
because cpu has several variants (Sure we could use the minimum configuration but it is not the best
solution from performance point of view). Also ram baseaddr can vary. This can be skip by using MMU
but also I don't think that this is good solution for bootloader.
But I think that we could end with generated config.mk file with compilation flags for cpu variants and
u-boot start address.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
More information about the U-Boot
mailing list