[Xenomai-help] "How to Adapt ARM I-pipe patch to S3C6410" - still not solved

[Xenomai-help] "How to Adapt ARM I-pipe patch to S3C6410" - still not solved

[Alex Nikitenko]

[-- Attachment #1: Type: text/plain, Size: 4499 bytes --]

Hi all.
I'm facing the same problem that has been already discussed some time ago.
Here is the subj.

 On 12/19/2011 02:38 AM, ?? wrote:
>> I want to get the  ARM I-pipe patch  Adapt to S3C6410,but when I start up
>> the board,it stopped at the head.s,with no warning and notice.I find It
>> even not go to the start_kernel() function.what can I do??
>>

>What kernel version? What I-pipe version? What kernel configuration?
>Have you tried the howto?

>http://www.xenomai.org/index.php/I-pipe:ArmPorting

On 12/22/2011 03:37 AM, ?? wrote:
> The kernel version is 2.6.37.6 I-pipe patch is 2.6.0-rc4,

2.6.0-rc4 is a xenomai version, not an I-pipe version. And xenomai
2.6.0-rc4 is obsolete and superseeded by xenomai 2.6.0.

I tried the
> howto ,but I couldn't find the variables and functions in irq.c ,but
> some of  the  functions and variables in time.c were here because of
> the patch.  I want to know whether all the function need to be add by
> myself ? because some of it exist when I patch the ipipe-patch.
> And the tip "Implementing a high-resolution counter.",I modified the
> CONFIG file and use the second way "Decrementer  See s3c24xx
> implementation."
> The complie work was finished with no error. Is there any patch t
> adpat  to the board?
> Thank you !

As indicated by the howto: "In the rest of this document we will call
these files time.c and irq.c, even though they may have another name for
your board. "

Anyway, irq demuxing is done differently with current versions of the
I-pipe, the howto is out of date. For each irq demux (the callbacks
registered with set_irq_chained_handler), the demux function should call
ipipe_handle_chained_irq instead of generic_handle_irq.

However, if the bug happens before start_kernel, the bug has probably
nothing to do with the modifications you made for the I-pipe. But are
you sure that the bug happens before start_kernel? Have you noted that
printk does not work as early as in start_kernel, you have to enable
early printk or use the printascii trick mentioned in the "tips and
tricks" section of the howto.

Please no private mails.

--
                                            Gilles.

On 12/24/2011 03:10 AM, ?? wrote:
> sorry for the mistake,my ipipe-patch is
> adeos-ipipe-2.6.37.6-arm-1.18-03   ,and where can I get the new
> "HowTo" as it maybe out of date.
> As I said,I add the printascii function in the begin of
> start_kernel(),but it didn't print out ,so I believe it didn't go to
> the start_kernel. I also add the printascii function to the
> arch/arm/kernel/head.S,I found when it run to "enable the mmu" it
> stopped. I believe the .config file works well before I patch the
> xenomai .I also believe the xenomai has nothing to do with the setup
> of hardware before the kernel startup.
>

There is no updated version of the howto. But the only wrong thing is
the part about multiplexed interrupts.

You should try printascii with a non-patched kernel to verify that
printascii works for the board you use.

As for using printascii around the place where the mmu is enabled, have
you read the following comment in the kernel sources:

/*
 * Enable the MMU.  This completely changes the structure of the visible
 * memory space.  You will not be able to trace execution through this.
 * If you have an enquiry about this, *please* check the linux-arm-kernel
 * mailing list archives BEFORE sending another post to the list.

Anyway, as early in the boot process the I-pipe patch does not change
anything, so, your problem does not come from the I-pipe patch. Have you
tried the exact same config you use with the patched kernel with an
unpatched kernel?

--
                                                                Gilles.

The problem is that I cannot enter start_kernel() function only with
CONFIG_IPIPE enabled.
If I disable this config everything boots just fine.

I used printascii at arch/arm/kernel/head.S to trace the execution. It goes
to start_kernel() and after this it hangs. But ONLY with CONFIG_IPIPE
enabled.
I also used printk("some string") at the very begining of start_kernel().
If CONFIG_IPIPE not set - string is printed out and kernel boots.
If CONFIG_IPIPE  - hang after calling start_kernel.
Printascii works well.
I used the howto but it seems to have nothing to deal with this problem.
IRQs and Timers are initialized later as I understood.
Kernel version - 2.6.36. Ipipe patch version -
adeos-ipipe-2.6.35.9-arm-1.18-
03.patch.

Any help would be appreciated.
Regards,
Alex

[-- Attachment #2: Type: text/html, Size: 5711 bytes --]

Re: [Xenomai-help] "How to Adapt ARM I-pipe patch to S3C6410" - still not solved

[Gilles Chanteperdrix]

On 01/31/2012 05:04 PM, Alex Nikitenko wrote:
> Hi all.
> I'm facing the same problem that has been already discussed some time ago.
> Here is the subj.

I am sorry, but I do not understand your question. If you want to reply
an old mail, use the "reply" button, and properly quote it, bottom
posting. Otherwise it is impossible to understand what you are talking
about.

Here you top-posting, and pasting without quoting a mail of answer to
someone who has issues on ARM. So, the least you can do is reply to each
of this answer, and tell us why they do not work for you, or are not
relevant, etc... Or if the mail is not relevant, simply do not quote it.

RFC 1855 may help.

-- 
					    Gilles.

Re: [Xenomai-help] "How to Adapt ARM I-pipe patch to S3C6410" - still not solved

[Gilles Chanteperdrix]

On 01/31/2012 05:49 PM, Alex Nikitenko wrote:
> Sorry for that mess.
> 
> I'm trying to adapt adeos-ipipe-2.6.35.9-arm-1.18-03.patch to a S3C6410
> (Tiny6410 board) with kernel ver. 2.6.36 in order to run xenomai on this
> board.
> 
> The problem is that the boot process hangs not entering the
> start_kernel() function.
> I used printascii at arch/arm/kernel/head.S to trace the execution. It
> hangs just before calling start_kernel(). But ONLY with CONFIG_IPIPE
> enabled.
> If I disable this config everything boots just fine.
> 
> I also used printk("some string") at the very begining of start_kernel().
> If CONFIG_IPIPE not set - string is printed out and kernel boots.
> If CONFIG_IPIPE  - hang after calling start_kernel.
> So, printascii works well on mz hardware.

If you are indeed using printk and not printascii this does not prove
that printascii works, and that you have successfully enabled the
earlyprintk mechanism.

When linux boots on arm, when the serial console is enabled, the
backlog, everything which has been printed before with printk, is
printed. If the kernel fails before enabling the console, nothing is
printed, but it does not mean that the kernel did not go farther than
your first printk.

The cure is to use printascii. I am not sure printascii works in head.S,
I believe it does, but you can:
- use printascii for some traces you would like to add (for instance in
ipipe_mach_acktimer to see if the timer is ticking)
- add a call to printascii in printk.c right after the call to
vscnprintf. If you do this, when the console is enabled, everything is
printed twice.
- enable CONFIG_EARLY_PRINTK in addition to CONFIG_DEBUG_LL, and pass
"earlyprintk" on the kernel command line. This will cause the printks
before console is enabled to use printascii, and then switch to the real
console.

You should make sure that printascii indeed works for your platform
without CONFIG_IPIPE before trying to use it with CONFIG_IPIPE, by
testing it separately from printk.

-- 
					    Gilles.