RE: [ECOS] Bootup and Redboot

["James Yates" <j dot yates at quartzuk dot com>]

Many Thanks for your help Gary. I will carry on looking into this.

The reasons for using a special bootloader are as follows:

The product I am working on is a successor to an existing slower board and so has to work in exactly the same way. All of our existing products are connected together by a custom variant of rs232 comms. Basically it is 38.4kBps Rs232 half duplex so all equipment is connected in a chain by standard coax cable. Our control product contains all of the config for the system associated with it and on boot up it passes relevant configuration to control panels by the above comms method.
We have a program, which is compatible with all our products where we can connect a pc to a serial port  and perform firmware upgrades from the PC to any piece of equipment in the chain. The box the pc is connected to becomes a dumb pass through product.
All products store their firmware in on-board flash. A bootloader is run on powerup which looks to see if the firmware is trying to be upgraded, it then checksums the firmware and if all is ok, it then copies this code to RAM and runs from there. If not, it sits waiting for valid firmware to be sent to it. This uses, and due to specification has to use the default bootloader for all our equipment. It's a pain but is a limitation imposed on me by the spec.

I will look further into my startup initialisation. 


		Thanks for your help.

			James Yates



-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: 29 October 2003 10:37
To: James Yates
Cc: Ecos Discuss
Subject: Re: [ECOS] Bootup and Redboot



James Yates said:
> I am currently trying to get a custom board up and running with eCos and I am have hit a brick
> wall. It seems that as soon as the scheduler is started and interrupts are enabled, and the
> installed RTC causes and Interrupt, and exception is raised and the code dies. I believe the
> problem is with the Vector table/VSR table but can't figure out why.
>
> I assume that the each entry in the Vector table, the entry point for each available ISR, should
> point to the default VSR handler which then looks up to see if an interrupt has been attached to
> this and if so then call the relevant ISR.
> I am not running Redboot since I am required to use a custom bootloader. Am I right in saying that
> Redboot sets up the Vector table correctlt and so my bootloader should do the same. On startup,
> before the scheduler is started, I print out the vector table pointed to by the VBR.
> The first 32 entries correctly point at the default_exception_vsr but the entries for peripheral
> Interrupts don't seem to point to anything valid. So I initialise as part of the platform init
> these entries to point to the default VSR handler. Is this correct? I am really stuck and don't
> know where to go from here.  This is running on an SH2 platform.
>

The way most architectures work is that the hardware interrupt/exception
mechanism (pointed to by a VBR or other hardware) chooses which code to
execute when an exception or interrupt happens.  This code is referred to
as the "vector service routine" or VSR.  You'll need some standard VSR
handler - normally these are slightly different for exceptions and interrupts.
In the case of the interrupt VSR, that code needs to save the interrupt
context (state) in a way that the kernel can make use of it.  Then the
interrupt VSR needs to determine what the actual interrupt is.  Sometimes
this is implicit (i.e. there could be a separate VSR for each interrupt)
or it the interrupt may need to be determined explicitly, e.g. reading
an interrupt-pending register.  In any case, you need to distill the
interrupt condition down to the selector - a one of N choice which is
mapped by the HAL_INTERRUPT_xxx defines.  This selector is then used
to look up the "interrupt service routine" (ISR) from a table.  This
table should be filled with "default_ISR" so that you can always handle
an interrupt, even if the program has not registered an ISR.  The interrupt
VSR then calls the appropriate ISR, via that table lookup.

I suspect that you've left out some of this in your initialization.
True, RedBoot normally takes care of this, but it's not necessary at
all.  The eCos application can (and should!) handle this if there is
no known "ROM monitor" supporting it (CYGSEM_HAL_USE_ROM_MONITOR is
not set/defined).

Just OOI, why can't you use RedBoot?  What's special about the bootloader
you have to use?

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