LinuxLists.cc - Re: v3.19-rc1 regression(?) on N900

2014-12-25 08:32:47

Subject: Re: v3.19-rc1 regression(?) on N900

On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> based on automated testing with u-boot as a chained
> bootloader..
>
> v3.18: boots fine:
> https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu
> s_defconfig/n900.txt
>
> v3.19-rc1: hung
> https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> 2plus_defconfig/n900.txt
>
> in the interim, my farm had a bit of breakdown around the time
> of n900 breakdown..
>
> as per my last functional linux-next logs:
> https://github.com/nmenon/kernel-test-logs/blob/next-20141204/
> omap2plus_defconfig/n900.txt -> hung.
> https://github.com/nmenon/kernel-test-logs/blob/next-20141112/
> omap2plus_defconfig/n900.txt -> working.
>
> DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not
> yield information either
>
> Note: I am using the combined uImage+dtb image.[2]
>
> I think this might just be my setup..(i use chained loader ->
> NOLO->u-boot->serial download->kernel) but anyways.. Since
> Pali thought others might be interested in sharing
> experience...
>
> [1] http://slexy.org/raw/s2osxhhwbR
> [2]
> https://github.com/nmenon/linux-2.6-playground/commit/177f5f71
> b3f21ea484ee4b09a2e0c015de522417

CCing other people.

I see same problem in qemu with 3.19-rc1 kernel when doing DT
boot. In qemu I'm using direct booting from OneNAND (X-Loader -->
NOLO --> kernel) without U-Boot. After NOLO load & boot kernel I
do not see any other output from serial console. Also on qemu
screen there is no new output (just NOKIA logo from bootloader).

I do not have this problem when doing legacy/board code boot with
3.19-rc1 kernel, so this problem is related to DT.

Kernel 3.18-rc1 worked fine for both DT and legacy boot.

Can somebody look what broke DT booting?

--
Pali Rohár
[email protected]

Attachments:

signature.asc (198.00 B)
This is a digitally signed message part.

2014-12-25 09:11:28

by Pavel Machek

[permalink] [raw]

Subject: Re: v3.19-rc1 regression(?) on N900

2014-12-25 10:48:07

by Pavel Machek

[permalink] [raw]

Subject: Re: v3.19-rc1 regression(?) on N900

On Thu 2014-12-25 09:32:40, Pali Roh?r wrote:
> On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> > based on automated testing with u-boot as a chained
> > bootloader..
> >
> > v3.18: boots fine:
> > https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu
> > s_defconfig/n900.txt
> >
> > v3.19-rc1: hung
> > https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> > 2plus_defconfig/n900.txt
> >
> > in the interim, my farm had a bit of breakdown around the time
> > of n900 breakdown..
> >
> > as per my last functional linux-next logs:
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141204/
> > omap2plus_defconfig/n900.txt -> hung.
> > https://github.com/nmenon/kernel-test-logs/blob/next-20141112/
> > omap2plus_defconfig/n900.txt -> working.
> >
> > DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not
> > yield information either
> >
> > Note: I am using the combined uImage+dtb image.[2]
> >
> > I think this might just be my setup..(i use chained loader ->
> > NOLO->u-boot->serial download->kernel) but anyways.. Since
> > Pali thought others might be interested in sharing
> > experience...
> >
> > [1] http://slexy.org/raw/s2osxhhwbR
> > [2]
> > https://github.com/nmenon/linux-2.6-playground/commit/177f5f71
> > b3f21ea484ee4b09a2e0c015de522417
>
> CCing other people.
>
> I see same problem in qemu with 3.19-rc1 kernel when doing DT
> boot. In qemu I'm using direct booting from OneNAND (X-Loader -->
> NOLO --> kernel) without U-Boot. After NOLO load & boot kernel I
> do not see any other output from serial console. Also on qemu
> screen there is no new output (just NOKIA logo from bootloader).
>
> I do not have this problem when doing legacy/board code boot with
> 3.19-rc1 kernel, so this problem is related to DT.
>
> Kernel 3.18-rc1 worked fine for both DT and legacy boot.
>
> Can somebody look what broke DT booting?

You should be able to apply this to get it back to boot.

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 53f3ca0..7c17d084 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -13,9 +13,16 @@
#include <dt-bindings/input/input.h>

/ {
- model = "Nokia N900";
+ model = "Nokia RX-51 board";
compatible = "nokia,omap3-n900", "ti,omap3430", "ti,omap3";

+ aliases {
+ i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ };
+
cpus {
cpu@0 {
cpu0-supply = <&vcc>;
@@ -26,7 +33,7 @@
compatible = "gpio-leds";
heartbeat {
label = "debug::sleep";
- gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* gpio162 */
+ gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* 162 */
linux,default-trigger = "default-on";
pinctrl-names = "default";
pinctrl-0 = <&debug_leds>;
@@ -140,14 +147,6 @@
>;
};

- ethernet_pins: pinmux_ethernet_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x20b4, PIN_INPUT_PULLDOWN | MUX_MODE4) /* gpmc_ncs3.gpio_54 */
- OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE4) /* dss_data16.gpio_86 */
- OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4) /* uart3_rts_sd.gpio_164 */
- >;
- };
-
gpmc_pins: pinmux_gpmc_pins {
pinctrl-single,pins = <

@@ -307,7 +306,7 @@
regulator-name = "V28";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
- regulator-always-on; /* due battery cover sensor */
+ regulator-always-on; /* due to battery cover sensor */
};

&vaux2 {
@@ -365,7 +364,6 @@
regulator-name = "VIO";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
-
};

&vintana1 {
@@ -504,30 +502,6 @@
clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */
enable-gpio = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* 41 */

- chan0 {
- chan-name = "lp5523:kb1";
- led-cur = /bits/ 8 <50>;
- max-cur = /bits/ 8 <100>;
- };
-
- chan1 {
- chan-name = "lp5523:kb2";
- led-cur = /bits/ 8 <50>;
- max-cur = /bits/ 8 <100>;
- };
-
- chan2 {
- chan-name = "lp5523:kb3";
- led-cur = /bits/ 8 <50>;
- max-cur = /bits/ 8 <100>;
- };
-
- chan3 {
- chan-name = "lp5523:kb4";
- led-cur = /bits/ 8 <50>;
- max-cur = /bits/ 8 <100>;
- };
-
chan4 {
chan-name = "lp5523:b";
led-cur = /bits/ 8 <50>;
@@ -545,18 +519,6 @@
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
};
-
- chan7 {
- chan-name = "lp5523:kb5";
- led-cur = /bits/ 8 <50>;
- max-cur = /bits/ 8 <100>;
- };
-
- chan8 {
- chan-name = "lp5523:kb6";
- led-cur = /bits/ 8 <50>;
- max-cur = /bits/ 8 <100>;
- };
};

bq27200: bq27200@55 {
@@ -564,6 +526,7 @@
reg = <0x55>;
};

+ /* Stereo headphone amplifier */
tpa6130a2: tpa6130a2@60 {
compatible = "ti,tpa6130a2";
reg = <0x60>;
@@ -596,6 +559,22 @@

ti,usb-charger-detection = <&isp1704>;
};
+
+ adp1653: led-controller@30 {
+ compatible = "adi,adp1653";
+ reg = <0x30>;
+ gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+ flash {
+ flash-timeout-microsec = <500000>;
+ flash-max-microamp = <320000>;
+ max-microamp = <50000>;
+ };
+
+ indicator {
+ max-microamp = <17500>;
+ };
+ };
};

&i2c3 {
@@ -603,6 +582,18 @@
pinctrl-0 = <&i2c3_pins>;

clock-frequency = <400000>;
+
+ /* bus 3, same as ad5820, et8ek8 */
+ /* bus 2, adp1653, smiapp */
+ ad5820: ad5820@c {
+ compatible = "adi,ad5820";
+ reg = <0x0c>;
+ };
+
+ et8ek8: et8ek8@3e {
+ compatible = "et,et8ek8";
+ reg = <0x3e>;
+ };
};

&mmc1 {
@@ -699,43 +690,6 @@
reg = <0x004c0000 0x0fb40000>;
};
};
-
- ethernet@gpmc {
- compatible = "smsc,lan91c94";
-
- status = "disabled";
-
- interrupt-parent = <&gpio2>;
- interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; /* gpio54 */
- reg = <1 0x300 0xf>; /* 16 byte IO range at offset 0x300 */
- bank-width = <2>;
- pinctrl-names = "default";
- pinctrl-0 = <&ethernet_pins>;
- power-gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>; /* gpio86 */
- reset-gpios = <&gpio6 4 GPIO_ACTIVE_HIGH>; /* gpio164 */
- gpmc,device-width = <2>;
- gpmc,sync-clk-ps = <0>;
- gpmc,cs-on-ns = <0>;
- gpmc,cs-rd-off-ns = <48>;
- gpmc,cs-wr-off-ns = <24>;
- gpmc,adv-on-ns = <0>;
- gpmc,adv-rd-off-ns = <0>;
- gpmc,adv-wr-off-ns = <0>;
- gpmc,we-on-ns = <12>;
- gpmc,we-off-ns = <18>;
- gpmc,oe-on-ns = <12>;
- gpmc,oe-off-ns = <48>;
- gpmc,page-burst-access-ns = <0>;
- gpmc,access-ns = <42>;
- gpmc,rd-cycle-ns = <180>;
- gpmc,wr-cycle-ns = <180>;
- gpmc,bus-turnaround-ns = <0>;
- gpmc,cycle2cycle-delay-ns = <0>;
- gpmc,wait-monitoring-ns = <0>;
- gpmc,clk-activation-ns = <0>;
- gpmc,wr-access-ns = <0>;
- gpmc,wr-data-mux-bus-ns = <12>;
- };
};

&mcspi1 {
@@ -823,9 +777,21 @@
};

&uart2 {
+ compatible = "brcm,uart,bcm2048";
interrupts-extended = <&intc 73 &omap3_pmx_core OMAP3_UART2_RX>;
pinctrl-names = "default";
pinctrl-0 = <&uart2_pins>;
+
+ clocks = <&uart2_fck>, <&uart2_ick>;
+ clock-names = "fck", "ick";
+
+ device {
+ compatible = "brcm,bcm2048";
+ reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* 91 */
+ host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* 101 */
+ bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* 37 */
+ bt-sysclk = <2>;
+ };
};

&uart3 {

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2014-12-25 22:21:35

by Aaro Koskinen

[permalink] [raw]

Subject: Re: v3.19-rc1 regression(?) on N900

Hi,

On Thu, Dec 25, 2014 at 10:11:21AM +0100, Pavel Machek wrote:
> On Thu 2014-12-25 09:32:40, Pali Roh?r wrote:
> > On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
> > > based on automated testing with u-boot as a chained
> > > bootloader..
> > >
> > > v3.19-rc1: hung
> > > https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
> > > 2plus_defconfig/n900.txt
>
> Early hang, independend on config. That's "dtb too big". Delete
> something, and it should work again.

For me, DT boot works fine with 3.19-rc1 as is...

> Plus you'll note video regression.

...however, I can confirm that framebuffer is broken:

[ 8.230743] omapfb omapfb: no displays
[ 8.255584] omapfb omapfb: failed to setup omapfb
[ 8.260620] platform omapfb: Driver omapfb requests probe deferral
[ 8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
'/ocp/spi@48098000/acx565akm@2[0]' - status (0)
[ 8.284271] acx565akm spi1.2: failed to find video source
[ 8.290069] spi spi1.2: Driver acx565akm requests probe deferral

I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
by matching reg-id). When I revert that, also FB works with 3.19-rc1.

A.

2014-12-29 08:05:40

by Tomi Valkeinen

[permalink] [raw]

Subject: Re: v3.19-rc1 regression(?) on N900

Hi,

On 26/12/14 00:21, Aaro Koskinen wrote:

> ...however, I can confirm that framebuffer is broken:
>
> [ 8.230743] omapfb omapfb: no displays
> [ 8.255584] omapfb omapfb: failed to setup omapfb
> [ 8.260620] platform omapfb: Driver omapfb requests probe deferral
> [ 8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
> '/ocp/spi@48098000/acx565akm@2[0]' - status (0)
> [ 8.284271] acx565akm spi1.2: failed to find video source
> [ 8.290069] spi spi1.2: Driver acx565akm requests probe deferral
>
> I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
> by matching reg-id). When I revert that, also FB works with 3.19-rc1.

I've attached a patch for this. Only hack-tested on OMAP3 beagle, so
please report if it works.

Tomi

Attachments:

0001-OMAPDSS-SDI-fix-output-port_num.patch (1.32 kB)
signature.asc (819.00 B)
OpenPGP digital signature Download all attachments

2014-12-29 18:03:05

by Aaro Koskinen

[permalink] [raw]

Subject: Re: v3.19-rc1 regression(?) on N900

Hi,

On Mon, Dec 29, 2014 at 10:04:46AM +0200, Tomi Valkeinen wrote:
> On 26/12/14 00:21, Aaro Koskinen wrote:
>
> > ...however, I can confirm that framebuffer is broken:
> >
> > [ 8.230743] omapfb omapfb: no displays
> > [ 8.255584] omapfb omapfb: failed to setup omapfb
> > [ 8.260620] platform omapfb: Driver omapfb requests probe deferral
> > [ 8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
> > '/ocp/spi@48098000/acx565akm@2[0]' - status (0)
> > [ 8.284271] acx565akm spi1.2: failed to find video source
> > [ 8.290069] spi spi1.2: Driver acx565akm requests probe deferral
> >
> > I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
> > by matching reg-id). When I revert that, also FB works with 3.19-rc1.
>
> I've attached a patch for this. Only hack-tested on OMAP3 beagle, so
> please report if it works.

That works, thanks.

A.

2014-12-30 17:39:49

by Pavel Machek

[permalink] [raw]

Subject: Re: v3.19-rc1 regression(?) on N900

On Mon 2014-12-29 10:04:46, Tomi Valkeinen wrote:
> Hi,
>
> On 26/12/14 00:21, Aaro Koskinen wrote:
>
> > ...however, I can confirm that framebuffer is broken:
> >
> > [ 8.230743] omapfb omapfb: no displays
> > [ 8.255584] omapfb omapfb: failed to setup omapfb
> > [ 8.260620] platform omapfb: Driver omapfb requests probe deferral
> > [ 8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node
> > '/ocp/spi@48098000/acx565akm@2[0]' - status (0)
> > [ 8.284271] acx565akm spi1.2: failed to find video source
> > [ 8.290069] spi spi1.2: Driver acx565akm requests probe deferral
> >
> > I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint
> > by matching reg-id). When I revert that, also FB works with 3.19-rc1.
>
> I've attached a patch for this. Only hack-tested on OMAP3 beagle, so
> please report if it works.

This fixes the issue for me.

Tested-by: Pavel Machek <[email protected]>

> From fe3e8dde8eae80541a3f3b39c421428ebd02955f Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen <[email protected]>
> Date: Mon, 29 Dec 2014 09:57:11 +0200
> Subject: [PATCH] OMAPDSS: SDI: fix output port_num
>
> After the commit ef691ff48bc8 (OMAPDSS: DT: Get source endpoint by
> matching reg-id) we look for the SDI output using the port number.
> However, the SDI driver doesn't set the port number, which causes the
> SDI display to not initialize.
>
> Fix this by setting the SDI port number to 1. We use a hardcoded value,
> as SDI was used only on OMAP3 and it's always port number 1 there.
>
> Reported-by: Aaro Koskinen <[email protected]>
> Reported-by: Pavel Machek <[email protected]>
> Signed-off-by: Tomi Valkeinen <[email protected]>
> ---
> drivers/video/fbdev/omap2/dss/sdi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/fbdev/omap2/dss/sdi.c b/drivers/video/fbdev/omap2/dss/sdi.c
> index d51a983075bc..5c2ccab5a958 100644
> --- a/drivers/video/fbdev/omap2/dss/sdi.c
> +++ b/drivers/video/fbdev/omap2/dss/sdi.c
> @@ -342,6 +342,8 @@ static void sdi_init_output(struct platform_device *pdev)
> out->output_type = OMAP_DISPLAY_TYPE_SDI;
> out->name = "sdi.0";
> out->dispc_channel = OMAP_DSS_CHANNEL_LCD;
> + /* We have SDI only on OMAP3, where it's on port 1 */
> + out->port_num = 1;
> out->ops.sdi = &sdi_ops;
> out->owner = THIS_MODULE;
>

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html