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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |