public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Stand-alone application working from RAM
@ 2000-07-19  9:29 Jurica Baricevic
  2000-07-19 23:48 ` Jesper Skov
  0 siblings, 1 reply; 4+ messages in thread
From: Jurica Baricevic @ 2000-07-19  9:29 UTC (permalink / raw)
  To: Ecos

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

Hi!

I have an custom MIPS board equipped with flash (at reset vector) and RAM
and here is boot procedure I would like to have:

1. What I have at power on:
-Small code for decompression of an eCos application from flash to RAM is
placed at the start of flash (reset vector)
-The compressed eCos application is ‘somewhere’ in the flash.

2. Code for decompression copies the eCos application to appropriate
location in RAM (of course, it is where the application is linked).

3. Decompression code starts application (jumps to its entry point).

4. The application works... :-)

In fact, I am worried only about point 4 since first three points are
working correctly. Namely, until now I worked with the application
configured for RAM linked at 0x80008000 and started/executed properly with
help of gdb (and gdb stubs in flash, of course). This configuration also had
CYGSEM_HAL_USE_ROM_MONITOR set to GDB_stubs. To get the described boot
procedure I disabled option CYGSEM_HAL_USE_ROM_MONITOR, recompiled
everything, but it does not work...
Of course, this is probably because I forgot to check exception vectors. My
application (eCos HAL) forces use of RAM exception vectors so I looked at
the HAL code for MIPS/my_platform and didnÂ’t find any procedure/macro for
copying exception vectors to appropriate RAM location (maybe I forgot to
write it?). So, now I am going to link my application to 0x80000000 (my
rom_vectors section is at the beginning of code) and hope that it will work.
Otherwise, I will have to go deeper into HAL...
Anyway, I wonder is there maybe anything else that I should care about?


Thanks and best regards,
Jura


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Stand-alone application working from RAM
  2000-07-19  9:29 [ECOS] Stand-alone application working from RAM Jurica Baricevic
@ 2000-07-19 23:48 ` Jesper Skov
  2000-07-20  7:52   ` Jurica Baricevic
  0 siblings, 1 reply; 4+ messages in thread
From: Jesper Skov @ 2000-07-19 23:48 UTC (permalink / raw)
  To: Jurica Baricevic; +Cc: Ecos

>>>>> "Jurica" == Jurica Baricevic <jura@INTESIS.hr> writes:

Jurica> forgot to write it?). So, now I am going to link my
Jurica> application to 0x80000000 (my rom_vectors section is at the
Jurica> beginning of code) and hope that it will work.  Otherwise, I
Jurica> will have to go deeper into HAL...  Anyway, I wonder is there
Jurica> maybe anything else that I should care about?

Yes, that might do it.

Alternatively have the hal_memc_init macro copy the vectors there. I
have the below (in a still not published platform HAL):

(from platform.inc)

#if !defined(CYG_HAL_STARTUP_RAM) || !defined(CYGSEM_HAL_USE_ROM_MONITOR)
        .macro  hal_memc_init
        <possibly init memory controllers here!>
#if !defined(CYGSEM_HAL_USE_ROM_MONITOR)
        // If we don't play nice with a ROM monitor, copy the required
        // vectors into the proper location.
        la      t0,0x80000000           # dest addr
        la      t1,utlb_vector          # source addr
        la      t3,utlb_vector_end      # end dest addr
1:      
        lw      v0,0(t1)                # get word
        addi    t1,t1,4
        sw      v0,0(t0)                # write word
        addi    t0,t0,4
        bne     t1,t3,1b
        nop

        la      t0,0x80000180           # dest addr
        la      t1,other_vector         # source addr
        la      t3,other_vector_end     # end dest addr
1:      
        lw      v0,0(t1)                # get word
        addi    t1,t1,4
        sw      v0,0(t0)                # write word
        addi    t0,t0,4
        bne     t1,t3,1b
        nop
#endif
        .endm
#define CYGPKG_HAL_MIPS_MEMC_DEFINED        
#endif


Jesper

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [ECOS] Stand-alone application working from RAM
  2000-07-19 23:48 ` Jesper Skov
@ 2000-07-20  7:52   ` Jurica Baricevic
  2000-07-20  9:00     ` Jesper Skov
  0 siblings, 1 reply; 4+ messages in thread
From: Jurica Baricevic @ 2000-07-20  7:52 UTC (permalink / raw)
  To: Jesper Skov; +Cc: Ecos

> >>>>> Jesper Skov wrote:
>
> Jurica> forgot to write it?). So, now I am going to link my
> Jurica> application to 0x80000000 (my rom_vectors section is at the
> Jurica> beginning of code) and hope that it will work.  Otherwise, I
> Jurica> will have to go deeper into HAL...  Anyway, I wonder is there
> Jurica> maybe anything else that I should care about?
>
> Yes, that might do it.
>
> Alternatively have the hal_memc_init macro copy the vectors there. I
> have the below (in a still not published platform HAL):
>
> (from platform.inc)
>
> #if !defined(CYG_HAL_STARTUP_RAM) || !defined(CYGSEM_HAL_USE_ROM_MONITOR)
>         .macro  hal_memc_init
>         <possibly init memory controllers here!>
> #if !defined(CYGSEM_HAL_USE_ROM_MONITOR)
>         // If we don't play nice with a ROM monitor, copy the required
>         // vectors into the proper location.
>         la      t0,0x80000000           # dest addr
>         la      t1,utlb_vector          # source addr
>         la      t3,utlb_vector_end      # end dest addr
> 1:
>         lw      v0,0(t1)                # get word
>         addi    t1,t1,4
>         sw      v0,0(t0)                # write word
>         addi    t0,t0,4
>         bne     t1,t3,1b
>         nop
>
>         la      t0,0x80000180           # dest addr
>         la      t1,other_vector         # source addr
>         la      t3,other_vector_end     # end dest addr
> 1:
>         lw      v0,0(t1)                # get word
>         addi    t1,t1,4
>         sw      v0,0(t0)                # write word
>         addi    t0,t0,4
>         bne     t1,t3,1b
>         nop
> #endif
>         .endm
> #define CYGPKG_HAL_MIPS_MEMC_DEFINED
> #endif
>


Thank you for the code - it helped me a lot since I didn't have to write it
by myself :-).
Only thing I had to modify is destination address of 'other_vector' because
my MIPS R3041 has general exception vector at 0x80000080.
Nevertheless, I am worried about using cached kernel segment in
'hal_memc_init' because cache is not yet initialized ('hal_cache_init' is
called latter).

Best regards,
Jura


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Stand-alone application working from RAM
  2000-07-20  7:52   ` Jurica Baricevic
@ 2000-07-20  9:00     ` Jesper Skov
  0 siblings, 0 replies; 4+ messages in thread
From: Jesper Skov @ 2000-07-20  9:00 UTC (permalink / raw)
  To: Jurica Baricevic; +Cc: Ecos

>>>>> "Jurica" == Jurica Baricevic <jura@INTESIS.hr> writes:

Jurica> Thank you for the code - it helped me a lot since I didn't
Jurica> have to write it by myself :-).  Only thing I had to modify is
Jurica> destination address of 'other_vector' because my MIPS R3041
Jurica> has general exception vector at 0x80000080.  Nevertheless, I
Jurica> am worried about using cached kernel segment in
Jurica> 'hal_memc_init' because cache is not yet initialized
Jurica> ('hal_cache_init' is called latter).

Good point. The code should be moved to hal_mon_init.

Jesper


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-07-20  9:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-19  9:29 [ECOS] Stand-alone application working from RAM Jurica Baricevic
2000-07-19 23:48 ` Jesper Skov
2000-07-20  7:52   ` Jurica Baricevic
2000-07-20  9:00     ` Jesper Skov

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