> -----Original Message----- > From: Gilles Chanteperdrix [mailto:[email protected]] > Sent: Tuesday, April 23, 2013 11:34 AM > To: George Pontis > Cc: [email protected] > Subject: Re: [Xenomai] for-core-3.8 on ARM ( i.MX53 ) > > On 04/23/2013 06:56 PM, George Pontis wrote: > > >> -----Original Message----- > >> From: Gilles Chanteperdrix [mailto:[email protected]] > >> Sent: Tuesday, April 23, 2013 12:51 AM > >> To: George Pontis > >> Cc: [email protected] > >> Subject: Re: [Xenomai] for-core-3.8 on ARM ( i.MX53 ) > >> > >> On 04/23/2013 04:35 AM, George Pontis wrote: > >> > >>> I took a crack at building a 3.8 kernel with Xenomai 2.6.2.1 for > ARM, > >> based > >>> on the work in progress toward that ipipe patch. > >> > >> > >> Xenomai 2.6.2.1 will not work, please upgrade to Xenomai 2.6 current > >> git > >> and tell us if you see the same issue. > >> > >> -- > >> > Gilles. > > > > I got the current Xenomai and rebuilt with that. The process went > smoothly and did not > > require any patching or manual intervention, but it still hangs at > the same point. Is > > it expected that the 2.6 current tree is identifying itself as > 2.6.2.1 ? > > > Yes it is expected, incrementing the version number is the last thing > we > do before a release. Now, about the hang, several questions: > - does the very same kernel version without CONFIG_IPIPE and > CONFIG_XENOMAI boot normally?
With these undefined and the kernel rebuilt, it does boot normally. I noticed that there is a 1-2 second delay after that same line for eth0, but then it continues to boot to a login prompt. I tried just CONFIG_IPIPE=y without Xenomai, and that kernel hangs at the same place. > - are the error messages: > mmc0: no vqmmc regulator found > mmc0: no vmmc regulator found > mmc1: no vqmmc regulator found > mmc1: no vmmc regulator found > sgtl5000 1-000a: clock-frequency missing or invalid > imx-sgtl5000: probe of sound.8 failed with error -22 > Expected? These messages have been there all along, even when the kernel boots normally. The sgtl5000 sound chip does not work, but we don't care about that now. > - does not the message: > Console: switching to colour frame buffer device 80x30 > Tell us that in fact the kernel logs are continuing on the framebuffer? Even when the kernel boots it says this, but the boot messages continue to display on the serial console. There is no output on the framebuffer except Tux, until one logs in and runs an application. > - is the timer running correctly? > - is the clocksource incrementing correctly? I don't know how to check either of these. > > Regards. > > -- > Gilles. Here in the Silicon Valley area of California we are having the embedded system conference this week. I visited some vendors that had JTAG hardware + software packages that could step through kernel code. ARM had a nice one but it included trace and was expensive. Arium had a more affordable solution. I could get one on these and use it to get closer to the source of the problem, but it would take a while. Any thoughts on the usefulness of those tools ? George _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
