On 06/19/12 09:47, the mail apparently from Scott Bambrough included:

• Andy

Hi -

Sorry for the delayed reply.

We only test the kernel configured with omap4plus defconfig (ie, make ARCH=arm omap4plus_defconfig to create .config), which works on omap4430, 4460 Panda and omap5432 dev boards.

We don't have access to any Blaze devices, so we neither target compatibility with that nor could test against it.

Having said that, you sure do pretty well from your log... edid is coming, both Alsa cards are probed.

We did work on HDMI hpd since your mail, removing the enable / disable imbalance that provokes the gpio error. It might be worth trying again with tilt-3.4 branch we created since then. The divide by zero just seems to be coming in the HDMI error path.

-Andy

On 12-06-15 12:44 AM, Ramakrishnan Muthukrishnan wrote:

...

Hi,

I am trying to boot the tilt-tracking branch of the TI OMAP kernel git repository. The silicon is OMAP4430 ES2.1 on TI Blaze platform. I see a kernel crash while booting. The logs also show that the HDMI GPIOs requests are not successful.

What I am looking for is a fairly recent kernel on which I can base the rest of the userspace (media) application on. Any help on which branch to look for, will be greatly appreciated.

Thanks Ramakrishnan

[ 4.836944] Console: switching to colour frame buffer device 240x67 [ 4.892089] sdp4430_panel_enable_hdmi: Cannot request HDMI GPIOs [ 4.898437] omapdss HDMI error: failed to enable GPIO's [ 4.903991] omapdss error: failed to power on [ 4.908599] omapfb omapfb: Failed to enable display 'hdmi' [ 4.914398] omapfb omapfb: failed to initialize default display [ 4.921325] omapfb omapfb: failed to setup omapfb [ 4.926330] omapfb: probe of omapfb failed with error -16 [ 4.932586] VANA: incomplete constraints, leaving on [ 4.938934] VDAC: incomplete constraints, leaving on [ 4.945983] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:03 UTC (946684803) [ 4.954620] ALSA device list: [ 4.957733] #0: SDP4430 [ 4.960540] #1: OMAPHDMI [ 4.997589] Division by zero in kernel. [ 4.997619] Backtrace: [ 4.997650] [<c0012d4c>] (dump_backtrace+0x0/0x118) from [<c04ec94c>] (dump_stack+0x20/0x24) [ 4.997650] r6:00000000 r5:f0800000 r4:ee21dd80 r3:00000000 [ 4.997680] [<c04ec92c>] (dump_stack+0x0/0x24) from [<c0012ea8>] (__div0+0x20/0x28) [ 4.997711] [<c0012e88>] (__div0+0x0/0x28) from [<c0259b14>] (Ldiv0+0x8/0x10) [ 4.997772] [<c0287348>] (cfb_imageblit+0x0/0x46c) from [<c0280828>] (soft_cursor+0x1b8/0x1c4) [ 4.997772] [<c0280670>] (soft_cursor+0x0/0x1c4) from [<c02801b0>] (bit_cursor+0x43c/0x44c) [ 4.997802] [<c027fd74>] (bit_cursor+0x0/0x44c) from [<c027a920>] (fb_flashcursor+0x108/0x124) [ 4.997802] [<c027a818>] (fb_flashcursor+0x0/0x124) from [<c00562e4>] (process_one_work+0x274/0x420) [ 4.997833] [<c0056070>] (process_one_work+0x0/0x420) from [<c005681c>] (worker_thread+0x1bc/0x2bc) [ 4.997863] [<c0056660>] (worker_thread+0x0/0x2bc) from [<c005c93c>] (kthread+0x98/0xa4) [ 4.997863] [<c005c8a4>] (kthread+0x0/0xa4) from [<c0041300>] (do_exit+0x0/0x790) [ 4.997894] r7:00000013 r6:c0041300 r5:c005c8a4 r4:ee093ed8 [ 5.192901] Division by zero in kernel. [ 5.192901] Backtrace:

---

linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel

On 06/25/12 14:04, the mail apparently from Ramakrishnan Muthukrishnan included:

Hi Andy,

On Saturday 23 June 2012 07:31 AM, Andy Green wrote:

...

We only test the kernel configured with omap4plus defconfig (ie, make ARCH=arm omap4plus_defconfig to create .config), which works on omap4430, 4460 Panda and omap5432 dev boards.

We don't have access to any Blaze devices, so we neither target compatibility with that nor could test against it.

Having said that, you sure do pretty well from your log... edid is coming, both Alsa cards are probed.

We did work on HDMI hpd since your mail, removing the enable / disable imbalance that provokes the gpio error. It might be worth trying again with tilt-3.4 branch we created since then. The divide by zero just seems to be coming in the HDMI error path.

I tried it again with the tilt-3.4 branch. Now, the kernel won't boot at all. It stops at "Starting kernel" and just stays there. I tried it on both 4430 and 4460 daughter cards on the Blaze. I also tried it on a Pandaboard with 4430 and it is stuck at the "Starting kernel ..." print on the serial port.

Well several TIers and others in the LT have been using that fine on Panda.

It might be worth making sure you have earlycon=ttyO2,115200,n8 earlyprintk=1 in you kernel commandline.

Also, we test it with Device Tree boot, where did you bootloader come from / what's your kernel commandline?

-Andy

On 06/27/12 14:56, the mail apparently from Ramakrishnan Muthukrishnan included:

On Monday 25 June 2012 12:44 PM, Andy Green wrote:

...

Well several TIers and others in the LT have been using that fine on Panda.

It might be worth making sure you have earlycon=ttyO2,115200,n8 earlyprintk=1 in you kernel commandline.

Also, we test it with Device Tree boot, where did you bootloader come from / what's your kernel commandline?

Hi Andy,

I am sorry, the problem was at my end. I was using a very old x-loader and u-boot. I switched to the u-boot-linaro-stable git and it seem to boot just fine now.

Great, glad to hear you're up.

-Andy

On 06/27/12 21:57, the mail apparently from Christian Robottom Reis included:

On Wed, Jun 27, 2012 at 12:26:33PM +0530, Ramakrishnan Muthukrishnan wrote:

...

On Monday 25 June 2012 12:44 PM, Andy Green wrote:

...

Well several TIers and others in the LT have been using that fine on Panda.

It might be worth making sure you have earlycon=ttyO2,115200,n8 earlyprintk=1 in you kernel commandline.

Also, we test it with Device Tree boot, where did you bootloader come from / what's your kernel commandline?

Hi Andy,

I am sorry, the problem was at my end. I was using a very old x-loader and u-boot. I switched to the u-boot-linaro-stable git and it seem to boot just fine now.

Is it documented clearly (perhaps in the tilt git repo page) that booting the kernel in DT mode requires an updated u-boot?

No, but it's not exactly new: U-Boot has been workable with DT boot on our kernels for like a year. The issue here was Ramakrishnan's U-Boot was ancient or built without DT support configured.

It might make sense to list the circumstances under which we test and what should be expected... the original problem in this thread is that the user has a blaze and we don't, that's a piece of information that could save trouble.

-Andy