[ECOS] Memory Layout

[ECOS] Memory Layout

[james chen]

Hello,

       From memory layout, I find that Redboot( startup in ROM) and
Applications( startup in RAM ) both share the same memory address and size.
When I use GDB debugging applications through redboot's gdb stub. Will
redboot's memory  be cracked by Applications? Thanks in advance!

Regards,
james chen

RE: [ECOS] Memory Layout

[Gary Thomas]

On 18-Apr-2001 james chen wrote:
> Hello,
> 
>        From memory layout, I find that Redboot( startup in ROM) and
> Applications( startup in RAM ) both share the same memory address and size.
> When I use GDB debugging applications through redboot's gdb stub. Will
> redboot's memory  be cracked by Applications? Thanks in advance!

Memory used by RedBoot and "normal" applications do not overlap.  The MLT
files imply that they do, but this is because RedBoot is just a ROM 
application and the MLT setup is to allow for any application to use all
available resources.

In general, RedBoot uses a chunk of low memory (128k is typical) and
RAM based applications are set up to load just above that and use the
remaining memory.

Re: [ECOS] Memory Layout

[james chen]

>
> On 18-Apr-2001 james chen wrote:
> > Hello,
> >
> >        From memory layout, I find that Redboot( startup in ROM) and
> > Applications( startup in RAM ) both share the same memory address and
size.
> > When I use GDB debugging applications through redboot's gdb stub. Will
> > redboot's memory  be cracked by Applications? Thanks in advance!
>
> Memory used by RedBoot and "normal" applications do not overlap.  The MLT
> files imply that they do, but this is because RedBoot is just a ROM
> application and the MLT setup is to allow for any application to use all
> available resources.
>
> In general, RedBoot uses a chunk of low memory (128k is typical) and
> RAM based applications are set up to load just above that and use the
> remaining memory.
>
       After looking many ARM based platform in eCos. RAM based applications
leave different size memory( from 0x8000--0x20000), I think these memory is
used by RedBoot except vectors( sure?:-) ). Which size will I leave memory
for RedBoot, I am using my custom board based on ARM7TDMI.
       Another quesiton, when I release my applications and RedBoot will not
ship in. Will the memory used by redboot be lost( can't used by normal
applicationss). If then, how can I re-use it?

      Thanks in advance!

james chen

Re: [ECOS] Memory Layout

[Gary Thomas]

On 19-Apr-2001 james chen wrote:
>>
>> On 18-Apr-2001 james chen wrote:
>> > Hello,
>> >
>> >        From memory layout, I find that Redboot( startup in ROM) and
>> > Applications( startup in RAM ) both share the same memory address and
> size.
>> > When I use GDB debugging applications through redboot's gdb stub. Will
>> > redboot's memory  be cracked by Applications? Thanks in advance!
>>
>> Memory used by RedBoot and "normal" applications do not overlap.  The MLT
>> files imply that they do, but this is because RedBoot is just a ROM
>> application and the MLT setup is to allow for any application to use all
>> available resources.
>>
>> In general, RedBoot uses a chunk of low memory (128k is typical) and
>> RAM based applications are set up to load just above that and use the
>> remaining memory.
>>
>        After looking many ARM based platform in eCos. RAM based applications
> leave different size memory( from 0x8000--0x20000), I think these memory is
> used by RedBoot except vectors( sure?:-) ). Which size will I leave memory
> for RedBoot, I am using my custom board based on ARM7TDMI.
>        Another quesiton, when I release my applications and RedBoot will not
> ship in. Will the memory used by redboot be lost( can't used by normal
> applicationss). If then, how can I re-use it?

If your application is to run in RAM, then you should leave things as is.
There *will* be a monitor of some sort, even if it is not RedBoot, and it will
require memory to run.  We have carved out the space up to 0x20000 for this.

If your application runs in ROM, then there is no problem as it will have
access to all of RAM.

Question: if you are building a custom board and shipping a bundled application
with it, why would you _not_ want RedBoot, even in the final product?

Re: [ECOS] Memory Layout

[james chen]

Hi, Thomas:
>
> Question: if you are building a custom board and shipping a bundled
application
> with it, why would you _not_ want RedBoot, even in the final product?
>
     First, I don't know whether it will cost down the performance or not.

     Second, it will require extra flash memory to hold it.

     Third, I want to replace redboot with my hardware check code in final
product. when power on, it will run code to check hardware, if the hardware
is all OK, then load eCos to RAM from flash memory and run eCos
automatically. it seems RedBoot doesn't support it.

Regards,
James

Re: [ECOS] Memory Layout

[Gary Thomas]

On 20-Apr-2001 james chen wrote:
> Hi, Thomas:
>>
>> Question: if you are building a custom board and shipping a bundled
> application
>> with it, why would you _not_ want RedBoot, even in the final product?
>>
>      First, I don't know whether it will cost down the performance or not.

None.

> 
>      Second, it will require extra flash memory to hold it.

There would be this cost, but IMO it's minor, especially when weighed against
the flexibility and features which are available.  Things like:
  * Ability to debug code in the field (things _do_ break)
  * Ability to update code in FLASH - RedBoot, applications, etc
  * If your target has networking hardware, ability to connect via network
    to the debug/bootstrap environment.
  * Flexible & extensible control over the boot-time behaviour
  * Support for POST and BIST

> 
>      Third, I want to replace redboot with my hardware check code in final
> product. when power on, it will run code to check hardware, if the hardware
> is all OK, then load eCos to RAM from flash memory and run eCos
> automatically. it seems RedBoot doesn't support it.

This mode of operation is fully supported by RedBoot and already in place on
a number of targets.

[ECOS] Bootloaders (was Re: [ECOS] Memory Layout)

[Lewin A.R.W. Edwards]

> > with it, why would you _not_ want RedBoot, even in the final product?
>     Second, it will require extra flash memory to hold it.
>     Third, I want to replace redboot with my hardware check code in final
>product. when power on, it will run code to check hardware, if the hardware
>is all OK, then load eCos to RAM from flash memory and run eCos
>automatically. it seems RedBoot doesn't support it.

Good points. Our application is exactly the same. The flash device we are 
using has a 16Kword (32Kbyte) bootblock. In this 32K resides my power-on 
self-test code, manufacturing test code (LCD test patterns, serial/USB 
test, switch test, storage device test and so on) and also the code that 
can be used for re-flashing the remainder of the device from serial port or 
removable media if the power-on checksum test fails.

I think this is a very standard and normal way of implementing a 
field-upgradable embedded system. The constraint of the typical sizes of 
flash bootblocks (or in evenly-sectored devices, the sector size) is a 
*very* important consideration, and overall flash budget is a 
not-too-distant second. RedBoot for EDB7212 is >80K which is way too big 
for my bootblock, and anyway I want the bootloader in my board to contain a 
lot of custom functionality (the aforementioned manufacturing support code).

In a second case we are working with an absolutely bare-minimum size 
bootable OTP EPROM that loads the main application from cheap NAND flash or 
hard disk. Again, size of the bootloader, and custom functionality, is 
paramount.

I haven't had time to study in depth what has changed now that RH has moved 
towards RedBoot, but I agree with comments Grant Edwards made some months 
ago on the topic.

Essentially the thing we want to do is (once the app is debugged) compile 
for RAM startup, manually stuff the resultant binary together with the 
custom bootloader into a flash chip, and have the custom bootloader copy 
[decompress] from the ROM image into RAM.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"... a man who is endowed with real qualities of leadership will be tempted 
to refrain from taking part in political life; because [...] the situation 
does not call for a man who has a capacity for constructive statesmanship 
but rather for a man who is capable of bargaining for the favour of the 
majority. Thus the situation will appeal to small minds and will attract 
them accordingly."