[ECOS] timer alarm or any timer in Redboot

[ECOS] timer alarm or any timer in Redboot

[Jacob Avraham]

Hi,

Does Redboot support an alarm timer, or any timer for that matter,
that I can use to toggle a LED while Redboot is booting?
I'm not asking about the delay timer, I need an asynchronous timer.

Thanks,

Jacob

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

Re: [ECOS] timer alarm or any timer in Redboot

[Andrew Lunn]

> Does Redboot support an alarm timer, or any timer for that matter,
> that I can use to toggle a LED while Redboot is booting?
> I'm not asking about the delay timer, I need an asynchronous timer.

Interrupts are not running, you don't have a kernel. So no.

The nearest you have is that Redboot has a poll loop. When redboot has
nothing to do, it calls do_idle() which calls a list of idle
functions. You could hook this and blink your LED. But by the time
this is being called, booting is over. Redboot is running.

           Andrew

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

[ECOS] Notification of changes required for CPU support

[Scott Moore]

 
Although we are not ready yet to commit changes, I thought it
would be good if we would give an overview of changes required
to support a new processor/processor board combination under
ecos, and get feedback on what the form of the changes should
be before putting that back to the ecos project.

The lpc2xxx series from NXP (formerly Phillips) has proceeded
through the lpc21xx and lpc22xx series to the current lpc23xx
series. The board we are working with is the MCB2300 available
from Keil. The current support under ecos is the MCB2100 board.

Unfortunately, unlike what the lpc2xxx directory tree under
ecos implies, the lpc23xx series processors aren't in fact
compatible with the lpc21xx and lpc22xx series. The method
of handling interrupts changed. The lpc2xxx series is downward
compatable with the ARM convention of a single IRQ vector at
location $28 in that the vector automatically selected by the
processor is placed in a register, which the instruction at
$28 can move to the PC, thus accomplishing a vectored
interrupt. This is downward compatible with ARM general
conventions, because if the code ignores the automatic vectoring
and simply proceeds to the the IRQ handler code from $28,
the code will function, but simply not benefit from the
automatic vectoring.

The lpc2xxx code in ecos ignores the automatic vectoring, but
uses the lpc2xxx autovectoring hardware to automatically
determine which logical vector (from 0-15) is being serviced.
This is then passed to the IRQ service code when it reaches
the point it needs to find the vector number, so that it can
look it up in the hal_interrupt_data and hal_interrupt_handlers
tables.

Since the lpc2xxx/var code depends on the hardware vectoring
in this way, and also because the number of interrupts servicable
by the CPU increase from 16 to 32, and because of other minor
ways the interrupt handling changes, the lpc2xx/var code must
change for the lpc23xx processors.

Here is a list of the files that required changes:

../hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.c
../hal/arm/lpc2xxx/var/current/include/var_io.h

This gets us going, but clearly creates a conflict in ecos, 
since the lpc2xxx tree no longer supports all processors in the
series.

I'm open to suggestions about what to do about that before trying
to put it back to ecos. The possibilities are:

1. Break the lpc2xxx tree into lpc21xx_lpc22xx and lpc23xx trees.

2. Have the lpc2xxx code automatically configure per the processor.

Other?

Right now, I am just hacking up the lpc2xxx series to get our stuff
running without regard for lpc21xx and lpc22xx backwards compatibility.

Hey, blame Phillips for creating an incompatibility in their own
series.

Scott Moore
Powerfile Inc.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


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

Re: [ECOS] Notification of changes required for CPU support

[Gary Thomas]

Scott Moore wrote:
>  
> Although we are not ready yet to commit changes, I thought it
> would be good if we would give an overview of changes required
> to support a new processor/processor board combination under
> ecos, and get feedback on what the form of the changes should
> be before putting that back to the ecos project.
> 
> The lpc2xxx series from NXP (formerly Phillips) has proceeded
> through the lpc21xx and lpc22xx series to the current lpc23xx
> series. The board we are working with is the MCB2300 available
> from Keil. The current support under ecos is the MCB2100 board.
> 
> Unfortunately, unlike what the lpc2xxx directory tree under
> ecos implies, the lpc23xx series processors aren't in fact
> compatible with the lpc21xx and lpc22xx series. The method
> of handling interrupts changed. The lpc2xxx series is downward
> compatable with the ARM convention of a single IRQ vector at
> location $28 in that the vector automatically selected by the
> processor is placed in a register, which the instruction at
> $28 can move to the PC, thus accomplishing a vectored
> interrupt. This is downward compatible with ARM general
> conventions, because if the code ignores the automatic vectoring
> and simply proceeds to the the IRQ handler code from $28,
> the code will function, but simply not benefit from the
> automatic vectoring.
> 
> The lpc2xxx code in ecos ignores the automatic vectoring, but
> uses the lpc2xxx autovectoring hardware to automatically
> determine which logical vector (from 0-15) is being serviced.
> This is then passed to the IRQ service code when it reaches
> the point it needs to find the vector number, so that it can
> look it up in the hal_interrupt_data and hal_interrupt_handlers
> tables.
> 
> Since the lpc2xxx/var code depends on the hardware vectoring
> in this way, and also because the number of interrupts servicable
> by the CPU increase from 16 to 32, and because of other minor
> ways the interrupt handling changes, the lpc2xx/var code must
> change for the lpc23xx processors.
> 
> Here is a list of the files that required changes:
> 
> ../hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.c
> ../hal/arm/lpc2xxx/var/current/include/var_io.h
> 
> This gets us going, but clearly creates a conflict in ecos, 
> since the lpc2xxx tree no longer supports all processors in the
> series.
> 
> I'm open to suggestions about what to do about that before trying
> to put it back to ecos. The possibilities are:
> 
> 1. Break the lpc2xxx tree into lpc21xx_lpc22xx and lpc23xx trees.
> 
> 2. Have the lpc2xxx code automatically configure per the processor.
> 
> Other?
> 
> Right now, I am just hacking up the lpc2xxx series to get our stuff
> running without regard for lpc21xx and lpc22xx backwards compatibility.
> 
> Hey, blame Phillips for creating an incompatibility in their own
> series.

How similar are the processor(s), apart from the interrupt
handling difference you've pointed out?

My preference would be to keep the tree as it is and add
a CDL option which describes the processor.  The code you've
pointed to can then have conditional support based on this
CDL.  Precedent for this would be the PowerPC (e.g. not all
8xx processors are the same, but they are close enough to
have a common HAL) and SH (again a myriad of variants)
Have a look at how those HALs handle this.  Once you have
something that works, propose it on ecos-patches and we
can discuss making these changes to the common CVS.


-- 
------------------------------------------------------------
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

RE: [ECOS] Notification of changes required for CPU support

[Scott Moore]

>How similar are the processor(s), apart from the interrupt handling difference you've pointed out?

>My preference would be to keep the tree as it is and add a CDL option which describes the processor.
>The code you've pointed to can then have conditional support based on this CDL.  Precedent for this
>would be the PowerPC (e.g. not all 8xx processors are the same, but they are close enough to have a
>common HAL) and SH (again a myriad of variants) Have a look at how those HALs handle this.  Once you
>have something that works, propose it on ecos-patches and we can discuss making these changes to the 
>common CVS.

Well, I don't have ecos running on the MCB2300 as yet, but the processors appear to be very
similar, and besides the interrupt changes there is only a clocking setup change. There are some
changes for the MCB2300 as well, so I suspect a different MCB2300 directory is justified.

Scott Moore
Powerfile Inc.

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

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


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

Re: [ECOS] Notification of changes required for CPU support

[Hans Rosenfeld]

On Wed, Aug 29, 2007 at 02:46:32PM -0400, Scott Moore wrote:
> Right now, I am just hacking up the lpc2xxx series to get our stuff
> running without regard for lpc21xx and lpc22xx backwards compatibility.
> 
> Hey, blame Phillips for creating an incompatibility in their own
> series.

Is this the only incompatibility? 

AFAIK the lpc23xx series uses a ARM9 core and has more (different)
on-chip peripherals and memory. I have currently no clue about that, but
I think that supporting the lpc23xx in a different tree would make sense
iff there more incompatibilities than just the interrupt stuff.

But renaming the lpc2xxx in lpc21xx_lpc22xx is something I wouldn't do.
I would just leave it as it is, adding a new CPU without disturbing any
old once.


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

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