[ECOS] RE: eCos/RedBoot on S3C44B0X

[Jesper Kjeldsen <JEK at penell dot com>]

Hi Andrea and Gary.

The two attached files needs to be copied to dir hal/arm/arch/current/src

The file hal_misc.c is only modified in line 99 from
static unsigned long *hardware_vectors = (unsigned long *)0x20;
to
static unsigned long *hardware_vectors = (unsigned long *)hal_vsr_table;

to Andrea: We are using both JTAG and rom monitor debugging. The only
requirement is that section
"fixed_vectors" is placed at the beginning of RAM with 0x20 bytes in front
of it. These bytes are 
used for the hardware vectors when "fixed_vectors" are placed at 0x00000020.

to Gary: The following comes from our discussion of subject [ECOS]ROM and
hardware vectors for ARM.
As you can se I have now made some small changes to vectors.S. The
modifications I have done
seems to work OK ! I am still testing on this but so far I have not run into
serious problems. Gary
will you please comment on this change ?



-----Original Message-----
From: llandre [mailto:r&d@wawnet.biz]
Sent: 19. november 2002 14:26
To: Jesper Kjeldsen
Subject: RE: eCos/RedBoot on S3C44B0X


Hi Jesper,

thanks for your answer.



>         Hi Andrea.
>
>         We have also altered vectors.s but not very much. We have added a
>jump to a location not far from the int-vectors that will look up the
>address in section "fixed vectors" and then jump to that address. As you
may
>have seen the original vectors.s have all addresses hard-coded. We have
also
>altered this so that "hal_vsr_table" is initialised even if it is not
placed
>at 0x00000020. This way section vectors can be placed anywhere ex.
>0x00000020, x03000020 or 0x0c000020 even if the hardware reset vectors is
>placed at 0x00000000. As there is the Hardware remapping penalty with the
>original way to do it, there is also a penalty with our way.
>
>         1. We use a few (very little) more asm-instructions to do it.
>         2. We do still not run the CPU interrupt system in vectored mode.
We
>use non-vectored mode. (slower).
>         3. We can't use interrupts if the memory located at 0x00000000 has
>not been programmed or pre-loaded with code. This is only a problem the
>first time a new hardware is started up. We have flash located at
>0x00000000. A RAM version of serial redboot do not use interrupts so we can
>still use it to program a ROM version of redboot into the flash. So soon as
>we have this code in the flash the interrupt system is in place.
>
>         The good thing about this way to do it is that it will still work
on
>existing platforms.

The solution you adopted is very interesting. What about the memory layout? 
Did you write a completely new one or you used one from existing ports?
Do you use also the JTAG interface to debug your code or you work 
exclusively with the RebBoot?


>         We are not done with our port. At the moment I'm working on my
>serial driver. I have my wallclock and watchdog driver but I still need
>drivers for IO, ADC, LCD ect. Do you have any of these drivers that we can
>use. ???

We derived our serial driver from EB40 port (If you wish, I'll send you the 
source code). Unfortunately we don't have drivers for the other 
peripherals, yet.


>         I can send you out vectors.s file if you like our way of doing
>things.

I would appreciate it very much.


Thanks again and best regards.




> > -----Original Message-----
> > From: llandre [SMTP:r&d@wawnet.biz]
> > Sent: 8. november 2002 13:11
> > To:   Erik Aagaard Knudsen
> > Subject:      eCos/RedBoot on S3C44B0X
> >
> > Hi Erik,
> >
> > I've just read a your message in the ecos-discuss mailing list (17 Oct
> > 2002
> > ) about the port of RebBoot on the S3C44B0X microcontroller.
> > Since I'm working with eCos on the same processor, I thought we could
> > share
> > some information to help each other.
> > We completed the port of eCos to our board and we are able to build
> > standalone ROMRAM applications that work without RedBoot. We deeply
> > changed
> > the vectors.S file to manage the unability to perform the remap.
> > We use the JTAG port to debug the code and so, so far, we did not need
any
> >
> > ROM monitor.
> > Now we would add the RedBoot as boot loader to manage the upgrade of
> > application firmware through serial and Ethernet links (we do not
require
> > the ROM monitor functionalities). I'm analyzing its source code but,
> > because the remap problem, I think the port will be quite complicated. I
> > sketched a possible solution but I still working on it.
> > What's your opinion about that?
> > Have you already found a solution?
> >
> > Thanks in advance and best regards.
> >
> >
> >
> > Andrea

Attachment: vectors.S
Description: Binary data

Attachment: hal_misc.c
Description: Binary data

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