[Bug 1001572] New: Separate FIQ and IRQ management

[Bug 1001572] New: Separate FIQ and IRQ management

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001572

           Summary: Separate FIQ and IRQ management
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: ARM
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: HAL
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: nickg@ecoscentric.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1712)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1712)
FIQ patch

This patch implements the separation of FIQ and IRQ in eCos critical sections.
The default is to continue disabling both FIQ and IRQ as at present. If
CYGOPT_HAL_ARM_FIQ_DISABLE is switched off then eCos will only manipulate IRQs
in HAL_DISABLE|ENABLE|RESTORE_INTERRUPTS FIQs will be untouched. This puts FIQs
entirely outside eCos, they cannot interact with the kernel through standard
means, and any FIQ handler must be written to run directly from the VSR, it
cannot be installed via the usual interrupt API.

To make FIQs easy to control, if FIQ and IRQ are separated, a set of FIQ
control macros, HAL_DISABLE|ENABLE|RESTORE|QUERY_FIQ, are enabled.


I'll check this in in a few days if nobody has any objections.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001572] Separate FIQ and IRQ management

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001572

--- Comment #1 from Nick Garnett <nickg@ecoscentric.com> 2012-04-23 17:29:42 BST ---
Created an attachment (id=1713)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1713)
EA2468 FIQ test


This is a companion patch to the architecture FIQ patch. It adds a FIQ test
program to the EA2468 HAL which allows FIQs to be delivered via the EINT0
push-button.

In addition to the FIQ test this patch also moves the fixed_vectors section in
the LDI files. This is necessary to place the VSR table in the correct place
for the hardware, otherwise the FIQ VSR cannot be installed properly. 

Note that this patch makes new builds incompatible with a RedBoot built with
the previous layout. So, if anyone is especially concerned about this, speak up
and I'll not commit it.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001572] Separate FIQ and IRQ management

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001572

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com
             Blocks|                            |1001160

--- Comment #2 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-23 20:38:25 BST ---
I notice that FUNC_START_ARM does not put the new functions in a different
section, so they won't be GC'd, so will be in all programs, whether used or
not. It looks like I was going to do something about this in the eCosCentric
sources, but then it seems I commented it out (changeset 371380826e8c). Hmm,
can't remember why now.

Thanks for incorporating the fix from bug 1001160.

But that bug also mentions a third possibility, that it might be useful for
some users to do their own FIQ handling (and not use the FIQ->IRQ kludge), but
for FIQs to still be disabled when handling IRQs. This can have benefits for
some people. In particular, you would no longer need a separate FIQ interrupt
stack, but could share one with IRQ again, which could be an important memory
saver.

I think all it would need is one more CDL option controlling the CPSR_INTR_MASK
define, which CYGOPT_HAL_ARM_FIQ_DISABLE can use 'requires' on to set. And also
then that lets us avoid defining __fiq_stack in that case. Thoughts?

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001572] Separate FIQ and IRQ management

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001572

--- Comment #3 from Nick Garnett <nickg@ecoscentric.com> 2012-04-24 10:53:38 BST ---
(In reply to comment #2)
> I notice that FUNC_START_ARM does not put the new functions in a different
> section, so they won't be GC'd, so will be in all programs, whether used or
> not. It looks like I was going to do something about this in the eCosCentric
> sources, but then it seems I commented it out (changeset 371380826e8c). Hmm,
> can't remember why now.

That is true of a number of asm utility routines. Something for a different
checkin to deal with.



> Thanks for incorporating the fix from bug 1001160.

Frankly, I had forgotten that was the source of that particular change.


> But that bug also mentions a third possibility, that it might be useful for
> some users to do their own FIQ handling (and not use the FIQ->IRQ kludge), but
> for FIQs to still be disabled when handling IRQs. This can have benefits for
> some people. In particular, you would no longer need a separate FIQ interrupt
> stack, but could share one with IRQ again, which could be an important memory
> saver.
> 
> I think all it would need is one more CDL option controlling the CPSR_INTR_MASK
> define, which CYGOPT_HAL_ARM_FIQ_DISABLE can use 'requires' on to set. And also
> then that lets us avoid defining __fiq_stack in that case. Thoughts?

I'm not convinced. It seems to be a rather nasty subversion of the way in which
the architecture is intended to work. I suspect that the IRQ entry code would
need to be rejigged a little to ensure there are no races.

For now I think we want to check this in as it stands. If there is any demand
for what you suggest above then it can be added at a later date.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001572] Separate FIQ and IRQ management

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001572

Nick Garnett <nickg@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #4 from Nick Garnett <nickg@ecoscentric.com> 2012-05-11 11:35:45 BST ---

Now checked in

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 1001572] New: Separate FIQ and IRQ management

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001572

           Summary: Separate FIQ and IRQ management
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: ARM
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: HAL
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: nickg@ecoscentric.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1712)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1712)
FIQ patch

This patch implements the separation of FIQ and IRQ in eCos critical sections.
The default is to continue disabling both FIQ and IRQ as at present. If
CYGOPT_HAL_ARM_FIQ_DISABLE is switched off then eCos will only manipulate IRQs
in HAL_DISABLE|ENABLE|RESTORE_INTERRUPTS FIQs will be untouched. This puts FIQs
entirely outside eCos, they cannot interact with the kernel through standard
means, and any FIQ handler must be written to run directly from the VSR, it
cannot be installed via the usual interrupt API.

To make FIQs easy to control, if FIQ and IRQ are separated, a set of FIQ
control macros, HAL_DISABLE|ENABLE|RESTORE|QUERY_FIQ, are enabled.


I'll check this in in a few days if nobody has any objections.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001572] Separate FIQ and IRQ management

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001572

--- Comment #1 from Nick Garnett <nickg@ecoscentric.com> 2012-04-23 17:29:42 BST ---
Created an attachment (id=1713)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1713)
EA2468 FIQ test


This is a companion patch to the architecture FIQ patch. It adds a FIQ test
program to the EA2468 HAL which allows FIQs to be delivered via the EINT0
push-button.

In addition to the FIQ test this patch also moves the fixed_vectors section in
the LDI files. This is necessary to place the VSR table in the correct place
for the hardware, otherwise the FIQ VSR cannot be installed properly. 

Note that this patch makes new builds incompatible with a RedBoot built with
the previous layout. So, if anyone is especially concerned about this, speak up
and I'll not commit it.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001572] Separate FIQ and IRQ management

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001572

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com
             Blocks|                            |1001160

--- Comment #2 from Jonathan Larmour <jifl@ecoscentric.com> 2012-04-23 20:38:25 BST ---
I notice that FUNC_START_ARM does not put the new functions in a different
section, so they won't be GC'd, so will be in all programs, whether used or
not. It looks like I was going to do something about this in the eCosCentric
sources, but then it seems I commented it out (changeset 371380826e8c). Hmm,
can't remember why now.

Thanks for incorporating the fix from bug 1001160.

But that bug also mentions a third possibility, that it might be useful for
some users to do their own FIQ handling (and not use the FIQ->IRQ kludge), but
for FIQs to still be disabled when handling IRQs. This can have benefits for
some people. In particular, you would no longer need a separate FIQ interrupt
stack, but could share one with IRQ again, which could be an important memory
saver.

I think all it would need is one more CDL option controlling the CPSR_INTR_MASK
define, which CYGOPT_HAL_ARM_FIQ_DISABLE can use 'requires' on to set. And also
then that lets us avoid defining __fiq_stack in that case. Thoughts?

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001572] Separate FIQ and IRQ management

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001572

--- Comment #3 from Nick Garnett <nickg@ecoscentric.com> 2012-04-24 10:53:38 BST ---
(In reply to comment #2)
> I notice that FUNC_START_ARM does not put the new functions in a different
> section, so they won't be GC'd, so will be in all programs, whether used or
> not. It looks like I was going to do something about this in the eCosCentric
> sources, but then it seems I commented it out (changeset 371380826e8c). Hmm,
> can't remember why now.

That is true of a number of asm utility routines. Something for a different
checkin to deal with.



> Thanks for incorporating the fix from bug 1001160.

Frankly, I had forgotten that was the source of that particular change.


> But that bug also mentions a third possibility, that it might be useful for
> some users to do their own FIQ handling (and not use the FIQ->IRQ kludge), but
> for FIQs to still be disabled when handling IRQs. This can have benefits for
> some people. In particular, you would no longer need a separate FIQ interrupt
> stack, but could share one with IRQ again, which could be an important memory
> saver.
> 
> I think all it would need is one more CDL option controlling the CPSR_INTR_MASK
> define, which CYGOPT_HAL_ARM_FIQ_DISABLE can use 'requires' on to set. And also
> then that lets us avoid defining __fiq_stack in that case. Thoughts?

I'm not convinced. It seems to be a rather nasty subversion of the way in which
the architecture is intended to work. I suspect that the IRQ entry code would
need to be rejigged a little to ensure there are no races.

For now I think we want to check this in as it stands. If there is any demand
for what you suggest above then it can be added at a later date.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001572] Separate FIQ and IRQ management

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001572

Nick Garnett <nickg@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |CURRENTRELEASE

--- Comment #4 from Nick Garnett <nickg@ecoscentric.com> 2012-05-11 11:35:45 BST ---

Now checked in

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.