| Message ID | 20130517191753.468.1734.stgit@localhost (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren <tony@atomide.com> wrote: > We can now boot with device tree. If you don't want to update u-boot, > you can boot with appended DTB with the following instructions: > > 1. Make sure you have the appended DTB support in .config > > CONFIG_ARM_APPENDED_DTB=y > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y > > 2. Build the zImage > > $ ARCH=arm CROSS_COMPILE=... make zImage > > 3. Build the device tree blobs > > $ ARCH=arm CROSS_COMPILE=... make dtbs > > 4. Append the correct panda dtb to zImage > > Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb > or omap4-panda-es.dtb. > > $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > /tmp/appended > > 5. Use mkimage to produce the appended device tree uImage > > $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ > -n "Linux" -d /tmp/appended /tmp/uImage I followed the above steps and tried devicetree on Pandaboard against 3.10.0-rc3-next-20130528, and the board will hang during boot, but works well with legacy mode. Hardware: Pandaboard A1 dtb: omap4-panda.dtb See 'dmesg' on below link: http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg Thanks,
* Ming Lei <tom.leiming@gmail.com> [130603 08:34]: > Hi, > > On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren <tony@atomide.com> wrote: > > We can now boot with device tree. If you don't want to update u-boot, > > you can boot with appended DTB with the following instructions: > > > > 1. Make sure you have the appended DTB support in .config > > > > CONFIG_ARM_APPENDED_DTB=y > > CONFIG_ARM_ATAG_DTB_COMPAT=y > > CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y > > > > 2. Build the zImage > > > > $ ARCH=arm CROSS_COMPILE=... make zImage > > > > 3. Build the device tree blobs > > > > $ ARCH=arm CROSS_COMPILE=... make dtbs > > > > 4. Append the correct panda dtb to zImage > > > > Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb > > or omap4-panda-es.dtb. > > > > $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > /tmp/appended > > > > 5. Use mkimage to produce the appended device tree uImage > > > > $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ > > -n "Linux" -d /tmp/appended /tmp/uImage > > I followed the above steps and tried devicetree on Pandaboard against > 3.10.0-rc3-next-20130528, and the board will hang during boot, but works > well with legacy mode. > > Hardware: Pandaboard A1 > dtb: omap4-panda.dtb > > See 'dmesg' on below link: > > http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg > Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in case there's some late_initcall that causes the issue. It's probably some trivial issue causing it. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren <tony@atomide.com> [130612 09:37]: > * Ming Lei <tom.leiming@gmail.com> [130603 08:34]: > > Hi, > > > > On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren <tony@atomide.com> wrote: > > > We can now boot with device tree. If you don't want to update u-boot, > > > you can boot with appended DTB with the following instructions: > > > > > > 1. Make sure you have the appended DTB support in .config > > > > > > CONFIG_ARM_APPENDED_DTB=y > > > CONFIG_ARM_ATAG_DTB_COMPAT=y > > > CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y > > > > > > 2. Build the zImage > > > > > > $ ARCH=arm CROSS_COMPILE=... make zImage > > > > > > 3. Build the device tree blobs > > > > > > $ ARCH=arm CROSS_COMPILE=... make dtbs > > > > > > 4. Append the correct panda dtb to zImage > > > > > > Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb > > > or omap4-panda-es.dtb. > > > > > > $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > /tmp/appended > > > > > > 5. Use mkimage to produce the appended device tree uImage > > > > > > $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ > > > -n "Linux" -d /tmp/appended /tmp/uImage > > > > I followed the above steps and tried devicetree on Pandaboard against > > 3.10.0-rc3-next-20130528, and the board will hang during boot, but works > > well with legacy mode. > > > > Hardware: Pandaboard A1 > > dtb: omap4-panda.dtb > > > > See 'dmesg' on below link: > > > > http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg > > > > Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in > case there's some late_initcall that causes the issue. It's probably some > trivial issue causing it. Sricharan, maybe give this a quick try if you have the original pandaboard? I only have pandaboard es. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [130612 09:37]: >> * Ming Lei <tom.leiming@gmail.com> [130603 08:34]: >>> Hi, >>> >>> On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren <tony@atomide.com> wrote: >>>> We can now boot with device tree. If you don't want to update u-boot, >>>> you can boot with appended DTB with the following instructions: >>>> >>>> 1. Make sure you have the appended DTB support in .config >>>> >>>> CONFIG_ARM_APPENDED_DTB=y >>>> CONFIG_ARM_ATAG_DTB_COMPAT=y >>>> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y >>>> >>>> 2. Build the zImage >>>> >>>> $ ARCH=arm CROSS_COMPILE=... make zImage >>>> >>>> 3. Build the device tree blobs >>>> >>>> $ ARCH=arm CROSS_COMPILE=... make dtbs >>>> >>>> 4. Append the correct panda dtb to zImage >>>> >>>> Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb >>>> or omap4-panda-es.dtb. >>>> >>>> $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > /tmp/appended >>>> >>>> 5. Use mkimage to produce the appended device tree uImage >>>> >>>> $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ >>>> -n "Linux" -d /tmp/appended /tmp/uImage >>> I followed the above steps and tried devicetree on Pandaboard against >>> 3.10.0-rc3-next-20130528, and the board will hang during boot, but works >>> well with legacy mode. >>> >>> Hardware: Pandaboard A1 >>> dtb: omap4-panda.dtb >>> >>> See 'dmesg' on below link: >>> >>> http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg >>> >> Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in >> case there's some late_initcall that causes the issue. It's probably some >> trivial issue causing it. > Sricharan, maybe give this a quick try if you have the original pandaboard? > I only have pandaboard es. > > Regards, > > Tony I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted to prompt fine. Hardware: Pandaboard A1 dtb: omap4-panda.dtb git pull on linux-next branch was not working though. Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 13 June 2013 02:51 PM, Sricharan R wrote: > Hi Tony, > On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: >> * Tony Lindgren <tony@atomide.com> [130612 09:37]: >>> * Ming Lei <tom.leiming@gmail.com> [130603 08:34]: >>>> Hi, >>>> >>>> On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren <tony@atomide.com> wrote: >>>>> We can now boot with device tree. If you don't want to update u-boot, >>>>> you can boot with appended DTB with the following instructions: >>>>> >>>>> 1. Make sure you have the appended DTB support in .config >>>>> >>>>> CONFIG_ARM_APPENDED_DTB=y >>>>> CONFIG_ARM_ATAG_DTB_COMPAT=y >>>>> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y >>>>> >>>>> 2. Build the zImage >>>>> >>>>> $ ARCH=arm CROSS_COMPILE=... make zImage >>>>> >>>>> 3. Build the device tree blobs >>>>> >>>>> $ ARCH=arm CROSS_COMPILE=... make dtbs >>>>> >>>>> 4. Append the correct panda dtb to zImage >>>>> >>>>> Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb >>>>> or omap4-panda-es.dtb. >>>>> >>>>> $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > /tmp/appended >>>>> >>>>> 5. Use mkimage to produce the appended device tree uImage >>>>> >>>>> $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ >>>>> -n "Linux" -d /tmp/appended /tmp/uImage >>>> I followed the above steps and tried devicetree on Pandaboard against >>>> 3.10.0-rc3-next-20130528, and the board will hang during boot, but works >>>> well with legacy mode. >>>> >>>> Hardware: Pandaboard A1 >>>> dtb: omap4-panda.dtb >>>> >>>> See 'dmesg' on below link: >>>> >>>> http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg >>>> >>> Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in >>> case there's some late_initcall that causes the issue. It's probably some >>> trivial issue causing it. >> Sricharan, maybe give this a quick try if you have the original pandaboard? >> I only have pandaboard es. >> >> Regards, >> >> Tony > > I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted > to prompt fine. > Hardware: Pandaboard A1 dtb: omap4-panda.dtb > > git pull on linux-next branch was not working though. > Ok, tested in linux-next as well and it booted fine with DTB. HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB Booted with ramdisk and mmc FS commit c04efed734409f5a44715b54a6ca1b54b0ccf215 Author: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri Jun 7 16:40:02 2013 +1000 Add linux-next specific files for 20130607 Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Sricharan R <r.sricharan@ti.com> [130613 03:18]: > > > > I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted > > to prompt fine. > > Hardware: Pandaboard A1 dtb: omap4-panda.dtb OK thanks for testing. > > git pull on linux-next branch was not working though. > > > Ok, tested in linux-next as well and it booted fine with DTB. > HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB > > Booted with ramdisk and mmc FS > > commit c04efed734409f5a44715b54a6ca1b54b0ccf215 > Author: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri Jun 7 16:40:02 2013 +1000 > > Add linux-next specific files for 20130607 OK thanks for testing that too. I don't think these patches are in linux-next yet. But still good to hear it works. Ming Lei, any further info on your board? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jun 13, 2013 at 7:05 PM, Tony Lindgren <tony@atomide.com> wrote: > * Sricharan R <r.sricharan@ti.com> [130613 03:18]: >> > >> > I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted >> > to prompt fine. >> > Hardware: Pandaboard A1 dtb: omap4-panda.dtb > > OK thanks for testing. > >> > git pull on linux-next branch was not working though. >> > >> Ok, tested in linux-next as well and it booted fine with DTB. >> HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB >> >> Booted with ramdisk and mmc FS >> >> commit c04efed734409f5a44715b54a6ca1b54b0ccf215 >> Author: Stephen Rothwell <sfr@canb.auug.org.au> >> Date: Fri Jun 7 16:40:02 2013 +1000 >> >> Add linux-next specific files for 20130607 > > OK thanks for testing that too. I don't think these patches are > in linux-next yet. But still good to hear it works. > > Ming Lei, any further info on your board? OK, I will test the latest next tree to see if my board can work, and post the result. Thanks,
On Thu, Jun 13, 2013 at 6:12 PM, Sricharan R <r.sricharan@ti.com> wrote: > On Thursday 13 June 2013 02:51 PM, Sricharan R wrote: >> Hi Tony, >> On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: >>> * Tony Lindgren <tony@atomide.com> [130612 09:37]: >>>> * Ming Lei <tom.leiming@gmail.com> [130603 08:34]: >>>>> Hi, >>>>> >>>>> On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren <tony@atomide.com> wrote: >>>>>> We can now boot with device tree. If you don't want to update u-boot, >>>>>> you can boot with appended DTB with the following instructions: >>>>>> >>>>>> 1. Make sure you have the appended DTB support in .config >>>>>> >>>>>> CONFIG_ARM_APPENDED_DTB=y >>>>>> CONFIG_ARM_ATAG_DTB_COMPAT=y >>>>>> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y >>>>>> >>>>>> 2. Build the zImage >>>>>> >>>>>> $ ARCH=arm CROSS_COMPILE=... make zImage >>>>>> >>>>>> 3. Build the device tree blobs >>>>>> >>>>>> $ ARCH=arm CROSS_COMPILE=... make dtbs >>>>>> >>>>>> 4. Append the correct panda dtb to zImage >>>>>> >>>>>> Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb >>>>>> or omap4-panda-es.dtb. >>>>>> >>>>>> $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > /tmp/appended >>>>>> >>>>>> 5. Use mkimage to produce the appended device tree uImage >>>>>> >>>>>> $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ >>>>>> -n "Linux" -d /tmp/appended /tmp/uImage >>>>> I followed the above steps and tried devicetree on Pandaboard against >>>>> 3.10.0-rc3-next-20130528, and the board will hang during boot, but works >>>>> well with legacy mode. >>>>> >>>>> Hardware: Pandaboard A1 >>>>> dtb: omap4-panda.dtb >>>>> >>>>> See 'dmesg' on below link: >>>>> >>>>> http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg >>>>> >>>> Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in >>>> case there's some late_initcall that causes the issue. It's probably some >>>> trivial issue causing it. >>> Sricharan, maybe give this a quick try if you have the original pandaboard? >>> I only have pandaboard es. >>> >>> Regards, >>> >>> Tony >> >> I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted >> to prompt fine. >> Hardware: Pandaboard A1 dtb: omap4-panda.dtb >> >> git pull on linux-next branch was not working though. >> > Ok, tested in linux-next as well and it booted fine with DTB. > HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB > > Booted with ramdisk and mmc FS > > commit c04efed734409f5a44715b54a6ca1b54b0ccf215 > Author: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri Jun 7 16:40:02 2013 +1000 > > Add linux-next specific files for 20130607 Looks linux-next-20130607 is broken, see below: LD [M] drivers/usb/gadget/g_ncm.o drivers/usb/musb/omap2430.c: In function 'omap2430_probe': drivers/usb/musb/omap2430.c:571:2: error: 'musb_resources' undeclared (first use in this function) drivers/usb/musb/omap2430.c:571:2: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/musb/omap2430.c:571:2: error: bit-field '<anonymous>' width not an integer constant drivers/usb/musb/omap2430.c:585:4: error: bit-field '<anonymous>' width not an integer constant make[3]: *** [drivers/usb/musb/omap2430.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [drivers/usb/musb] Error 2 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 install kernel and modules DEPMOD 3.10.0-rc4-next-20130607+ Thanks,
On Fri, Jun 14, 2013 at 9:31 PM, Ming Lei <tom.leiming@gmail.com> wrote: > On Thu, Jun 13, 2013 at 6:12 PM, Sricharan R <r.sricharan@ti.com> wrote: >> On Thursday 13 June 2013 02:51 PM, Sricharan R wrote: >>> Hi Tony, >>> On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: >>>> * Tony Lindgren <tony@atomide.com> [130612 09:37]: >>>>> * Ming Lei <tom.leiming@gmail.com> [130603 08:34]: >>>>>> Hi, >>>>>> >>>>>> On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren <tony@atomide.com> wrote: >>>>>>> We can now boot with device tree. If you don't want to update u-boot, >>>>>>> you can boot with appended DTB with the following instructions: >>>>>>> >>>>>>> 1. Make sure you have the appended DTB support in .config >>>>>>> >>>>>>> CONFIG_ARM_APPENDED_DTB=y >>>>>>> CONFIG_ARM_ATAG_DTB_COMPAT=y >>>>>>> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y >>>>>>> >>>>>>> 2. Build the zImage >>>>>>> >>>>>>> $ ARCH=arm CROSS_COMPILE=... make zImage >>>>>>> >>>>>>> 3. Build the device tree blobs >>>>>>> >>>>>>> $ ARCH=arm CROSS_COMPILE=... make dtbs >>>>>>> >>>>>>> 4. Append the correct panda dtb to zImage >>>>>>> >>>>>>> Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb >>>>>>> or omap4-panda-es.dtb. >>>>>>> >>>>>>> $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > /tmp/appended >>>>>>> >>>>>>> 5. Use mkimage to produce the appended device tree uImage >>>>>>> >>>>>>> $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ >>>>>>> -n "Linux" -d /tmp/appended /tmp/uImage >>>>>> I followed the above steps and tried devicetree on Pandaboard against >>>>>> 3.10.0-rc3-next-20130528, and the board will hang during boot, but works >>>>>> well with legacy mode. >>>>>> >>>>>> Hardware: Pandaboard A1 >>>>>> dtb: omap4-panda.dtb >>>>>> >>>>>> See 'dmesg' on below link: >>>>>> >>>>>> http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg >>>>>> >>>>> Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in >>>>> case there's some late_initcall that causes the issue. It's probably some >>>>> trivial issue causing it. >>>> Sricharan, maybe give this a quick try if you have the original pandaboard? >>>> I only have pandaboard es. >>>> >>>> Regards, >>>> >>>> Tony >>> >>> I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted >>> to prompt fine. >>> Hardware: Pandaboard A1 dtb: omap4-panda.dtb >>> >>> git pull on linux-next branch was not working though. >>> >> Ok, tested in linux-next as well and it booted fine with DTB. >> HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB >> >> Booted with ramdisk and mmc FS >> >> commit c04efed734409f5a44715b54a6ca1b54b0ccf215 >> Author: Stephen Rothwell <sfr@canb.auug.org.au> >> Date: Fri Jun 7 16:40:02 2013 +1000 >> >> Add linux-next specific files for 20130607 > > Looks linux-next-20130607 is broken, see below: > > LD [M] drivers/usb/gadget/g_ncm.o > drivers/usb/musb/omap2430.c: In function 'omap2430_probe': > drivers/usb/musb/omap2430.c:571:2: error: 'musb_resources' undeclared > (first use in this function) > drivers/usb/musb/omap2430.c:571:2: note: each undeclared identifier is > reported only once for each function it appears in > drivers/usb/musb/omap2430.c:571:2: error: bit-field '<anonymous>' > width not an integer constant > drivers/usb/musb/omap2430.c:585:4: error: bit-field '<anonymous>' > width not an integer constant > make[3]: *** [drivers/usb/musb/omap2430.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** [drivers/usb/musb] Error 2 > make[2]: *** Waiting for unfinished jobs.... > make[1]: *** [drivers/usb] Error 2 > make: *** [drivers] Error 2 > install kernel and modules > > DEPMOD 3.10.0-rc4-next-20130607+ Even I disable musb so that kernel building is OK, but the kernel with dtb still can't boot, see attachment 'dmesg' and config. Thanks,
On Friday 14 June 2013 07:28 PM, Ming Lei wrote: > On Fri, Jun 14, 2013 at 9:31 PM, Ming Lei <tom.leiming@gmail.com> wrote: >> On Thu, Jun 13, 2013 at 6:12 PM, Sricharan R <r.sricharan@ti.com> wrote: >>> On Thursday 13 June 2013 02:51 PM, Sricharan R wrote: >>>> Hi Tony, >>>> On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: >>>>> * Tony Lindgren <tony@atomide.com> [130612 09:37]: >>>>>> * Ming Lei <tom.leiming@gmail.com> [130603 08:34]: >>>>>>> Hi, >>>>>>> >>>>>>> On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren <tony@atomide.com> wrote: >>>>>>>> We can now boot with device tree. If you don't want to update u-boot, >>>>>>>> you can boot with appended DTB with the following instructions: >>>>>>>> >>>>>>>> 1. Make sure you have the appended DTB support in .config >>>>>>>> >>>>>>>> CONFIG_ARM_APPENDED_DTB=y >>>>>>>> CONFIG_ARM_ATAG_DTB_COMPAT=y >>>>>>>> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y >>>>>>>> >>>>>>>> 2. Build the zImage >>>>>>>> >>>>>>>> $ ARCH=arm CROSS_COMPILE=... make zImage >>>>>>>> >>>>>>>> 3. Build the device tree blobs >>>>>>>> >>>>>>>> $ ARCH=arm CROSS_COMPILE=... make dtbs >>>>>>>> >>>>>>>> 4. Append the correct panda dtb to zImage >>>>>>>> >>>>>>>> Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb >>>>>>>> or omap4-panda-es.dtb. >>>>>>>> >>>>>>>> $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > /tmp/appended >>>>>>>> >>>>>>>> 5. Use mkimage to produce the appended device tree uImage >>>>>>>> >>>>>>>> $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ >>>>>>>> -n "Linux" -d /tmp/appended /tmp/uImage >>>>>>> I followed the above steps and tried devicetree on Pandaboard against >>>>>>> 3.10.0-rc3-next-20130528, and the board will hang during boot, but works >>>>>>> well with legacy mode. >>>>>>> >>>>>>> Hardware: Pandaboard A1 >>>>>>> dtb: omap4-panda.dtb >>>>>>> >>>>>>> See 'dmesg' on below link: >>>>>>> >>>>>>> http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg >>>>>>> >>>>>> Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in >>>>>> case there's some late_initcall that causes the issue. It's probably some >>>>>> trivial issue causing it. >>>>> Sricharan, maybe give this a quick try if you have the original pandaboard? >>>>> I only have pandaboard es. >>>>> >>>>> Regards, >>>>> >>>>> Tony >>>> I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted >>>> to prompt fine. >>>> Hardware: Pandaboard A1 dtb: omap4-panda.dtb >>>> >>>> git pull on linux-next branch was not working though. >>>> >>> Ok, tested in linux-next as well and it booted fine with DTB. >>> HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB >>> >>> Booted with ramdisk and mmc FS >>> >>> commit c04efed734409f5a44715b54a6ca1b54b0ccf215 >>> Author: Stephen Rothwell <sfr@canb.auug.org.au> >>> Date: Fri Jun 7 16:40:02 2013 +1000 >>> >>> Add linux-next specific files for 20130607 >> Looks linux-next-20130607 is broken, see below: >> >> LD [M] drivers/usb/gadget/g_ncm.o >> drivers/usb/musb/omap2430.c: In function 'omap2430_probe': >> drivers/usb/musb/omap2430.c:571:2: error: 'musb_resources' undeclared >> (first use in this function) >> drivers/usb/musb/omap2430.c:571:2: note: each undeclared identifier is >> reported only once for each function it appears in >> drivers/usb/musb/omap2430.c:571:2: error: bit-field '<anonymous>' >> width not an integer constant >> drivers/usb/musb/omap2430.c:585:4: error: bit-field '<anonymous>' >> width not an integer constant >> make[3]: *** [drivers/usb/musb/omap2430.o] Error 1 >> make[3]: *** Waiting for unfinished jobs.... >> make[2]: *** [drivers/usb/musb] Error 2 >> make[2]: *** Waiting for unfinished jobs.... >> make[1]: *** [drivers/usb] Error 2 >> make: *** [drivers] Error 2 >> install kernel and modules >> >> DEPMOD 3.10.0-rc4-next-20130607+ > Even I disable musb so that kernel building is OK, but the kernel with dtb > still can't boot, see attachment 'dmesg' and config. > > > Thanks, I am not sure how both of us are different. I was testing 20130607 with an omap2plusdefconfig. Also i was using a minimal busy box file system.. Is there anything specific FS that you want me to try ? I am using the latest u-boot version. U-Boot SPL 2013.07-rc1-00010-gdfdb3d3 (Jun 17 2013 - 13:09:51) OMAP4430 ES2.1 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.07-rc1-00010-gdfdb3d3 (Jun 17 2013 - 13:09:51) CPU : OMAP4430 ES2.1 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Panda # Panda # setenv bootargs root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 earlyprintk Panda # mmc dev 0 mmc0 is current device Panda # fatload mmc 0 0x80300000 uImage reading uImage 4394007 bytes read in 300 ms (14 MiB/s) Panda # fatload mmc 0 0x81600000 bb.raw reading bb.raw 10240000 bytes read in 722 ms (13.5 MiB/s) Panda # bootm 0x80300000 ## Booting kernel from Legacy Image at 80300000 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4393943 Bytes = 4.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.10.0-rc4-next-20130607 (a0393807@uda0393807) (gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-57) ) #18 SMP Mon Jun 17 12:55:05 IST 2013 [ 0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: OMAP4 Panda board [ 0.000000] cma: CMA: reserved 16 MiB at ae800000 [ 0.000000] Memory policy: ECC disabled, Data cache writealloc [ 0.000000] OMAP4430 ES2.1 [ 0.000000] PERCPU: Embedded 9 pages/cpu @c15d5000 s13440 r8192 d15232 u36864 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260368 [ 0.000000] Kernel command line: root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 earlyprintk [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 987436K/1047552K available (5619K kernel code, 603K rwdata, 1908K rodata, 393K init, 5521K bss, 60116K reserved, 269312K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB) [ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc07620e8 (7529 kB) [ 0.000000] .init : 0xc0763000 - 0xc07c5480 ( 394 kB) [ 0.000000] .data : 0xc07c6000 - 0xc085ccc8 ( 604 kB) [ 0.000000] .bss : 0xc085ccc8 - 0xc0dc10f0 (5522 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.000000] ... MAX_LOCK_DEPTH: 48 [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 [ 0.000000] ... CLASSHASH_SIZE: 4096 [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 [ 0.000000] ... CHAINHASH_SIZE: 16384 [ 0.000000] memory used by lock dependency info: 3695 kB [ 0.000000] per task-struct memory footprint: 1152 bytes [ 0.001403] Calibrating delay loop... 1191.11 BogoMIPS (lpj=5955584) [ 0.079742] pid_max: default: 32768 minimum: 301 [ 0.080535] Security Framework initialized [ 0.080780] Mount-cache hash table entries: 512 [ 0.085571] CPU: Testing write buffer coherency: ok [ 0.087493] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.087829] Setting up static identity map for 0xc0556058 - 0xc05560c8 [ 0.087890] L310 cache controller enabled [ 0.087921] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, Cache size: 1048576 B [ 0.093048] CPU1: Booted secondary processor [ 0.177764] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.178283] Brought up 2 CPUs [ 0.178314] SMP: Total of 2 processors activated (2387.96 BogoMIPS). [ 0.178314] CPU: All CPU(s) started in SVC mode. [ 0.181152] devtmpfs: initialized [ 0.254455] pinctrl core: initialized pinctrl subsystem [ 0.258117] regulator-dummy: no parameters [ 0.261657] NET: Registered protocol family 16 [ 0.270538] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.272033] omap-gpmc omap-gpmc: GPMC revision 6.0 [ 0.281036] OMAP GPIO hardware version 0.1 [ 0.295837] omap_mux_init: Add partition: #1: core, flags: 3 [ 0.298095] omap_mux_init: Add partition: #2: wkup, flags: 3 [ 0.298309] error setting wl12xx data: -38 [ 0.298583] omap_mux_get_by_name: Could not find signal sys_nirq [ 0.303375] omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx [ 0.384521] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers. [ 0.384521] hw-breakpoint: maximum watchpoint size is 4 bytes. [ 0.398803] OMAP DMA hardware revision 0.0 [ 0.402832] ARM PMU: not yet supported on OMAP4430 due to missing CTI driver [ 0.449371] bio: create slab <bio-0> at 0 [ 0.514038] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.515258] vwl1271: 1800 mV [ 0.516174] hsusb1_reset: 3300 mV [ 0.516967] hsusb1_vcc: 3300 mV [ 0.522064] SCSI subsystem initialized [ 0.523773] usbcore: registered new interface driver usbfs [ 0.524139] usbcore: registered new interface driver hub [ 0.524658] usbcore: registered new device driver usb [ 0.528869] omap_i2c omap_i2c.1: bus 1 rev0.10 at 400 kHz [ 0.529907] omap_i2c omap_i2c.2: bus 2 rev0.10 at 400 kHz [ 0.531280] omap_i2c omap_i2c.3: bus 3 rev0.10 at 100 kHz [ 0.532226] omap_i2c omap_i2c.4: bus 4 rev0.10 at 400 kHz [ 0.538391] Switching to clocksource 32k_counter [ 0.655364] NET: Registered protocol family 2 [ 0.657409] TCP established hash table entries: 8192 (order: 4, 65536 bytes) [ 0.657806] TCP bind hash table entries: 8192 (order: 6, 294912 bytes) [ 0.660980] TCP: Hash tables configured (established 8192 bind 8192) [ 0.661315] TCP: reno registered [ 0.661346] UDP hash table entries: 512 (order: 3, 40960 bytes) [ 0.661773] UDP-Lite hash table entries: 512 (order: 3, 40960 bytes) [ 0.663421] NET: Registered protocol family 1 [ 0.664733] RPC: Registered named UNIX socket transport module. [ 0.664764] RPC: Registered udp transport module. [ 0.664764] RPC: Registered tcp transport module. [ 0.664764] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.665740] Trying to unpack rootfs image as initramfs... [ 0.666931] rootfs image is not initramfs (junk in compressed archive); looks like an initrd [ 0.819061] Freeing initrd memory: 20480K (c1600000 - c2a00000) [ 0.819183] NetWinder Floating Point Emulator V0.97 (double precision) [ 1.007995] bounce pool size: 64 pages [ 1.008575] VFS: Disk quotas dquot_6.5.2 [ 1.009033] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.011779] NFS: Registering the id_resolver key type [ 1.012207] Key type id_resolver registered [ 1.012237] Key type id_legacy registered [ 1.012390] jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. [ 1.013031] msgmni has been set to 1474 [ 1.016387] io scheduler noop registered [ 1.016418] io scheduler deadline registered [ 1.016510] io scheduler cfq registered (default) [ 1.020660] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.027069] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0 [ 1.029296] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1 [ 1.030670] omap_uart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2 [ 1.724426] console [ttyO2] enabled [ 1.729583] omap_uart.3: ttyO3 at MMIO 0x4806e000 (irq = 102) is a OMAP UART3 [ 1.765686] brd: module loaded [ 1.784973] loop: module loaded [ 1.791503] Skipping twl internal clock init and using bootloader value (unknown osc rate) [ 1.802978] twl 1-0048: PIH (irq 39) chaining IRQs 418..438 [ 1.811218] VUSB: 3300 mV normal standby [ 1.816864] vdd_mpu: 500 <--> 1500 mV normal [ 1.823730] vdd_iva: 500 <--> 1500 mV normal [ 1.829803] vdd_core: 500 <--> 1500 mV normal [ 1.836334] V1V8: 1800 mV normal standby [ 1.841979] V2V1: 2100 mV normal standby [ 1.847717] VMMC: 1200 <--> 3000 mV at 3000 mV normal standby [ 1.855773] VPP: 1800 <--> 2500 mV at 1900 mV normal standby [ 1.864196] VCXIO: 1800 mV normal standby [ 1.868499] VCXIO: supplied by V2V1 [ 1.875030] VDAC: 1800 mV normal standby [ 1.879333] VDAC: supplied by V2V1 [ 1.885223] VAUX2_6030: 1200 <--> 2800 mV at 1800 mV normal standby [ 1.893768] VAUX3_6030: 1000 <--> 3000 mV at 1200 mV normal standby [ 1.903076] VANA: 2100 mV normal standby [ 1.917877] mtdoops: mtd device (mtddev=name/number) must be supplied [ 1.934997] usbcore: registered new interface driver asix [ 1.941284] usbcore: registered new interface driver ax88179_178a [ 1.948089] usbcore: registered new interface driver cdc_ether [ 1.954681] usbcore: registered new interface driver smsc95xx [ 1.961242] usbcore: registered new interface driver net1080 [ 1.967559] usbcore: registered new interface driver cdc_subset [ 1.974243] usbcore: registered new interface driver zaurus [ 1.980621] usbcore: registered new interface driver cdc_ncm [ 1.988220] usbcore: registered new interface driver cdc_wdm [ 1.994659] usbcore: registered new interface driver usb-storage [ 2.001464] usbcore: registered new interface driver usbtest [ 2.009277] mousedev: PS/2 mouse device common for all mice [ 2.020721] twl_rtc twl_rtc: Enabling TWL-RTC [ 2.030181] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 [ 2.059692] i2c /dev entries driver [ 2.067108] Driver for 1-wire Dallas network protocol. [ 2.076293] omap_wdt: OMAP Watchdog Timer Rev 0x00: initial timeout 60 sec [ 2.086364] omap-dma-engine omap-dma-engine: allocating channel for 62 [ 2.093414] omap-dma-engine omap-dma-engine: allocating channel for 61 [ 2.139251] omap-dma-engine omap-dma-engine: allocating channel for 60 [ 2.146209] omap-dma-engine omap-dma-engine: allocating channel for 59 [ 2.262664] ledtrig-cpu: registered to indicate activity on CPUs [ 2.270233] usbcore: registered new interface driver usbhid [ 2.276153] usbhid: USB HID core driver [ 2.281402] oprofile: no performance counters [ 2.288024] oprofile: using timer interrupt. [ 2.293334] TCP: cubic registered [ 2.296844] Initializing XFRM netlink socket [ 2.301544] NET: Registered protocol family 17 [ 2.306365] NET: Registered protocol family 15 [ 2.311614] Key type dns_resolver registered [ 2.316284] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 1 [ 2.334320] Power Management for TI OMAP4. [ 2.338684] OMAP4 PM: u-boot >= v2012.07 is required for full PM support [ 2.346069] ThumbEE CPU extension supported. [ 2.354187] VANA: incomplete constraints, leaving on [ 2.361175] VDAC: incomplete constraints, leaving on [ 2.367614] VUSB: incomplete constraints, leaving on [ 2.377258] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:03:17 UTC (946684997) [ 2.388793] RAMDISK: ext2 filesystem found at block 0 [ 2.395324] RAMDISK: Loading 10000KiB [1 disk] into ram disk... [ 2.410461] mmc0: host does not support reading read-only switch. assuming write-enable. [ 2.424896] mmc0: new high speed SD card at address 0002 [ 2.436248] mmcblk0: mmc0:0002 00000 1.86 GiB [ 2.455200] mmcblk0: p1 p2 done. [ 2.858886] EXT2-fs (ram0): warning: mounting unchecked fs, running e2fsck is recommended [ 2.858886] VFS: Mounted root (ext2 filesystem) on device 1:0. [ 2.874725] devtmpfs: mounted [ 2.879028] Freeing unused kernel memory: 392K (c0763000 - c07c5000) Mounting proc : OK Mounting sysfs : OK Mounting /dev : OK Creating local mdev devices umount: can't umount /mnt/mmc: Invalid argument ****************************************** Starting System Init for 6430EVM-6430 Release: OpnSrc ****************************************** Saving kernel ring buffer : OK Mounting devpts : OK Setting up networking Configuring lo : OK Configuring eth0 : ifconfig: eth0: error fetching interface information: Device not found ifup: can't open '/etc/network/interfaces': No such file or directory Failed Starting syslogd : OK Starting klogd : OK Mounting filesystems : mount: according to /proc/mounts, none is already mounted on /dev/pts mount: according to /proc/mounts, /proc is already mounted on /proc OK Please press Enter to activate this console. # Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sricharan R <r.sricharan@ti.com> writes: Hi, [...] > Starting kernel ... > > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 3.10.0-rc4-next-20130607 (a0393807@uda0393807) (gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-57) ) #18 SMP Mon Jun 17 12:55:05 IST 2013 > [ 0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > [ 0.000000] Machine: OMAP4 Panda board > [ 0.000000] cma: CMA: reserved 16 MiB at ae800000 > [ 0.000000] Memory policy: ECC disabled, Data cache writealloc > [ 0.000000] OMAP4430 ES2.1 > [ 0.000000] PERCPU: Embedded 9 pages/cpu @c15d5000 s13440 r8192 d15232 u36864 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260368 > [ 0.000000] Kernel command line: root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 earlyprintk > [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) > [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > [ 0.000000] Memory: 987436K/1047552K available (5619K kernel code, 603K rwdata, 1908K rodata, 393K init, 5521K bss, 60116K reserved, 269312K highmem) > [ 0.000000] Virtual kernel memory layout: > [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) > [ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB) > [ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB) > [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) > [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) > [ 0.000000] .text : 0xc0008000 - 0xc07620e8 (7529 kB) > [ 0.000000] .init : 0xc0763000 - 0xc07c5480 ( 394 kB) > [ 0.000000] .data : 0xc07c6000 - 0xc085ccc8 ( 604 kB) > [ 0.000000] .bss : 0xc085ccc8 - 0xc0dc10f0 (5522 kB) > [ 0.000000] Hierarchical RCU implementation. > [ 0.000000] NR_IRQS:16 nr_irqs:16 16 > [ 0.000000] OMAP clockevent source: timer1 at 32768 Hz > [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms > [ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz > [ 0.000000] Console: colour dummy device 80x30 > [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar > [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 > [ 0.000000] ... MAX_LOCK_DEPTH: 48 > [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 > [ 0.000000] ... CLASSHASH_SIZE: 4096 > [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 > [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 > [ 0.000000] ... CHAINHASH_SIZE: 16384 > [ 0.000000] memory used by lock dependency info: 3695 kB > [ 0.000000] per task-struct memory footprint: 1152 bytes > [ 0.001403] Calibrating delay loop... 1191.11 BogoMIPS (lpj=5955584) > [ 0.079742] pid_max: default: 32768 minimum: 301 > [ 0.080535] Security Framework initialized > [ 0.080780] Mount-cache hash table entries: 512 > [ 0.085571] CPU: Testing write buffer coherency: ok > [ 0.087493] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 > [ 0.087829] Setting up static identity map for 0xc0556058 - 0xc05560c8 > [ 0.087890] L310 cache controller enabled > [ 0.087921] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, Cache size: 1048576 B > [ 0.093048] CPU1: Booted secondary processor > [ 0.177764] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 > [ 0.178283] Brought up 2 CPUs > [ 0.178314] SMP: Total of 2 processors activated (2387.96 BogoMIPS). > [ 0.178314] CPU: All CPU(s) started in SVC mode. > [ 0.181152] devtmpfs: initialized > [ 0.254455] pinctrl core: initialized pinctrl subsystem > [ 0.258117] regulator-dummy: no parameters > [ 0.261657] NET: Registered protocol family 16 > [ 0.270538] DMA: preallocated 256 KiB pool for atomic coherent allocations > [ 0.272033] omap-gpmc omap-gpmc: GPMC revision 6.0 > [ 0.281036] OMAP GPIO hardware version 0.1 > [ 0.295837] omap_mux_init: Add partition: #1: core, flags: 3 > [ 0.298095] omap_mux_init: Add partition: #2: wkup, flags: 3 > [ 0.298309] error setting wl12xx data: -38 > [ 0.298583] omap_mux_get_by_name: Could not find signal sys_nirq > [ 0.303375] omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx > [ 0.384521] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers. > [ 0.384521] hw-breakpoint: maximum watchpoint size is 4 bytes. > [ 0.398803] OMAP DMA hardware revision 0.0 > [ 0.402832] ARM PMU: not yet supported on OMAP4430 due to missing CTI driver > [ 0.449371] bio: create slab <bio-0> at 0 > [ 0.514038] omap-dma-engine omap-dma-engine: OMAP DMA engine driver > [ 0.515258] vwl1271: 1800 mV > [ 0.516174] hsusb1_reset: 3300 mV > [ 0.516967] hsusb1_vcc: 3300 mV > [ 0.522064] SCSI subsystem initialized > [ 0.523773] usbcore: registered new interface driver usbfs > [ 0.524139] usbcore: registered new interface driver hub > [ 0.524658] usbcore: registered new device driver usb > [ 0.528869] omap_i2c omap_i2c.1: bus 1 rev0.10 at 400 kHz > [ 0.529907] omap_i2c omap_i2c.2: bus 2 rev0.10 at 400 kHz > [ 0.531280] omap_i2c omap_i2c.3: bus 3 rev0.10 at 100 kHz > [ 0.532226] omap_i2c omap_i2c.4: bus 4 rev0.10 at 400 kHz > [ 0.538391] Switching to clocksource 32k_counter > [ 0.655364] NET: Registered protocol family 2 > [ 0.657409] TCP established hash table entries: 8192 (order: 4, 65536 bytes) > [ 0.657806] TCP bind hash table entries: 8192 (order: 6, 294912 bytes) > [ 0.660980] TCP: Hash tables configured (established 8192 bind 8192) > [ 0.661315] TCP: reno registered > [ 0.661346] UDP hash table entries: 512 (order: 3, 40960 bytes) > [ 0.661773] UDP-Lite hash table entries: 512 (order: 3, 40960 bytes) > [ 0.663421] NET: Registered protocol family 1 > [ 0.664733] RPC: Registered named UNIX socket transport module. > [ 0.664764] RPC: Registered udp transport module. > [ 0.664764] RPC: Registered tcp transport module. > [ 0.664764] RPC: Registered tcp NFSv4.1 backchannel transport module. > [ 0.665740] Trying to unpack rootfs image as initramfs... > [ 0.666931] rootfs image is not initramfs (junk in compressed archive); looks like an initrd > [ 0.819061] Freeing initrd memory: 20480K (c1600000 - c2a00000) > [ 0.819183] NetWinder Floating Point Emulator V0.97 (double precision) > [ 1.007995] bounce pool size: 64 pages > [ 1.008575] VFS: Disk quotas dquot_6.5.2 > [ 1.009033] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > [ 1.011779] NFS: Registering the id_resolver key type > [ 1.012207] Key type id_resolver registered > [ 1.012237] Key type id_legacy registered > [ 1.012390] jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. > [ 1.013031] msgmni has been set to 1474 > [ 1.016387] io scheduler noop registered > [ 1.016418] io scheduler deadline registered > [ 1.016510] io scheduler cfq registered (default) > [ 1.020660] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [ 1.027069] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0 > [ 1.029296] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1 > [ 1.030670] omap_uart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2 > [ 1.724426] console [ttyO2] enabled > [ 1.729583] omap_uart.3: ttyO3 at MMIO 0x4806e000 (irq = 102) is a OMAP UART3 > [ 1.765686] brd: module loaded > [ 1.784973] loop: module loaded > [ 1.791503] Skipping twl internal clock init and using bootloader value (unknown osc rate) > [ 1.802978] twl 1-0048: PIH (irq 39) chaining IRQs 418..438 > [ 1.811218] VUSB: 3300 mV normal standby > [ 1.816864] vdd_mpu: 500 <--> 1500 mV normal > [ 1.823730] vdd_iva: 500 <--> 1500 mV normal > [ 1.829803] vdd_core: 500 <--> 1500 mV normal > [ 1.836334] V1V8: 1800 mV normal standby > [ 1.841979] V2V1: 2100 mV normal standby > [ 1.847717] VMMC: 1200 <--> 3000 mV at 3000 mV normal standby > [ 1.855773] VPP: 1800 <--> 2500 mV at 1900 mV normal standby > [ 1.864196] VCXIO: 1800 mV normal standby > [ 1.868499] VCXIO: supplied by V2V1 > [ 1.875030] VDAC: 1800 mV normal standby > [ 1.879333] VDAC: supplied by V2V1 > [ 1.885223] VAUX2_6030: 1200 <--> 2800 mV at 1800 mV normal standby > [ 1.893768] VAUX3_6030: 1000 <--> 3000 mV at 1200 mV normal standby > [ 1.903076] VANA: 2100 mV normal standby > [ 1.917877] mtdoops: mtd device (mtddev=name/number) must be supplied > [ 1.934997] usbcore: registered new interface driver asix > [ 1.941284] usbcore: registered new interface driver ax88179_178a > [ 1.948089] usbcore: registered new interface driver cdc_ether > [ 1.954681] usbcore: registered new interface driver smsc95xx > [ 1.961242] usbcore: registered new interface driver net1080 > [ 1.967559] usbcore: registered new interface driver cdc_subset > [ 1.974243] usbcore: registered new interface driver zaurus > [ 1.980621] usbcore: registered new interface driver cdc_ncm > [ 1.988220] usbcore: registered new interface driver cdc_wdm > [ 1.994659] usbcore: registered new interface driver usb-storage > [ 2.001464] usbcore: registered new interface driver usbtest > [ 2.009277] mousedev: PS/2 mouse device common for all mice > [ 2.020721] twl_rtc twl_rtc: Enabling TWL-RTC > [ 2.030181] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 > [ 2.059692] i2c /dev entries driver > [ 2.067108] Driver for 1-wire Dallas network protocol. > [ 2.076293] omap_wdt: OMAP Watchdog Timer Rev 0x00: initial timeout 60 sec > [ 2.086364] omap-dma-engine omap-dma-engine: allocating channel for 62 > [ 2.093414] omap-dma-engine omap-dma-engine: allocating channel for 61 > [ 2.139251] omap-dma-engine omap-dma-engine: allocating channel for 60 > [ 2.146209] omap-dma-engine omap-dma-engine: allocating channel for 59 > [ 2.262664] ledtrig-cpu: registered to indicate activity on CPUs > [ 2.270233] usbcore: registered new interface driver usbhid > [ 2.276153] usbhid: USB HID core driver > [ 2.281402] oprofile: no performance counters > [ 2.288024] oprofile: using timer interrupt. > [ 2.293334] TCP: cubic registered > [ 2.296844] Initializing XFRM netlink socket > [ 2.301544] NET: Registered protocol family 17 > [ 2.306365] NET: Registered protocol family 15 > [ 2.311614] Key type dns_resolver registered > [ 2.316284] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 1 > [ 2.334320] Power Management for TI OMAP4. > [ 2.338684] OMAP4 PM: u-boot >= v2012.07 is required for full PM support > [ 2.346069] ThumbEE CPU extension supported. > [ 2.354187] VANA: incomplete constraints, leaving on > [ 2.361175] VDAC: incomplete constraints, leaving on > [ 2.367614] VUSB: incomplete constraints, leaving on > [ 2.377258] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:03:17 UTC (946684997) > [ 2.388793] RAMDISK: ext2 filesystem found at block 0 > [ 2.395324] RAMDISK: Loading 10000KiB [1 disk] into ram disk... [ 2.410461] mmc0: host does not support reading read-only switch. assuming write-enable. > [ 2.424896] mmc0: new high speed SD card at address 0002 > [ 2.436248] mmcblk0: mmc0:0002 00000 1.86 GiB > [ 2.455200] mmcblk0: p1 p2 > done. > [ 2.858886] EXT2-fs (ram0): warning: mounting unchecked fs, running e2fsck is recommended > [ 2.858886] VFS: Mounted root (ext2 filesystem) on device 1:0. > [ 2.874725] devtmpfs: mounted > [ 2.879028] Freeing unused kernel memory: 392K (c0763000 - c07c5000) > Mounting proc : OK > Mounting sysfs : OK > Mounting /dev : OK > Creating local mdev devices > umount: can't umount /mnt/mmc: Invalid argument > > ****************************************** > Starting System Init for 6430EVM-6430 > Release: OpnSrc > ****************************************** > Saving kernel ring buffer : OK > Mounting devpts : OK > Setting up networking > Configuring lo : OK > Configuring eth0 : ifconfig: eth0: error fetching interface information: Device not found > ifup: can't open '/etc/network/interfaces': No such file or directory > Failed I hoped to have missed some mails and that people were testing pandabard support with full support but given what I see, the ethernet support is not there yet. This thread is about removing the non-DT boot. I see some contradiction here. Please, look again at what Thomas said in the IGEP thread: breaking existing support is bad and removing non-DT boot for panda with not-working ethernet would exactly to that. Yeah, I'm aware that some extra patches are being developped like the omap clocks one: https://patchwork.kernel.org/patch/2541331/ but they don't seem to be in -next. So, again, please, wait that all needed bits are merged mainline before killing non-DT support (or provide 'mixed' support like what is/was done on kirkwood) Thanks, Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 17, 2013 at 4:06 PM, Arnaud Patard <arnaud.patard@rtp-net.org> wrote: > Sricharan R <r.sricharan@ti.com> writes: > > I hoped to have missed some mails and that people were testing pandabard > support with full support but given what I see, the ethernet support is > not there yet. This thread is about removing the non-DT boot. I see some > contradiction here. Please, look again at what Thomas said in the IGEP thread: > breaking existing support is bad and removing non-DT boot for panda with > not-working ethernet would exactly to that. +1 Even no any USB support on Sricharan's setting. > > Yeah, I'm aware that some extra patches are being developped like the > omap clocks one: https://patchwork.kernel.org/patch/2541331/ but they > don't seem to be in -next. So, again, please, wait that all needed bits > are merged mainline before killing non-DT support (or provide 'mixed' > support like what is/was done on kirkwood) Agree, please don't be too quick, :-) Thanks,
* Arnaud Patard <arnaud.patard@rtp-net.org> [130617 01:13]: > > I hoped to have missed some mails and that people were testing pandabard > support with full support but given what I see, the ethernet support is > not there yet. This thread is about removing the non-DT boot. I see some > contradiction here. Please, look again at what Thomas said in the IGEP thread: > breaking existing support is bad and removing non-DT boot for panda with > not-working ethernet would exactly to that. Hmm yes I guess the panda needs the aux clock and there are various patches posted for that for quite a while but have not gotten merged. When I did my patches it seemed that Nishant's and my solution for getting the auxclk via DT was acceptable. Then Mike started doing all the clocks in DT and things changed. Mike, got any solution for us for v3.11 for the DT defined auxclk? > Yeah, I'm aware that some extra patches are being developped like the > omap clocks one: https://patchwork.kernel.org/patch/2541331/ but they > don't seem to be in -next. So, again, please, wait that all needed bits > are merged mainline before killing non-DT support (or provide 'mixed' > support like what is/was done on kirkwood) The ethernet issue can be fixed with the legacy mode support in the worst case, but probably just adding a clock alias for it does the trick. I'd rather not postpone making omap4 DT only because I think at this point fixing the any DT related issues is way less work compared to maintaining and testing both legacy boot and DT boot. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ming Lei <tom.leiming@gmail.com> [130617 01:22]: > On Mon, Jun 17, 2013 at 4:06 PM, Arnaud Patard > <arnaud.patard@rtp-net.org> wrote: > > Sricharan R <r.sricharan@ti.com> writes: > > > > I hoped to have missed some mails and that people were testing pandabard > > support with full support but given what I see, the ethernet support is > > not there yet. This thread is about removing the non-DT boot. I see some > > contradiction here. Please, look again at what Thomas said in the IGEP thread: > > breaking existing support is bad and removing non-DT boot for panda with > > not-working ethernet would exactly to that. > > +1 > > Even no any USB support on Sricharan's setting. That's also related to the auxclk. Let's see what Mike says before we start adding back any legacy hacks for it. > > Yeah, I'm aware that some extra patches are being developped like the > > omap clocks one: https://patchwork.kernel.org/patch/2541331/ but they > > don't seem to be in -next. So, again, please, wait that all needed bits > > are merged mainline before killing non-DT support (or provide 'mixed' > > support like what is/was done on kirkwood) > > Agree, please don't be too quick, :-) Too quick? The basic DT based booting has been working for a few years now to some extent on omaps :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 17, 2013 at 4:27 PM, Tony Lindgren <tony@atomide.com> wrote: > Too quick? The basic DT based booting has been working for a few years > now to some extent on omaps :) I mean it is OK to drop legacy mode now if it won't break old system. Otherwise, it is better to slow down the dropping legacy patch so that the board won't be one brick for us old board users, :-) Thanks,
* Ming Lei <tom.leiming@gmail.com> [130617 01:47]: > On Mon, Jun 17, 2013 at 4:27 PM, Tony Lindgren <tony@atomide.com> wrote: > > Too quick? The basic DT based booting has been working for a few years > > now to some extent on omaps :) > > I mean it is OK to drop legacy mode now if it won't break old system. > Otherwise, it is better to slow down the dropping legacy patch so that > the board won't be one brick for us old board users, :-) Right, the plan is be able to use it naturally. The USB auxclk issue is fixable for DT boot, we just need to decide what's the best way to fix it. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tony Lindgren <tony@atomide.com> writes: Hi, > * Arnaud Patard <arnaud.patard@rtp-net.org> [130617 01:13]: >> >> I hoped to have missed some mails and that people were testing pandabard >> support with full support but given what I see, the ethernet support is >> not there yet. This thread is about removing the non-DT boot. I see some >> contradiction here. Please, look again at what Thomas said in the IGEP thread: >> breaking existing support is bad and removing non-DT boot for panda with >> not-working ethernet would exactly to that. > > Hmm yes I guess the panda needs the aux clock and there are various > patches posted for that for quite a while but have not gotten merged. yes, it needs aux clock, see: https://lkml.org/lkml/2013/4/19/124 > > When I did my patches it seemed that Nishant's and my solution for > getting the auxclk via DT was acceptable. Then Mike started doing > all the clocks in DT and things changed. > > Mike, got any solution for us for v3.11 for the DT defined auxclk? > >> Yeah, I'm aware that some extra patches are being developped like the >> omap clocks one: https://patchwork.kernel.org/patch/2541331/ but they >> don't seem to be in -next. So, again, please, wait that all needed bits >> are merged mainline before killing non-DT support (or provide 'mixed' >> support like what is/was done on kirkwood) > > The ethernet issue can be fixed with the legacy mode support in the > worst case, but probably just adding a clock alias for it does the > trick. > > I'd rather not postpone making omap4 DT only because I think at this > point fixing the any DT related issues is way less work compared to > maintaining and testing both legacy boot and DT boot. I understand your concerns but, please, cope with reality: the clock work is not in -next so this tends to make me think it won't reach 3.11. We're at -rc6 after all. Telling users that their system doesn't have any network because it was easier to maintain, is not something they will understand imho. Regards, Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Arnaud Patard <arnaud.patard@rtp-net.org> [130617 02:52]: > Tony Lindgren <tony@atomide.com> writes: > > I understand your concerns but, please, cope with reality: the clock > work is not in -next so this tends to make me think it won't reach > 3.11. We're at -rc6 after all. Telling users that their system doesn't > have any network because it was easier to maintain, is not something > they will understand imho. Right, like I said: the idea is to have it usable with DT. And USB and Ethernet certainly are part of what I call usable. So is MMC, WLAN and DSS. I've certainly spent quite a bit of time on making sure panda works with DT, and I can assure you that fixing the USB extclock is easier than supporting the legacy boot with DT :) This issue can also be fixed with a clock alias if we don't have DT defined clocks ready for v3.11. It may take a few days for us to have the solution. But get getting a clock to a driver certainly is not a showstopper here. After all, that's what all drivers already do. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren <tony@atomide.com> [130617 03:32]: > * Arnaud Patard <arnaud.patard@rtp-net.org> [130617 02:52]: > > Tony Lindgren <tony@atomide.com> writes: > > > > I understand your concerns but, please, cope with reality: the clock > > work is not in -next so this tends to make me think it won't reach > > 3.11. We're at -rc6 after all. Telling users that their system doesn't > > have any network because it was easier to maintain, is not something > > they will understand imho. > > Right, like I said: the idea is to have it usable with DT. And USB and > Ethernet certainly are part of what I call usable. So is MMC, WLAN and > DSS. I've certainly spent quite a bit of time on making sure panda works > with DT, and I can assure you that fixing the USB extclock is easier than > supporting the legacy boot with DT :) > > This issue can also be fixed with a clock alias if we don't have DT > defined clocks ready for v3.11. It may take a few days for us to have > the solution. But get getting a clock to a driver certainly is not a > showstopper here. After all, that's what all drivers already do. Care to test the last patch just posted by Roger in thread " [PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix"? That adds a clock alias for the EHCI auxclk so it should continue working until we have the DT clock patches available. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tony Lindgren <tony@atomide.com> writes: Hi, > * Tony Lindgren <tony@atomide.com> [130617 03:32]: >> * Arnaud Patard <arnaud.patard@rtp-net.org> [130617 02:52]: >> > Tony Lindgren <tony@atomide.com> writes: >> > >> > I understand your concerns but, please, cope with reality: the clock >> > work is not in -next so this tends to make me think it won't reach >> > 3.11. We're at -rc6 after all. Telling users that their system doesn't >> > have any network because it was easier to maintain, is not something >> > they will understand imho. >> >> Right, like I said: the idea is to have it usable with DT. And USB and >> Ethernet certainly are part of what I call usable. So is MMC, WLAN and >> DSS. I've certainly spent quite a bit of time on making sure panda works >> with DT, and I can assure you that fixing the USB extclock is easier than >> supporting the legacy boot with DT :) >> >> This issue can also be fixed with a clock alias if we don't have DT >> defined clocks ready for v3.11. It may take a few days for us to have >> the solution. But get getting a clock to a driver certainly is not a >> showstopper here. After all, that's what all drivers already do. > > Care to test the last patch just posted by Roger in thread > " [PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix"? I tried to test them but they don't apply on linux-next due to some pinctrl changes probably missing: Error: arch/arm/boot/dts/omap4-panda-common.dtsi:177.14-15 syntax error which corresponds to : 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) Also, the patch 3 (ARM: dts: omap5-uevm: Provide USB Host PHY clock) doesn't apply as the omap5-uevm.dts doesn't exist. Which tree should I use to test the patches if it's not linux-next ? Also, you might want to know that drivers/usb/musb/omap2430.c doesn't build due to some typos (musb_resources vs musb_resouces). Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Arnaud Patard <arnaud.patard@rtp-net.org> [130619 02:52]: > Tony Lindgren <tony@atomide.com> writes: > > Hi, > > > * Tony Lindgren <tony@atomide.com> [130617 03:32]: > >> * Arnaud Patard <arnaud.patard@rtp-net.org> [130617 02:52]: > >> > Tony Lindgren <tony@atomide.com> writes: > >> > > >> > I understand your concerns but, please, cope with reality: the clock > >> > work is not in -next so this tends to make me think it won't reach > >> > 3.11. We're at -rc6 after all. Telling users that their system doesn't > >> > have any network because it was easier to maintain, is not something > >> > they will understand imho. > >> > >> Right, like I said: the idea is to have it usable with DT. And USB and > >> Ethernet certainly are part of what I call usable. So is MMC, WLAN and > >> DSS. I've certainly spent quite a bit of time on making sure panda works > >> with DT, and I can assure you that fixing the USB extclock is easier than > >> supporting the legacy boot with DT :) > >> > >> This issue can also be fixed with a clock alias if we don't have DT > >> defined clocks ready for v3.11. It may take a few days for us to have > >> the solution. But get getting a clock to a driver certainly is not a > >> showstopper here. After all, that's what all drivers already do. > > > > Care to test the last patch just posted by Roger in thread > > " [PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix"? > > I tried to test them but they don't apply on linux-next due to some > pinctrl changes probably missing: > Error: arch/arm/boot/dts/omap4-panda-common.dtsi:177.14-15 syntax error > > which corresponds to : > 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) Oops, right, that's in Benoit's branch too for the .dts preprocessing. Until it is merged, maybe try with Roger's earlier version of that patch that did not yet use the macros? > Also, the patch 3 (ARM: dts: omap5-uevm: Provide USB Host PHY clock) > doesn't apply as the omap5-uevm.dts doesn't exist. OK that's in Benoit's branch. But you won't need that one. > Which tree should I use to test the patches if it's not linux-next ? > > Also, you might want to know that drivers/usb/musb/omap2430.c doesn't > build due to some typos (musb_resources vs musb_resouces). Thanks, I think Felipe is already aware of that. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Tony Lindgren <tony@atomide.com> writes: Hi, > * Arnaud Patard <arnaud.patard@rtp-net.org> [130619 02:52]: >> Tony Lindgren <tony@atomide.com> writes: >> >> Hi, >> >> > * Tony Lindgren <tony@atomide.com> [130617 03:32]: >> >> * Arnaud Patard <arnaud.patard@rtp-net.org> [130617 02:52]: >> >> > Tony Lindgren <tony@atomide.com> writes: >> >> > >> >> > I understand your concerns but, please, cope with reality: the clock >> >> > work is not in -next so this tends to make me think it won't reach >> >> > 3.11. We're at -rc6 after all. Telling users that their system doesn't >> >> > have any network because it was easier to maintain, is not something >> >> > they will understand imho. >> >> >> >> Right, like I said: the idea is to have it usable with DT. And USB and >> >> Ethernet certainly are part of what I call usable. So is MMC, WLAN and >> >> DSS. I've certainly spent quite a bit of time on making sure panda works >> >> with DT, and I can assure you that fixing the USB extclock is easier than >> >> supporting the legacy boot with DT :) >> >> >> >> This issue can also be fixed with a clock alias if we don't have DT >> >> defined clocks ready for v3.11. It may take a few days for us to have >> >> the solution. But get getting a clock to a driver certainly is not a >> >> showstopper here. After all, that's what all drivers already do. >> > >> > Care to test the last patch just posted by Roger in thread >> > " [PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix"? >> >> I tried to test them but they don't apply on linux-next due to some >> pinctrl changes probably missing: >> Error: arch/arm/boot/dts/omap4-panda-common.dtsi:177.14-15 syntax error >> >> which corresponds to : >> 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) > > Oops, right, that's in Benoit's branch too for the .dts preprocessing. > Until it is merged, maybe try with Roger's earlier version of that patch > that did not yet use the macros? > Right. I've changed the missing macros with their values and now, it compiles and I can even ping the board, so works for me. Thanks, Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Arnaud Patard <arnaud.patard@rtp-net.org> [130620 00:36]: > Tony Lindgren <tony@atomide.com> writes: > > Hi, > > > * Arnaud Patard <arnaud.patard@rtp-net.org> [130619 02:52]: > >> Tony Lindgren <tony@atomide.com> writes: > >> > >> Hi, > >> > >> > * Tony Lindgren <tony@atomide.com> [130617 03:32]: > >> >> * Arnaud Patard <arnaud.patard@rtp-net.org> [130617 02:52]: > >> >> > Tony Lindgren <tony@atomide.com> writes: > >> >> > > >> >> > I understand your concerns but, please, cope with reality: the clock > >> >> > work is not in -next so this tends to make me think it won't reach > >> >> > 3.11. We're at -rc6 after all. Telling users that their system doesn't > >> >> > have any network because it was easier to maintain, is not something > >> >> > they will understand imho. > >> >> > >> >> Right, like I said: the idea is to have it usable with DT. And USB and > >> >> Ethernet certainly are part of what I call usable. So is MMC, WLAN and > >> >> DSS. I've certainly spent quite a bit of time on making sure panda works > >> >> with DT, and I can assure you that fixing the USB extclock is easier than > >> >> supporting the legacy boot with DT :) > >> >> > >> >> This issue can also be fixed with a clock alias if we don't have DT > >> >> defined clocks ready for v3.11. It may take a few days for us to have > >> >> the solution. But get getting a clock to a driver certainly is not a > >> >> showstopper here. After all, that's what all drivers already do. > >> > > >> > Care to test the last patch just posted by Roger in thread > >> > " [PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix"? > >> > >> I tried to test them but they don't apply on linux-next due to some > >> pinctrl changes probably missing: > >> Error: arch/arm/boot/dts/omap4-panda-common.dtsi:177.14-15 syntax error > >> > >> which corresponds to : > >> 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) > > > > Oops, right, that's in Benoit's branch too for the .dts preprocessing. > > Until it is merged, maybe try with Roger's earlier version of that patch > > that did not yet use the macros? > > > > Right. I've changed the missing macros with their values and now, it > compiles and I can even ping the board, so works for me. Good to hear thanks. Sounds like we should have things mostly working with DT in mainline kernel by v3.11-rc1. I'm sure some minor fixes will be needed as more people start using it, but they should be all fixable either by binding changes, or by initializing missing things using platform data. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 465edd1..1f941c4 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -378,14 +378,6 @@ config MACH_TI8148EVM depends on SOC_TI81XX default y -config MACH_OMAP4_PANDA - bool "OMAP4 Panda Board" - default y - depends on ARCH_OMAP4 - select OMAP_PACKAGE_CBL - select OMAP_PACKAGE_CBS - select REGULATOR_FIXED_VOLTAGE if REGULATOR - config OMAP3_EMU bool "OMAP3 debugging peripherals" depends on ARCH_OMAP3 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 875d61d..2cbf3ef 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -251,7 +251,6 @@ obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o obj-$(CONFIG_MACH_CM_T3517) += board-cm-t3517.o obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o obj-$(CONFIG_MACH_TOUCHBOOK) += board-omap3touchbook.o -obj-$(CONFIG_MACH_OMAP4_PANDA) += board-omap4panda.o obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c deleted file mode 100644 index 1e2c75e..0000000 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ /dev/null @@ -1,455 +0,0 @@ -/* - * Board support file for OMAP4430 based PandaBoard. - * - * Copyright (C) 2010 Texas Instruments - * - * Author: David Anders <x0132446@ti.com> - * - * Based on mach-omap2/board-4430sdp.c - * - * Author: Santosh Shilimkar <santosh.shilimkar@ti.com> - * - * Based on mach-omap2/board-3430sdp.c - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#include <linux/kernel.h> -#include <linux/init.h> -#include <linux/platform_device.h> -#include <linux/clk.h> -#include <linux/io.h> -#include <linux/leds.h> -#include <linux/gpio.h> -#include <linux/usb/otg.h> -#include <linux/i2c/twl.h> -#include <linux/mfd/twl6040.h> -#include <linux/regulator/machine.h> -#include <linux/regulator/fixed.h> -#include <linux/ti_wilink_st.h> -#include <linux/usb/musb.h> -#include <linux/usb/phy.h> -#include <linux/usb/nop-usb-xceiv.h> -#include <linux/wl12xx.h> -#include <linux/irqchip/arm-gic.h> -#include <linux/platform_data/omap-abe-twl6040.h> - -#include <asm/mach-types.h> -#include <asm/mach/arch.h> -#include <asm/mach/map.h> - -#include "common.h" -#include "soc.h" -#include "mmc.h" -#include "hsmmc.h" -#include "control.h" -#include "mux.h" -#include "common-board-devices.h" -#include "dss-common.h" - -#define GPIO_HUB_POWER 1 -#define GPIO_HUB_NRESET 62 -#define GPIO_WIFI_PMENA 43 -#define GPIO_WIFI_IRQ 53 - -/* wl127x BT, FM, GPS connectivity chip */ -static struct ti_st_plat_data wilink_platform_data = { - .nshutdown_gpio = 46, - .dev_name = "/dev/ttyO1", - .flow_cntrl = 1, - .baud_rate = 3000000, - .chip_enable = NULL, - .suspend = NULL, - .resume = NULL, -}; - -static struct platform_device wl1271_device = { - .name = "kim", - .id = -1, - .dev = { - .platform_data = &wilink_platform_data, - }, -}; - -static struct gpio_led gpio_leds[] = { - { - .name = "pandaboard::status1", - .default_trigger = "heartbeat", - .gpio = 7, - }, - { - .name = "pandaboard::status2", - .default_trigger = "mmc0", - .gpio = 8, - }, -}; - -static struct gpio_led_platform_data gpio_led_info = { - .leds = gpio_leds, - .num_leds = ARRAY_SIZE(gpio_leds), -}; - -static struct platform_device leds_gpio = { - .name = "leds-gpio", - .id = -1, - .dev = { - .platform_data = &gpio_led_info, - }, -}; - -static struct omap_abe_twl6040_data panda_abe_audio_data = { - /* Audio out */ - .has_hs = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT, - /* HandsFree through expansion connector */ - .has_hf = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT, - /* PandaBoard: FM TX, PandaBoardES: can be connected to audio out */ - .has_aux = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT, - /* PandaBoard: FM RX, PandaBoardES: audio in */ - .has_afm = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT, - /* No jack detection. */ - .jack_detection = 0, - /* MCLK input is 38.4MHz */ - .mclk_freq = 38400000, - -}; - -static struct platform_device panda_abe_audio = { - .name = "omap-abe-twl6040", - .id = -1, - .dev = { - .platform_data = &panda_abe_audio_data, - }, -}; - -static struct platform_device panda_hdmi_audio_codec = { - .name = "hdmi-audio-codec", - .id = -1, -}; - -static struct platform_device btwilink_device = { - .name = "btwilink", - .id = -1, -}; - -/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */ -static struct nop_usb_xceiv_platform_data hsusb1_phy_data = { - /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */ - .clk_rate = 19200000, -}; - -static struct usbhs_phy_data phy_data[] __initdata = { - { - .port = 1, - .reset_gpio = GPIO_HUB_NRESET, - .vcc_gpio = GPIO_HUB_POWER, - .vcc_polarity = 1, - .platform_data = &hsusb1_phy_data, - }, -}; - -static struct platform_device *panda_devices[] __initdata = { - &leds_gpio, - &wl1271_device, - &panda_abe_audio, - &panda_hdmi_audio_codec, - &btwilink_device, -}; - -static struct usbhs_omap_platform_data usbhs_bdata __initdata = { - .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY, -}; - -static void __init omap4_ehci_init(void) -{ - int ret; - - /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */ - ret = clk_add_alias("main_clk", "nop_usb_xceiv.1", "auxclk3_ck", NULL); - if (ret) - pr_err("Failed to add main_clk alias to auxclk3_ck\n"); - - usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data)); - usbhs_init(&usbhs_bdata); -} - -static struct omap_musb_board_data musb_board_data = { - .interface_type = MUSB_INTERFACE_UTMI, - .mode = MUSB_OTG, - .power = 100, -}; - -static struct omap2_hsmmc_info mmc[] = { - { - .mmc = 1, - .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA, - .gpio_wp = -EINVAL, - .gpio_cd = -EINVAL, - }, - { - .name = "wl1271", - .mmc = 5, - .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD, - .gpio_wp = -EINVAL, - .gpio_cd = -EINVAL, - .ocr_mask = MMC_VDD_165_195, - .nonremovable = true, - }, - {} /* Terminator */ -}; - -static struct regulator_consumer_supply omap4_panda_vmmc5_supply[] = { - REGULATOR_SUPPLY("vmmc", "omap_hsmmc.4"), -}; - -static struct regulator_init_data panda_vmmc5 = { - .constraints = { - .valid_ops_mask = REGULATOR_CHANGE_STATUS, - }, - .num_consumer_supplies = ARRAY_SIZE(omap4_panda_vmmc5_supply), - .consumer_supplies = omap4_panda_vmmc5_supply, -}; - -static struct fixed_voltage_config panda_vwlan = { - .supply_name = "vwl1271", - .microvolts = 1800000, /* 1.8V */ - .gpio = GPIO_WIFI_PMENA, - .startup_delay = 70000, /* 70msec */ - .enable_high = 1, - .enabled_at_boot = 0, - .init_data = &panda_vmmc5, -}; - -static struct platform_device omap_vwlan_device = { - .name = "reg-fixed-voltage", - .id = 1, - .dev = { - .platform_data = &panda_vwlan, - }, -}; - -static struct wl12xx_platform_data omap_panda_wlan_data __initdata = { - .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */ -}; - -static struct twl6040_codec_data twl6040_codec = { - /* single-step ramp for headset and handsfree */ - .hs_left_step = 0x0f, - .hs_right_step = 0x0f, - .hf_left_step = 0x1d, - .hf_right_step = 0x1d, -}; - -static struct twl6040_platform_data twl6040_data = { - .codec = &twl6040_codec, - .audpwron_gpio = 127, -}; - -static struct i2c_board_info __initdata panda_i2c_1_boardinfo[] = { - { - I2C_BOARD_INFO("twl6040", 0x4b), - .irq = 119 + OMAP44XX_IRQ_GIC_START, - .platform_data = &twl6040_data, - }, -}; - -/* Panda board uses the common PMIC configuration */ -static struct twl4030_platform_data omap4_panda_twldata; - -/* - * Display monitor features are burnt in their EEPROM as EDID data. The EEPROM - * is connected as I2C slave device, and can be accessed at address 0x50 - */ -static struct i2c_board_info __initdata panda_i2c_eeprom[] = { - { - I2C_BOARD_INFO("eeprom", 0x50), - }, -}; - -static int __init omap4_panda_i2c_init(void) -{ - omap4_pmic_get_config(&omap4_panda_twldata, TWL_COMMON_PDATA_USB, - TWL_COMMON_REGULATOR_VDAC | - TWL_COMMON_REGULATOR_VAUX2 | - TWL_COMMON_REGULATOR_VAUX3 | - TWL_COMMON_REGULATOR_VMMC | - TWL_COMMON_REGULATOR_VPP | - TWL_COMMON_REGULATOR_VANA | - TWL_COMMON_REGULATOR_VCXIO | - TWL_COMMON_REGULATOR_VUSB | - TWL_COMMON_REGULATOR_CLK32KG | - TWL_COMMON_REGULATOR_V1V8 | - TWL_COMMON_REGULATOR_V2V1); - omap4_pmic_init("twl6030", &omap4_panda_twldata, panda_i2c_1_boardinfo, - ARRAY_SIZE(panda_i2c_1_boardinfo)); - omap_register_i2c_bus(2, 400, NULL, 0); - /* - * Bus 3 is attached to the DVI port where devices like the pico DLP - * projector don't work reliably with 400kHz - */ - omap_register_i2c_bus(3, 100, panda_i2c_eeprom, - ARRAY_SIZE(panda_i2c_eeprom)); - omap_register_i2c_bus(4, 400, NULL, 0); - return 0; -} - -#ifdef CONFIG_OMAP_MUX -static struct omap_board_mux board_mux[] __initdata = { - /* WLAN IRQ - GPIO 53 */ - OMAP4_MUX(GPMC_NCS3, OMAP_MUX_MODE3 | OMAP_PIN_INPUT), - /* WLAN POWER ENABLE - GPIO 43 */ - OMAP4_MUX(GPMC_A19, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT), - /* WLAN SDIO: MMC5 CMD */ - OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), - /* WLAN SDIO: MMC5 CLK */ - OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), - /* WLAN SDIO: MMC5 DAT[0-3] */ - OMAP4_MUX(SDMMC5_DAT0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), - OMAP4_MUX(SDMMC5_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), - OMAP4_MUX(SDMMC5_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), - OMAP4_MUX(SDMMC5_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), - /* gpio 0 - TFP410 PD */ - OMAP4_MUX(KPD_COL1, OMAP_PIN_OUTPUT | OMAP_MUX_MODE3), - /* dispc2_data23 */ - OMAP4_MUX(USBB2_ULPITLL_STP, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data22 */ - OMAP4_MUX(USBB2_ULPITLL_DIR, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data21 */ - OMAP4_MUX(USBB2_ULPITLL_NXT, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data20 */ - OMAP4_MUX(USBB2_ULPITLL_DAT0, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data19 */ - OMAP4_MUX(USBB2_ULPITLL_DAT1, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data18 */ - OMAP4_MUX(USBB2_ULPITLL_DAT2, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data15 */ - OMAP4_MUX(USBB2_ULPITLL_DAT3, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data14 */ - OMAP4_MUX(USBB2_ULPITLL_DAT4, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data13 */ - OMAP4_MUX(USBB2_ULPITLL_DAT5, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data12 */ - OMAP4_MUX(USBB2_ULPITLL_DAT6, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data11 */ - OMAP4_MUX(USBB2_ULPITLL_DAT7, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data10 */ - OMAP4_MUX(DPM_EMU3, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data9 */ - OMAP4_MUX(DPM_EMU4, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data16 */ - OMAP4_MUX(DPM_EMU5, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data17 */ - OMAP4_MUX(DPM_EMU6, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_hsync */ - OMAP4_MUX(DPM_EMU7, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_pclk */ - OMAP4_MUX(DPM_EMU8, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_vsync */ - OMAP4_MUX(DPM_EMU9, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_de */ - OMAP4_MUX(DPM_EMU10, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data8 */ - OMAP4_MUX(DPM_EMU11, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data7 */ - OMAP4_MUX(DPM_EMU12, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data6 */ - OMAP4_MUX(DPM_EMU13, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data5 */ - OMAP4_MUX(DPM_EMU14, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data4 */ - OMAP4_MUX(DPM_EMU15, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data3 */ - OMAP4_MUX(DPM_EMU16, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data2 */ - OMAP4_MUX(DPM_EMU17, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data1 */ - OMAP4_MUX(DPM_EMU18, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* dispc2_data0 */ - OMAP4_MUX(DPM_EMU19, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5), - /* NIRQ2 for twl6040 */ - OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE0 | - OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE), - /* GPIO_127 for twl6040 */ - OMAP4_MUX(HDQ_SIO, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT), - /* McPDM */ - OMAP4_MUX(ABE_PDM_UL_DATA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN), - OMAP4_MUX(ABE_PDM_DL_DATA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN), - OMAP4_MUX(ABE_PDM_FRAME, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), - OMAP4_MUX(ABE_PDM_LB_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN), - OMAP4_MUX(ABE_CLKS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN), - /* McBSP1 */ - OMAP4_MUX(ABE_MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), - OMAP4_MUX(ABE_MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN), - OMAP4_MUX(ABE_MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT | - OMAP_PULL_ENA), - OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT), - - /* UART2 - BT/FM/GPS shared transport */ - OMAP4_MUX(UART2_CTS, OMAP_PIN_INPUT | OMAP_MUX_MODE0), - OMAP4_MUX(UART2_RTS, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0), - OMAP4_MUX(UART2_RX, OMAP_PIN_INPUT | OMAP_MUX_MODE0), - OMAP4_MUX(UART2_TX, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0), - - { .reg_offset = OMAP_MUX_TERMINATOR }, -}; - -#else -#define board_mux NULL -#endif - - -static void omap4_panda_init_rev(void) -{ - if (cpu_is_omap443x()) { - /* PandaBoard 4430 */ - /* ASoC audio configuration */ - panda_abe_audio_data.card_name = "PandaBoard"; - panda_abe_audio_data.has_hsmic = 1; - } else { - /* PandaBoard ES */ - /* ASoC audio configuration */ - panda_abe_audio_data.card_name = "PandaBoardES"; - } -} - -static void __init omap4_panda_init(void) -{ - int package = OMAP_PACKAGE_CBS; - int ret; - - if (omap_rev() == OMAP4430_REV_ES1_0) - package = OMAP_PACKAGE_CBL; - omap4_mux_init(board_mux, NULL, package); - - omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ); - ret = wl12xx_set_platform_data(&omap_panda_wlan_data); - if (ret) - pr_err("error setting wl12xx data: %d\n", ret); - - omap4_panda_init_rev(); - omap4_panda_i2c_init(); - platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices)); - platform_device_register(&omap_vwlan_device); - omap_serial_init(); - omap_sdrc_init(NULL, NULL); - omap4_twl6030_hsmmc_init(mmc); - omap4_ehci_init(); - usb_bind_phy("musb-hdrc.2.auto", 0, "omap-usb2.3.auto"); - usb_musb_init(&musb_board_data); - omap4_panda_display_init(); -} - -MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board") - /* Maintainer: David Anders - Texas Instruments Inc */ - .atag_offset = 0x100, - .smp = smp_ops(omap4_smp_ops), - .reserve = omap_reserve, - .map_io = omap4_map_io, - .init_early = omap4430_init_early, - .init_irq = gic_init_irq, - .init_machine = omap4_panda_init, - .init_late = omap4430_init_late, - .init_time = omap4_local_timer_init, - .restart = omap44xx_restart, -MACHINE_END
We can now boot with device tree. If you don't want to update u-boot, you can boot with appended DTB with the following instructions: 1. Make sure you have the appended DTB support in .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y 2. Build the zImage $ ARCH=arm CROSS_COMPILE=... make zImage 3. Build the device tree blobs $ ARCH=arm CROSS_COMPILE=... make dtbs 4. Append the correct panda dtb to zImage Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb or omap4-panda-es.dtb. $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > /tmp/appended 5. Use mkimage to produce the appended device tree uImage $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ -n "Linux" -d /tmp/appended /tmp/uImage Signed-off-by: Tony Lindgren <tony@atomide.com --- arch/arm/mach-omap2/Kconfig | 8 - arch/arm/mach-omap2/Makefile | 1 arch/arm/mach-omap2/board-omap4panda.c | 455 -------------------------------- 3 files changed, 464 deletions(-) delete mode 100644 arch/arm/mach-omap2/board-omap4panda.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html