Drop legacy booting for omap4 for v3.11, boot with device tree only

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 dtb to zImage

   $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.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 <[email protected]>

Quoted 23 lines · Tony Lindgren

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 dtb to zImage

   $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb > /tmp/appended

5. Use mkimage to produce the appended device tree uImage

Quoted 4 lines

   $ 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 <[email protected]>

Okay, I'm removing the 4430SDP from the boot test system once this goes in, because this will mean rewriting the build system to cope with this stuff.

Quoted 23 lines · Tony Lindgren

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 dtb to zImage

   $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb > /tmp/appended

5. Use mkimage to produce the appended device tree uImage

Quoted 4 lines

   $ 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 <[email protected]>

Okay, I'm removing the 4430SDP from the boot test system once this goes in, because this will mean rewriting the build system to cope with this stuff.

Well, this doesn't work. I've tried several things, and I think I'm generating a correct image, but it doesn't boot.

This could be that the current Linus tip plus my stuff plus arm-soc is broken, but as it boots on the 3430LDP I suspect that isn't the case.

I've tried with omap4-sdp.dtb and the other omap4-sdp DTB file with no improvement. No idea how to even begin to debug this, as there's no way for the decompressor to produce output, and I've no idea which OMAP uart to use for debug output (because that information has been removed from the kernel source.)

And... WTF is the OMAP debug uart selection in its own separate menu from the main "choice" statement? This is totally unnecessary complexity and is just making things more complicated for the hell of it. Look at what every other platform does - they put their stuff in the main choice statement even if they have multiple UARTs. The hint there is that these depend on the appropriate support being selected, so in the case of a kernel only targetting OMAP, as things stand you'll end up with a menu which lists the OMAP2PLUS, none, icedcc, and semihosting entries followed by another menu to select which OMAP port you want. That's utterly rediculous and broken. And just think about the two titles for the menus:

prompt "Kernel low-level debugging port"
vs
prompt "Low-level debug console UART"

Oh wait, why don't I get to choose my "debug console UART" on an AT91? Maybe AT91 should move their debug uart selection into this menu as well, and maybe the Versatile Express options too, because they're all to do with selecting the UART to be used. Please... some sane *thought* would be *really* good here.

Oh my god, you're not the only ones. Arnd/Olof, who started this madness and _why_ haven't you already stepped on it? Right, I'm fixing this in this merge window. Everything is moving under the original choice menu as it was intended to be.

The attempts are all on the builder website against the (disabled) omap4430-sdp entry.

Okay, I guessed that the OMAP4430SDP was "blaze" (it's not obvious to use internal codenames for boards when they're known as "SDP" etc - especially when they have stickers on them saying that they're "SDP".)

With that worked out, throwing my standard printascii() hack into the kernel results in boot messages... up to the point where the timer is calibrated. So, it looks like either interrupts, clocks, or the OMAP timers are non-functional with DT based kernels on the SDP board.

Any ideas?

Quoted 4 lines · Russell King - ARM Linux

Okay, I guessed that the OMAP4430SDP was "blaze" (it's not obvious to use internal codenames for boards when they're known as "SDP" etc - especially when they have stickers on them saying that they're "SDP".)

Agreed, let's update that.

Quoted 4 lines

With that worked out, throwing my standard printascii() hack into the kernel results in boot messages... up to the point where the timer is calibrated. So, it looks like either interrupts, clocks, or the OMAP timers are non-functional with DT based kernels on the SDP board.

Hey the good news is that you've updated your build system to support also appended dtb images, thanks for doing that!

Quoted 1 line

Any ideas?

Looks like you need some things updated and added to your .config.

(quoted diff) +1 -1

-# CONFIG_OMAP_MUX is not set
+CONFIG_MACH_OMAP_GENERIC=y

That we should nowadays always select though.

CONFIG_REGULATOR_FIXED_VOLTAGE=y

This you will need for Ethernet.

CONFIG_PINCTRL_SINGLE=y

This is good to have, will be needed especially for for UART wake-up events with deeper idle modes enabled once the pending pinctrl patches are merged.

Then there's a pending patch to change drivers/i2c/busses/i2c-omap.c to use just a regular module_init, that should remove the i2c timeout errors as then deferred probe will work properly.

BTW, maybe add a link to your build system to www.arm.linux.org.uk developer page too? At least I could not find a link to it.

Quoted 3 lines · Tony Lindgren

Hey the good news is that you've updated your build system to support also appended dtb images, thanks for doing that!

It was far from trivial - there's many places in the build process which do things quite differently depending on whether it's a DTB build or not.

It seems that - yet again - the mmc devices have swapped themselves.

Also looks like the nonfunctional video stuff is even more nonfunctional than usual:

omapdss DSI error: can't get VDDS_DSI regulator omapdss HDMI error: can't get VDDA_HDMI_DAC regulator

ASoC looks dead too:

omap-abe-twl6040 sound.10: ASoC: CPU DAI (null) not registered omap-abe-twl6040 sound.10: snd_soc_register_card() failed: -517

Quoted 4 lines

ASoC looks dead too:

omap-abe-twl6040 sound.10: ASoC: CPU DAI (null) not registered omap-abe-twl6040 sound.10: snd_soc_register_card() failed: -517

Peter, I think you've had audio working with devicetree for at least a year or something?

Also looks like the nonfunctional video stuff is even more nonfunctional than usual:

omapdss DSI error: can't get VDDS_DSI regulator omapdss HDMI error: can't get VDDA_HDMI_DAC regulator

Quoted 5 lines · Russell King - ARM Linux

Also looks like the nonfunctional video stuff is even more nonfunctional than usual:

omapdss DSI error: can't get VDDS_DSI regulator omapdss HDMI error: can't get VDDA_HDMI_DAC regulator

Those should be followed by "...requests probe deferral", and the driver is probed again later.

The log
http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=946
shows "taal display2: panel revision e3.83.7d" which hints that the panel (and DSS) was initialized properly.

Those error prints should probably be tuned down a bit now that the driver uses probe deferral.

Tomi

When booting with DT the omapfb's probe is deferred several times but it always fails on dpi_connect() due not being able to get the VDDS_DSI regulator:

So I tried adding this to my DT with no luck.

arch/arm/boot/dts/omap3-igep0020.dts +0 -0

index 17a6fc1..eaae935 100644

Quoted 3 lines · Javier Martinez Canillas

When booting with DT the omapfb's probe is deferred several times but it always fails on dpi_connect() due not being able to get the VDDS_DSI regulator:

The problem with DT boot is that the VDDS_DSI is not linked to the DPI device. For omap4, we have a few hacks to go around this (see dsi.c, dsi_regulator_init()).

Quoted 13 lines

So I tried adding this to my DT with no luck.

arch/arm/boot/dts/omap3-igep0020.dts +2 -0

index 17a6fc1..eaae935 100644
@@ -256,3 +256,8 @@
 &usbhsehci {
        phys = <&hsusb1_phy>;
 };
+
+&vpll2 {

arch/arm/boot/dts/omap3-igep0020.dts line 263

Quoted 3 lines

arch/arm/boot/dts/omap3-igep0020.dts +3 -0

+        supply-dev = "omapdss_dpi.0";
+        supply = "vdds_dsi";
+};

I didn't see "supply-dev" defined in dt bindings documentation, is that supposed to work? If it should work, then the problem could be solved with the above. Otherwise I guess we must add more hacks to omapdss driver, to all places where it uses regulator_get...

Tomi

With that worked out, throwing my standard printascii() hack into the kernel results in boot messages... up to the point where the timer is calibrated. So, it looks like either interrupts, clocks, or the OMAP timers are non-functional with DT based kernels on the SDP board.

Any ideas?

This is pretty painful, and I don't know if we want to rethink Arnd's patch since it will break existing defconfigs out there that rely on OMAP2PLUS enabling the socs instead of the other way around. Opinions?

Quoted 3 lines · Olof Johansson

This is pretty painful, and I don't know if we want to rethink Arnd's patch since it will break existing defconfigs out there that rely on OMAP2PLUS enabling the socs instead of the other way around. Opinions?

(replying to myself, I know, I know...)

I think it's probably easiest to just select the OMAP{2,3,4} and AM33XX options in multi_v7_defconfig just like Arnd did in the commit that changed the dependencies for now. I've added a patch on top of our current fixes branch to do so.

Note that you need to make corresponding changes to your seeds for your build tests, Russell.

Oh wait, why don't I get to choose my "debug console UART" on an AT91? Maybe AT91 should move their debug uart selection into this menu as well, and maybe the Versatile Express options too, because they're all to do with selecting the UART to be used. Please... some sane thought would be really good here.

Oh my god, you're not the only ones. Arnd/Olof, who started this madness and why haven't you already stepped on it? Right, I'm fixing this in this merge window. Everything is moving under the original choice menu as it was intended to be.

Sorry, I missed that this was going on, and I absolutely agree with your sentiment. From what I can tell from the git log, Tegra was the first to have the separate choice statement, after it just move its options from mach-tegra/Kconfig into the Kconfig.debug. OMAP followed with the same method and I think from there people just copied it.

I can understand why one wants to have some more structure in the list, given that i.MX alone has 37 options for UART addresses, but we first need to have a consistent method of configuring the addresses.

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

Hi,

Quoted 22 lines · Tony Lindgren

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.

Quoted 6 lines

   $ 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

Quoted 39 lines · Ming Lei

Hi,

Quoted 22 lines · Tony Lindgren

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.

Quoted 6 lines

   $ 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

Quoted 4 lines

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.

Quoted 39 lines · Tony Lindgren

Quoted 38 lines · Ming Lei

Hi,

Quoted 22 lines · Tony Lindgren

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.

Quoted 6 lines

   $ 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

Quoted 7 lines

Quoted 4 lines

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

Hi Tony,

Quoted 52 lines · Tony Lindgren

Quoted 39 lines · Tony Lindgren

Quoted 38 lines · Ming Lei

Hi,

Quoted 22 lines · Tony Lindgren

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.

Quoted 6 lines

   $ 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

Quoted 7 lines

Quoted 4 lines

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,

Quoted 1 line

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.

Quoted 4 lines

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

Quoted 2 lines

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 <[email protected]>
Date:   Fri Jun 7 16:40:02 2013 +1000

Add linux-next specific files for 20130607

Quoted 4 lines · Sricharan R

Quoted 4 lines

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.

Quoted 11 lines

Quoted 2 lines

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 <[email protected]>
Date:   Fri Jun 7 16:40:02 2013 +1000

Quoted 1 line

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?

Quoted 54 lines · Sricharan R

Hi Tony,

Quoted 52 lines · Tony Lindgren

Quoted 39 lines · Tony Lindgren

Quoted 38 lines · Ming Lei

Hi,

Quoted 22 lines · Tony Lindgren

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.

Quoted 6 lines

   $ 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

Quoted 7 lines

Quoted 4 lines

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,

Quoted 8 lines

Quoted 1 line

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 <[email protected]>
Date:   Fri Jun 7 16:40:02 2013 +1000

Add linux-next specific files for 20130607

Quoted 66 lines · Sricharan R

Quoted 54 lines · Sricharan R

Hi Tony,

Quoted 52 lines · Tony Lindgren

Quoted 39 lines · Tony Lindgren

Quoted 38 lines · Ming Lei

Hi,

Quoted 22 lines · Tony Lindgren

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.

Quoted 6 lines

   $ 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

Quoted 7 lines

Quoted 4 lines

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,

Quoted 8 lines

Quoted 1 line

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

Quoted 7 lines

Booted with ramdisk and mmc FS

commit c04efed734409f5a44715b54a6ca1b54b0ccf215

Author: Stephen Rothwell <[email protected]>
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+

Quoted 93 lines · Ming Lei

Quoted 65 lines · Sricharan R

Quoted 52 lines · Sricharan R

Hi Tony,

Quoted 50 lines · Tony Lindgren

Quoted 39 lines · Tony Lindgren

Quoted 38 lines · Ming Lei

Hi,

Quoted 22 lines · Tony Lindgren

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.

Quoted 6 lines

   $ 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

Quoted 7 lines

Quoted 4 lines

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.

Quoted 9 lines

Quoted 3 lines

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

Quoted 7 lines

Booted with ramdisk and mmc FS

commit c04efed734409f5a44715b54a6ca1b54b0ccf215

Author: Stephen Rothwell <[email protected]>
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

Quoted 1 line

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,

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.0-rc4-next-20130607 (a0393807 at 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

Sricharan R <[email protected]> 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.

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)

Quoted 8 lines · Arnaud Patard

Sricharan R <[email protected]> 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.

Quoted 5 lines

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 :)

Quoted 2 lines · Tony Lindgren

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, :-)

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)

Quoted 7 lines

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?

Quoted 5 lines

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.

Tony Lindgren <[email protected]> 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.

Quoted 7 lines · Arnaud Patard

Tony Lindgren <[email protected]> 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.

Quoted 15 lines · Arnaud Patard

Quoted 7 lines

Tony Lindgren <[email protected]> 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 :)

Quoted 4 lines

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"?

Tony Lindgren <[email protected]> writes:

Hi,

Quoted 16 lines · Tony Lindgren

Quoted 15 lines · Arnaud Patard

Quoted 7 lines

Tony Lindgren <[email protected]> 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 :)

Quoted 7 lines

Quoted 4 lines

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).

Quoted 32 lines

Tony Lindgren <[email protected]> writes:

Hi,

Quoted 16 lines · Tony Lindgren

Quoted 15 lines · Arnaud Patard

Quoted 7 lines

Tony Lindgren <[email protected]> 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 :)

Quoted 7 lines

Quoted 4 lines

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

Quoted 2 lines

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?

Tony Lindgren <[email protected]> writes:

Hi,

Quoted 36 lines · Arnaud Patard

Quoted 34 lines

Tony Lindgren <[email protected]> writes:

Hi,

Quoted 16 lines · Tony Lindgren

Quoted 15 lines · Arnaud Patard

Quoted 7 lines

Tony Lindgren <[email protected]> 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 :)

Quoted 7 lines

Quoted 4 lines

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)

Quoted 4 lines

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.

This is omap4+ only and no longer needed as omap4+ can be booted using device tree.

Also remove the related pdata handling from the driver and the now unneeded platform_data/omap_ocp2scp.h.

Cc Kishon Vijay Abraham I <[email protected]>

Cc Felipe Balbi <[email protected]>

Cc Arnd Bergmann <[email protected]>

Cc Olof Johansson <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

This is omap4+ only and no longer needed as omap4+ can be booted using device tree.

Also remove the related pdata handling from the driver and the now unneeded platform_data/omap_ocp2scp.h.

Cc Kishon Vijay Abraham I <[email protected]>

Cc Felipe Balbi <[email protected]>

Cc Arnd Bergmann <[email protected]>

Cc Olof Johansson <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Hi all,

Here are patches against v3.10-rc1 to drop omap4 legacy booting as things are now working well enough for booting omap4 with device tree.

We already have am33xx and omap5 booting with device tree only, and converting omap4 is relatively easy with just two board-*.c files merged as we have not accepted any new board-*.c files for quite some time now.

By working "well enough" I mean that I can use my omap4 panda-es with device tree with a Motorola LapDock with HDMI, DVI, HID, USB and WLAN using v3.10-rc1 and the patches in this series plus some extra patches that are driver related.

Of course some things will need more work, like PM. But that has not yet been fully working for omap4 anyways, and that work can now be combined with omap5 PM work to some extent.

From d22837262b59ad381feb215496fafe3fe399972f Mon Sep 17 00:00:00 2001