diff mbox

DTB build failure due to preproccessing

Message ID 20130531114824.60D223E0901@localhost (mailing list archive)
State New, archived
Headers show

Commit Message

Grant Likely May 31, 2013, 11:48 a.m. UTC
On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
> actually a more general issue:
> 
>         $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb 
>           CC      scripts/mod/devicetable-offsets.s
>           GEN     scripts/mod/devicetable-offsets.h
>           HOSTCC  scripts/mod/file2alias.o
>           HOSTLD  scripts/mod/modpost
>           DTC     arch/powerpc/boot/virtex440-ml510.dtb
>         Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error
>         FATAL ERROR: Unable to parse input tree
>         make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1
>         make: *** [virtex440-ml510.dtb] Error 2
>         
> Line 374 is the "IDSEL 0x16..." line here:
> 			interrupt-map = <
> 				/* IRQ mapping for pci slots and ALI M1533
> 				 ...
> 				 * management core also isn't used.
> 				 */
> 
> 				/* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
> 				0x3000 0 0 1 &xps_intc_0 3 2
> 				0x3000 0 0 2 &xps_intc_0 2 2
> 				0x3000 0 0 3 &xps_intc_0 5 2
> 				0x3000 0 0 4 &xps_intc_0 4 2
> 
> Which gets preprocessed into:
>            interrupt-map = <
>         # 375 "arch/powerpc/boot/dts/virtex440-ml510.dts"
>             0x3000 0 0 1 &xps_intc_0 3 2
>             0x3000 0 0 2 &xps_intc_0 2 2
>             0x3000 0 0 3 &xps_intc_0 5 2
>             0x3000 0 0 4 &xps_intc_0 4 2
> 
> If I manually remove the "# 375 " line then that fixes the error
> (although there is then a subsequent one of the same type).
> 
> I suppose this is a bug in dtc? It appears to have at least some
> awareness of these preprocessor line number comments since it manages to
> report the original source line number.

dtc is only able to track line numbers when the native /include/
directive is used. The #include directive doesn't help it. It should be
added, but until it is the following patch solves the problem:

I've got this patch in my tree. Either Rob or I will push it to Linus in
the next few days.

g.

---
commit d01dccdcb3ea8233b09efb9c24db9f057fbd3b37
Author: Grant Likely <grant.likely@linaro.org>
Date:   Fri May 31 12:45:18 2013 +0100

    dtc: Suppress cpp linemarker annotations
    
    DTC isn't able to parse cpp linemarker annotations, so suppress them in
    the cpp output by adding the -P flag to the cpp options.
    
    Signed-off-by: Grant Likely <grant.likely@linaro.org>

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Ian Campbell May 31, 2013, 11:58 a.m. UTC | #1
On Fri, 2013-05-31 at 12:48 +0100, Grant Likely wrote:
> On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
> > actually a more general issue:
> > 
> >         $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb 
> >           CC      scripts/mod/devicetable-offsets.s
> >           GEN     scripts/mod/devicetable-offsets.h
> >           HOSTCC  scripts/mod/file2alias.o
> >           HOSTLD  scripts/mod/modpost
> >           DTC     arch/powerpc/boot/virtex440-ml510.dtb
> >         Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error
> >         FATAL ERROR: Unable to parse input tree
> >         make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1
> >         make: *** [virtex440-ml510.dtb] Error 2
> >         
> > Line 374 is the "IDSEL 0x16..." line here:
> > 			interrupt-map = <
> > 				/* IRQ mapping for pci slots and ALI M1533
> > 				 ...
> > 				 * management core also isn't used.
> > 				 */
> > 
> > 				/* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
> > 				0x3000 0 0 1 &xps_intc_0 3 2
> > 				0x3000 0 0 2 &xps_intc_0 2 2
> > 				0x3000 0 0 3 &xps_intc_0 5 2
> > 				0x3000 0 0 4 &xps_intc_0 4 2
> > 
> > Which gets preprocessed into:
> >            interrupt-map = <
> >         # 375 "arch/powerpc/boot/dts/virtex440-ml510.dts"
> >             0x3000 0 0 1 &xps_intc_0 3 2
> >             0x3000 0 0 2 &xps_intc_0 2 2
> >             0x3000 0 0 3 &xps_intc_0 5 2
> >             0x3000 0 0 4 &xps_intc_0 4 2
> > 
> > If I manually remove the "# 375 " line then that fixes the error
> > (although there is then a subsequent one of the same type).
> > 
> > I suppose this is a bug in dtc? It appears to have at least some
> > awareness of these preprocessor line number comments since it manages to
> > report the original source line number.
> 
> dtc is only able to track line numbers when the native /include/
> directive is used. The #include directive doesn't help it. It should be
> added, but until it is the following patch solves the problem:
> 
> I've got this patch in my tree. Either Rob or I will push it to Linus in
> the next few days.

Thanks, I'll do something similar in my device-tree.git tree.

Ian


--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jon Loeliger May 31, 2013, 1:01 p.m. UTC | #2
> >         
> > Line 374 is the "IDSEL 0x16..." line here:
> > 			interrupt-map = <
> > 				/* IRQ mapping for pci slots and ALI M1533
> > 				 ...
> > 				 * management core also isn't used.
> > 				 */
> > 
> > 				/* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
> > 				0x3000 0 0 1 &xps_intc_0 3 2
> > 				0x3000 0 0 2 &xps_intc_0 2 2
> > 				0x3000 0 0 3 &xps_intc_0 5 2
> > 				0x3000 0 0 4 &xps_intc_0 4 2

Can you show me the original source without mods here, please?
Or is the "..." purely elided comments?

> > Which gets preprocessed into:
> >            interrupt-map = <
> >         # 375 "arch/powerpc/boot/dts/virtex440-ml510.dts"
> >             0x3000 0 0 1 &xps_intc_0 3 2
> >             0x3000 0 0 2 &xps_intc_0 2 2
> >             0x3000 0 0 3 &xps_intc_0 5 2
> >             0x3000 0 0 4 &xps_intc_0 4 2


> dtc is only able to track line numbers when the native /include/
> directive is used. The #include directive doesn't help it. It should be
> added, but until it is the following patch solves the problem:

It's supposed to do better than that, I think.
This, from dtc-lexer.l

<*>^"#"(line)?{WS}+[0-9]+{WS}+{STRING}({WS}+[0-9]+)? {
                        char *line, *tmp, *fn;
                        /* skip text before line # */
                        line = yytext;
                        while (!isdigit(*line))
                                line++;
                        /* skip digits in line # */
                        tmp = line;
                        while (!isspace(*tmp))
                                tmp++;
                        /* "NULL"-terminate line # */
                        *tmp = '\0';
                        /* start of filename */
                        fn = strchr(tmp + 1, '"') + 1;
                        /* strip trailing " from filename */
                        tmp = strchr(fn, '"');
                        *tmp = 0;
                        /* -1 since #line is the number of the next line */
                        srcpos_set_line(xstrdup(fn), atoi(line) - 1);
                }

Hrm.  Is this a "that's not in the kernel's copy yet" problem?
Or did this fail to match the offending '# <line> <file>' somehow?
(Like, is that '# 375' really in column 1?)

Thanks,
jdl
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ian Campbell May 31, 2013, 1:07 p.m. UTC | #3
On Fri, 2013-05-31 at 08:01 -0500, Jon Loeliger wrote:
> > >         
> > > Line 374 is the "IDSEL 0x16..." line here:
> > > 			interrupt-map = <
> > > 				/* IRQ mapping for pci slots and ALI M1533
> > > 				 ...
> > > 				 * management core also isn't used.
> > > 				 */
> > > 
> > > 				/* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
> > > 				0x3000 0 0 1 &xps_intc_0 3 2
> > > 				0x3000 0 0 2 &xps_intc_0 2 2
> > > 				0x3000 0 0 3 &xps_intc_0 5 2
> > > 				0x3000 0 0 4 &xps_intc_0 4 2
> 
> Can you show me the original source without mods here, please?

This is Linux v3.10-rc3 arch/powerpc/boot/dts/virtex440-ml510.dts also
attached.

> Or is the "..." purely elided comments?

Yes.

> > > Which gets preprocessed into:
> > >            interrupt-map = <
> > >         # 375 "arch/powerpc/boot/dts/virtex440-ml510.dts"
> > >             0x3000 0 0 1 &xps_intc_0 3 2
> > >             0x3000 0 0 2 &xps_intc_0 2 2
> > >             0x3000 0 0 3 &xps_intc_0 5 2
> > >             0x3000 0 0 4 &xps_intc_0 4 2
> 
> 
> > dtc is only able to track line numbers when the native /include/
> > directive is used. The #include directive doesn't help it. It should be
> > added, but until it is the following patch solves the problem:
> 
> It's supposed to do better than that, I think.
> This, from dtc-lexer.l
> 
> <*>^"#"(line)?{WS}+[0-9]+{WS}+{STRING}({WS}+[0-9]+)? {
>                         char *line, *tmp, *fn;
>                         /* skip text before line # */
>                         line = yytext;
>                         while (!isdigit(*line))
>                                 line++;
>                         /* skip digits in line # */
>                         tmp = line;
>                         while (!isspace(*tmp))
>                                 tmp++;
>                         /* "NULL"-terminate line # */
>                         *tmp = '\0';
>                         /* start of filename */
>                         fn = strchr(tmp + 1, '"') + 1;
>                         /* strip trailing " from filename */
>                         tmp = strchr(fn, '"');
>                         *tmp = 0;
>                         /* -1 since #line is the number of the next line */
>                         srcpos_set_line(xstrdup(fn), atoi(line) - 1);
>                 }
> 
> Hrm.  Is this a "that's not in the kernel's copy yet" problem?
> Or did this fail to match the offending '# <line> <file>' somehow?
> (Like, is that '# 375' really in column 1?)

The "#" is in the first column.

I've attached the actual file.

Ian.
# 1 "arch/powerpc/boot/dts/virtex440-ml510.dts"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "arch/powerpc/boot/dts/virtex440-ml510.dts"
# 12 "arch/powerpc/boot/dts/virtex440-ml510.dts"
/dts-v1/;
/ {
 #address-cells = <1>;
 #size-cells = <1>;
 compatible = "xlnx,ml510-ref-design", "xlnx,virtex440";
 dcr-parent = <&ppc440_0>;
 DDR2_SDRAM_DIMM0: memory@0 {
  device_type = "memory";
  reg = < 0x0 0x20000000 >;
 } ;
 alias {
  ethernet0 = &Hard_Ethernet_MAC;
  serial0 = &RS232_Uart_1;
 } ;
 chosen {
  bootargs = "console=ttyS0 root=/dev/ram";
  linux,stdout-path = "/plb@0/serial@83e00000";
 } ;
 cpus {
  #address-cells = <1>;
  #cpus = <0x1>;
  #size-cells = <0>;
  ppc440_0: cpu@0 {
   #address-cells = <1>;
   #size-cells = <1>;
   clock-frequency = <300000000>;
   compatible = "PowerPC,440", "ibm,ppc440";
   d-cache-line-size = <0x20>;
   d-cache-size = <0x8000>;
   dcr-access-method = "native";
   dcr-controller ;
   device_type = "cpu";
   i-cache-line-size = <0x20>;
   i-cache-size = <0x8000>;
   model = "PowerPC,440";
   reg = <0>;
   timebase-frequency = <300000000>;
   xlnx,apu-control = <0x2000>;
   xlnx,apu-udi-0 = <0x0>;
   xlnx,apu-udi-1 = <0x0>;
   xlnx,apu-udi-10 = <0x0>;
   xlnx,apu-udi-11 = <0x0>;
   xlnx,apu-udi-12 = <0x0>;
   xlnx,apu-udi-13 = <0x0>;
   xlnx,apu-udi-14 = <0x0>;
   xlnx,apu-udi-15 = <0x0>;
   xlnx,apu-udi-2 = <0x0>;
   xlnx,apu-udi-3 = <0x0>;
   xlnx,apu-udi-4 = <0x0>;
   xlnx,apu-udi-5 = <0x0>;
   xlnx,apu-udi-6 = <0x0>;
   xlnx,apu-udi-7 = <0x0>;
   xlnx,apu-udi-8 = <0x0>;
   xlnx,apu-udi-9 = <0x0>;
   xlnx,dcr-autolock-enable = <0x1>;
   xlnx,dcu-rd-ld-cache-plb-prio = <0x0>;
   xlnx,dcu-rd-noncache-plb-prio = <0x0>;
   xlnx,dcu-rd-touch-plb-prio = <0x0>;
   xlnx,dcu-rd-urgent-plb-prio = <0x0>;
   xlnx,dcu-wr-flush-plb-prio = <0x0>;
   xlnx,dcu-wr-store-plb-prio = <0x0>;
   xlnx,dcu-wr-urgent-plb-prio = <0x0>;
   xlnx,dma0-control = <0x0>;
   xlnx,dma0-plb-prio = <0x0>;
   xlnx,dma0-rxchannelctrl = <0x1010000>;
   xlnx,dma0-rxirqtimer = <0x3ff>;
   xlnx,dma0-txchannelctrl = <0x1010000>;
   xlnx,dma0-txirqtimer = <0x3ff>;
   xlnx,dma1-control = <0x0>;
   xlnx,dma1-plb-prio = <0x0>;
   xlnx,dma1-rxchannelctrl = <0x1010000>;
   xlnx,dma1-rxirqtimer = <0x3ff>;
   xlnx,dma1-txchannelctrl = <0x1010000>;
   xlnx,dma1-txirqtimer = <0x3ff>;
   xlnx,dma2-control = <0x0>;
   xlnx,dma2-plb-prio = <0x0>;
   xlnx,dma2-rxchannelctrl = <0x1010000>;
   xlnx,dma2-rxirqtimer = <0x3ff>;
   xlnx,dma2-txchannelctrl = <0x1010000>;
   xlnx,dma2-txirqtimer = <0x3ff>;
   xlnx,dma3-control = <0x0>;
   xlnx,dma3-plb-prio = <0x0>;
   xlnx,dma3-rxchannelctrl = <0x1010000>;
   xlnx,dma3-rxirqtimer = <0x3ff>;
   xlnx,dma3-txchannelctrl = <0x1010000>;
   xlnx,dma3-txirqtimer = <0x3ff>;
   xlnx,endian-reset = <0x0>;
   xlnx,generate-plb-timespecs = <0x1>;
   xlnx,icu-rd-fetch-plb-prio = <0x0>;
   xlnx,icu-rd-spec-plb-prio = <0x0>;
   xlnx,icu-rd-touch-plb-prio = <0x0>;
   xlnx,interconnect-imask = <0xffffffff>;
   xlnx,mplb-allow-lock-xfer = <0x1>;
   xlnx,mplb-arb-mode = <0x0>;
   xlnx,mplb-awidth = <0x20>;
   xlnx,mplb-counter = <0x500>;
   xlnx,mplb-dwidth = <0x80>;
   xlnx,mplb-max-burst = <0x8>;
   xlnx,mplb-native-dwidth = <0x80>;
   xlnx,mplb-p2p = <0x0>;
   xlnx,mplb-prio-dcur = <0x2>;
   xlnx,mplb-prio-dcuw = <0x3>;
   xlnx,mplb-prio-icu = <0x4>;
   xlnx,mplb-prio-splb0 = <0x1>;
   xlnx,mplb-prio-splb1 = <0x0>;
   xlnx,mplb-read-pipe-enable = <0x1>;
   xlnx,mplb-sync-tattribute = <0x0>;
   xlnx,mplb-wdog-enable = <0x1>;
   xlnx,mplb-write-pipe-enable = <0x1>;
   xlnx,mplb-write-post-enable = <0x1>;
   xlnx,num-dma = <0x0>;
   xlnx,pir = <0xf>;
   xlnx,ppc440mc-addr-base = <0x0>;
   xlnx,ppc440mc-addr-high = <0x1fffffff>;
   xlnx,ppc440mc-arb-mode = <0x0>;
   xlnx,ppc440mc-bank-conflict-mask = <0x1800000>;
   xlnx,ppc440mc-control = <0xf810008f>;
   xlnx,ppc440mc-max-burst = <0x8>;
   xlnx,ppc440mc-prio-dcur = <0x2>;
   xlnx,ppc440mc-prio-dcuw = <0x3>;
   xlnx,ppc440mc-prio-icu = <0x4>;
   xlnx,ppc440mc-prio-splb0 = <0x1>;
   xlnx,ppc440mc-prio-splb1 = <0x0>;
   xlnx,ppc440mc-row-conflict-mask = <0x7ffe00>;
   xlnx,ppcdm-asyncmode = <0x0>;
   xlnx,ppcds-asyncmode = <0x0>;
   xlnx,user-reset = <0x0>;
  } ;
 } ;
 plb_v46_0: plb@0 {
  #address-cells = <1>;
  #size-cells = <1>;
  compatible = "xlnx,plb-v46-1.03.a", "simple-bus";
  ranges ;
  FLASH: flash@fc000000 {
   bank-width = <2>;
   compatible = "xlnx,xps-mch-emc-2.00.a", "cfi-flash";
   reg = < 0xfc000000 0x2000000 >;
   xlnx,family = "virtex5";
   xlnx,include-datawidth-matching-0 = <0x1>;
   xlnx,include-datawidth-matching-1 = <0x0>;
   xlnx,include-datawidth-matching-2 = <0x0>;
   xlnx,include-datawidth-matching-3 = <0x0>;
   xlnx,include-negedge-ioregs = <0x0>;
   xlnx,include-plb-ipif = <0x1>;
   xlnx,include-wrbuf = <0x1>;
   xlnx,max-mem-width = <0x10>;
   xlnx,mch-native-dwidth = <0x20>;
   xlnx,mch-plb-clk-period-ps = <0x2710>;
   xlnx,mch-splb-awidth = <0x20>;
   xlnx,mch0-accessbuf-depth = <0x10>;
   xlnx,mch0-protocol = <0x0>;
   xlnx,mch0-rddatabuf-depth = <0x10>;
   xlnx,mch1-accessbuf-depth = <0x10>;
   xlnx,mch1-protocol = <0x0>;
   xlnx,mch1-rddatabuf-depth = <0x10>;
   xlnx,mch2-accessbuf-depth = <0x10>;
   xlnx,mch2-protocol = <0x0>;
   xlnx,mch2-rddatabuf-depth = <0x10>;
   xlnx,mch3-accessbuf-depth = <0x10>;
   xlnx,mch3-protocol = <0x0>;
   xlnx,mch3-rddatabuf-depth = <0x10>;
   xlnx,mem0-width = <0x10>;
   xlnx,mem1-width = <0x20>;
   xlnx,mem2-width = <0x20>;
   xlnx,mem3-width = <0x20>;
   xlnx,num-banks-mem = <0x1>;
   xlnx,num-channels = <0x2>;
   xlnx,priority-mode = <0x0>;
   xlnx,synch-mem-0 = <0x0>;
   xlnx,synch-mem-1 = <0x0>;
   xlnx,synch-mem-2 = <0x0>;
   xlnx,synch-mem-3 = <0x0>;
   xlnx,synch-pipedelay-0 = <0x2>;
   xlnx,synch-pipedelay-1 = <0x2>;
   xlnx,synch-pipedelay-2 = <0x2>;
   xlnx,synch-pipedelay-3 = <0x2>;
   xlnx,tavdv-ps-mem-0 = <0x1adb0>;
   xlnx,tavdv-ps-mem-1 = <0x3a98>;
   xlnx,tavdv-ps-mem-2 = <0x3a98>;
   xlnx,tavdv-ps-mem-3 = <0x3a98>;
   xlnx,tcedv-ps-mem-0 = <0x1adb0>;
   xlnx,tcedv-ps-mem-1 = <0x3a98>;
   xlnx,tcedv-ps-mem-2 = <0x3a98>;
   xlnx,tcedv-ps-mem-3 = <0x3a98>;
   xlnx,thzce-ps-mem-0 = <0x88b8>;
   xlnx,thzce-ps-mem-1 = <0x1b58>;
   xlnx,thzce-ps-mem-2 = <0x1b58>;
   xlnx,thzce-ps-mem-3 = <0x1b58>;
   xlnx,thzoe-ps-mem-0 = <0x1b58>;
   xlnx,thzoe-ps-mem-1 = <0x1b58>;
   xlnx,thzoe-ps-mem-2 = <0x1b58>;
   xlnx,thzoe-ps-mem-3 = <0x1b58>;
   xlnx,tlzwe-ps-mem-0 = <0x88b8>;
   xlnx,tlzwe-ps-mem-1 = <0x0>;
   xlnx,tlzwe-ps-mem-2 = <0x0>;
   xlnx,tlzwe-ps-mem-3 = <0x0>;
   xlnx,twc-ps-mem-0 = <0x1adb0>;
   xlnx,twc-ps-mem-1 = <0x3a98>;
   xlnx,twc-ps-mem-2 = <0x3a98>;
   xlnx,twc-ps-mem-3 = <0x3a98>;
   xlnx,twp-ps-mem-0 = <0x11170>;
   xlnx,twp-ps-mem-1 = <0x2ee0>;
   xlnx,twp-ps-mem-2 = <0x2ee0>;
   xlnx,twp-ps-mem-3 = <0x2ee0>;
   xlnx,xcl0-linesize = <0x4>;
   xlnx,xcl0-writexfer = <0x1>;
   xlnx,xcl1-linesize = <0x4>;
   xlnx,xcl1-writexfer = <0x1>;
   xlnx,xcl2-linesize = <0x4>;
   xlnx,xcl2-writexfer = <0x1>;
   xlnx,xcl3-linesize = <0x4>;
   xlnx,xcl3-writexfer = <0x1>;
  } ;
  Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
   #address-cells = <1>;
   #size-cells = <1>;
   compatible = "xlnx,compound";
   ethernet@81c00000 {
    compatible = "xlnx,xps-ll-temac-1.01.b";
    device_type = "network";
    interrupt-parent = <&xps_intc_0>;
    interrupts = < 8 2 >;
    llink-connected = <&Hard_Ethernet_MAC_fifo>;
    local-mac-address = [ 02 00 00 00 00 00 ];
    reg = < 0x81c00000 0x40 >;
    xlnx,bus2core-clk-ratio = <0x1>;
    xlnx,phy-type = <0x3>;
    xlnx,phyaddr = <0x1>;
    xlnx,rxcsum = <0x0>;
    xlnx,rxfifo = <0x8000>;
    xlnx,temac-type = <0x0>;
    xlnx,txcsum = <0x0>;
    xlnx,txfifo = <0x8000>;
   } ;
  } ;
  Hard_Ethernet_MAC_fifo: xps-ll-fifo@81a00000 {
   compatible = "xlnx,xps-ll-fifo-1.01.a";
   interrupt-parent = <&xps_intc_0>;
   interrupts = < 6 2 >;
   reg = < 0x81a00000 0x10000 >;
   xlnx,family = "virtex5";
  } ;
  IIC_EEPROM: i2c@81600000 {
   compatible = "xlnx,xps-iic-2.00.a";
   interrupt-parent = <&xps_intc_0>;
   interrupts = < 9 2 >;
   reg = < 0x81600000 0x10000 >;
   xlnx,clk-freq = <0x5f5e100>;
   xlnx,family = "virtex5";
   xlnx,gpo-width = <0x1>;
   xlnx,iic-freq = <0x186a0>;
   xlnx,scl-inertial-delay = <0x5>;
   xlnx,sda-inertial-delay = <0x5>;
   xlnx,ten-bit-adr = <0x0>;
  } ;
  LCD_OPTIONAL: gpio@81420000 {
   compatible = "xlnx,xps-gpio-1.00.a";
   reg = < 0x81420000 0x10000 >;
   xlnx,all-inputs = <0x0>;
   xlnx,all-inputs-2 = <0x0>;
   xlnx,dout-default = <0x0>;
   xlnx,dout-default-2 = <0x0>;
   xlnx,family = "virtex5";
   xlnx,gpio-width = <0xb>;
   xlnx,interrupt-present = <0x0>;
   xlnx,is-bidir = <0x1>;
   xlnx,is-bidir-2 = <0x1>;
   xlnx,is-dual = <0x0>;
   xlnx,tri-default = <0xffffffff>;
   xlnx,tri-default-2 = <0xffffffff>;
  } ;
  LEDs_4Bit: gpio@81400000 {
   compatible = "xlnx,xps-gpio-1.00.a";
   reg = < 0x81400000 0x10000 >;
   xlnx,all-inputs = <0x0>;
   xlnx,all-inputs-2 = <0x0>;
   xlnx,dout-default = <0x0>;
   xlnx,dout-default-2 = <0x0>;
   xlnx,family = "virtex5";
   xlnx,gpio-width = <0x4>;
   xlnx,interrupt-present = <0x0>;
   xlnx,is-bidir = <0x1>;
   xlnx,is-bidir-2 = <0x1>;
   xlnx,is-dual = <0x0>;
   xlnx,tri-default = <0xffffffff>;
   xlnx,tri-default-2 = <0xffffffff>;
  } ;
  RS232_Uart_1: serial@83e00000 {
   clock-frequency = <100000000>;
   compatible = "xlnx,xps-uart16550-2.00.b", "ns16550";
   current-speed = <9600>;
   device_type = "serial";
   interrupt-parent = <&xps_intc_0>;
   interrupts = < 11 2 >;
   reg = < 0x83e00000 0x10000 >;
   reg-offset = <0x1003>;
   reg-shift = <2>;
   xlnx,family = "virtex5";
   xlnx,has-external-rclk = <0x0>;
   xlnx,has-external-xin = <0x0>;
   xlnx,is-a-16550 = <0x1>;
  } ;
  SPI_EEPROM: xps-spi@feff8000 {
   compatible = "xlnx,xps-spi-2.00.b";
   interrupt-parent = <&xps_intc_0>;
   interrupts = < 10 2 >;
   reg = < 0xfeff8000 0x80 >;
   xlnx,family = "virtex5";
   xlnx,fifo-exist = <0x1>;
   xlnx,num-ss-bits = <0x1>;
   xlnx,num-transfer-bits = <0x8>;
   xlnx,sck-ratio = <0x80>;
  } ;
  SysACE_CompactFlash: sysace@83600000 {
   compatible = "xlnx,xps-sysace-1.00.a";
   interrupt-parent = <&xps_intc_0>;
   interrupts = < 7 2 >;
   reg = < 0x83600000 0x10000 >;
   xlnx,family = "virtex5";
   xlnx,mem-width = <0x10>;
  } ;
  plbv46_pci_0: plbv46-pci@85e00000 {
   #size-cells = <2>;
   #address-cells = <3>;
   compatible = "xlnx,plbv46-pci-1.03.a";
   device_type = "pci";
   reg = < 0x85e00000 0x10000 >;
# 350 "arch/powerpc/boot/dts/virtex440-ml510.dts"
   ranges = <0x02000000 0 0xa0000000 0xa0000000 0 0x20000000
      0x01000000 0 0x00000000 0xf0000000 0 0x00010000>;

   #interrupt-cells = <1>;
   interrupt-parent = <&xps_intc_0>;
   interrupt-map-mask = <0xff00 0x0 0x0 0x7>;
   interrupt-map = <
# 375 "arch/powerpc/boot/dts/virtex440-ml510.dts"
    0x3000 0 0 1 &xps_intc_0 3 2
    0x3000 0 0 2 &xps_intc_0 2 2
    0x3000 0 0 3 &xps_intc_0 5 2
    0x3000 0 0 4 &xps_intc_0 4 2
# 396 "arch/powerpc/boot/dts/virtex440-ml510.dts"
    0x2800 0 0 1 &xps_intc_0 4 2
# 412 "arch/powerpc/boot/dts/virtex440-ml510.dts"
    0x0800 0 0 1 &i8259 7 2


    0x5800 0 0 1 &i8259 14 2


    0x7800 0 0 1 &i8259 7 2
   >;
   ali_m1533 {
    #size-cells = <1>;
    #address-cells = <2>;
    i8259: interrupt-controller@20 {
     reg = <1 0x20 2
       1 0xa0 2
       1 0x4d0 2>;
     interrupt-controller;
     device_type = "interrupt-controller";
     #address-cells = <0>;
     #interrupt-cells = <2>;
     compatible = "chrp,iic";


     interrupts = <1 3>;
     interrupt-parent = <&xps_intc_0>;
    };
   };
  } ;
  xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffff0000 {
   compatible = "xlnx,xps-bram-if-cntlr-1.00.a";
   reg = < 0xffff0000 0x10000 >;
   xlnx,family = "virtex5";
  } ;
  xps_intc_0: interrupt-controller@81800000 {
   #interrupt-cells = <0x2>;
   compatible = "xlnx,xps-intc-1.00.a";
   interrupt-controller ;
   reg = < 0x81800000 0x10000 >;
   xlnx,num-intr-inputs = <0xc>;
  } ;
  xps_tft_0: tft@86e00000 {
   compatible = "xlnx,xps-tft-1.00.a";
   reg = < 0x86e00000 0x10000 >;
   xlnx,dcr-splb-slave-if = <0x1>;
   xlnx,default-tft-base-addr = <0x0>;
   xlnx,family = "virtex5";
   xlnx,i2c-slave-addr = <0x76>;
   xlnx,mplb-awidth = <0x20>;
   xlnx,mplb-dwidth = <0x80>;
   xlnx,mplb-native-dwidth = <0x40>;
   xlnx,mplb-smallest-slave = <0x20>;
   xlnx,tft-interface = <0x1>;
  } ;
 } ;
} ;
Ian Campbell May 31, 2013, 1:16 p.m. UTC | #4
On Fri, 2013-05-31 at 08:01 -0500, Jon Loeliger wrote:
> Hrm.  Is this a "that's not in the kernel's copy yet" problem? 

BTW I'm using dtc.git 4e76ec796c90d44d417f82d9db2d67cfe575f8ed and not
the kernel copy. 

dtc-lexer.l in my HEAD is identical to the current master
(2e3fc7e9b3a4722a5500afaa9faf7874c61b2e6a) according to git diff.

Ian.

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Warren May 31, 2013, 4:04 p.m. UTC | #5
On 05/31/2013 05:48 AM, Grant Likely wrote:
> On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
>> actually a more general issue:
>>
>>         $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb 
>>           CC      scripts/mod/devicetable-offsets.s
>>           GEN     scripts/mod/devicetable-offsets.h
>>           HOSTCC  scripts/mod/file2alias.o
>>           HOSTLD  scripts/mod/modpost
>>           DTC     arch/powerpc/boot/virtex440-ml510.dtb
>>         Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error
>>         FATAL ERROR: Unable to parse input tree
>>         make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1
>>         make: *** [virtex440-ml510.dtb] Error 2
>>         
>> Line 374 is the "IDSEL 0x16..." line here:
>> 			interrupt-map = <
>> 				/* IRQ mapping for pci slots and ALI M1533
>> 				 ...
>> 				 * management core also isn't used.
>> 				 */
>>
>> 				/* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
>> 				0x3000 0 0 1 &xps_intc_0 3 2
>> 				0x3000 0 0 2 &xps_intc_0 2 2
>> 				0x3000 0 0 3 &xps_intc_0 5 2
>> 				0x3000 0 0 4 &xps_intc_0 4 2
>>
>> Which gets preprocessed into:
>>            interrupt-map = <
>>         # 375 "arch/powerpc/boot/dts/virtex440-ml510.dts"
>>             0x3000 0 0 1 &xps_intc_0 3 2
>>             0x3000 0 0 2 &xps_intc_0 2 2
>>             0x3000 0 0 3 &xps_intc_0 5 2
>>             0x3000 0 0 4 &xps_intc_0 4 2
>>
>> If I manually remove the "# 375 " line then that fixes the error
>> (although there is then a subsequent one of the same type).
>>
>> I suppose this is a bug in dtc? It appears to have at least some
>> awareness of these preprocessor line number comments since it manages to
>> report the original source line number.
> 
> dtc is only able to track line numbers when the native /include/
> directive is used. The #include directive doesn't help it. It should be
> added, but until it is the following patch solves the problem:
> 
> I've got this patch in my tree. Either Rob or I will push it to Linus in
> the next few days.
> 
> g.
> 
> ---
> commit d01dccdcb3ea8233b09efb9c24db9f057fbd3b37
> Author: Grant Likely <grant.likely@linaro.org>
> Date:   Fri May 31 12:45:18 2013 +0100
> 
>     dtc: Suppress cpp linemarker annotations
>     
>     DTC isn't able to parse cpp linemarker annotations, so suppress them in
>     the cpp output by adding the -P flag to the cpp options.

That's not true; it explicitly does have code to parse the line markers.
I'll have to investigate why it isn't working in this case.

If you apply this patch, then anyone who has switched to #include rther
than /include/ will get incorrect line numbers in dtc error messages.
Admittedly that's a smaller population right now though. Perhaps we
should just do a kernel-wide conversion though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Grant Likely May 31, 2013, 4:31 p.m. UTC | #6
On Fri, May 31, 2013 at 5:04 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 05/31/2013 05:48 AM, Grant Likely wrote:
>> On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
>>> actually a more general issue:
>>>
>>>         $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb
>>>           CC      scripts/mod/devicetable-offsets.s
>>>           GEN     scripts/mod/devicetable-offsets.h
>>>           HOSTCC  scripts/mod/file2alias.o
>>>           HOSTLD  scripts/mod/modpost
>>>           DTC     arch/powerpc/boot/virtex440-ml510.dtb
>>>         Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error
>>>         FATAL ERROR: Unable to parse input tree
>>>         make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1
>>>         make: *** [virtex440-ml510.dtb] Error 2
>>>
>>> Line 374 is the "IDSEL 0x16..." line here:
>>>                      interrupt-map = <
>>>                              /* IRQ mapping for pci slots and ALI M1533
>>>                               ...
>>>                               * management core also isn't used.
>>>                               */
>>>
>>>                              /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
>>>                              0x3000 0 0 1 &xps_intc_0 3 2
>>>                              0x3000 0 0 2 &xps_intc_0 2 2
>>>                              0x3000 0 0 3 &xps_intc_0 5 2
>>>                              0x3000 0 0 4 &xps_intc_0 4 2
>>>
>>> Which gets preprocessed into:
>>>            interrupt-map = <
>>>         # 375 "arch/powerpc/boot/dts/virtex440-ml510.dts"
>>>             0x3000 0 0 1 &xps_intc_0 3 2
>>>             0x3000 0 0 2 &xps_intc_0 2 2
>>>             0x3000 0 0 3 &xps_intc_0 5 2
>>>             0x3000 0 0 4 &xps_intc_0 4 2
>>>
>>> If I manually remove the "# 375 " line then that fixes the error
>>> (although there is then a subsequent one of the same type).
>>>
>>> I suppose this is a bug in dtc? It appears to have at least some
>>> awareness of these preprocessor line number comments since it manages to
>>> report the original source line number.
>>
>> dtc is only able to track line numbers when the native /include/
>> directive is used. The #include directive doesn't help it. It should be
>> added, but until it is the following patch solves the problem:
>>
>> I've got this patch in my tree. Either Rob or I will push it to Linus in
>> the next few days.
>>
>> g.
>>
>> ---
>> commit d01dccdcb3ea8233b09efb9c24db9f057fbd3b37
>> Author: Grant Likely <grant.likely@linaro.org>
>> Date:   Fri May 31 12:45:18 2013 +0100
>>
>>     dtc: Suppress cpp linemarker annotations
>>
>>     DTC isn't able to parse cpp linemarker annotations, so suppress them in
>>     the cpp output by adding the -P flag to the cpp options.
>
> That's not true; it explicitly does have code to parse the line markers.
> I'll have to investigate why it isn't working in this case.
>
> If you apply this patch, then anyone who has switched to #include rther
> than /include/ will get incorrect line numbers in dtc error messages.
> Admittedly that's a smaller population right now though. Perhaps we
> should just do a kernel-wide conversion though.

My mistake. I tested the wrong thing. I've dropped the patch.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ian Campbell June 3, 2013, 9:44 a.m. UTC | #7
On Fri, 2013-05-31 at 17:31 +0100, Grant Likely wrote:
> On Fri, May 31, 2013 at 5:04 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > On 05/31/2013 05:48 AM, Grant Likely wrote:
> >> ---
> >> commit d01dccdcb3ea8233b09efb9c24db9f057fbd3b37
> >> Author: Grant Likely <grant.likely@linaro.org>
> >> Date:   Fri May 31 12:45:18 2013 +0100
> >>
> >>     dtc: Suppress cpp linemarker annotations
> >>
> >>     DTC isn't able to parse cpp linemarker annotations, so suppress them in
> >>     the cpp output by adding the -P flag to the cpp options.
> >
> > That's not true; it explicitly does have code to parse the line markers.
> > I'll have to investigate why it isn't working in this case.
> >
> > If you apply this patch, then anyone who has switched to #include rther
> > than /include/ will get incorrect line numbers in dtc error messages.
> > Admittedly that's a smaller population right now though. Perhaps we
> > should just do a kernel-wide conversion though.
> 
> My mistake. I tested the wrong thing. I've dropped the patch.

FWIW I've also dropped it from my device-tree.git tree.

Ian.


--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 51bb3de..fc08a2b 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -149,7 +149,7 @@  cpp_flags      = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE)     \
 
 ld_flags       = $(LDFLAGS) $(ldflags-y)
 
-dtc_cpp_flags  = -Wp,-MD,$(depfile).pre -nostdinc                        \
+dtc_cpp_flags  = -Wp,-MD,$(depfile).pre -nostdinc -P                     \
 		 -I$(srctree)/arch/$(SRCARCH)/boot/dts                   \
 		 -I$(srctree)/arch/$(SRCARCH)/boot/dts/include           \
 		 -undef -D__DTS__