AM3517 fails to boot 3.16-rc5 device tree kernel

DISCUSSION mwelling 2 participants 11 messages Jul 17, 2014 – Jul 22, 2014

lore

Share & tools

lore

mwelling

author

2014-07-17 23:40 UTC #0 lore raw

I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device.

First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported.

Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support.

Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM.

I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release?

Are there any versions where the LCD output works?

Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this.

Any suggestions would be greatly appreciated.

Tony Lindgren

2014-07-18 06:39 UTC #1 lore raw

Quoted 11 lines · mwelling

I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device.
First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported.
Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support.
Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM.

For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too.

Quoted 3 lines

I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release?

No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine?

Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline?

Quoted 1 line

Are there any versions where the LCD output works?

Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup.

Quoted 4 lines

Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this.
Any suggestions would be greatly appreciated.

Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly.

Regards,

Tony

Michael Welling

author

2014-07-18 14:40 UTC #2 lore raw

Quoted 22 lines · Tony Lindgren

Quoted 11 lines · mwelling
I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device.
First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported.
Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support.
Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM.
For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too.
Quoted 3 lines
I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release?

Quoted 5 lines

No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine?
Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline?

I will try this.

Quoted 11 lines

Quoted 2 lines
Are there any versions where the LCD output works?
Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup.
Quoted 3 lines
Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this.

Quoted 6 lines

Quoted 1 line
Any suggestions would be greatly appreciated.
Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly.

I downloaded the version from the test results and it did boot. These are combining the uImage and dtb. How do you accomplish this?

Quoted 4 lines

Regards,
Tony

Michael Welling

author

2014-07-18 15:02 UTC #3 lore raw

Quoted 23 lines · Michael Welling

Quoted 22 lines · Tony Lindgren
Quoted 11 lines · mwelling
I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device.
First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported.
Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support.
Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM.
For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too.
Quoted 3 lines
I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release?

Quoted 6 lines

Quoted 5 lines
No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine?
Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline?
I will try this.

Adding the earlyprintk did not work. It still hangs without any messages.

Quoted 11 lines

Quoted 11 lines
Quoted 2 lines
Are there any versions where the LCD output works?
Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup.
Quoted 3 lines
Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this.

Quoted 6 lines

Quoted 6 lines
Quoted 1 line
Any suggestions would be greatly appreciated.
Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly.

How do you determine which you are booting?

Quoted 6 lines

I downloaded the version from the test results and it did boot. These are combining the uImage and dtb. How do you accomplish this?
Quoted 4 lines
Regards,
Tony

Michael Welling

author

2014-07-18 16:13 UTC #5 lore raw

In reply to Michael Welling

Quoted 40 lines · Michael Welling

Quoted 22 lines · Tony Lindgren
Quoted 11 lines · mwelling
I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device.
First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported.
Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support.
Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM.
For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too.
Quoted 3 lines
I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release?
Quoted 5 lines
No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine?
Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline?
I will try this.
Quoted 11 lines
Quoted 2 lines
Are there any versions where the LCD output works?
Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup.
Quoted 3 lines
Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this.

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
Any suggestions would be greatly appreciated.
Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly.
I downloaded the version from the test results and it did boot. These are combining the uImage and dtb. How do you accomplish this?

It should be noted that when you try to boot the seperate zImage and dtb from the test build it fails. This replicates my issue.

Here are the two binaries that I used:
http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/build_z/omap2plus_defconfig/zImage
http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/dtbs/am3517-evm.dtb

Here is the boot attempt:
U-Boot> dhcp;set serverip 10.0.2.168;tftp 0x82000000 zImage; tftp 0x80000000 am3517-evm.dtb;bootz 0x82000000 - 0x80000000 BOOTP broadcast 1
DHCP client bound to address 10.0.3.33
Using DaVinci-EMAC device
TFTP from server 10.0.2.168; our IP address is 10.0.3.33
Filename 'zImage'.
Load address: 0x82000000
Loading: #################################################################

         #################################################################
         #################################################################
         #################################################################
         ######################################
         2 MiB/s

done
Bytes transferred = 4360800 (428a60 hex)
Using DaVinci-EMAC device
TFTP from server 10.0.2.168; our IP address is 10.0.3.33 Filename 'am3517-evm.dtb'.
Load address: 0x80000000
Loading: ####

         1.8 MiB/s

done
Bytes transferred = 50145 (c3e1 hex)
Kernel image @ 0x82000000 [ 0x000000 - 0x428a60 ] ## Flattened Device Tree blob at 80000000
Booting using the fdt blob at 0x80000000 Loading Device Tree to 9ff05000, end 9ff143e0 ... OK

Starting kernel ...

Using the exact same boot sequence worked for 3.10 and 3.14.

Quoted 4 lines

Quoted 4 lines
Regards,
Tony

Tony Lindgren

2014-07-21 07:10 UTC #7 lore raw

In reply to Michael Welling

Quoted 8 lines · Michael Welling

Quoted 5 lines · Tony Lindgren
Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly.
I downloaded the version from the test results and it did boot.

OK that's good to hear.

Quoted 1 line

These are combining the uImage and dtb. How do you accomplish this?

You need to make sure you have the appended DTB support enabled like we do in omap2plus_defconfig:

CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y

Then just cat zImage board.dtb > /tmp/zImage-dtba and run mkimage to convert it to a uImage:

$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
	-n "Linux" -d /tmp/zImage-dtba /tmp/uImage

Regards,

Tony

Tony Lindgren

2014-07-21 07:18 UTC #4 lore raw

In reply to Michael Welling

Quoted 9 lines · Michael Welling

Quoted 5 lines · Michael Welling
Quoted 3 lines · Tony Lindgren
Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline?
I will try this.
Adding the earlyprintk did not work. It still hangs without any messages.

If you have it enabled for the wrong UART it will always hang.. Maybe check you have the right port?

Quoted 6 lines

Quoted 4 lines
Quoted 4 lines
Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly.
How do you determine which you are booting?

Looking at the dmesg, the earliest point you'll see it is from "Machine model: " line, that's most likely different than for legacy booting :)

And later on you'll see some DT only drivers get initialized properly like pinctrl-single:

pinctrl-single 48002030.pinmux: 284 pins at pa fa002030 size 568
...

Regards,

Tony

Tony Lindgren

2014-07-21 07:20 UTC #6 lore raw

In reply to Michael Welling

Quoted 86 lines · Michael Welling

Quoted 40 lines · Michael Welling
Quoted 22 lines · Tony Lindgren
Quoted 11 lines · mwelling
I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device.
First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported.
Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support.
Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM.
For device tree based booting on omap3 I would user v.16-rc4 or later. There have been multiple issues fixed over past year and PM is working finally at least for 36xx/37xx. And we do have the DSS panels finally working too.
Quoted 3 lines
I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release?
Quoted 5 lines
No reason that I can think of. AFAIK 3517 has been booting in the test farms just fine?
Can you please enable debug_ll + earlyprintk and pass also earlyprintk in the kernel cmdline?
I will try this.
Quoted 11 lines
Quoted 2 lines
Are there any versions where the LCD output works?
Starting with v3.16-rc1 you should get the LCD working for panel-dpi based devices. Most of them actually are actually ls037v3dw01, so see omap3-panel-sharp-ls037v7dw01.dtsi and omap3-evm-common.dtsi variants if you have similar setup.
Quoted 3 lines
Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Any suggestions would be greatly appreciated.
Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly.
I downloaded the version from the test results and it did boot. These are combining the uImage and dtb. How do you accomplish this?
It should be noted that when you try to boot the seperate zImage and dtb from the test build it fails. This replicates my issue.
Here are the two binaries that I used:
http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/build_z/omap2plus_defconfig/zImage
http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/dtbs/am3517-evm.dtb
Here is the boot attempt:
U-Boot> dhcp;set serverip 10.0.2.168;tftp 0x82000000 zImage; tftp 0x80000000 am3517-evm.dtb;bootz 0x82000000 - 0x80000000 BOOTP broadcast 1
DHCP client bound to address 10.0.3.33
Using DaVinci-EMAC device
TFTP from server 10.0.2.168; our IP address is 10.0.3.33
Filename 'zImage'.
Load address: 0x82000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ######################################
         2 MiB/s
done
Bytes transferred = 4360800 (428a60 hex)
Using DaVinci-EMAC device
TFTP from server 10.0.2.168; our IP address is 10.0.3.33 Filename 'am3517-evm.dtb'.
Load address: 0x80000000
Loading: ####
         1.8 MiB/s
done
Bytes transferred = 50145 (c3e1 hex)
Kernel image @ 0x82000000 [ 0x000000 - 0x428a60 ] ## Flattened Device Tree blob at 80000000
Booting using the fdt blob at 0x80000000 Loading Device Tree to 9ff05000, end 9ff143e0 ... OK

Quoted 3 lines

Starting kernel ...
Using the exact same boot sequence worked for 3.10 and 3.14.

Hmm maybe we still have some relocation issues left and the kernel or the .dtb size has changed enough to cause trouble. Can you try with .dtb at a different address?

Regards,

Tony

Michael Welling

author

2014-07-21 16:38 UTC #8 lore raw

In reply to Tony Lindgren

Quoted 21 lines · Tony Lindgren

Quoted 8 lines · Michael Welling
Quoted 5 lines · Tony Lindgren
Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly.
I downloaded the version from the test results and it did boot.
OK that's good to hear.
Quoted 1 line
These are combining the uImage and dtb. How do you accomplish this?
You need to make sure you have the appended DTB support enabled like we do in omap2plus_defconfig:
CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y

Quoted 6 lines

Then just cat zImage board.dtb > /tmp/zImage-dtba and run mkimage to convert it to a uImage:
$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
	-n "Linux" -d /tmp/zImage-dtba /tmp/uImage

I actually discovered this and got LCD video working. Now USB host is not working. The only thing that registers is the OHCI/EHCI hosts.

root@som3517:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Not sure what the problem is. The USB devices that are plugged in are powered but never detected.

Any hints?

Quoted 3 lines

Regards,
Tony

Michael Welling

author

2014-07-22 00:15 UTC #9 lore raw

Quoted 32 lines · Michael Welling

Quoted 21 lines · Tony Lindgren
Quoted 8 lines · Michael Welling
Quoted 5 lines · Tony Lindgren
Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly.
I downloaded the version from the test results and it did boot.
OK that's good to hear.
Quoted 1 line
These are combining the uImage and dtb. How do you accomplish this?
You need to make sure you have the appended DTB support enabled like we do in omap2plus_defconfig:
CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
Quoted 6 lines
Then just cat zImage board.dtb > /tmp/zImage-dtba and run mkimage to convert it to a uImage:
$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
      -n "Linux" -d /tmp/zImage-dtba /tmp/uImage
I actually discovered this and got LCD video working. Now USB host is not working. The only thing that registers is the OHCI/EHCI hosts.

Quoted 8 lines

root@som3517:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Not sure what the problem is. The USB devices that are plugged in are powered but never detected.
Any hints?

So I got the USB host to work on boot with additional entries in the devicetree. Documentation/devicetree/bindings/omap-usb-host.txt

Though the devices work if plugged in at boot, any time a device is hotplugged then
the device is not detected. It is powered very briefly and then off without any kernel messages.

So hints from this point would be good.

Quoted 4 lines

Quoted 4 lines
Regards,
Tony

Tony Lindgren

2014-07-22 06:22 UTC #10 lore raw

Quoted 45 lines · Michael Welling

Quoted 32 lines · Michael Welling
Quoted 21 lines · Tony Lindgren
Quoted 8 lines · Michael Welling
Quoted 5 lines · Tony Lindgren
Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly.
I downloaded the version from the test results and it did boot.
OK that's good to hear.
Quoted 1 line
These are combining the uImage and dtb. How do you accomplish this?
You need to make sure you have the appended DTB support enabled like we do in omap2plus_defconfig:
CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
Quoted 6 lines
Then just cat zImage board.dtb > /tmp/zImage-dtba and run mkimage to convert it to a uImage:
$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
      -n "Linux" -d /tmp/zImage-dtba /tmp/uImage
I actually discovered this and got LCD video working. Now USB host is not working. The only thing that registers is the OHCI/EHCI hosts.
Quoted 8 lines
root@som3517:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Not sure what the problem is. The USB devices that are plugged in are powered but never detected.
Any hints?
So I got the USB host to work on boot with additional entries in the devicetree. Documentation/devicetree/bindings/omap-usb-host.txt

Quoted 6 lines

Though the devices work if plugged in at boot, any time a device is hotplugged then
the device is not detected. It is powered very briefly and then off without any kernel messages.
So hints from this point would be good.

Sorry no idea on that, maybe send a separate email about that with the USB and PHY people in Cc.

Regards,

Tony