This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LPC2XXX: Spurious Interrupts Issue


Sergei Gavrikov wrote:


On Sat, 3 Feb 2007, Gary Thomas wrote:

wang cui wrote:
Fine for me.
Does eCos maintainer read this? Is it worth to patch this into CVS?

Yes. Send a proposed patch to ecos-patches@sourceware.org and we'll review it.

They haven't to do such things for us. We have to do it. There is an evil for me in eCos world :) That is a copyright assignment. The $0.02 patches (a few lines of code) are welcome to CVS without any printer's sheets.

I brief look at my evening letter. It looks like that I have to read again
the Bart's 'The eCos Component Writer's Guide'. I have a doubt about
the name CYGSEM_HAL_ARM_VECTOR_0x14. It seems such a name is correct
for boolean values only. And CYGNUM_HAL_ARM_VECTOR_0x14 is a suitable
for numeric values (our case). Gary did suggest to name it CYGINT_ ...
But if I didn't forget that prefix is suitable for interfaces.

Gary, what is your view about CYG naming?

CYGNUM_HAL_ARM_VECTOR_0x14 is a better choice, use that.



Well, anybody from us has to make the final patch, test it on the LPC targets and then send it to ecos-patches list. If they will accept it, that will be okay for us.

Please do. This patch will be small enough to not worry about a copyright assignment (plus you got the ideas from me :-)




From: Sergei Gavrikov <w3sg@SoftHome.net>
To: wang cui <iucgnaw@msn.com>
CC: w3sg@SoftHome.net, ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] LPC2XXX: Spurious Interrupts Issue
Date: Sat, 3 Feb 2007 00:39:19 +0200 (EET)



On Fri, 2 Feb 2007, wang cui wrote:

Thanks, I brief look at the patch. You fix the LPC2XX vector table.
...
I raised discrssion about this issue serval months ago:
http://sources.redhat.com/ml/ecos-discuss/2006-08/msg00225.html I
think Gary's advice is a good solution, and I just havn't done it yet.
So still leave this piece of ugly code here. :-)

As I need burn the image into off-chip flash, so the ARM_VECTOR_0x14
should be set correctly without rely on burner.  Of cource, your
suggestion of do it with a script in "make" process is good, but how
about Redboot(I don't think modify Redboot's make process is
resonable)? And other newbies may be very hard to catch this
problem(because they can't find any info from CVS except search
maillist).

So I suggest to solve it in Gary's way. We add a CDL interface in ARM
arch package to allow user configure ARM_VECTOR_0x14, then add a CDL
implemention in LPC2XXX's variant package.

What is your opinion? Hope we can solve this issue.

I did miss that issue. I read, thanks, So, there is an inclusion of the <pkgconf/hal.h> at first in vector.S, therefore, to wrap 'unused' vector at 0x14 (as Gary suggested) by that condition in vector.S would be enough for everybody

    #ifdef CYGSEM_HAL_ARM_VECTOR_0x14
            .word   CYGSEM_HAL_ARM_VECTOR_0x14
    #else
            .word   0
    #endif

IMO, such a CDL option would be introduced in variant, that will
be in cyg/hal/hal_arm_lpc2xxx.h (= hal.h) then

    cdl_option CYGSEM_HAL_ARM_VECTOR_0x14 {
        display    "Default value of unused vector"
        flavor     data
        default_value <today value>
        description "
           In order to detect if a valid program is present, every
           user program must have a program signature. This signature
           is a word-wide number that is stored in the unused
           location in the ARM7 vector table at 0x00000014. The
           program signature is the two's compliment of the checksum
           of the ARM vector table."
    }

Gary pointed out then

    Gary> The other problem I see is that this may not
    Gary> be constant as you have made it.  Would it not
    Gary> change if the various other vector handlers move
    Gary> around, i.e.  if 'abort_data' changes address,
    Gary> etc?  Would it not need to be [re]calculated?

Well, we know that <cyg/hal/hal_platform_setup.h> include itself in
vector.S then (after hal.h), therefore, the target specific assembler
code would contain a commented note (at EOF), like a memory stick

    #if 0
    #undef CYGSEM_HAL_ARM_VECTOR_0x14
    // In order to detect if a valid program is present,
    // every user program must have a program signature. This
    // signature is a word-wide number that is stored
    // in the unused location in the ARM7 vector table
    // at 0x00000014. The program signature is the two's
    // compliment of the checksum of the ARM vector table.
    #define CYSEM_HAL_ARM_VECTOR_0x14 <tommorow value>
    #endif

In this case an advanced user would be overwrite that then without
reconfigure build tree.


--
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]