Message ID | 1341001359.3999.106.camel@keto |
---|---|
State | Accepted |
Commit | a1d2478e2d5011bed3e085033f11427fb1423efb |
Headers | show |
2012/6/29 Stephan Linz <linz@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. Thanks, Michal
Hi, On Fri, Jun 29, 2012 at 1:22 PM, Stephan Linz <linz@li-pro.net> wrote: > 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? > > > > > > > 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). > Yes - we want to move away from this and use a newer dtc which supports -i for include files, but can't yet. Stephen Warren suggested including the new dtc inside the U-Boot tree. > > > > 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) > I suppose this is ok. Really the better plan would be to use -i and specify the various directories where we can get include files. But for now, ok. Regards, Simon > > > br, > Stephan > > > It will be good for Microblaze (probably there is any smarter solution > for SKIP case not to have two cats there). > > The same situation will happen for Xilinx ppc support and partially for > upcoming ARM zynq where > > full DTS is generated for unique hw design. > > > > Here is the patch to show you what phase I would like to skip. > > > > diff --git a/dts/Makefile b/dts/Makefile > > index 914e479..d670cb8 100644 > > --- a/dts/Makefile > > +++ b/dts/Makefile > > @@ -45,9 +45,15 @@ all: $(obj).depend $(LIB) > > # the filename. > > DT_BIN := $(obj)dt.dtb > > > > +ifndef CONFIG_DTS_SKIP_PREPROCESSOR > > +SKIP := $(CPP) -P $(DTS_CPPFLAGS) - > > +else > > +SKIP := cat > > +endif > > + > > $(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts > > rc=$$( \ > > - cat $< | $(CPP) -P $(DTS_CPPFLAGS) - | \ > > + cat $< | $(SKIP) |\ > > { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 2>&1 ; \ > > echo $$? >&3 ; } | \ > > grep -v '^DTC: dts->dtb on file' ; \ > > > > > > Thanks for your comments. > > Michal > > > > >
Hi, On Sun, Jul 1, 2012 at 10:43 PM, Michal Simek <monstr@monstr.eu> wrote: > 2012/6/29 Stephan Linz <linz@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? Regards, Simon > > Thanks, > Michal >
Hi, Am Montag, den 02.07.2012, 07:43 +0200 schrieb Michal Simek: > 2012/6/29 Stephan Linz <linz@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. For Microblaze you can ignore the ARCH_CPU_DTS and the dtsi file in arch/cpu completely and ... > From my point of view will be the best to support only one dts file > (without dtsi) ... remove the ARCH_CPU_DTS inclusion in board/microblaze/dts/microblaze.dts -- instead use the new CPP substitution BOARD_DTS (patch above) to hide the content of the autogenerated dts from CPP until the new dtc with -i option will be available (see Simons E-Mail). Content of board/microblaze/dts/microblaze.dts is one line only: /include/ BOARD_DTS As an result the board/microblaze/dts/microblaze.dts will never changed again and you can save the autogenerated dts within the board specific code area in board/<vendor>/<boardname>/dts/microblaze.dts -- only one file have to be handled (changed). br, Stephan > because it is much cleaner then using 3 dts files. > > Thanks, > Michal > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
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@monstr.eu> wrote: > > > 2012/6/29 Stephan Linz <linz@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. br, Stephan > > Regards, > Simon > > > > > > Thanks, > > Michal > > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
Hi, On Tue, Jul 3, 2012 at 1:22 PM, Stephan Linz <linz@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@monstr.eu> wrote: > > > > > 2012/6/29 Stephan Linz <linz@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. Regards, Simon > > > br, > Stephan > > > > > > Regards, > > Simon > > > > > > > > > > Thanks, > > > Michal > > > > > _______________________________________________ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > > > > >
On 07/03/2012 09:05 PM, Simon Glass wrote: > Hi, > > On Fri, Jun 29, 2012 at 1:22 PM, Stephan Linz <linz@li-pro.net <mailto:linz@li-pro.net>> wrote: > > 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? > > > > > > > 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). > > > Yes - we want to move away from this and use a newer dtc which supports -i for include files, but can't yet. Stephen Warren suggested including the new dtc inside the U-Boot tree. ok > > > > > > 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) > > > I suppose this is ok. Really the better plan would be to use -i and specify the various directories where we can get include files. But for now, ok. What is the problem to add the latest dtc? 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
On 07/04/2012 03:48 AM, Simon Glass wrote: > Hi, > > On Tue, Jul 3, 2012 at 1:22 PM, Stephan Linz <linz@li-pro.net <mailto:linz@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@monstr.eu <mailto:monstr@monstr.eu>> wrote: > > > > > 2012/6/29 Stephan Linz <linz@li-pro.net <mailto:linz@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
On 07/03/2012 10:22 PM, Stephan Linz 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@monstr.eu> wrote: >> >>> 2012/6/29 Stephan Linz<linz@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. ok. Stephan: go ahead and create proper patch with empty dts/dtsi files. Thanks, Michal
On 07/04/2012 12:02 AM, Michal Simek wrote:
...
> What is the problem to add the latest dtc?
To really make use of device tree you need a recent dtc, but we've had
pushback requiring a recent dtc because people may not have it
installed. I asked Wolfgang a while back whether we could just put a
copy of dtc into the U-Boot source tree to avoid this issue, just like
the kernel did, but simply haven't received any response. Perhaps the
best thing is to just send a patch to do this; patches often get more
responses than non-patch email.
On 07/05/2012 05:34 PM, Stephen Warren wrote: > On 07/04/2012 12:02 AM, Michal Simek wrote: > ... >> What is the problem to add the latest dtc? > > To really make use of device tree you need a recent dtc, but we've had > pushback requiring a recent dtc because people may not have it > installed. I asked Wolfgang a while back whether we could just put a > copy of dtc into the U-Boot source tree to avoid this issue, just like > the kernel did, but simply haven't received any response. Perhaps the > best thing is to just send a patch to do this; patches often get more > responses than non-patch email. Yeah. When you send the patch, please cc me. I will test it with microblaze. Thanks, Michal
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)