[ECOS] RedBoot necessary for porting ecos?

[ECOS] RedBoot necessary for porting ecos?

[Lukas Riezler]

Hello everyone!

First I have to say, that I'm quite new in microcontroller theme (and my english is not so good).
But I'm interested to get ecos run on my IAR-EvalBoard with CortexM3 (FM3).
I've read a lot of stuff but though I have some elementary questions:

- is it a requirement to work with RedBoot or is it also possible to port ecos without using RedBoot?
- I know that RedBoot is based on the ecos-HAL. Does it mean, if I port RedBoot to my target, that I can use later the same HAL-Code for ecos?

With kind regards,
Lukas R. 

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

Re: [ECOS] RedBoot necessary for porting ecos?

[Michael Jones]

Lukas,

I just went through the newbie problems, so I'll give some advice. I am not an expert, but I can tell you my thoughts based on my newbie experience.

RedBoot is basically a program that runs in the target device's flash, and loads an application over some serial device and then becomes a GDB server. In this case, RedBoot is an eCos application just like the application you are debugging.

The issues with using RedBoot are that the application being debugged can corrupt RedBoot, and RedBoot uses up memory that the application could use. I managed to get this to work on a K60, which is also CortexM3, but eventually I decided to use a JTAG debugger instead. I found the experience using JTAG much better. However, if you need to debug over an ethernet, RedBoot could do it.

For JTAG, find the openocd website and find it's pdf manual. In that manual is a list of supported JTAG devices. Then look in its script files to see if there is a script for your target, JTAG device, etc. Once you are satisfied, buy the JTAG device. I used one from Amontec. If you choose that, my blog post explains how to compile openocd and deal with drivers for the JTagKey (on linux).

Once openocd is running and connected to the target, GDB will debug using an IP address and port. Openocd is basically a GDB server that talks to JTAG.

You can also buy more expensive solutions based on ethernet that have GDB servers built in, but JTAG is a reasonable place to start.

I also use Eclipse, but that took a bit of effort. But I did post a blog on how I did it if you want to try it. Using Eclipse does not give you a task aware debugger, because neither does GDB. But you can eventually purchase a task aware debugger if you need one.

Mike

On Jan 10, 2013, at 5:55 PM, Lukas Riezler <lukas.riezler@gmx.net> wrote:

> Hello everyone!
> 
> First I have to say, that I'm quite new in microcontroller theme (and my english is not so good).
> But I'm interested to get ecos run on my IAR-EvalBoard with CortexM3 (FM3).
> I've read a lot of stuff but though I have some elementary questions:
> 
> - is it a requirement to work with RedBoot or is it also possible to port ecos without using RedBoot?
> - I know that RedBoot is based on the ecos-HAL. Does it mean, if I port RedBoot to my target, that I can use later the same HAL-Code for ecos?
> 
> With kind regards,
> Lukas R. 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 


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

Re: [ECOS] RedBoot necessary for porting ecos?

[Ilija Kocho]

Hi Mike and Lukas

Some comments on RedBoot.



On 11.01.2013 05:33, Michael Jones wrote:
> Lukas,
>
> I just went through the newbie problems, so I'll give some advice. I am not an expert, but I can tell you my thoughts based on my newbie experience.
>
> RedBoot is basically a program that runs in the target device's flash, and loads an application over some serial device and then becomes a GDB server. In this case, RedBoot is an eCos application just like the application you are debugging.
>
> The issues with using RedBoot are that the application being debugged can corrupt RedBoot, and RedBoot uses up memory that the application could use. I managed to get this to work on a K60, which is also CortexM3, but eventually I decided to use a JTAG debugger instead. I found the experience using JTAG much better. However, if you need to debug over an ethernet, RedBoot could do it.

RedBoot usability can be, indeed, limited by memory constrains. On
single chip systems with about 128KiB RAM it is possible to run and even
debug eCos application under RedBoot, but the application size will be
severely limited, because a part of RAM is allocated by RedBoot itself.

But there are other examples such as TWR-K70F120M, a system with 128MiB
external RAM where memory constrain is no issue and RedBoot debugging
runs smoothly. Even more, in order to load the application into external
memory you need initialization of DDRAM controller, which requires
initialised clock - a tedious work for JTAG. On the other hand when
running/debugging from RedBoot you start with initialised clock and
DDRAM controller.

Ilija


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

Re: [ECOS] RedBoot necessary for porting ecos?

[Ilija Kocho]

Hello Lukas

Actually RedBoot works on top of eCos so before eCos is ported you can't
run RedBoot.

Porting eCos to Cortex-M is relatively straight-forward (compared to
other architectures)  because some essential components are
implemented/defined on architectural level: interrupt controller,
systick, and general memory map.

In most cases, all you need to make in order get first eCos "Hello
World!" on serial line are:
   1. Clocking
   2. Diagnostic (HAL) serial support.

Once you have reached this point, you can start with device drivers
(serial, Ethernet, etc).

Regarding peripheral drivers: Before you start coding, do some research
through eCos source tree, it is possible that your chip has some
peripherals that are already supported for other architectures, then you
can probably use the same drivers (with or without some tweaks). Usually
the manufacturers combine same peripherals with different architectures.
For instance LPC17xx uses drivers from LPC2xxx.

Have fun!
Ilija

On 11.01.2013 01:55, Lukas Riezler wrote:
> Hello everyone!
>
> First I have to say, that I'm quite new in microcontroller theme (and my english is not so good).
> But I'm interested to get ecos run on my IAR-EvalBoard with CortexM3 (FM3).
> I've read a lot of stuff but though I have some elementary questions:
>
> - is it a requirement to work with RedBoot or is it also possible to port ecos without using RedBoot?
> - I know that RedBoot is based on the ecos-HAL. Does it mean, if I port RedBoot to my target, that I can use later the same HAL-Code for ecos?
>
> With kind regards,
> Lukas R. 
>


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

Re: [ECOS] RedBoot necessary for porting ecos?

[Michael Jones]

Lukas,

Ilija is correct, I was in a hurry and did not see the word "port" in your request. Therefore, my recommendations assumed your platform was supported.

Mike





On Jan 11, 2013, at 12:55 AM, Ilija Kocho <ilijak@siva.com.mk> wrote:

> Hello Lukas
> 
> Actually RedBoot works on top of eCos so before eCos is ported you can't
> run RedBoot.
> 
> Porting eCos to Cortex-M is relatively straight-forward (compared to
> other architectures)  because some essential components are
> implemented/defined on architectural level: interrupt controller,
> systick, and general memory map.
> 
> In most cases, all you need to make in order get first eCos "Hello
> World!" on serial line are:
>   1. Clocking
>   2. Diagnostic (HAL) serial support.
> 
> Once you have reached this point, you can start with device drivers
> (serial, Ethernet, etc).
> 
> Regarding peripheral drivers: Before you start coding, do some research
> through eCos source tree, it is possible that your chip has some
> peripherals that are already supported for other architectures, then you
> can probably use the same drivers (with or without some tweaks). Usually
> the manufacturers combine same peripherals with different architectures.
> For instance LPC17xx uses drivers from LPC2xxx.
> 
> Have fun!
> Ilija
> 
> On 11.01.2013 01:55, Lukas Riezler wrote:
>> Hello everyone!
>> 
>> First I have to say, that I'm quite new in microcontroller theme (and my english is not so good).
>> But I'm interested to get ecos run on my IAR-EvalBoard with CortexM3 (FM3).
>> I've read a lot of stuff but though I have some elementary questions:
>> 
>> - is it a requirement to work with RedBoot or is it also possible to port ecos without using RedBoot?
>> - I know that RedBoot is based on the ecos-HAL. Does it mean, if I port RedBoot to my target, that I can use later the same HAL-Code for ecos?
>> 
>> With kind regards,
>> Lukas R. 
>> 
> 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 


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

Re: [ECOS] RedBoot necessary for porting ecos?

[Ilija Kocho]

Lukas

On 13.01.2013 18:21, Lukas Riezler wrote:
> Hi Michael & Ilja!
>
> Thank you very much for your answers!
>
> So, if I'm right now, I need to port ecos before RedBoot is able to
> run...and I don't really need RedBoot for my intention. (?)
> Is there any suggestion which existing ecos-port for Cortex-M I should
> take to be my template?

Instead of suggesting I'll try to list specifics of existing ports, I
hope it will help you pick one that's closest to your system.

- STM32 is the initial Cortex-M port and probably was used as model for
others, contains wide span of memory configurations and probably most
complete driver set, including USB but lacks Ethernet (which you can
finf in Bugzilla), You already noticed STM32 support for external
interrupts.

- LM3S is nice example for a tiny system with very little memory.

- Kinetis, A2FXXX and LPC17XX have Ethernet.

- LPC 17xx is example for reusing drivers from other architecture (ARM
and Cortex-M are considered separate architectures in eCos)

- Kinetis and A2FXXX feature Consolidated Interrupt Priority Scheme,

- Kinetis features wide range of memory models including single chip and
systems with external memory. Single-chip memory models are generically
supported on variant level.

> > Porting eCos to Cortex-M is relatively straight-forward (compared to
> > other architectures)  because some essential components are
> > implemented/defined on architectural level: interrupt controller,
> > systick, and general memory map.
>
> If I take a look in the existing port for stm32, there is a also
> interrupt handling header-file in the variant-layer. But these are
> onley special interrupts for the peripherals - did I understand right?
Yes.
> Sorry for my "simple" questions - but I need to get basic knowledge
> and a solid overview :-)
>
>
I take it that you have read eCos docs. Additional information regarding
porting you shall find in Massa's book.
http://www.informit.com/content/images/0130354732/downloads/0130354732.pdf

HTH
Ilija

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