* [ECOS] timer alarm or any timer in Redboot @ 2007-08-29 12:03 Jacob Avraham 2007-08-29 12:53 ` Andrew Lunn 0 siblings, 1 reply; 6+ messages in thread From: Jacob Avraham @ 2007-08-29 12:03 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] timer alarm or any timer in Redboot 2007-08-29 12:03 [ECOS] timer alarm or any timer in Redboot Jacob Avraham @ 2007-08-29 12:53 ` Andrew Lunn 2007-08-29 18:48 ` [ECOS] Notification of changes required for CPU support Scott Moore 0 siblings, 1 reply; 6+ messages in thread From: Andrew Lunn @ 2007-08-29 12:53 UTC (permalink / raw) To: Jacob Avraham; +Cc: ecos-discuss > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [ECOS] Notification of changes required for CPU support 2007-08-29 12:53 ` Andrew Lunn @ 2007-08-29 18:48 ` Scott Moore 2007-08-29 19:00 ` Gary Thomas 2007-08-29 19:29 ` Hans Rosenfeld 0 siblings, 2 replies; 6+ messages in thread From: Scott Moore @ 2007-08-29 18:48 UTC (permalink / raw) To: ecos-discuss; +Cc: Steve Gaskill 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Notification of changes required for CPU support 2007-08-29 18:48 ` [ECOS] Notification of changes required for CPU support Scott Moore @ 2007-08-29 19:00 ` Gary Thomas 2007-08-29 19:08 ` Scott Moore 2007-08-29 19:29 ` Hans Rosenfeld 1 sibling, 1 reply; 6+ messages in thread From: Gary Thomas @ 2007-08-29 19:00 UTC (permalink / raw) To: Scott Moore; +Cc: ecos-discuss, Steve Gaskill 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [ECOS] Notification of changes required for CPU support 2007-08-29 19:00 ` Gary Thomas @ 2007-08-29 19:08 ` Scott Moore 0 siblings, 0 replies; 6+ messages in thread From: Scott Moore @ 2007-08-29 19:08 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss, Steve Gaskill >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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Notification of changes required for CPU support 2007-08-29 18:48 ` [ECOS] Notification of changes required for CPU support Scott Moore 2007-08-29 19:00 ` Gary Thomas @ 2007-08-29 19:29 ` Hans Rosenfeld 1 sibling, 0 replies; 6+ messages in thread From: Hans Rosenfeld @ 2007-08-29 19:29 UTC (permalink / raw) To: Scott Moore; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-08-29 19:29 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-08-29 12:03 [ECOS] timer alarm or any timer in Redboot Jacob Avraham 2007-08-29 12:53 ` Andrew Lunn 2007-08-29 18:48 ` [ECOS] Notification of changes required for CPU support Scott Moore 2007-08-29 19:00 ` Gary Thomas 2007-08-29 19:08 ` Scott Moore 2007-08-29 19:29 ` Hans Rosenfeld
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).