[ECOS] How to create a new platform?

[ECOS] How to create a new platform?

[Grant Edwards]

I'm currently using the ARM-PID platform to build eCos for
custom target hardware, but this requires that I modify by hand
a bunch of files like target.ld, hal_platform_setup.h,
hal_platform_ints.h, pid_misc.c, hal_diag.c, etc.

This is a pain, since some of these files sometimes get
overwritten when I do a "make", and then I have to fix them
again.

I've been looking for documentation on how to create a new
platform so that my customized files don't get blown away by
the make process.  So far I haven't found anything.  Can
anybody lend me a clue?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] How to create a new platform?

[Jesper Skov]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> I'm currently using the ARM-PID platform to build eCos for
Grant> custom target hardware, but this requires that I modify by hand
Grant> a bunch of files like target.ld, hal_platform_setup.h,
Grant> hal_platform_ints.h, pid_misc.c, hal_diag.c, etc.

Grant> This is a pain, since some of these files sometimes get
Grant> overwritten when I do a "make", and then I have to fix them
Grant> again.

Grant> I've been looking for documentation on how to create a new
Grant> platform so that my customized files don't get blown away by
Grant> the make process.  So far I haven't found anything.  Can
Grant> anybody lend me a clue?

See:

http://sourceware.cygnus.com/ecos/docs-1.2.1/ref/ecos-ref/kernel-porting-notes.html

It's crap though (I'm allowed to say that. I wrote it :)... And we
know.  We want to make it better, but there never seems to be enough
time to do stuff like this.



Basically, copy an existing platform directory and make your
adjustments in the new directory. Then edit the top-level files
packages and targets accordingly.

So, clone the pid HAL:

 cd hal/arm
 cp -a pid <platformname>

Edit the files.  Then look in the top-level files and search for
PID. Clone/edit entries appropriately. It should be reasonable obvious
what needs changing.


Jesper

 

Re: [ECOS] How to create a new platform?

[Grant Edwards]

On Wed, Feb 16, 2000 at 05:53:41PM +0100, Jesper Skov wrote:
> >>>>> "Grant" == Grant Edwards <grante@visi.com> writes:
> 
> Grant> I've been looking for documentation on how to create a new
> Grant> platform so that my customized files don't get blown away by
> Grant> the make process.  So far I haven't found anything.  Can
> Grant> anybody lend me a clue?
> 
> See:
> 
> http://sourceware.cygnus.com/ecos/docs-1.2.1/ref/ecos-ref/kernel-porting-notes.html

Ah, that's what I was looking for.

> It's crap though (I'm allowed to say that. I wrote it :)... And we
> know.  We want to make it better, but there never seems to be enough
> time to do stuff like this.

I know, I know.

> Basically, copy an existing platform directory and make your
> adjustments in the new directory. Then edit the top-level files
> packages and targets accordingly.

I've got that mostly done.  It took me a little while to figure
out that I needed to add my new target to both the targets and
packages files.

Next, I need to modify the linker command file for my target to
add "glue" sections and add some "provides" to set the
addresses of periperals.  I can do this by adding lines to
mlt_arm_mustang_ram.mlt or I can delete the .mlt file and edit
the .ldi file directly -- right?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] How to create a new platform?

[Jesper Skov]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

>> Basically, copy an existing platform directory and make your
>> adjustments in the new directory. Then edit the top-level files
>> packages and targets accordingly.

Grant> I've got that mostly done.  It took me a little while to figure
Grant> out that I needed to add my new target to both the targets and
Grant> packages files.

Grant> Next, I need to modify the linker command file for my target to
Grant> add "glue" sections and add some "provides" to set the
Grant> addresses of periperals.  I can do this by adding lines to
Grant> mlt_arm_mustang_ram.mlt or I can delete the .mlt file and edit
Grant> the .ldi file directly -- right?

Two answers:
 1) Addresses of peripherals should be defined in header files, not in
    the linker script.

 2) mlt is the master file. You should create new files using the
    ConfigTool's memory map editor. It will also generate the .h and
    .ldi files for you.

Jesper

Re: [ECOS] How to create a new platform?

[Grant Edwards]

On Thu, Feb 17, 2000 at 09:04:18AM +0100, Jesper Skov wrote:

> Grant> Next, I need to modify the linker command file for my target to
> Grant> add "glue" sections and add some "provides" to set the
> Grant> addresses of peripherals.  I can do this by adding lines to
> Grant> mlt_arm_mustang_ram.mlt or I can delete the .mlt file and edit
> Grant> the .ldi file directly -- right?
> 
> Two answers:
>  1) Addresses of peripherals should be defined in header files, not in
>     the linker script.

I guess I've always operated under the philosophy that it is
the linker's job to determine where things are located in the
memory map.  It seems a bit inconsistent to use the linker
command file to determine the location of most of code and data
objects but then hard-wire the addresses of a few of them into
the source code.

If I've got two targets that differ only in their memory maps,
I generally want those differences to happen at the linking
stage, not at the compiling stage.

BTW, how do you force a variable to a specified address in a
header file?  I can't find an appropriate __attribute__.  For
example, I have a structure named uart0, and I want it located
at address 0x3604000.  In the linker command file this is
accomplished simply enough with an assignment statement:

In C source:

   extern UartType uart0;
   
   [...]
   
   if (uart0.status & UartRxDataReady)
      c = uart0.rxData;

In the linker command file:

   Uart0 =0x3604000;


Do you prefer the "declare a pointer and then type-cast a
hard-wired constant value" method?

   const UartType Uart0Ptr = (UartType*) 0x3604000;

   if (uart0Ptr->status & UartRxDataReady)
      c = uart0Ptr->.rxData;

For most of the processors I've used in the past, the pointer
dereferencing generates larger code.  [Once you've spend a
couple weeks trying to trim a couple hundred bytes from a
binary, you have a hard time breaking the habit of not using
memory that you don't have to.] 

The previous example allows the compiler to generate references
to absolute locations in memory, which on some processors
results in smaller and faster code.

Of course on some processors (like the ARM) everything is done
via pointers anyway since there is no direct addressing mode --
and if you write functions that take pointers to the device in
question, you end up with the same code either way.

>  2) mlt is the master file. You should create new files using the
>     ConfigTool's memory map editor. It will also generate the .h and
>     .ldi files for you.

What is ConfigTool?  Is that something that runs under NT?  I
tried editing the mlt file and then re-running the tcl
configuration script, but that didn't seem to have any effect.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] How to create a new platform?

[Jesper Skov]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> I guess I've always operated under the philosophy that it is
Grant> the linker's job to determine where things are located in the
Grant> memory map.  It seems a bit inconsistent to use the linker
Grant> command file to determine the location of most of code and data
Grant> objects but then hard-wire the addresses of a few of them into
Grant> the source code.

I guess there are arguments for and against. I don't really have the
experience to tell which is better - as long as it's a conscious
choice on your part, I'm happy.  Some of the other eCos engineers may
know better, though :)

Grant> Do you prefer the "declare a pointer and then type-cast a
Grant> hard-wired constant value" method?

Grant>    const UartType Uart0Ptr = (UartType*) 0x3604000;

This is the method I'm familiar with. But I'm just a dumb kid :)

>> 2) mlt is the master file. You should create new files using the
>> ConfigTool's memory map editor. It will also generate the .h and
>> .ldi files for you.

Grant> What is ConfigTool?  Is that something that runs under NT?  I
Grant> tried editing the mlt file and then re-running the tcl
Grant> configuration script, but that didn't seem to have any effect.

Yup. Nasty Windows thingie. If you edit by hand, you only have to
change .h and .ldi. But if you ever want to contribute the work back
to Red Hat you'll want someone to make the proper .mlt file as
well.

The ConfigTool uses .mlt as the savefile, generating .h and .ldi files
as required. The .mlt file is not used by the target code.

Jesper

Re: [ECOS] How to create a new platform?

[Jonathan Larmour]

Jesper Skov wrote:
> 
>  2) mlt is the master file. You should create new files using the
>     ConfigTool's memory map editor. It will also generate the .h and
>     .ldi files for you.

That's the wrong way round! The .ldi is the master file, and the .h and .mlt
files are generated.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] How to create a new platform?

[Grant Edwards]

On Thu, Feb 17, 2000 at 05:52:58PM +0100, Jesper Skov wrote:

> Grant> Do you prefer the "declare a pointer and then type-cast a
> Grant> hard-wired constant value" method?
> 
> Grant>    const UartType Uart0Ptr = (UartType*) 0x3604000;
> 
> This is the method I'm familiar with. But I'm just a dumb kid :)

That seems to be the method used by all of the other device
drivers, so making mine different would just be confusing.

> >> 2) mlt is the master file. You should create new files using the
> >> ConfigTool's memory map editor. It will also generate the .h and
> >> .ldi files for you.
> 
> Grant> What is ConfigTool?  Is that something that runs under NT?  I
> Grant> tried editing the mlt file and then re-running the tcl
> Grant> configuration script, but that didn't seem to have any effect.
> 
> Yup. Nasty Windows thingie. If you edit by hand, you only have
> to change .h and .ldi. But if you ever want to contribute the
> work back to Red Hat you'll want someone to make the proper
> .mlt file as well.

There are actually two platforms I'm using.  One is a Samsung
eval board, and I'll probably contribute that one.  The other
is custom hardware, and won't be of much use to anybody else.

> The ConfigTool uses .mlt as the savefile, generating .h and
> .ldi files as required. The .mlt file is not used by the target
> code.

So the tcl config script doesn't translage .mlt files into .ldi
and .h files?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] How to create a new platform?

[Jonathan Larmour]

Jonathan Larmour wrote:
> 
> Jesper Skov wrote:
> >
> >  2) mlt is the master file. You should create new files using the
> >     ConfigTool's memory map editor. It will also generate the .h and
> >     .ldi files for you.
> 
> That's the wrong way round! The .ldi is the master file, and the .h and .mlt
> files are generated.

Oh no it's not. <fx: goes away and cries in corner>

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] How to create a new platform?

[Jonathan Larmour]

Jesper Skov wrote:
> Grant> Do you prefer the "declare a pointer and then type-cast a
> Grant> hard-wired constant value" method?
> 
> Grant>    const UartType Uart0Ptr = (UartType*) 0x3604000;
> 
> This is the method I'm familiar with. But I'm just a dumb kid :)

If this is actually a define, ie. #define UARTBASE ((UartType *)0x3604000)
then it would be very bad if gcc could not optimize "UARTBASE->foo" to be a
direct access to a single memory address, rather than having to do the
addition.

I'm not sure I could guarantee that for "const"s though.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] How to create a new platform?

[Grant Edwards]

> > Grant> Do you prefer the "declare a pointer and then type-cast a
> > Grant> hard-wired constant value" method?
> > 
> > Grant>    const UartType Uart0Ptr = (UartType*) 0x3604000;
> > 
> > This is the method I'm familiar with. But I'm just a dumb kid :)
> 
> If this is actually a define, ie. #define UARTBASE ((UartType *)0x3604000)
> then it would be very bad if gcc could not optimize "UARTBASE->foo" to be a
> direct access to a single memory address, rather than having to do the
> addition.

Most compilers will do that (and I'm pretty sure gcc does).
But since the ARM can't directly access memory in a general
way, the code generated ends up being pointer operations
anyway, so for me I think it turns out to be a moot point.

> I'm not sure I could guarantee that for "const"s though.

IIRC, the code generate for the ARM for the following cases is
pretty much identical

  x = *((int*)(0x123456));

  const int *p = (int*)0x123456;
  x = *p;

Since there is no direct memory addressing in the ARM, the
former case has to generate a const pointer and put it in
memory somewhere close to the instruction which needs it (where
it can be read using an offset from either the frame pointer or
the program counter), and then generates code to read and
dereference the pointer.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] How to create a new platform?

[Jonathan Larmour]

Grant Edwards wrote:
> Jifl wrote:
> > If this is actually a define, ie. #define UARTBASE ((UartType *)0x3604000)
> > then it would be very bad if gcc could not optimize "UARTBASE->foo" to be a
> > direct access to a single memory address, rather than having to do the
> > addition.
> 
> Most compilers will do that (and I'm pretty sure gcc does).
> But since the ARM can't directly access memory in a general
> way, the code generated ends up being pointer operations
> anyway, so for me I think it turns out to be a moot point.

But surely this is no worse than specifying it in a linker script? i.e. when
you said:

>For most of the processors I've used in the past, the pointer
>dereferencing generates larger code.  [Once you've spend a
>couple weeks trying to trim a couple hundred bytes from a
>binary, you have a hard time breaking the habit of not using
>memory that you don't have to.] 

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] How to create a new platform?

[Grant Edwards]

On Thu, Feb 17, 2000 at 06:35:44PM +0000, Jonathan Larmour wrote:

> > > If this is actually a define, ie. #define UARTBASE ((UartType *)0x3604000)
> > > then it would be very bad if gcc could not optimize "UARTBASE->foo" to be a
> > > direct access to a single memory address, rather than having to do the
> > > addition.
> > 
> > Most compilers will do that (and I'm pretty sure gcc does).
> > But since the ARM can't directly access memory in a general
> > way, the code generated ends up being pointer operations
> > anyway, so for me I think it turns out to be a moot point.
> 
> But surely this is no worse than specifying it in a linker script? 

You're right.  Using ((UartType*)0x3604000)->foo should
generate the same code as the extern/linker-command method. I
was thinking of the case where a pointer variable is declared
and initialized with the constant value.

Back when I first started doing embedded stuff using a HLL it
was in Pascal, and the extern/linker-command method was easier
than convincing the compiler to access arbitrary addresses in
memory.  It also made writing test stubs/drivers much easier,
since you didn't have to re-compile the module, just link to
the test harness. I've been doing it that way ever since.

-- 
Grant Edwards
grante@visi.com