This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RE: eCos/RedBoot on S3C44B0X


Hi,

      May I ask what is the memory layout for your modified vectors.S ?
Did you modify the mlt_arm_xxx_ram.h as well?

 thanks for the help

 Al

----- Original Message -----
From: "Jesper Kjeldsen" <JEK@penell.com>
To: "'llandre'" <r&d@wawnet.biz>; <gthomas@ecoscentric.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Tuesday, November 19, 2002 10:02 PM
Subject: [ECOS] RE: eCos/RedBoot on S3C44B0X


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


----------------------------------------------------------------------------
----


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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]