[Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

Howdy folks,

I am currently working on a project to get Xenomai up and running on an
AM3517 based board and have run into some difficulties.

First off, I am starting with a vendor-supplied kernel that was put into
use several months ago and on top of which patches have been applied to
get it working with a board designed by one of my coworkers. This kernel
works fine. It is a based on a TI 2.6.37-based kernel:

http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=adcd067326836777c049e3cb32a5b7d9d401fc31

Because of this I initially chose the following patch:

http://download.gna.org/adeos/patches/v2.6/arm/older/adeos-ipipe-2.6.37.6-arm-1.18-03.patch

because I thought this was as close as I would get.

When it comes time to apply the adeos i-pipe patch, we cannot simply
apply it over our existing kernel tree using the prepare-kernel.sh
script due to merge conflicts.

Because of this I checked out a commit from TI's kernel tree that I
thought would be compatible with the adeos i-pipe patch and it seems to
have applied cleanly. After this, I merged the version of the TI kernel
tree on which our product-specific changes were made; this resulted in
eight conflicts which I was able to resolve in such a way that the
resulting code compiles, but does not boot: When loading this kernel
from u-boot, the kernel seems to hang early in the startup sequence.

It occurred to me, however, that it really might be better to apply the
adeos i-pipe patch directly over the known-to-work commit so that when
searching for the regression I can have a better idea of where to start
looking based on a "git diff --name-only" command.

This would involved pulling the i-pipe patch in directly from:

http://git.xenomai.org/?p=ipipe-gch.git;a=tags

The tag that I have my eye on is ipip-2.6.37.6-arm-1.18-03 which I
believe would correspond with the .patch file listed above. In fact, I
have applied this patch and again resolved the merge conflicts, but run
into a problem in that the Makefile/Kconfig kernel configuration
variables do not seem to be included in that code. What seems to happen
instead in the prepare-kernel.sh script adds them when patching the
kernel. It seems like this script may do other important tasks as well.

I am hoping someone can advise me with regard to either how to proceed
without those variables or maybe offer advice for generally how to
proceed with this attempt to pull in the i-pipe patches for a
vendor-specific kernel branch.

Thanks in advance!

Wayne Warren

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/02/2012 11:08 PM, Wayne Warren wrote:

> Howdy folks,


Hi

(snip)
> The tag that I have my eye on is ipip-2.6.37.6-arm-1.18-03 which I

> believe would correspond with the .patch file listed above. In fact, I
> have applied this patch and again resolved the merge conflicts, but run
> into a problem in that the Makefile/Kconfig kernel configuration
> variables do not seem to be included in that code. What seems to happen
> instead in the prepare-kernel.sh script adds them when patching the
> kernel. It seems like this script may do other important tasks as well.
> 
> I am hoping someone can advise me with regard to either how to proceed
> without those variables or maybe offer advice for generally how to
> proceed with this attempt to pull in the i-pipe patches for a
> vendor-specific kernel branch.


You need to run prepare-kernel.sh with the I-pipe tree as well.
prepare-kernel.sh will simply skip the step where it tries to apply the
adeos patch. Actually, that is the way we maintain the Xenomai and the
I-pipe patch: we work with git and compile the prepared kernel.

To merge the I-pipe tree with a vendor tree, you can use git merge.


-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/02/2012 11:32 PM, Gilles Chanteperdrix wrote:

> On 10/02/2012 11:08 PM, Wayne Warren wrote:
> 
>> Howdy folks,
> 
> 
> Hi
> 
> (snip)
>> The tag that I have my eye on is ipip-2.6.37.6-arm-1.18-03 which I
> 
>> believe would correspond with the .patch file listed above. In fact, I
>> have applied this patch and again resolved the merge conflicts, but run
>> into a problem in that the Makefile/Kconfig kernel configuration
>> variables do not seem to be included in that code. What seems to happen
>> instead in the prepare-kernel.sh script adds them when patching the
>> kernel. It seems like this script may do other important tasks as well.
>>
>> I am hoping someone can advise me with regard to either how to proceed
>> without those variables or maybe offer advice for generally how to
>> proceed with this attempt to pull in the i-pipe patches for a
>> vendor-specific kernel branch.
> 
> 
> You need to run prepare-kernel.sh with the I-pipe tree as well.
> prepare-kernel.sh will simply skip the step where it tries to apply the
> adeos patch. Actually, that is the way we maintain the Xenomai and the
> I-pipe patch: we work with git and compile the prepared kernel.
> 
> To merge the I-pipe tree with a vendor tree, you can use git merge.


Also note that there is a guide for porting the I-pipe patch to a new board:
http://www.xenomai.org/index.php/I-pipe:ArmPorting

It is a bit outdated for 2.6.37, so, look at an architecture which works
(for instance omap3) to know what to do.

In your case, you should try the first entry in the "tips and tricks"
section.

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

Gilles,

Thanks for your help!

The ArmPorting guide is helpful, but unfortunately the first tip and
trick did not reveal any boot messages. I had to add a function
declaration for "printascii" to get the code to compile. I have
CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_LL, and CONFIG_EARLY_PRINTK enabled
and have passed the boot parameter "earlyprintk" when attempting to
boot. 

According to 

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

(which seems to be a newer version of the page you mentioned) I should
try to boot the kernel without CONFIG_IPIPE or CONFIG_XENOMAI enabled
and if it does not work it is likely to be a problem with the timer.

I have then used "git diff --name-only <known-working-ti-kernel-ref>
<ipipe-merged-ref>" to get a list of files and I have been looking
through their current versions alongside a diff of each given file while
reading to the instructions provided in both the old and the new
ArmPorting guides to see what might have changed in timer-related code
that would prevent the kernel from booting.

If you have any additional advice, I would greatly appreciate it. Also,
if I could get an account on the Xenomai wiki, there are some simple
changes I would make to the ArmPorting page to improve its readability a
little (for example, create indented paragraphs for the description of
the "struct ipipe_timer" members). I guess I don't really have anything
concrete or technical to add to it so if you don't want to add me, I
understand.

Thanks again for your generous help!

Wayne

On Tue, 2012-10-02 at 23:35 +0200, Gilles Chanteperdrix wrote:
> On 10/02/2012 11:32 PM, Gilles Chanteperdrix wrote:
> 
> > On 10/02/2012 11:08 PM, Wayne Warren wrote:
> > 
> >> Howdy folks,
> > 
> > 
> > Hi
> > 
> > (snip)
> >> The tag that I have my eye on is ipip-2.6.37.6-arm-1.18-03 which I
> > 
> >> believe would correspond with the .patch file listed above. In fact, I
> >> have applied this patch and again resolved the merge conflicts, but run
> >> into a problem in that the Makefile/Kconfig kernel configuration
> >> variables do not seem to be included in that code. What seems to happen
> >> instead in the prepare-kernel.sh script adds them when patching the
> >> kernel. It seems like this script may do other important tasks as well.
> >>
> >> I am hoping someone can advise me with regard to either how to proceed
> >> without those variables or maybe offer advice for generally how to
> >> proceed with this attempt to pull in the i-pipe patches for a
> >> vendor-specific kernel branch.
> > 
> > 
> > You need to run prepare-kernel.sh with the I-pipe tree as well.
> > prepare-kernel.sh will simply skip the step where it tries to apply the
> > adeos patch. Actually, that is the way we maintain the Xenomai and the
> > I-pipe patch: we work with git and compile the prepared kernel.
> > 
> > To merge the I-pipe tree with a vendor tree, you can use git merge.
> 
> 
> Also note that there is a guide for porting the I-pipe patch to a new board:
> http://www.xenomai.org/index.php/I-pipe:ArmPorting
> 
> It is a bit outdated for 2.6.37, so, look at an architecture which works
> (for instance omap3) to know what to do.
> 
> In your case, you should try the first entry in the "tips and tricks"
> section.
> 

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/04/2012 06:57 PM, Wayne Warren wrote:
> Gilles,
> 
> Thanks for your help!
> 
> The ArmPorting guide is helpful, but unfortunately the first tip and
> trick did not reveal any boot messages. I had to add a function
> declaration for "printascii" to get the code to compile. I have
> CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_LL, and CONFIG_EARLY_PRINTK enabled
> and have passed the boot parameter "earlyprintk" when attempting to
> boot. 

Either you enable CONFIG_EARLY_PRINTK and pass earlyprintk on the
command line, that is the "new" way.

Or, you do the printascii in printk trick, that is the "old" way.

If you do both, you should see everything printed twice.
If you do not see anything, it probably means that printascii does not
work for your platform. To get it working, you have to look at
arch/arm/your-machine/include/mach/debug-macro.S
And of course, your kernel has to be compiled for only one board, if the
UART used by these macros depends on the board.

You can validate printascii without the I-pipe patch first. Simply put
printascii("!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n") in some board init
function, and check if you see that line among the boot logs.


> 
> According to 
> 
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> 
> (which seems to be a newer version of the page you mentioned) I should
> try to boot the kernel without CONFIG_IPIPE or CONFIG_XENOMAI enabled
> and if it does not work it is likely to be a problem with the timer.
> 
> I have then used "git diff --name-only <known-working-ti-kernel-ref>
> <ipipe-merged-ref>" to get a list of files and I have been looking
> through their current versions alongside a diff of each given file while
> reading to the instructions provided in both the old and the new
> ArmPorting guides to see what might have changed in timer-related code
> that would prevent the kernel from booting.
> 
> If you have any additional advice, I would greatly appreciate it.

The first advice is to try booting a kernel without even the Adeos patch
applied, to have a .config which you are 100% sure is supposed to boot.
Then try to get printascii running. Then debug the boot process to see
at what point the lockup happens.

The code you have to add to get the timer running with the I-pipe patch
is what is documented in the old document, not the new one. The new one
documents the I-pipe patch for Linux kernels starting with 3.2.

> Also, if I could get an account on the Xenomai wiki, there are some simple
> changes I would make to the ArmPorting page to improve its readability a
> little (for example, create indented paragraphs for the description of
> the "struct ipipe_timer" members). I guess I don't really have anything
> concrete or technical to add to it so if you don't want to add me, I
> understand.

Done, you should have received a mail with your password.


-- 
					    Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/04/2012 07:09 PM, Gilles Chanteperdrix wrote:

> On 10/04/2012 06:57 PM, Wayne Warren wrote:
>> Gilles,
>>
>> Thanks for your help!
>>
>> The ArmPorting guide is helpful, but unfortunately the first tip and
>> trick did not reveal any boot messages. I had to add a function
>> declaration for "printascii" to get the code to compile. I have
>> CONFIG_DEBUG_KERNEL, CONFIG_DEBUG_LL, and CONFIG_EARLY_PRINTK enabled
>> and have passed the boot parameter "earlyprintk" when attempting to
>> boot. 
> 
> Either you enable CONFIG_EARLY_PRINTK and pass earlyprintk on the
> command line, that is the "new" way.
> 
> Or, you do the printascii in printk trick, that is the "old" way.
> 
> If you do both, you should see everything printed twice.
> If you do not see anything, it probably means that printascii does not
> work for your platform. To get it working, you have to look at
> arch/arm/your-machine/include/mach/debug-macro.S
> And of course, your kernel has to be compiled for only one board, if the
> UART used by these macros depends on the board.


Ah, if it is an OMAP based processor, you need to add a call to
_DEBUG_LL_ENTRY for your processor in
arch/arm/plat-omap/include/plat/uncompress.h, it may be what is missing.


-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/04/2012 07:09 PM, Gilles Chanteperdrix wrote:
>> Also, if I could get an account on the Xenomai wiki, there are some simple
>> changes I would make to the ArmPorting page to improve its readability a
>> little (for example, create indented paragraphs for the description of
>> the "struct ipipe_timer" members). I guess I don't really have anything
>> concrete or technical to add to it so if you don't want to add me, I
>> understand.
> 
> Done, you should have received a mail with your password.

By the way, if you feel like correcting my frenglish, I will not be vexed.

-- 
					    Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

Cool,

First off, thanks again for the help and...my wiki account does not seem
to have edit privileges on the page I was referring to in my previous
e-mail.

Second, I have confirmed that the TI code we originally modified for our
product does boot. However! Whenever I pass in
"earlyprink=ttyO2,115200n8" the kernel seems to hang. Adding this
parameter seems to be the only difference between the kernel that boots
properly and the one that does not in this branch. 

I am fairly certain the kernel is not booting because if it was booting
I would see communication with the network filesystem I am booting into
when I run "tcpdump -n -i <interface> | grep <dhcp_ip_address>" on my
development PC which is connected to the same subnet. I know the IP
address assigned will be the same as what it acquires in U-boot because
the IP address lease time on our server is set to 10 minutes and
whenever it boots correctly without the earlyprintk parameter, it
retains this ip address.

I read Documentation/kernel-parameters.txt and saw that only ttyS0 and
ttyS1 are supported, but these names do not correspond to the device
names normally assigned by whatever serial driver is in use. Plus, the
documentation seems to suggest that earlyprintk is not supported for ARM
processors.

I also tried just using printascii() as described in the older version
of the ArmPorting page--no luck there.

Wayne Warren

On Fri, 2012-10-05 at 10:06 +0200, Gilles Chanteperdrix wrote:
> On 10/04/2012 07:09 PM, Gilles Chanteperdrix wrote:
> >> Also, if I could get an account on the Xenomai wiki, there are some simple
> >> changes I would make to the ArmPorting page to improve its readability a
> >> little (for example, create indented paragraphs for the description of
> >> the "struct ipipe_timer" members). I guess I don't really have anything
> >> concrete or technical to add to it so if you don't want to add me, I
> >> understand.
> > 
> > Done, you should have received a mail with your password.
> 
> By the way, if you feel like correcting my frenglish, I will not be vexed.
> 

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/05/2012 08:47 PM, Wayne Warren wrote:

> Cool,
> 
> First off, thanks again for the help and...my wiki account does not seem
> to have edit privileges on the page I was referring to in my previous
> e-mail.


That should be fixed by that.

> 
> Second, I have confirmed that the TI code we originally modified for our
> product does boot. However! Whenever I pass in
> "earlyprink=ttyO2,115200n8" the kernel seems to hang. Adding this
> parameter seems to be the only difference between the kernel that boots
> properly and the one that does not in this branch. 


That is what I told you: you should validate earlyprintk, starting by
validating printascii alone, that is, compile a kernel with
CONFIG_DEBUG_LL, without CONFIG_EARLY_PRINTK, and add a call to
printascii somewhere in the boot process, not in vprintk implementation.

earlyprintk is a module parameter with no argument: what uart is used by
printascii is determined, as I also told you, by the code in
arch/arm/plat-omap/include/plat/uncompress.h, it is not a dynamic parameter.

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

Sorry,

I did put a call to printascii() in arch/arm/kernel/setup.c right before
the only call I could find to "paging_init()" per the comments in
arch/arm/plat-omap/include/plat/serial.h.

Still, this is not quite what you said so I have just now included the
same lines in several places throughout our board file's init function
just to see if calls before or after the omap_serial_init() function
would make a different. Each time, the kernel hangs--and during
compilation I always see "warning: 'printascii' used but never
defined". 

Does this warning mean that the "printascii" symbol is not exported
properly by the PROC() macro? Or does it indicate that I am doing
something wrong with the printascii declaration which I must always
insert in whatever file I include a call for the function? I guess this
also touches on my lack of understanding of what the PROC() macro is
doing--I have been assuming that it sets the enclosed symbol up to be
available globally for the executable. I picked up a book Understanding
the Linux Kernel today, but it is pretty old and x86 specific.

The impression I had from the wiki page was that earlyprintk and your
advice has no arguments, but the Documentation/kernel-parameters.txt
file confused me on that issue.

Something else I was looking at was attempting to hard code the
omap_phys_addr and omap_virt_addr values in
arch/arm/mach-omap2/include/mach/debug-macro.S--I know the first value
from the technical reference manual, not sure about the other.

Wayne

On Fri, 2012-10-05 at 22:16 +0200, Gilles Chanteperdrix wrote:
> On 10/05/2012 08:47 PM, Wayne Warren wrote:
> 
> > Cool,
> > 
> > First off, thanks again for the help and...my wiki account does not seem
> > to have edit privileges on the page I was referring to in my previous
> > e-mail.
> 
> 
> That should be fixed by that.
> 
> > 
> > Second, I have confirmed that the TI code we originally modified for our
> > product does boot. However! Whenever I pass in
> > "earlyprink=ttyO2,115200n8" the kernel seems to hang. Adding this
> > parameter seems to be the only difference between the kernel that boots
> > properly and the one that does not in this branch. 
> 
> 
> That is what I told you: you should validate earlyprintk, starting by
> validating printascii alone, that is, compile a kernel with
> CONFIG_DEBUG_LL, without CONFIG_EARLY_PRINTK, and add a call to
> printascii somewhere in the boot process, not in vprintk implementation.
> 
> earlyprintk is a module parameter with no argument: what uart is used by
> printascii is determined, as I also told you, by the code in
> arch/arm/plat-omap/include/plat/uncompress.h, it is not a dynamic parameter.
> 

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/05/2012 11:47 PM, Wayne Warren wrote:

> The impression I had from the wiki page was that earlyprintk and your
> advice has no arguments, but the Documentation/kernel-parameters.txt
> file confused me on that issue.


That is because it documents this option for x86, not ARM.

> 
> Something else I was looking at was attempting to hard code the
> omap_phys_addr and omap_virt_addr values in
> arch/arm/mach-omap2/include/mach/debug-macro.S--I know the first value
> from the technical reference manual, not sure about the other.


For the third time, see:
arch/arm/plat-omap/include/plat/uncompress.h
That is where the virtual and physical addresses are set for OMAP based
processors.

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

Gilles,

I should have mentioned this earlier... I did as you mentioned in one of
your previous e-mails and added DEBUG_LL_OMAP3(3, am3517evm) after finding
that this string corresponds to the processor id passed to the linux
kernel from u-boot (unless I am misunderstanding how that works). This
applies to all the kernels I built and tested as described in my previous
two e-mails.

Thanks for your patience, and sorry for the confusion!

Wayne

Gilles Chanteperdrix wrote:
> On 10/05/2012 11:47 PM, Wayne Warren wrote:
>
>> The impression I had from the wiki page was that earlyprintk and your
>> advice has no arguments, but the Documentation/kernel-parameters.txt
>> file confused me on that issue.
>
>
> That is because it documents this option for x86, not ARM.
>
>>
>> Something else I was looking at was attempting to hard code the
>> omap_phys_addr and omap_virt_addr values in
>> arch/arm/mach-omap2/include/mach/debug-macro.S--I know the first value
>> from the technical reference manual, not sure about the other.
>
>
> For the third time, see:
> arch/arm/plat-omap/include/plat/uncompress.h
> That is where the virtual and physical addresses are set for OMAP based
> processors.
>
> --
>                                                                 Gilles.
>


-- 
S. Wayne Warren

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/06/2012 06:29 AM, Wayne Warren wrote:

> Gilles,
> 
> I should have mentioned this earlier... I did as you mentioned in one of
> your previous e-mails and added DEBUG_LL_OMAP3(3, am3517evm) after finding
> that this string corresponds to the processor id passed to the linux
> kernel from u-boot (unless I am misunderstanding how that works). This
> applies to all the kernels I built and tested as described in my previous
> two e-mails.
> 
> Thanks for your patience, and sorry for the confusion!


Ok, but for some reason, that is probably what is not working. Are you
sure that:
- the am3517 uart has the same address and registers as an omap3 uart?
- that the serial console is on UART3 ?
- the uart registers range is mapped where the code in debug-macro.S
expects it?

I never had to debug this, but if I had to, I would try to find what are
the values used by the decompressor for the uart physical and virutal
addresses and check whether the virtual adress is really mapped.

If your kernel does not start with CONFIG_IPIPE, earlyprintk does not
work, and you do not have a JTAG probe, you can try toggling some GPIOs
to light some LEDS.

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

On Sat, 2012-10-06 at 11:46 +0200, Gilles Chanteperdrix wrote:
> On 10/06/2012 06:29 AM, Wayne Warren wrote:
> 
> > Gilles,
> > 
> > I should have mentioned this earlier... I did as you mentioned in one of
> > your previous e-mails and added DEBUG_LL_OMAP3(3, am3517evm) after finding
> > that this string corresponds to the processor id passed to the linux
> > kernel from u-boot (unless I am misunderstanding how that works). This
> > applies to all the kernels I built and tested as described in my previous
> > two e-mails.
> > 
> > Thanks for your patience, and sorry for the confusion!
> 
> 
> Ok, but for some reason, that is probably what is not working. Are you
> sure that:
> - the am3517 uart has the same address and registers as an omap3 uart?

I verified this using the AM3517 (which apparently used to be called the
OMAP3517...I think) Technical Reference Manual.  

> - that the serial console is on UART3 ?

Yes, I just re-verified this looking at the product schematic.

> - the uart registers range is mapped where the code in debug-macro.S
> expects it?

Not sure how to check this, will probably have to read the tech ref
manual more in-depth. 

> 
> I never had to debug this, but if I had to, I would try to find what are
> the values used by the decompressor for the uart physical and virutal
> addresses and check whether the virtual adress is really mapped.

One thing I spent some time on Friday night was trying to figure out
what exactly was happening in the assembly code (which I have little
familiarity with, but am learning more as I go) to translate physical to
virtual and back again.

> 
> If your kernel does not start with CONFIG_IPIPE, earlyprintk does not
> work, and you do not have a JTAG probe, you can try toggling some GPIOs
> to light some LEDS.
> 

Thanks again for the advice!

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/09/2012 10:55 PM, Wayne Warren wrote:

> 
> 
> On Sat, 2012-10-06 at 11:46 +0200, Gilles Chanteperdrix wrote:
>> On 10/06/2012 06:29 AM, Wayne Warren wrote:
>>
>>> Gilles,
>>>
>>> I should have mentioned this earlier... I did as you mentioned in one of
>>> your previous e-mails and added DEBUG_LL_OMAP3(3, am3517evm) after finding
>>> that this string corresponds to the processor id passed to the linux
>>> kernel from u-boot (unless I am misunderstanding how that works). This
>>> applies to all the kernels I built and tested as described in my previous
>>> two e-mails.
>>>
>>> Thanks for your patience, and sorry for the confusion!
>>
>>
>> Ok, but for some reason, that is probably what is not working. Are you
>> sure that:
>> - the am3517 uart has the same address and registers as an omap3 uart?
> 
> I verified this using the AM3517 (which apparently used to be called the
> OMAP3517...I think) Technical Reference Manual.  
> 
>> - that the serial console is on UART3 ?
> 
> Yes, I just re-verified this looking at the product schematic.


There may be a trap in arch/arm/plat-omap/include/mach/serial.h: the
constants OMAP3_UARTx_BASE are numbered starting from 1. So, if the
hardware UART are numbered from 0, you should pass 4 instead of 3 to the
DEBUG_LL_OMAP3 macro.

> 
>> - the uart registers range is mapped where the code in debug-macro.S
>> expects it?
> 
> Not sure how to check this, will probably have to read the tech ref
> manual more in-depth. 


No, you will have to check the code and find the place where the I/O
mapping is done.


> 
>>
>> I never had to debug this, but if I had to, I would try to find what are
>> the values used by the decompressor for the uart physical and virutal
>> addresses and check whether the virtual adress is really mapped.
> 
> One thing I spent some time on Friday night was trying to figure out
> what exactly was happening in the assembly code (which I have little
> familiarity with, but am learning more as I go) to translate physical to
> virtual and back again.


The idea is that printascii should work whether the MMU is enabled or
not. If the MMU is not enabled the physical address is used directly,
if the MMU is enabled, the virtual address is used. However, for this to
work, a mapping, presumably static, should have been defined for the
UART registers, still presumably somewhere in the .map_io callback for
your board. I have to admit that I could not find where this happens for
the omap3 based board I use, where printascii works.

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

Just an update...

I currently have GDB connected to the unit using a BDI2000 JTAG
debugger.


(gdb) bt
#0  __set_irq_handler (irq=395, handle=0xc00c3424 <handle_simple_irq>, is_chained=0, name=0x0) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/irq/chip.c:836
#1  0xc0010f04 in gpmc_init () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/include/linux/irq.h:288
#2  0xc000beb4 in init_IRQ () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/irq.c:159
#3  0xc0008b44 in start_kernel () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/init/main.c:611
#4  0x80008034 in ?? ()

Then if I continue from here the next breakpoint I have set up is
__delay:

(gdb) bt
#0  __delay () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/lib/delay.S:44
#1  0xc0482acc in panic (fmt=0xc0641d24 "\001") at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/panic.c:152
#2  0xc00800b4 in do_exit (code=11) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/exit.c:915
#3  0xc004ed9c in die (str=0xc00c2e10 "x0\222, regs=0xc062df38, err=0) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/traps.c:287
#4  0xc003f3b8 in do_DataAbort (addr=3735899941, fsr=1, regs=0xc062df38) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/mm/fault.c:575
#5  0xc04868ec in __dabt_svc ()
Backtrace stopped: frame did not save the PC


I don't really understand __dabt_svc, maybe it means "data abort
service" or something. I have pinpointed what seems to be the exact
instruction just prior to the entry into __dabt_svc, though it seems
like there is probably something going on behind the scenes in the
processor which is not visible from the debug unit.

I also now understand why there are no printk messages--since the
machine_init() has not been called yet, there are no UARTs registered as
a serial console. The way early_printk works is also a little more clear
to me, but I do not plan at this time to continue trying to get it to
work.

One thing I tried was to reduce GPMC_CS_NUM to 7 in
arch/arm/plat-omap/include/plat/gpmc.h (even though the AM3517 does have
8 chip selects) since it was always failing on the 8th
__set_irq_handler invocation in gpmc_init(), which I assume corresponds
to the 8th chip select. But, it still failed anyway so I guess it is
just the last GPMC interrupt that fails, maybe regardless of the number.

Wayne

> 
> There may be a trap in arch/arm/plat-omap/include/mach/serial.h: the
> constants OMAP3_UARTx_BASE are numbered starting from 1. So, if the
> hardware UART are numbered from 0, you should pass 4 instead of 3 to the
> DEBUG_LL_OMAP3 macro.
> 
> > 
> >> - the uart registers range is mapped where the code in debug-macro.S
> >> expects it?
> > 
> > Not sure how to check this, will probably have to read the tech ref
> > manual more in-depth. 
> 
> 
> No, you will have to check the code and find the place where the I/O
> mapping is done.
> 

> The idea is that printascii should work whether the MMU is enabled or
> not. If the MMU is not enabled the physical address is used directly,
> if the MMU is enabled, the virtual address is used. However, for this to
> work, a mapping, presumably static, should have been defined for the
> UART registers, still presumably somewhere in the .map_io callback for
> your board. I have to admit that I could not find where this happens for
> the omap3 based board I use, where printascii works.
> 

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

Oh yeah, I also wanted to let you know that I did look into making the
changes I mentioned previously to the Xenomai wiki but it appears that
the content of the wiki was originally formatted to insert line breaks
at column 80 for most of the page. While it would not be difficult to
fix this programmatically, I figure it was probably done that way for a
reason and would rather not interfere too strongly with existing
conventions.

Also, making the change I mentioned on that one page would require
similar changes made to other pages to retain a sense of consistency
which does not seem worth the effort.

Wayne

On Tue, 2012-10-09 at 23:12 +0200, Gilles Chanteperdrix wrote:
> On 10/09/2012 10:55 PM, Wayne Warren wrote:
> 
> > 
> > 
> > On Sat, 2012-10-06 at 11:46 +0200, Gilles Chanteperdrix wrote:
> >> On 10/06/2012 06:29 AM, Wayne Warren wrote:
> >>
> >>> Gilles,
> >>>
> >>> I should have mentioned this earlier... I did as you mentioned in one of
> >>> your previous e-mails and added DEBUG_LL_OMAP3(3, am3517evm) after finding
> >>> that this string corresponds to the processor id passed to the linux
> >>> kernel from u-boot (unless I am misunderstanding how that works). This
> >>> applies to all the kernels I built and tested as described in my previous
> >>> two e-mails.
> >>>
> >>> Thanks for your patience, and sorry for the confusion!
> >>
> >>
> >> Ok, but for some reason, that is probably what is not working. Are you
> >> sure that:
> >> - the am3517 uart has the same address and registers as an omap3 uart?
> > 
> > I verified this using the AM3517 (which apparently used to be called the
> > OMAP3517...I think) Technical Reference Manual.  
> > 
> >> - that the serial console is on UART3 ?
> > 
> > Yes, I just re-verified this looking at the product schematic.
> 
> 
> There may be a trap in arch/arm/plat-omap/include/mach/serial.h: the
> constants OMAP3_UARTx_BASE are numbered starting from 1. So, if the
> hardware UART are numbered from 0, you should pass 4 instead of 3 to the
> DEBUG_LL_OMAP3 macro.
> 
> > 
> >> - the uart registers range is mapped where the code in debug-macro.S
> >> expects it?
> > 
> > Not sure how to check this, will probably have to read the tech ref
> > manual more in-depth. 
> 
> 
> No, you will have to check the code and find the place where the I/O
> mapping is done.
> 
> 
> > 
> >>
> >> I never had to debug this, but if I had to, I would try to find what are
> >> the values used by the decompressor for the uart physical and virutal
> >> addresses and check whether the virtual adress is really mapped.
> > 
> > One thing I spent some time on Friday night was trying to figure out
> > what exactly was happening in the assembly code (which I have little
> > familiarity with, but am learning more as I go) to translate physical to
> > virtual and back again.
> 
> 
> The idea is that printascii should work whether the MMU is enabled or
> not. If the MMU is not enabled the physical address is used directly,
> if the MMU is enabled, the virtual address is used. However, for this to
> work, a mapping, presumably static, should have been defined for the
> UART registers, still presumably somewhere in the .map_io callback for
> your board. I have to admit that I could not find where this happens for
> the omap3 based board I use, where printascii works.
> 

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/19/2012 11:22 PM, Wayne Warren wrote:

> Just an update...
> 
> I currently have GDB connected to the unit using a BDI2000 JTAG
> debugger.
> 
> 
> (gdb) bt
> #0  __set_irq_handler (irq=395, handle=0xc00c3424 <handle_simple_irq>, is_chained=0, name=0x0) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/irq/chip.c:836


So what is the code at line 836 in kernel/irq/chip.c ?

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/19/2012 11:32 PM, Wayne Warren wrote:

> Oh yeah, I also wanted to let you know that I did look into making the
> changes I mentioned previously to the Xenomai wiki but it appears that
> the content of the wiki was originally formatted to insert line breaks
> at column 80 for most of the page.


That is my fault. I use a text buffer formatted with a normal editor
which wraps line at 80 columns, then paste it in the wiki forms, then
remove the line breaks which the wiki seem to consider important.

> While it would not be difficult to
> fix this programmatically, I figure it was probably done that way for a
> reason and would rather not interfere too strongly with existing
> conventions.


No good reason, I find text wrapped at 80 columns more readable, that is
all.

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/19/2012 11:22 PM, Wayne Warren wrote:

> I also now understand why there are no printk messages--since the
> machine_init() has not been called yet, there are no UARTs registered as
> a serial console. The way early_printk works is also a little more clear
> to me, but I do not plan at this time to continue trying to get it to
> work.


By the way, if early_printk does not work, printascii is supposed to
work very early, so the "printascii in printk" trick should work. If it
does not work, it means that printascii does not work, and as I already
said, you can validate printascii separately, on a correctly working
kernel. But JTAG is fine, too...

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

This code is the __set_irq_handler function which, given an interrupt
number/id, appears to set up an entry in an irq_desc array. This
structure (irq_desc) appears to be the place to go for information
related to a given IRQ id.

We seem to have discovered the problem, which was that this array was
not initialized with enough slots...in
arch/arm/plat-omap/include/play/irqs.h OMAP_GPMC_NR_IRQS was defined as
7 rather than 8 (there are actually 8 GPMC chip selects). In a
roundabout way, this macro is used to calculate the array size for
irq_desc.

Since gpmc_init() was using GPMC_CS_NUM as a bound in the for loop that
was calling __set_irq_handler and the "irq" variable in that same
function was initialized using OMAP_GPMC_IRQ_BASE, it seems like:

  - OMAP_GPMC_NR_IRQS should be used in the for loop instead of
GPMC_CS_NUM,
  - GPMC_CS_NUM should be used to define OMAP_GPMC_NR_IRQS,
  - or at the very least, GPMC_CS_NUM and OMAP_GPMC_NR_IRQS should be
set to the same constant value (8).

I think maybe the first two of those together should be the fix, but I
am still fairly lost here. Temporarily, we have set OMAP_GPMC_NR_IRQS to
8 which eliminates the data abort exception that was occurring in
__set_irq_handler.

But we still have a kernel panic. Stepping further through the
start_kernel function in GDB leads to local_irq_enable() which after
some investigation is preprocessed into __ipipe_unstall_root().

It is the last line of this function, "local_irq_enable_hw()" where the
next data abort exception occurs. This line translates into the
assembler instruction "cpsie i" which is the last instruction before
__dabt_svc(). Any idea what might be going on there? 

Thanks again for your help and prompt replies, they are very helpful.

Wayne

On Sat, 2012-10-20 at 03:33 +0200, Gilles Chanteperdrix wrote:
> On 10/19/2012 11:22 PM, Wayne Warren wrote:
> 
> > Just an update...
> > 
> > I currently have GDB connected to the unit using a BDI2000 JTAG
> > debugger.
> > 
> > 
> > (gdb) bt
> > #0  __set_irq_handler (irq=395, handle=0xc00c3424 <handle_simple_irq>, is_chained=0, name=0x0) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/irq/chip.c:836
> 
> 
> So what is the code at line 836 in kernel/irq/chip.c ?
> 

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/22/2012 09:22 PM, Wayne Warren wrote:

> This code is the __set_irq_handler function which, given an interrupt
> number/id, appears to set up an entry in an irq_desc array. This
> structure (irq_desc) appears to be the place to go for information
> related to a given IRQ id.
> 
> We seem to have discovered the problem, which was that this array was
> not initialized with enough slots...in
> arch/arm/plat-omap/include/play/irqs.h OMAP_GPMC_NR_IRQS was defined as
> 7 rather than 8 (there are actually 8 GPMC chip selects). In a
> roundabout way, this macro is used to calculate the array size for
> irq_desc.
> 
> Since gpmc_init() was using GPMC_CS_NUM as a bound in the for loop that
> was calling __set_irq_handler and the "irq" variable in that same
> function was initialized using OMAP_GPMC_IRQ_BASE, it seems like:
> 
>   - OMAP_GPMC_NR_IRQS should be used in the for loop instead of
> GPMC_CS_NUM,
>   - GPMC_CS_NUM should be used to define OMAP_GPMC_NR_IRQS,
>   - or at the very least, GPMC_CS_NUM and OMAP_GPMC_NR_IRQS should be
> set to the same constant value (8).
> 
> I think maybe the first two of those together should be the fix, but I
> am still fairly lost here. Temporarily, we have set OMAP_GPMC_NR_IRQS to
> 8 which eliminates the data abort exception that was occurring in
> __set_irq_handler.
> 
> But we still have a kernel panic. Stepping further through the
> start_kernel function in GDB leads to local_irq_enable() which after
> some investigation is preprocessed into __ipipe_unstall_root().
> 
> It is the last line of this function, "local_irq_enable_hw()" where the
> next data abort exception occurs. This line translates into the
> assembler instruction "cpsie i" which is the last instruction before
> __dabt_svc(). Any idea what might be going on there? 
> 
> Thanks again for your help and prompt replies, they are very helpful.


Chances are you are calling into Adeos code too early. Normally, the
first call to local_irq_enable() happens in init/main.c, after the call
to __ipipe_init() (you should see both in function start_kernel). I
suspect you can not call services such as __set_irq_handler too early in
the boot process.

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

> 
> Chances are you are calling into Adeos code too early. Normally, the
> first call to local_irq_enable() happens in init/main.c, after the call
> to __ipipe_init() (you should see both in function start_kernel). I
> suspect you can not call services such as __set_irq_handler too early in
> the boot process.

In the code I am looking at, local_irq_enable() is called after
ipipe_init().

Are you saying that the __set_irq_handler() service should not be called
before ipipe_init() also? Cause it is called after ipipe_init_early()
but before ipipe_init().

Wayne

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/22/2012 09:34 PM, Wayne Warren wrote:

> 
>>
>> Chances are you are calling into Adeos code too early. Normally, the
>> first call to local_irq_enable() happens in init/main.c, after the call
>> to __ipipe_init() (you should see both in function start_kernel). I
>> suspect you can not call services such as __set_irq_handler too early in
>> the boot process.
> 
> In the code I am looking at, local_irq_enable() is called after
> ipipe_init().
> 
> Are you saying that the __set_irq_handler() service should not be called
> before ipipe_init() also? Cause it is called after ipipe_init_early()
> but before ipipe_init().


The same order happens on OMAP3 for the primary interrupt controller.
So, that should work.

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

Yeah, this is actually an OMAP3 processor, except the kernel tree you
are using (if it is the Adeos I-Pipe one) I think was branched from the
vanilla kernel whereas the one we are using is branched from a TI kernel
released specifically for the AM3517 (previously known as OMAP3517, I
think? still confused about that).

The current problem is in __ipipe_stall_root(). After analyzing the
GDB-disassembled function, I can see that there are three "ldr" and one
"str" instructions that might be the cause of the Data Abort exception
that leads into the kernel panic. These instructions all load or store
values related to the __ipipe_percpu_darray variable. Specifically, they
deal with the first entry in this array, clear the status member (ldr,
bic) and write it back (str), check the value of irqpend_himap (ldr,
cmp) to determine if __ipipe_sync_stage should be called (the answer is
no), then try to re-enable interrupts using "cpsie"

The Data Abort exception actually occurs on the "cpsie" instruction, but
according to the ARMv7-A/ARMv7-R architecture reference manual, the
"CPS" type instructions do not generate any exceptions. However, the
manual also indicates that in Debug mode the behavior of the processor
when this instruction is called can be unpredictable.

Anyway, I am somewhat at a loss. The "ldr" and "str" instructions used
perform the operations as expected according to printouts of
__ipipe_cpu_darray.

Wayne

On Mon, 2012-10-22 at 23:12 +0200, Gilles Chanteperdrix wrote:
> On 10/22/2012 09:34 PM, Wayne Warren wrote:
> 
> > 
> >>
> >> Chances are you are calling into Adeos code too early. Normally, the
> >> first call to local_irq_enable() happens in init/main.c, after the call
> >> to __ipipe_init() (you should see both in function start_kernel). I
> >> suspect you can not call services such as __set_irq_handler too early in
> >> the boot process.
> > 
> > In the code I am looking at, local_irq_enable() is called after
> > ipipe_init().
> > 
> > Are you saying that the __set_irq_handler() service should not be called
> > before ipipe_init() also? Cause it is called after ipipe_init_early()
> > but before ipipe_init().
> 
> 
> The same order happens on OMAP3 for the primary interrupt controller.
> So, that should work.
> 

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/23/2012 05:32 PM, Wayne Warren wrote:

> Yeah, this is actually an OMAP3 processor, except the kernel tree you
> are using (if it is the Adeos I-Pipe one) I think was branched from the
> vanilla kernel whereas the one we are using is branched from a TI kernel
> released specifically for the AM3517 (previously known as OMAP3517, I
> think? still confused about that).
> 
> The current problem is in __ipipe_stall_root(). After analyzing the
> GDB-disassembled function, I can see that there are three "ldr" and one
> "str" instructions that might be the cause of the Data Abort exception
> that leads into the kernel panic. These instructions all load or store
> values related to the __ipipe_percpu_darray variable. Specifically, they
> deal with the first entry in this array, clear the status member (ldr,
> bic) and write it back (str), check the value of irqpend_himap (ldr,
> cmp) to determine if __ipipe_sync_stage should be called (the answer is
> no), then try to re-enable interrupts using "cpsie"
> 
> The Data Abort exception actually occurs on the "cpsie" instruction, but
> according to the ARMv7-A/ARMv7-R architecture reference manual, the
> "CPS" type instructions do not generate any exceptions. However, the
> manual also indicates that in Debug mode the behavior of the processor
> when this instruction is called can be unpredictable.
> 
> Anyway, I am somewhat at a loss. The "ldr" and "str" instructions used
> perform the operations as expected according to printouts of
> __ipipe_cpu_darray.


Normally, if the kernel is not an SMP kernel, the root state is a simple
variable. The only reason I see why ldr or str could fail would be if
the address is invalid or not aligned correctly. Apart from that,
debugging this kind of issue remotely is a bit hard.

You can try another method, if the vanilla kernel from which the branch
you are working on is forked works on the processor you are using, and
works with xenomai, you can try a git bisect, to try and find which
commit exactly conflicts with the I-pipe patch.

Yet another method, you can try and reduce the kernel to the simplest
possible configuration which allows to boot your system (disabling NAND
and NOR, which should for instance remove the need for GPMC, and boot
using NFS), see if it works, and if it works, gradually add the options
until you find which option is a problem, then compare the code this
option enables with the vanilla linux code.

-- 
                                                                Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

We decided to try to continue debugging our current branch for another
day or two.

We thought to check the link register just as execution enters
__dabt_srv and found that the data abort exception occurs in an
interrupt handler called from __int_svc, which is why we thought it was
occurring on the cpsie instruction...actually, an interrupt seems to
have occurred just as interrupts were enabled. The backtrace from the
breakpoint in the function found using the LR value at __dabt_svc is:

(gdb) bt                                                                                                                                                     │············································································································
#0  __ipipe_tsc_update () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/ipipe_tsc.c:123                                                 │············································································································
#1  0xc0059ac0 in omap2_gp_timer_interrupt (irq=38, dev_id=0xc07e4ba0) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/mach-omap2/timer-gp.c:77  │············································································································
#2  0xc00c0bb0 in handle_IRQ_event (irq=38, action=0xc0634038) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/irq/handle.c:68                     │············································································································
#3  0xc00c3378 in handle_level_irq (irq=38, desc=0xc07a68c8) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/irq/chip.c:529                        │············································································································
#4  0xc003f044 in asm_do_IRQ (irq=38, regs=<value optimized out>) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/include/linux/irqdesc.h:125             │············································································································
#5  0xc00c57c8 in __ipipe_sync_stage () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/ipipe/core.c:1284                                          │············································································································
#6  0xc005280c in __ipipe_grab_irq (irq=38, regs=0xc062df80) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/ipipe.c:605                  │············································································································
#7  0xc04868f8 in __irq_svc ()                                                                                                                               │············································································································
Backtrace stopped: frame did not save the PC       

This shows that the backtrace occurs in __ipipe_tsc_update.
Specifically, it occurs when a "BLX" instruction is called on a register
holding an address that points to no function in particular. I believe
this is because the function __ipipe_tsc_get (called in
__ipipe_tsc_update) is not defined.

CONFIG_IPIPE_ARM_KUSER_TSC is set to 'y' by default since CONFIG_OMAP is
selected, so it seems that __ipipe_tsc_get is not mapped to
__ipipe_mach_get_tsc by the preprocessor macro in
arc/arm/include/asm/ipipe.h, near line 340. 

__ipipe_mach_get_tsc is something that the ArmPorting guide you linked
me to a couple weeks ago mentions as needing to be defined, yet it
appears because CONFIG_IPIPE_ARM_KUSER_TSC is defined, it wouldn't
matter.

Do you have any suggestions? For now I think I will work on the
__ipipe_mach_get_tsc function and force CONFIG_IPIPE_ARM_KUSER_TSC=n.

Wayne

> 
> 
> Normally, if the kernel is not an SMP kernel, the root state is a simple
> variable. The only reason I see why ldr or str could fail would be if
> the address is invalid or not aligned correctly. Apart from that,
> debugging this kind of issue remotely is a bit hard.
> 
> You can try another method, if the vanilla kernel from which the branch
> you are working on is forked works on the processor you are using, and
> works with xenomai, you can try a git bisect, to try and find which
> commit exactly conflicts with the I-pipe patch.
> 
> Yet another method, you can try and reduce the kernel to the simplest
> possible configuration which allows to boot your system (disabling NAND
> and NOR, which should for instance remove the need for GPMC, and boot
> using NFS), see if it works, and if it works, gradually add the options
> until you find which option is a problem, then compare the code this
> option enables with the vanilla linux code.
> 

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

By the way...

The dmesg function in Documentation/kdump/gdbmacros.txt is very slow
about printing out the log buffer, so we figured out a somewhat hackish
way to get the current log_buffer contents faster. This example assumes
that the value of "logged_chars" is 3513:

(gdb) printf "%.3513s", log_buf
<5>[    0.000000] Linux version 2.6.37.6+ (wayne@ENG-09-LX) (gcc version 4.3.1 (GCC) ) #31 Wed Oct 24 09:17:39 CDT 2012                                      │············································································································
<4>[    0.000000] CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7f                                                                            │············································································································
<4>[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache                                                                       │············································································································
<4>[    0.000000] Machine: EMAC SOM-3517                                                                                                                     │············································································································
<6>[    0.000000] Reserving 4194304 bytes SDRAM for VRAM                                                                                                     │············································································································
<4>[    0.000000] Memory policy: ECC disabled, Data cache writeback                                                                                          │············································································································
<6>[    0.000000] AM3517 ES1.1 (l2cache sgx neon isp )                                                                                                       │············································································································
<6>[    0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000                                                                                  │············································································································
<7>[    0.000000] On node 0 totalpages: 64512                                                                                                                │············································································································
<7>[    0.000000] free_area_init_node: node 0, pgdat c07e060c, node_mem_map c0d95000                                                                         │············································································································
<7>[    0.000000]   Normal zone: 512 pages used for memmap                                                                                                   │············································································································
<7>[    0.000000]   Normal zone: 0 pages reserved                                                                                                            │············································································································
<7>[    0.000000]   Normal zone: 64000 pages, LIFO batch:15                                                                                                  │············································································································
<7>[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768                                                                                              │············································································································
<7>[    0.000000] pcpu-alloc: [0] 0                                                                                                                          │············································································································
<4>[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64000                                                                 │············································································································
<5>[    0.000000] Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait                                                │············································································································
<6>[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)                                                                                        │············································································································
<6>[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)                                                                            │············································································································
<6>[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)                                                                              │············································································································
<6>[    0.000000] Memory: 252MB = 252MB total                                                                                                                │············································································································
<5>[    0.000000] Memory: 241840k/241840k available, 20304k reserved, 0K highmem                                                                             │············································································································
<5>[    0.000000] Virtual kernel memory layout:                                                                                                              │············································································································
<5>[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)                                                                                          │············································································································
<5>[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)                                                                                          │············································································································
<5>[    0.000000]     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)                                                                                          │············································································································
<5>[    0.000000]     vmalloc : 0xd0800000 - 0xf8000000   ( 632 MB)                                                                                          │············································································································
<5>[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)                                                                                          │············································································································
<5>[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)                                                                                          │············································································································
<5>[    0.000000]       .init : 0xc0008000 - 0xc003f000   ( 220 kB)                                                                                          │············································································································
<5>[    0.000000]       .text : 0xc003f000 - 0xc062b828   (6067 kB)                                                                                          │············································································································
<5>[    0.000000]       .data : 0xc062c000 - 0xc07e4920   (1763 kB)                                                                                          │············································································································
<6>[    0.000000] NR_IRQS:396                                                                                                                                │············································································································
<6>[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz                                                                                         │············································································································
<4>[    0.000000] omap_hwmod: i2c1: softreset failed (waited 10000 usec)                                                                                     │············································································································
<4>[    0.000000] omap_hwmod: i2c2: softreset failed (waited 10000 usec)                                                                                     │············································································································
<4>[    0.000000] omap_hwmod: i2c3: softreset failed (waited 10000 usec)                                                                                     │············································································································
<6>[    0.000000] Reprogramming SDRC clock to 332000000 Hz                                                                                                   │············································································································
<3>[    0.000000] dpll3_m2_clk rate change failed: -22                                                                                                       │············································································································
<6>[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts                                                                         │············································································································
<6>[    0.000000] Total of 96 interrupts on 1 active controller                                                                                              │············································································································
<6>[    0.000000] GPMC revision 5.0                                                                                                                          │············································································································
<4>[    0.000000] Trying to install interrupt handler for IRQ388                                                                                             │············································································································
<4>[    0.000000] Trying to install interrupt handler for IRQ389                                                                                             │············································································································
<4>[    0.000000] Trying to install interrupt handler for IRQ390                                                                                             │············································································································
<4>[    0.000000] Trying to install interrupt handler for IRQ391                                                                                             │············································································································
<4>[    0.000000] Trying to install interrupt handler for IRQ392                                                                                             │············································································································
<4>[    0.000000] Trying to install interrupt handler for IRQ393                                                                                             │············································································································
<4>[    0.000000] Trying to install interrupt handler for IRQ394                                                                                             │············································································································
<4>[    0.000000] Trying to install interrupt handler for IRQ395                                                                                             │············································································································
<6>[    0.000000] OMAP clockevent source: GPTIMER2 at 13000000 Hz                                                                                            │············································································································
<6>[    0.000000] I-pipe, 13.000 MHz clocksource                                                                                                             │············································································································
<6>[    0.000000] I-pipe 1.18-03: pipeline enabled.         

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/24/2012 07:32 PM, Wayne Warren wrote:
> We decided to try to continue debugging our current branch for another
> day or two.
> 
> We thought to check the link register just as execution enters
> __dabt_srv and found that the data abort exception occurs in an
> interrupt handler called from __int_svc, which is why we thought it was
> occurring on the cpsie instruction...actually, an interrupt seems to
> have occurred just as interrupts were enabled. The backtrace from the
> breakpoint in the function found using the LR value at __dabt_svc is:
> 
> (gdb) bt                                                                                                                                                     │············································································································
> #0  __ipipe_tsc_update () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/ipipe_tsc.c:123                                                 │············································································································
> #1  0xc0059ac0 in omap2_gp_timer_interrupt (irq=38, dev_id=0xc07e4ba0) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/mach-omap2/timer-gp.c:77  │············································································································
> #2  0xc00c0bb0 in handle_IRQ_event (irq=38, action=0xc0634038) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/irq/handle.c:68                     │············································································································
> #3  0xc00c3378 in handle_level_irq (irq=38, desc=0xc07a68c8) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/irq/chip.c:529                        │············································································································
> #4  0xc003f044 in asm_do_IRQ (irq=38, regs=<value optimized out>) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/include/linux/irqdesc.h:125             │············································································································
> #5  0xc00c57c8 in __ipipe_sync_stage () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/kernel/ipipe/core.c:1284                                          │············································································································
> #6  0xc005280c in __ipipe_grab_irq (irq=38, regs=0xc062df80) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/ipipe.c:605                  │············································································································
> #7  0xc04868f8 in __irq_svc ()                                                                                                                               │············································································································
> Backtrace stopped: frame did not save the PC       
> 
> This shows that the backtrace occurs in __ipipe_tsc_update.
> Specifically, it occurs when a "BLX" instruction is called on a register
> holding an address that points to no function in particular. I believe
> this is because the function __ipipe_tsc_get (called in
> __ipipe_tsc_update) is not defined.
> 
> CONFIG_IPIPE_ARM_KUSER_TSC is set to 'y' by default since CONFIG_OMAP is
> selected, so it seems that __ipipe_tsc_get is not mapped to
> __ipipe_mach_get_tsc by the preprocessor macro in
> arc/arm/include/asm/ipipe.h, near line 340. 
> 
> __ipipe_mach_get_tsc is something that the ArmPorting guide you linked
> me to a couple weeks ago mentions as needing to be defined, yet it
> appears because CONFIG_IPIPE_ARM_KUSER_TSC is defined, it wouldn't
> matter.
> 
> Do you have any suggestions? For now I think I will work on the
> __ipipe_mach_get_tsc function and force CONFIG_IPIPE_ARM_KUSER_TSC=n.

What you need is __ipipe_tsc_register to be called before any call to
__ipipe_tsc_update.

__ipipe_tsc_get is supposed to be defined to be something like 0xffff0f40

Or apply the following patch:
http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=42dd9056983cb6f65b6a336363f2f08f4426625a;hp=3b51cebda0b0d0123cb61b6ec07ecb62f293a528
-- 
					    Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

> 
> What you need is __ipipe_tsc_register to be called before any call to
> __ipipe_tsc_update.

This breakpoint is definitely hit before the __ipipe_tsc_update
breakpoint:

Breakpoint 8, __ipipe_tsc_register (info=0xc0634108) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/ipipe_tsc.c:45
45              switch(info->type) { 
(gdb) bt                                                                                                                              
#0  __ipipe_tsc_register (info=0xc0634108) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/ipipe_tsc.c:45          
#1  0xc001121c in omap2_gp_timer_init () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/mach-omap2/timer-gp.c:274       
#2  0xc000cae4 in time_init () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/time.c:163                          
#3  0xc0008b5c in start_kernel () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/init/main.c:617                          
#4  0x80008034 in ?? ()    


> 
> __ipipe_tsc_get is supposed to be defined to be something like 0xffff0f40

   │0xc0052ca4 <__ipipe_tsc_update+88>      ldr    r3, [pc, #36]   ; 0xc0052cd0 <__ipipe_tsc_update+132>
  >│0xc0052ca8 <__ipipe_tsc_update+92>      blx    r3                                                   
   │0xc0052cac <__ipipe_tsc_update+96>      ldr    r3, [pc, #24]   ; 0xc0052ccc <__ipipe_tsc_update+128>    

(gdb) info reg r3                                                         
r3             0xffff0f40       4294905664                                
(gdb) disassemble 0xffff0f40                                              
No function contains specified address.                                   
(gdb) x 0xffff0f40                                                        
0xffff0f40:     0xe51f000c                                                
(gdb) focus cmd                                                           
Focus set to CMD window.                                                  
(gdb) x /10                                                               
0xffff0f40:     0xe51f000c      0xe14f22dc      0xe5900000      0xe1520000
0xffff0f50:     0xe2a31000      0xe12fff1e      0xe1a00000      0xe1a00000
0xffff0f60:     0x00000000      0x00000000                                                                                                                   
(gdb)                        

So it looks like maybe __ipipe_tsc_get is working as expected? 
                      
> 
> Or apply the following patch:
> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=42dd9056983cb6f65b6a336363f2f08f4426625a;hp=3b51cebda0b0d0123cb61b6ec07ecb62f293a528

I will try this out, thanks!

Wayne

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/24/2012 07:36 PM, Wayne Warren wrote:
> By the way...
> 
> The dmesg function in Documentation/kdump/gdbmacros.txt is very slow
> about printing out the log buffer, so we figured out a somewhat hackish
> way to get the current log_buffer contents faster. This example assumes
> that the value of "logged_chars" is 3513:
> 
> (gdb) printf "%.3513s", log_buf
> <5>[    0.000000] Linux version 2.6.37.6+ (wayne@ENG-09-LX) (gcc version 4.3.1 (GCC) ) #31 Wed Oct 24 09:17:39 CDT 2012                                      │············································································································
> <4>[    0.000000] CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7f                                                                            │············································································································
> <4>[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache                                                                       │············································································································
> <4>[    0.000000] Machine: EMAC SOM-3517                                                                                                                     │············································································································
> <6>[    0.000000] Reserving 4194304 bytes SDRAM for VRAM                                                                                                     │············································································································
> <4>[    0.000000] Memory policy: ECC disabled, Data cache writeback                                                                                          │············································································································
> <6>[    0.000000] AM3517 ES1.1 (l2cache sgx neon isp )                                                                                                       │············································································································
> <6>[    0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000                                                                                  │············································································································
> <7>[    0.000000] On node 0 totalpages: 64512                                                                                                                │············································································································
> <7>[    0.000000] free_area_init_node: node 0, pgdat c07e060c, node_mem_map c0d95000                                                                         │············································································································
> <7>[    0.000000]   Normal zone: 512 pages used for memmap                                                                                                   │············································································································
> <7>[    0.000000]   Normal zone: 0 pages reserved                                                                                                            │············································································································
> <7>[    0.000000]   Normal zone: 64000 pages, LIFO batch:15                                                                                                  │············································································································
> <7>[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768                                                                                              │············································································································
> <7>[    0.000000] pcpu-alloc: [0] 0                                                                                                                          │············································································································
> <4>[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64000                                                                 │············································································································
> <5>[    0.000000] Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait                                                │············································································································
> <6>[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)                                                                                        │············································································································
> <6>[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)                                                                            │············································································································
> <6>[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)                                                                              │············································································································
> <6>[    0.000000] Memory: 252MB = 252MB total                                                                                                                │············································································································
> <5>[    0.000000] Memory: 241840k/241840k available, 20304k reserved, 0K highmem                                                                             │············································································································
> <5>[    0.000000] Virtual kernel memory layout:                                                                                                              │············································································································
> <5>[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)                                                                                          │············································································································
> <5>[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)                                                                                          │············································································································
> <5>[    0.000000]     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)                                                                                          │············································································································
> <5>[    0.000000]     vmalloc : 0xd0800000 - 0xf8000000   ( 632 MB)                                                                                          │············································································································
> <5>[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)                                                                                          │············································································································
> <5>[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)                                                                                          │············································································································
> <5>[    0.000000]       .init : 0xc0008000 - 0xc003f000   ( 220 kB)                                                                                          │············································································································
> <5>[    0.000000]       .text : 0xc003f000 - 0xc062b828   (6067 kB)                                                                                          │············································································································
> <5>[    0.000000]       .data : 0xc062c000 - 0xc07e4920   (1763 kB)                                                                                          │············································································································
> <6>[    0.000000] NR_IRQS:396                                                                                                                                │············································································································
> <6>[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz                                                                                         │············································································································
> <4>[    0.000000] omap_hwmod: i2c1: softreset failed (waited 10000 usec)                                                                                     │············································································································
> <4>[    0.000000] omap_hwmod: i2c2: softreset failed (waited 10000 usec)                                                                                     │············································································································
> <4>[    0.000000] omap_hwmod: i2c3: softreset failed (waited 10000 usec)                                                                                     │············································································································
> <6>[    0.000000] Reprogramming SDRC clock to 332000000 Hz                                                                                                   │············································································································
> <3>[    0.000000] dpll3_m2_clk rate change failed: -22                                                                                                       │············································································································
> <6>[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts                                                                         │············································································································
> <6>[    0.000000] Total of 96 interrupts on 1 active controller                                                                                              │············································································································
> <6>[    0.000000] GPMC revision 5.0                                                                                                                          │············································································································
> <4>[    0.000000] Trying to install interrupt handler for IRQ388                                                                                             │············································································································
> <4>[    0.000000] Trying to install interrupt handler for IRQ389                                                                                             │············································································································
> <4>[    0.000000] Trying to install interrupt handler for IRQ390                                                                                             │············································································································
> <4>[    0.000000] Trying to install interrupt handler for IRQ391                                                                                             │············································································································
> <4>[    0.000000] Trying to install interrupt handler for IRQ392                                                                                             │············································································································
> <4>[    0.000000] Trying to install interrupt handler for IRQ393                                                                                             │············································································································
> <4>[    0.000000] Trying to install interrupt handler for IRQ394                                                                                             │············································································································
> <4>[    0.000000] Trying to install interrupt handler for IRQ395                                                                                             │············································································································
> <6>[    0.000000] OMAP clockevent source: GPTIMER2 at 13000000 Hz                                                                                            │············································································································
> <6>[    0.000000] I-pipe, 13.000 MHz clocksource                                                                                                             │············································································································
> <6>[    0.000000] I-pipe 1.18-03: pipeline enabled.         

So, I-pipe tsc not registered, this fits the bill.

-- 
					    Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/24/2012 07:55 PM, Wayne Warren wrote:
> 
>>
>> What you need is __ipipe_tsc_register to be called before any call to
>> __ipipe_tsc_update.
> 
> This breakpoint is definitely hit before the __ipipe_tsc_update
> breakpoint:
> 
> Breakpoint 8, __ipipe_tsc_register (info=0xc0634108) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/ipipe_tsc.c:45
> 45              switch(info->type) { 
> (gdb) bt                                                                                                                              
> #0  __ipipe_tsc_register (info=0xc0634108) at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/ipipe_tsc.c:45          
> #1  0xc001121c in omap2_gp_timer_init () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/mach-omap2/timer-gp.c:274       
> #2  0xc000cae4 in time_init () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/arch/arm/kernel/time.c:163                          
> #3  0xc0008b5c in start_kernel () at /home/wayne/src/linux/linux-2.6.37-3517-xenomai/init/main.c:617                          
> #4  0x80008034 in ?? ()    
> 
> 
>>
>> __ipipe_tsc_get is supposed to be defined to be something like 0xffff0f40
> 
>    │0xc0052ca4 <__ipipe_tsc_update+88>      ldr    r3, [pc, #36]   ; 0xc0052cd0 <__ipipe_tsc_update+132>
>   >│0xc0052ca8 <__ipipe_tsc_update+92>      blx    r3                                                   
>    │0xc0052cac <__ipipe_tsc_update+96>      ldr    r3, [pc, #24]   ; 0xc0052ccc <__ipipe_tsc_update+128>    
> 
> (gdb) info reg r3                                                         
> r3             0xffff0f40       4294905664                                
> (gdb) disassemble 0xffff0f40                                              
> No function contains specified address.                                   
> (gdb) x 0xffff0f40                                                        
> 0xffff0f40:     0xe51f000c                                                
> (gdb) focus cmd                                                           
> Focus set to CMD window.                                                  
> (gdb) x /10                                                               
> 0xffff0f40:     0xe51f000c      0xe14f22dc      0xe5900000      0xe1520000
> 0xffff0f50:     0xe2a31000      0xe12fff1e      0xe1a00000      0xe1a00000
> 0xffff0f60:     0x00000000      0x00000000                                                                                                                   
> (gdb)                        
> 
> So it looks like maybe __ipipe_tsc_get is working as expected? 

Yes, the debugger can not know what is at 0xffff0f40 because the code
copied there is not known at compilation (though you can run disass
*0xffff0f40, this should work). __ipipe_tsc_register does copy the
actual code, but before __ipipe_tsc_register copies the code, the code
there simply returns r0 and r1 set to 0.

You should try and put a breakpoint at 0xffff040 to see what address is
invalid. Maybe the counter virtual address is invalid, or the access to
the timer register because the timer is not enabled yet at hardware level.

>                       
>>
>> Or apply the following patch:
>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=42dd9056983cb6f65b6a336363f2f08f4426625a;hp=3b51cebda0b0d0123cb61b6ec07ecb62f293a528
> 
> I will try this out, thanks!

It will probably not fix this issue, but it is better to start from that
code anyway.

-- 
					    Gilles.

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Wayne Warren]

  
> > 
> > So it looks like maybe __ipipe_tsc_get is working as expected? 
> 
> Yes, the debugger can not know what is at 0xffff0f40 because the code
> copied there is not known at compilation (though you can run disass
> *0xffff0f40, this should work). __ipipe_tsc_register does copy the
> actual code, but before __ipipe_tsc_register copies the code, the code
> there simply returns r0 and r1 set to 0.
> 
> You should try and put a breakpoint at 0xffff040 to see what address is
> invalid. Maybe the counter virtual address is invalid, or the access to
> the timer register because the timer is not enabled yet at hardware level.
> 

disass *0xffff0f40 did not work, "No function contains specified
address."

So in other words, you are saying that if __ipipe_tsc_register had not
registered the code, the exception would not occur because it would
simply set r0 and r1 to 0 then return to the calling function? Just want
to be certain I understand...

I did try to put a breakpoint at 0xffff040 (but I think you meant
0xfff0f040, i tried both) but then I get "Warning: Cannot insert
breakpoint 10. Error accessing memory address 0xffff040: Unknown error".

> >                       
> >>
> >> Or apply the following patch:
> >> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=42dd9056983cb6f65b6a336363f2f08f4426625a;hp=3b51cebda0b0d0123cb61b6ec07ecb62f293a528
> > 
> > I will try this out, thanks!
> 
> It will probably not fix this issue, but it is better to start from that
> code anyway.
> 

Okay, just to be clear are you suggesting that we start all over with
this patch, merge in the TI changes and our own code, and begin
debugging again from there?

Re: [Xenomai] Adeos I-Pipe patch problem on vendor-specific kernel

[Gilles Chanteperdrix]

On 10/24/2012 08:26 PM, Wayne Warren wrote:
>   
>>>
>>> So it looks like maybe __ipipe_tsc_get is working as expected? 
>>
>> Yes, the debugger can not know what is at 0xffff0f40 because the code
>> copied there is not known at compilation (though you can run disass
>> *0xffff0f40, this should work). __ipipe_tsc_register does copy the
>> actual code, but before __ipipe_tsc_register copies the code, the code
>> there simply returns r0 and r1 set to 0.
>>
>> You should try and put a breakpoint at 0xffff040 to see what address is
>> invalid. Maybe the counter virtual address is invalid, or the access to
>> the timer register because the timer is not enabled yet at hardware level.
>>
> 
> disass *0xffff0f40 did not work, "No function contains specified
> address."

Sorry, it is disass /r 0xffff0f20,+0x60

For instance, I have, in user-space, with the I-pipe core for Linux 3.4
on omap3 (where __ipipe_tsc_get shifted a bit), but it should work the
same for the kernel:

(gdb) disass /r 0xffff0ee0,+0x60
Dump of assembler code from 0xffff0ee0 to 0xffff0f40:
   0xffff0ee0:   3b 48 8f 8c    stchi   8, cr4, [pc], {59}      ; 0x3b
   0xffff0ee4:   ec 01 00 00    andeq   r0, r0, r12, ror #3
   0xffff0ee8:   00 00 00 00    andeq   r0, r0, r0
   0xffff0eec:   00 00 00 00    andeq   r0, r0, r0
   0xffff0ef0:   00 00 00 00    andeq   r0, r0, r0
   0xffff0ef4:   00 00 00 00    andeq   r0, r0, r0
   0xffff0ef8:   00 00 00 00    andeq   r0, r0, r0
   0xffff0efc:   28 20 03 fb    blx     0xb8fa6
   0xffff0f00:   0c 00 1f e5    ldr     r0, [pc, #-12]  ; 0xffff0efc
   0xffff0f04:   dc 22 4f e1    ldrd    r2, [pc, #-44]  ; 0xffff0ee0
   0xffff0f08:   00 00 90 e5    ldr     r0, [r0]
   0xffff0f0c:   00 00 52 e1    cmp     r2, r0
   0xffff0f10:   00 10 a3 e2    adc     r1, r3, #0
   0xffff0f14:   1e ff 2f e1    bx      lr
   0xffff0f18:   00 f0 20 e3    nop     {0}
   0xffff0f1c:   00 f0 20 e3    nop     {0}
   0xffff0f20:   00 00 00 00    andeq   r0, r0, r0
   0xffff0f24:   00 00 00 00    andeq   r0, r0, r0
   0xffff0f28:   00 00 00 00    andeq   r0, r0, r0
   0xffff0f2c:   00 00 00 00    andeq   r0, r0, r0
   0xffff0f30:   00 00 00 00    andeq   r0, r0, r0
   0xffff0f34:   00 00 00 00    andeq   r0, r0, r0
   0xffff0f38:   00 00 00 00    andeq   r0, r0, r0
   0xffff0f3c:   00 00 00 00    andeq   r0, r0, r0

The range from 0xffff0ee0 to 0xffff0ef8 is really data, not code.
The hardware timer virtual address is at 0xffff0efc, so it is
0xfb032028
The 64 bits value at 0xffff0ee0 is where __ipipe_tsc_update stored the
value of __ipipe_tsc_get when it was last called.


> 
> So in other words, you are saying that if __ipipe_tsc_register had not
> registered the code, the exception would not occur because it would
> simply set r0 and r1 to 0 then return to the calling function? Just want
> to be certain I understand...
> 
> I did try to put a breakpoint at 0xffff040 (but I think you meant
> 0xfff0f040, i tried both) but then I get "Warning: Cannot insert
> breakpoint 10. Error accessing memory address 0xffff040: Unknown error".

That is where you need *, so, try break *0xffff0f40, yes 0xffff040 was a
typo.

> 
>>>                       
>>>>
>>>> Or apply the following patch:
>>>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=42dd9056983cb6f65b6a336363f2f08f4426625a;hp=3b51cebda0b0d0123cb61b6ec07ecb62f293a528
>>>
>>> I will try this out, thanks!
>>
>> It will probably not fix this issue, but it is better to start from that
>> code anyway.
>>
> 
> Okay, just to be clear are you suggesting that we start all over with
> this patch, merge in the TI changes and our own code, and begin
> debugging again from there?

No, the patch should not have any dependency, so, you should be able to
apply it without any problem.

-- 
					    Gilles.