From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Wed, 04 Jul 2012 08:24:20 +0200 Subject: [U-Boot] ARM CONFIG_OF_CONTROL status In-Reply-To: <1341346946.2746.93.camel@keto> References: <4FEAD263.2020707@monstr.eu> <4FEB1A3C.7050207@monstr.eu> <4FEBF08D.2060604@monstr.eu> <4FEBFE72.20106@monstr.eu> <4FED64C3.8050302@monstr.eu> <1341001359.3999.106.camel@keto> <1341346946.2746.93.camel@keto> Message-ID: <4FF3E194.4000801@monstr.eu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 wrote: >> >>> 2012/6/29 Stephan Linz: >>>> 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//dts/microblaze.dts >>>>> and empty arch/microblaze/dts/microblaze.dtsi >>>>> >>>>> :34:3: error: invalid preprocessing directive #address >>>>> :35:3: error: invalid preprocessing directive #size >>>>> :52:4: error: invalid preprocessing directive #address >>>>> :53:4: error: invalid preprocessing directive #cpus >>>>> :54:4: error: invalid preprocessing directive #size >>>>> :155:4: error: invalid preprocessing directive #address >>>>> :156:4: error: invalid preprocessing directive #size >>>>> :160:5: error: invalid preprocessing directive #gpio >>>>> :192:5: error: invalid preprocessing directive #gpio >>>>> :209:5: error: invalid preprocessing directive #gpio >>>>> :241:5: error: invalid preprocessing directive #gpio >>>>> :267:5: error: invalid preprocessing directive #address >>>>> :268:5: error: invalid preprocessing directive #size >>>>> :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 -- 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