[ECOS] PID ROM and eCos

[ECOS] PID ROM and eCos

[Dave Airlie]

Hi,
	I've got an application that uses serial, and I seem to be getting
serial overruns at 38400 on the serial port on the PID but only when I'm
running eCos out of the FLASH on board, the flash is 16-bit so is probably
slow to load stuff from, 

I've enabled serial FIFOs and set the level to 8 bytes and fixed the
serial driver so this works :-), (patch attached),

So my question is how feasible is to build eCos for RAM, and build a small
routine to link against it that boots up and copies all of eCos into RAM
and starts it ?

Could I use something like redboot or anything like that for this purpose
or is a platform where this has been done ..

Regards,
	Dave.

-- 
      David Airlie, Software Engineer, Parthus Technologies plc.,
       Mary Rosse Centre, National Tech Park, Limerick, Ireland.
   t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com

Re: [ECOS] PID ROM and eCos

[Andrew Lunn]

> Hi,
> 	I've got an application that uses serial, and I seem to be getting
> serial overruns at 38400 on the serial port on the PID but only when I'm
> running eCos out of the FLASH on board, the flash is 16-bit so is probably
> slow to load stuff from, 
> 
> So my question is how feasible is to build eCos for RAM, and build a small
> routine to link against it that boots up and copies all of eCos into RAM
> and starts it ?

Some platforms support ROMRAM. The HAL copies itself out of ROM into
RAM and then executes. I'd suggest you find such a HAL and use it as a
template to make your HAL do the same.

        Andrew

Re: [ECOS] PID ROM and eCos

[Grant Edwards]

On Wed, Jan 24, 2001 at 03:15:20PM +0000, Dave Airlie wrote:

> So my question is how feasible is to build eCos for RAM, and
> build a small routine to link against it that boots up and
> copies all of eCos into RAM and starts it ?

Piece of cake.

> Could I use something like redboot or anything like that for
> this purpose or is a platform where this has been done ..

Sure, RedBoot would work great, but's it's overkill if all you
want is to copy a single fixed image to RAM and execute it.
That only takes 10-15 lines of assembly language.

You'll probably also want to re-map memory so that RAM is at
address 0 instead of ROM (if possible). You can run eCos from
RAM with ROM at 0, but it's a pain since you'll have to hack up
the vectors.S file in hal/arm/arch/.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] PID ROM and eCos

[Gary Thomas]

On 24-Jan-2001 Grant Edwards wrote:
> On Wed, Jan 24, 2001 at 03:15:20PM +0000, Dave Airlie wrote:
> 
>> So my question is how feasible is to build eCos for RAM, and
>> build a small routine to link against it that boots up and
>> copies all of eCos into RAM and starts it ?
> 
> Piece of cake.
> 
>> Could I use something like redboot or anything like that for
>> this purpose or is a platform where this has been done ..
> 
> Sure, RedBoot would work great, but's it's overkill if all you
> want is to copy a single fixed image to RAM and execute it.
> That only takes 10-15 lines of assembly language.
> 
> You'll probably also want to re-map memory so that RAM is at
> address 0 instead of ROM (if possible). You can run eCos from
> RAM with ROM at 0, but it's a pain since you'll have to hack up
> the vectors.S file in hal/arm/arch/.

Look at the startup code for the Cirrus Logic EDB7xxx boards.  They
support this configuration where the image in ROM (FLASH or whatever)
is linked at an address different from where they are stored.  If
this case is detected, the ROM code simply gets copied to RAM at
startup time.  Look in the file:
  hal/arm/edb7xxx/current/include/hal_platform_setup.h

Re: [ECOS] PID ROM and eCos

[Jonathan Larmour]

Gary Thomas wrote:
> 
> Look at the startup code for the Cirrus Logic EDB7xxx boards.  They
> support this configuration where the image in ROM (FLASH or whatever)
> is linked at an address different from where they are stored.  If
> this case is detected, the ROM code simply gets copied to RAM at
> startup time.  Look in the file:
>   hal/arm/edb7xxx/current/include/hal_platform_setup.h

Why was it done this way, and not with a more explicit ROMRAM startup type?
If you have a separate startup type it is more under user control.

Anyway, you can also refer to the way the mips vrc4373 or sh edk7708 do it,
which use an explicit ROMRAM startup.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] PID ROM and eCos

[Dave Airlie]

> > this case is detected, the ROM code simply gets copied to RAM at
> > startup time.  Look in the file:
> >   hal/arm/edb7xxx/current/include/hal_platform_setup.h
> 
> Why was it done this way, and not with a more explicit ROMRAM startup type?
> If you have a separate startup type it is more under user control.
> 
> Anyway, you can also refer to the way the mips vrc4373 or sh edk7708 do it,
> which use an explicit ROMRAM startup.

This is what I am currently looking at all right... I might even submit
some patches if I can figure the bloody thing out :-)

Dave

> 
> Jifl
> 

-- 
      David Airlie, Software Engineer, Parthus Technologies plc.,
       Mary Rosse Centre, National Tech Park, Limerick, Ireland.
   t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com

Re: [ECOS] PID ROM and eCos

[Gary Thomas]

On 24-Jan-2001 Jonathan Larmour wrote:
> Gary Thomas wrote:
>> 
>> Look at the startup code for the Cirrus Logic EDB7xxx boards.  They
>> support this configuration where the image in ROM (FLASH or whatever)
>> is linked at an address different from where they are stored.  If
>> this case is detected, the ROM code simply gets copied to RAM at
>> startup time.  Look in the file:
>>   hal/arm/edb7xxx/current/include/hal_platform_setup.h
> 
> Why was it done this way, and not with a more explicit ROMRAM startup type?
> If you have a separate startup type it is more under user control.
> 

It has been this way for more than 18 months - long before the new CDL and
the tools to make adding new/different startup types simple.  Also, I only
did it in a moment since running some code on that platform did not perform
adequately from FLASH, but would from RAM.

> Anyway, you can also refer to the way the mips vrc4373 or sh edk7708 do it,
> which use an explicit ROMRAM startup.

And all the trappings [read details and troubles] that go with it.

Re: [ECOS] PID ROM and eCos

[Jonathan Larmour]

Gary Thomas wrote:
> 
> On 24-Jan-2001 Jonathan Larmour wrote:
> > Gary Thomas wrote:
> >>
> >> Look at the startup code for the Cirrus Logic EDB7xxx boards.  They
> >> support this configuration where the image in ROM (FLASH or whatever)
> >> is linked at an address different from where they are stored.  If
> >> this case is detected, the ROM code simply gets copied to RAM at
> >> startup time.  Look in the file:
> >>   hal/arm/edb7xxx/current/include/hal_platform_setup.h
> >
> > Why was it done this way, and not with a more explicit ROMRAM startup type?
> > If you have a separate startup type it is more under user control.
> >
> 
> It has been this way for more than 18 months - long before the new CDL and
> the tools to make adding new/different startup types simple.  Also, I only
> did it in a moment since running some code on that platform did not perform
> adequately from FLASH, but would from RAM.

Good answer :-).
 
> > Anyway, you can also refer to the way the mips vrc4373 or sh edk7708 do it,
> > which use an explicit ROMRAM startup.
> 
> And all the trappings [read details and troubles] that go with it.

Firstly, it should be down to the user on whether they want to copy to RAM.
But also I've done other work (Gary can probably guess what) this way and
it was no real trouble. The only problem is determining real addresses
before relocation, but that's easy too. With the ARM you could even use MMU
tricks, but I wouldn't recommend it :).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] PID ROM and eCos

[Dave Airlie]

> Firstly, it should be down to the user on whether they want to copy to RAM.
> But also I've done other work (Gary can probably guess what) this way and
> it was no real trouble. The only problem is determining real addresses
> before relocation, but that's easy too. With the ARM you could even use MMU
> tricks, but I wouldn't recommend it :).

I'm hitting a small snag which may not be a snag but is catching me none
the less,

The PID flash programmer seems to use a trick to get the image for the
FLASH into memory, after generating the ROM image up at 0x4000000, objcopy
is used to relocate it down to 0x60000, and this loaded to the PID via
angel, the flash programmer is then downloaded and executed at 0x8000, and
it writes the stuff between 0x60000 and 0x80000 into the FLASH at
0x4000000

This seems to be working okay for the ROM image, but not for me, I
relocate my image from 0x8000 to 0x60000, program it in and the first
thing I do in reset_vector after the RAM enable is copy it down to 0x8000, 

Now I've just realised I'm not then jumping down to the code in RAM, but I
can't see where the other code does this, from the edbxxxx stuff..

Dave.

-- 
      David Airlie, Software Engineer, Parthus Technologies plc.,
       Mary Rosse Centre, National Tech Park, Limerick, Ireland.
   t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com