On 07/04/2012 03:48 AM, Simon Glass wrote:
Hi,
On Tue, Jul 3, 2012 at 1:22 PM, Stephan Linz <l...@li-pro.net
<mailto:l...@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 <mon...@monstr.eu
<mailto:mon...@monstr.eu>> wrote:
>
> > 2012/6/29 Stephan Linz <l...@li-pro.net <mailto:l...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
